Inhaltsverzeichnis

Managed File Transfer

General

By Managed File Transfer (short MFT) we understand the file transfer from point A to point B.
Here the communication or exchange can consist of any combination of HDD and FTP.
So all permutations of the two variants:

Note: In addition, eBiss specific methods can be used here, so that a partner recognition based on the paths1) and a partner specific2) forwarding is possible without having to look into the files3).

A possible solution is based on the following components

  1. For each source path - target path combination4) there is a new tradingpartner with corresponding communication addresses of the type file system, consisting of the directory names.
    1. The target path is the default address for the send channel („MFT.Send“) and
    2. the source_path for partner detection at the receive channel5)
  2. To collect these partners in a group, you create a corresponding template partner, for which the outgoing communication channel is stored.
  3. For the files there is a mailbox6) specially created for this purpose, in which all files end up:
    1. the messages that cannot be forwarded are directly discarded in a part of a job7),
    2. all others are marked as „send“ by the send channel („MFT.Send“).
  4. The receive channel8), which also carries out partner detection based on the source directories, moves the contents of the folders to a subdirectory9)
  5. A file system transmission channel with a corresponding destination path and the setting „Use transmitter address“.
  6. A job(„MFT.In“)) opens the receive channel(„MFT.Receive“) and
    1. discards all files that match the filter specified10).
    2. All files that do not match the first filter will be filtered again in the second step in reverse11)
    3. OPTIONALLY a CustomJob Object can be triggered12)

All the names for channel / jobs etc. are fictitious

HDD source directory in this example:

C:\TEMP\MFT_TEST
├───Partner A
│ └───Archiv
├───Partner B
│ └───Archiv
├───Partner C
│ └───Archiv
├───Partner X
│ └───Archiv
└───Partner Y
  └───Archiv

HDD destination directory in this example:

z:\hostsystem_edi_inbound
├───host1
├───host2
├───host3
├───host4
└───host5

Test if the MFT works

  1. Navigate to the desired source path (it is best to create a temporary folder)
  2. There create some folders with test files (do not create „archive“ folders)
    Example for test folders
    Example for test files
  3. Then start the job that picks up the files and filters them - here „MFT.In“
  4. Check the directory - If everything worked fine, there should be no files in the folders. They should now be in a newly created subfolder „Archive“
    Result after successful execution of the job
1)
See e.g. Determine partner using subdirectory.
2)
See methods of Alternative communication.
3)
The usual procedures of the message recognition and analysis are omitted here completely.
4)
by default
5) , 8)
„MFT.Receive“
6)
referred to as MFT
7)
„MFT.In“
9)
here called „Archive“ / see HDD directory structure above
10)
For example, here we have filtered all files that do not end in „.txt“ or „.xml“. In addition, all files coming from „Partner X“ will be processed. For this purpose use a MessageSelector with the following XPATH expression: 
/SelectionBase/InputMessages[(substring(Attachments[1]/@Filename,string-length(Attachments[1]/@Filename) - 3) ! = '.xml' and substring(Attachments[1]/@Filename,string-length(Attachments[1]/@Filename) - 3)!= '.txt') and @PartnerName != 'Partner X']
11)
This means that the first filter will check again in reverse here. So we only let files with the extension „.xml“ / „.txt“ or everything from „Partner X“ pass. To do this, use a MessageSelector with the following XPATH expression: 
/SelectionBase/InputMessages[(substring(Attachments[1]/@Filename,string-length(Attachments[1]/@Filename) - 3) = '. xml' or substring(Attachments[1]/@Filename,string-length(Attachments[1]/@Filename) - 3)= '.txt') or @PartnerName = 'Partner X']
12)
For example, you may want to delete the files copied to the archive after a certain expiration time. For this you need OS functionality that can be scripted in such a Custom-Job-object.