Actions (Rule)
See section MFT as introduction.
In this area, a copy of the received file can be stored on the MFT server and the file can be forwarded to other partners.
Copy
(1) If you specify a file name here, a copy of the received file will be placed in the installation directory (or a subdirectory) of the MFT server. If no copy should be created, please click the button No backup. This creates the dummy entry /dev/null. Following the allowed placeholders for the file name. Note: Please also make sure to enter a 'real' file name (and not /dev/null) if you work with raw files, as this name will then also be used for the forwarded file. See also (2) and (3).
|
@ORIG@ |
The original name of the received file. |
|
@SENDER@ |
The sender read from the file. See section Detection (Rule). |
|
@RECEIVER@ |
The recipient read from the file. See section Detection (Rule). |
|
<y,M,d,H,m,n,s,S,w,Y> |
Allowed placeholders for the file name. See also section File Names and File Patterns. |
(2) and (3) must be set for incoming files with data type Image/Raw (for other data types these two items can be ignored). The profile must have an Input Agent of type Rule and a Response Route of type Custom Class with class DefaultRuleResponder (with empty configuration string). See also (1).
Split Message
This area is for all file with data types other than Image/Raw.
There must be at least one entry here and one of the entries must match for a rule to match for an incoming file received by the MFT server. The entries are sorted automatically after they have been created and are then checked from the top to the bottom of the list. The first entry that matches is used. The profile of this entry is then executed and the output file of the profile is forwarded to the recipient. The profile must have an Input Agent of type Rule and a Response Route of type Custom Class with class DefaultRuleResponder (with empty configuration string). In the profile, the file received by the MFT server can be manipulated or remain unchanged (without mapping).
The sending partner is either the partner that actually sent the file to the MFT server or the one that was read out in the Detection. The receiving partner is always read out in the Detection.
If an incoming file has been split in the Detection, all split files are forwarded individually here.
(4) For sender Channel002 and any recipient, Profile_2 is executed and the profile output is sent to the recipient.
(5) For sender Channel001 and recipient Channel003, Profile_1 is executed and the profile output is sent to the recipient.
(6) Profile_3 is executed for any sender and any recipient. This is the most unspecific entry, which is always at the bottom of the sort and always takes effect if no other entry takes effect before it.