In a business transaction, documents are generated in a document rule. On 'End-of-Transaction', i.e. when [SAVE] is clicked, these messages are stored in a file in directory “data\docs” and an entry is created in the SMH (Structured Message Header) table. These messages consist of a header - generated with procedure “TRNMOD.SwtCreateHeader” - and the message body with standard SWIFT res. TradeConnect tags.

Content of the CORTYP field for the SMH row created indicates the message format.

Letters are stored in TradeDesign XML document format, all other messages are stored as a .TXT file in a :TAG: data format.

The service used to generate outgoing messages (typically launched in MGRTSK) creates new files from the .TXT files that contain messages in the format required by the dispatch interface.

The SWITSK service and/or the incoming service integrated for the relevant message type (e.g. SRVSWI) reads files containing electronic messages.

These messages can be files containing multiple messages in any of the following formats:

• SWIFT II format with Header Blocks, Text Blocks and Trailer Blocks
• TradeConnect (AKK) format with a common header (Ax-tags) and trailer (Zx-tags) and a sequence of messages (i.e. TCO, DTE, DTA, DTG)

SWITSK creates an SMH row for every message (i.e. as many SMH rows as the file contains messages).

For single messages (i.e. those that are not part of a sequence of MT700/MT701) the message is then analyzed and mapped into a pending item using the corresponding SWM entries (cf. DBISWM for maintaining the SWIFT Mapping Table (SWM)). The Frame for which the mapping has been executed is stored in SPT\MAPFRM. When an incoming message is picked up, DOKA-NG checks, if mapping was executed for the current target frame and if not chains with message to SPTRER so that a re interpretation is executed if needed ( done in OFFMOD.CallTRN / QUEMOD.CallTRN / SPTSEL.CallTRN by calling IncSPTRemappingNeeded).

It is possible, that an execution date is provided. This is mapped out of the incoming message to SWIADD and will be the be taken over from SWIADD to TRN\EXEDAT in the business transaction.

Thus, the tag M9 TradeConnect and DTA messages is mapped in transactions, so that the PDD service (check execution date) can be executed.

As the tag M9 can be used in DTA and TradeConnect messages (not in DTE!), the mapping is extended by M9 in the relevant message types. For this purpose, fieldM9EXEDAT is available in SWIADD, to which the mapping refers. According to this, there is a default in TRNMOD, which stores the content of M9EXEDAT in TRN\EXEDAT.

If a file contains a message or several parts of a related sequence of messages (e.g. SWIFT Tag :27: 1/2), as a final step in processing the file SRVSWI checks whether the appropriate subsequent messages (e.g. SWIFT TAg :27: 2/2) are already available and whether the message is now complete. If all corresponding SMH rows are at hand, the messages are loaded, combined and mapped into a pending item using the SWM table for the relevant message type (e.g. MT 700).

All fields that cannot be resolved, and that are not explicitly marked to be ignored with content 'Ignore' in the translation method of the corresponding SWM entry are reported in the additional field SWIADD\ADDBLK. When a tag of a guarantee message that contains sequences is reported via SWIADD\ADDBLK, the text “(Seq. B)” or (Seq. C) is automatically added to the Tag name to allow easy identification in “Unmapped” view.

The INR for all SMH entries that are connected with this pending item and that must be updated with a contract reference on creation of such contract, are stored in SWIADD\SMHINRBLK.

The document type (i.e. CORTYP SWT) is determined by the directory from where the field is read. Depending on this type, the file tag description file used (TAGSUP.INI res. TCOSUP.INI res. DTESUP.INI res. DTASUP.INI) is determined.

For files wilth a general header (Ax-Tags) all header tags (i.e. those mentioned in section [HEADERTAG] of file “INI\TAGSUP.INI”) are logically duplicated, as if they were part of every message in the file.

The PrettyPrint allows messages to be prepared for presentation in :Tag: data format. It supports both SWIFT II format (including Header and Text Blocks in curly brackets '{ }') and raw format, only containing tagged messages. As input it can either use an ASCII file or a stream already containing a message or a sequence of messages. It allows the display of a single message within a multimessage file, if its starting position within the file is known. Channel-specific files xxxSUP.INI and xxxOVR.INI are used to analyze and format the message.

For this purpose the descriptions have to be entered in the xxxSUP.ini file used (also for the other language). For more information see 'xxxSUP and xxxOVR Files'.