Message channels can be distinguished between logic and technical channels, with only the logical channel (i.e. CORTYP) being visible to users. The technical channel solely describes how messages are passed over to the application or how the application sends the messages. This can be either through CORBA, SWIFT, MQS or by file transfer. Thus, the word 'channel' in the application always refers to a logical channel. A logical channel is assigned to each document and this information is saved in the field CORTYP in SMH. The entire logic describing and controlling the messages depends on this CORTYP.

A number of definitions are required before a channel can be used.

The channel has a three-digit alphabetical name.

The following names are currently supported in the standard:

• LET (Letter),
• SWT (SWIFT),
• TCO (TradeConnect)
• TCX (TradeConnect DocX)
• DTE (DTAEA)
• DTA (DTALC)
• DTG (DTA Guarantee)
• TAR (TARGET)
• BOL (Bolero)
• SIC (Swiss Clearing)
• EML (Email)
• ANT (AllNett)

(Full list see codetable CORTYP )

If technically possible, a CORTYP is defined in the CORMOD module. When defining a new channel, all rules need to be checked to determine whether they might need to be extended for a new channel.

If the incoming or outgoing messages are to be formatted via PrettyPrint, a <CORTYP>sup.ini is to be defined. Optionally, a <CORTYP>ovr.ini can be defined which overlays the entries in <CORTYP>sup.ini. Use CORMOD.GetTagSupFile to assign the channel to <CORTYP>sup.ini. The PrettyPrint parameters are programmed in DOCIMM and in DOCEOT.

Use 'DOCIMM.SpecialHandledExternal' to customize message formats.

Documents have to be automatically converted in “DOCEOT.MakeAndConvertRuleDoc” or in “DOCEOT.DetermineConversion”.

SWITSK, SRVSWI and SPTRER have to be extended for the new channel.

If you want to use the incoming mapping of an already existing channel, this needs to be programmed in SRVSWI. If you use youir own mapping, this has to be incorporated into DBxSWM.

Either an existing service has to be extended or a new service has to be created and incorporated into MGRTSK.

DOCEOT definitely has to be extended. If internal text functions are used, these functions have to be defined in the business transactions.

DOCEOT needs be adapted as required.

Technical headers and footers are defined in DOCIMM.

The attachments (incoming or outgoing) are managed by adding an SMH record for each attachment. The main message and the attachments are marked as belonging to one group (i.e. in all messages the SMH\INR of the main message is specified as GRPINR).

The type of attachment (created document, SMH record from another transaction, file) is encoded in SMH\ORIFLG.

When interacting with TradeConnect, it is possible to receive, manage and send respective attachments along with the messages.

During the transport, attachments are contained in the LST file belonging to the message. Incoming attachments are received together with the message and are associated to the contract. Outgoing attachments are transferred together with the TradeConnect message.

Note: There is no length limitation for TCO outgoing messages. The maximum length is currently set to 50.000 characters in file TCOSUP.INI. If necessary, this value can be changed.

If an Email has been received with MIME format and attachments, the incoming file is divided into a main message and attachments. All attachments - also recursive, if for example additional Emails with attachments are attached - are stored as attachments of the main Email

The technical realization for outgoing Emails is implemented in the function “SendMessageCus” of the instance SRVEML of service SRVFAX - depending on the interface used.

Basically, it is perhaps more effective to search for a code of a comparable channel in SWITSK, MGRTSK and in a business transaction (e.g. LETOPN) and, where applicable, to adapt the items found.

In addition, code table CORTYP, APFCLA will have to be adapted, and possibly alsoBICAUT.
< A form class is to be set up for each channel using DBxAPF.