DASH SFTP: Directory Guidance for the Oracle Integration Cloud (OIC) SFTP Server

General Information:

We decided that UT will use our existing MFT (File transfer) software for SFTP needs for the DASH project. Existing UT users will already know this as the https://uttransfer.admin.utk.edu server. We have an alias to use for DASH that is more Oracle specific, but the software/system is the same. The alias URL is https://transfer.oracle.tennessee.edu. The integrated OIC SFTP server can be used for individual demos/testing/etc., but all “real” interfaces will utilize the MFT for interfacing.

All “real” interface directories will need to be requested much like they are currently for IRIS. This is by design to ensure security is carefully maintained.

Directory Names:

  • Interface Name: This is the directory that should match the interface name inside of OIC. This will be a one-to-one or one-to-many mapping based on the criteria listed below.
  • Naming Guidelines/Instructions: Before requesting a new directory, the requester should make sure the name follows the pattern and template set forth in the DASH OIC Name Creation Spreadsheet.xls file stored on the Developers channel under the DASH Integrations Team in Microsoft Teams. If you do not have access to this file, please send a request to DASH Support. Full details are in the spreadsheet, but in summary, the directory should typically follow the following template: Module_Verb_Source_Target_Campus (if necessary).
  • Default Sub-Directories:
    • The following sub-directories are included by default. There is no need to specify this level in the directory name:
      • in – This is for data coming into the Fusion application (DASH).
      • out – This is for data coming out of the Fusion application (DASH).
      • transient – This is for processed or completed interface files (probably mainly from the “in” directory). Once an interface program processes an incoming file, it should be moved to this directory. The file will be retained here for a maximum of 180 days. For any interface file that must be retained longer, a request must be made and approved to archive the data off to another location.
      • errors – This is for interface files that had errors during their processing.

Directory Structure Principals:

When OIC code either processes incoming data files, or outgoing data files, those files will live in a corresponding interface directory scoped to the target audience. This means if a single incoming or outgoing program is reading or generating data for multiple audiences, it should read/write the different files or version of the file to/from separate directories. If a single interface generates 3 different files, but they are for the same audience AND purpose, they can all reside in the single set of directories named after the interface. The guiding question is, “Are these files to be used in tandem and/or are the files directly related? Or, are these for distinct and different purposes and/or audiences?” The goal of this approach is to allow more granular security on files coming into and out of DASH than we had in IRIS. All vendor (or external to UT) accounts are discreet directories.

Directory Folder Examples:

  • ERP:
    • AP_UPSuppliers_PaymentWorks_ERP 
      • Updates supplier file in ERP
    • AP_SYSuppliers_ERP_PaymentWorks
      • Syncs supplier file in PaymentWorks
  • HCM:
    • PY_GTHSA_Deductions_HCM_Optum 
      • Extracts HSA deductions from HCM and sends to Optum
    • HR_CREmpExtract_OIC_SFTP
      • Creates an output file from the staging database and writes it to the SFTP location
      • Note: in this example, this is the final step of a three-step interface; however, we only need a directory for the step that writes a file to the SFTP server. In addition, there is no reason to include "_Step03" on the end of the directory.

Additional Comments:

In order to prevent accidental overwriting of a file in a different environment, each OIC instance will not be able to see the directories for any other environment. In OIC, the directories will be as listed above exactly; there will be no environmental component needed as part of the directory location, (e.g., DEV1, PROD, etc.).

For users logging into the SFTP server (including external interfaces and vendors), they will see one additional level at the top which matches the environment. For instance, an SFTP log in would show (using the first example above):

  • /dev1/AP_UPSuppliers_PaymentWorks_ERP/(in|out|transient|errors)
  • /prod/AP_UPSuppliers_PaymentWorks_ERP/(in|out|transient|errors)

However, when writing an interface in the DEV1 OIC environment, the directory is simply: 

  • /AP_UPSuppliers_PaymentWorks_ERP/(in|out|transient|errors)

When the interface is moved into the PROD OIC environment, it will be the same path:

  • /AP_UPSuppliers_PaymentWorks_ERP/(in|out|transient|errors)

This will allow the OIC code to be 100% portable without modification. It will also prevent accidental interaction with other environments.

Also, remember that the SFTP area is not intended for long-term storage of any data. It is a transfer mechanism. This is why we changed the “processed” directory name to “transient”. Long-term storage requirements for any interface file must be expressly requested and approved by the DASH leads, to be stored long-term in a location outside of the SFTP server.

Print Article