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:
(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.
| Module | Rule | Meaning |
|---|---|---|
| doceot | setCORTYP | Sets selectable message channels in the DOCEOT grid |
| savdoc | Sets the Workflow for the channel | |
| GetSNDKEY | Reads the address | |
| SetDOCCORSEA | Prioritizes the search paths through available channels | |
| SetAddressingInfo | Fills address fields in the Details panel | |
| ADDINF | Adds address subpanels to the panel, where necessary | |
| DetermineConversion | Defines how the message is generated | |
| docimm | SetDisplayFormatDefault | Sets the corresponding display format |
| ptmmod | PtmGetRelevantAdrFieldOfCortyp | Sets the name of the datafield containing the address details to the channel |
| setfeg | RegisterSettlementCorrCha | Counts the number of messages and adds the corresponding fees for settlement |
| trndoc | GetCurrentCORLineLength | Defines the maximum line length per message channel |
| init order 1100 | Defines how document rules for the channel are to be searched for | |
| trnism | WfmAdd_xxx | Where necessary, sets the required Workflow entries for an xxx-message (e.g. print, service to interface, release) |
| adrdef | check ADR\CORTYP | Checks the correctness of the address for the corresponding channel |
| cormod | GetTagSupFile | Delivers the name of the xxxsup.ini file for the channel relating to the Doctyp (1-digit) or channel (3-digit code) |
| GetCORTYPCanHaveAttachment | Defines the message channel with attachment | |
| GetCORTYPTechnical | Defines the technical message channel | |
| GetCORTYPFromFormat | Maps letters in three-digit channel code | |
| GetFormatFromCorTyp | Maps three-digit channel code in letters | |
| dbxtrn | init order 1100 | Sets possible message channels |
| GetWFESrv | Defines the corresponding service per message channel |
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.