TCH wrapper mapper - (ISOMessageRouter)

The ISOMessageRouterInbound and ISOMessageRouterOutbound pair of TCH wrapper mappers act as routers to message body mappers for incoming and outgoing messages. A message that requires mapping arrives in the wrapper mapper, which initially creates and populates root elements in the mapped document. The wrapper mapper then routes the message to an appropriate mapper to map the body of the document. When the message body mapper is done, the message is returned to the wrapper mapper.

Several channels can be configured to use the same wrapper mapper because the wrapper dynamically delegates the message body mapping to dedicated mappers. The wrapper mapper chooses the message body mapper to use based on the message type and the content that was received.

Note: The TCH wrapper mappers cannot be used in the following channels because the ISO message to or from the CSM usually contains a TCH business application header (head.001.001.01). The TCH wrapper mappers cannot process this header.
  • Request/Response from CSM
  • System Notification From CSM
  • Request/Response to CSM
The TCH business application header mapper (TCHMessageMapper) can be used in these channels. For more information, see TCH business application header mapper.

ISOMessageRouterInbound

Incoming messages that use ISOMessageRouterInbound are processed in the following manner. The message type is determined by examining the element that is underneath the <Document> element. The following list shows the elements for the messages.
  • <FIToFICstmrCdtTrf> indicates a pacs.008.* message.
  • <FICdtTrf> indicates a pacs.009.* message.
  • <FIToFIPmtStsRpt> indicates a pacs.002.* message.
  • <FIToFIPmtStsReq> indicates a pacs.028.* message.
  • <FIToFIPmtCxlReq> indicates a camt.056.* message.
  • <UblToApply> indicates a camt.026.* message.
  • <AddtlPmtInf> indicates a camt.028.* message.
  • <RsltnOfInvstgtn> indicates a camt.029.* message.
  • <PrtryFrmtInvstgtn> indicates a camt.035.* message.
  • <CdtrPmtActvtnReq> indicates a pain.013.* message.
  • <CdtrPmtActvtnReqStsRpt> indicates a pain.014.* message.
  • <RmtAdvc> indicates a remt.001.* message.
  • <CstmrCdtTrfInitn> indicates a pain.001.* message.
  • <IdModAdvc> indicates an acmt.022.* message.

The CONFIG=entry parameter, which is stored as a channel parameter, and the identified message type are used to retrieve the <msgTypeCfg> element from the value table. The <msgTypeCfg> element contains the name of the message body mapper to be used to map the received message.

For example, the Request From Channel channel can be configured to use the ISOMessageRouterInbound mapper by using a CONFIG=IP_MAP_CFG_REQ_FROM_CHAN parameter. When a camt.026.001.05 message is received from the channel, ISOMessageRouterInbound determines that it is a camt.026.* message from the <UblToApply> element. The channel config parameter provides the config value IP_MAP_CFG_REQ_FROM_CHAN.

Each <msgTypeCfg> element with a category of IP_MAP_CFG_REQ_FROM_CHAN in the value table is examined. When a <msgTypeCfg> element with a <type> child element that matches camt.026.* is found, the name of the mapper in the <mapName> child element is used to map the received message. In this example, the name of the message body mapper to use to map the received message is Camt026ToISFMapper.

If a <msgTypeCfg> element with a matching value in the <type> child element is not found, a mapper not found error occurs.

The following table shows some sample entries for the value table.
Table 1. Sample configuration value table entries
Category Key Configuration value
IP_MAP_CFG_REQ_FROM_CHAN msgTypeCfg_camt.026
<msgTypeCfg>
   <class>CAMT026</class>
   <subType>IP_FROM_SNDR_RFI</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>Y</value>
   </extendedCfg>
   <pt>
      <class>CAMT026</class>
      <subType>IP_FROM_SNDR_RFI</subType>
   </pt>
   <mapName>Camt026ToISFMapper</mapName>
   <type>camt.026.*</type>
</msgTypeCfg>
Note: To continue with the example, this entry in the value table has the <type> child element that matches the message. The <mapName> child element in this entry identifies the correct message body mapper to use.
IP_MAP_CFG_REQ_FROM_CHAN msgTypeCfg_camt.028
<msgTypeCfg>
   <class>CAMT028</class>
   <subType>IP_FROM_SNDR_RFIR</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>Y</value>
   </extendedCfg>
   <pt>
      <class>CAMT028</class>
      <subType>IP_FROM_SNDR_RFIR</subType>
   </pt>
   <mapName>Camt028ToISFMapper</mapName>
   <type>camt.028.*</type>
</msgTypeCfg>
IP_MAP_CFG_REQ_FROM_CHAN msgTypeCfg_camt.029
<msgTypeCfg>
   <class>CAMT029</class>
   <subType>IP_OUTGOING_ROI</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>N</value>
   </extendedCfg>
   <extendedCfg>
      <name>SUBTYPE_RJCR</name>
      <value>_REJECT</value>
   </extendedCfg>
   <extendedCfg>
      <name>SUBTYPE_IPAY</name>
      <value>_ACCEPT</value>
   </extendedCfg>
   <extendedCfg>
      <name>SUBTYPE_CNCL</name>
      <value>_ACCEPT_RETURN</value>
   </extendedCfg>
   <pt>
      <class>CAMT029</class>
      <subType>IP_OUTGOING_ROI</subType>
   </pt>
   <mapName>Camt029ToISFMapper</mapName>
   <type>camt.029.*</type>
</msgTypeCfg>
IP_MAP_CFG_REQ_FROM_CHAN msgTypeCfg_camt.035
<msgTypeCfg>
   <class>CAMT035</class>
   <subType>IP_FROM_CDTR_PACK</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>Y</value>
   </extendedCfg>
   <pt>
      <class>CAMT035</class>
      <subType>IP_FROM_CDTR_PACK</subType>
   </pt>
   <mapName>Camt035ToISFMapper</mapName>
   <type>camt.035.*</type>
</msgTypeCfg>
IP_MAP_CFG_PAY_FROM_CHAN msgTypeCfg_pacs.008
<msgTypeCfg>
   <class>PACS008</class>
   <subType>IP_FROM_DBTR_INSTR</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>Y</value>
   </extendedCfg>
   <pt>
      <class>PACS008</class>
      <subType>IP_FROM_DBTR_INSTR</subType>
   </pt>
   <mapName>Pacs008ToISFMapper</mapName>
   <type>pacs.008.*</type>
</msgTypeCfg>

After the ISOMessageRouterInbound mapper identifies the mapper to use for the body of the incoming message, it sets environment variables that are used by the message body mapper. The message body mapper uses these variables to determine where to start mapping from in the incoming message. The incoming message is then redirected to the appropriate dedicated message body mapper from the Route to Label node in ISOMessageRouterInbound. Then, it is redirected back to ISOMessageRouterInbound when the message body mapper is finished.

The following figure shows the inbound wrapper mapper. ISOMessageRouterInbound.subflow diagram

The following figure shows an example inbound ISO mapper. Pacs008ToISFMapper.subflow diagram

ISOMessageRouterOutbound

Outgoing messages that use ISOMessageRouterOutbound are processed in the following manner, which is similar to ISOMessageRouterInbound.
  • The ISF business concept of the outgoing message is identified, for example, IP_TO_CDTR_PSTAT.
  • The value of the channel config parameter is used as the category to query the value table. For example, the value of the channel config parameter is IP_MAP_CFG_STATUS_TO_CHANNEL for the Status To Channel channel.
  • The value table entries that match the category are searched to find the identified ISF business concept. These value table entries are searched until one with a <msgTypeCfg> element with a <subType> child element that matches the ISF business concept is found. The outbound mapper searches for a <subType> child element instead of the <type> child element that the inbound mapper searches for.
  • When an entry with a <subType> child element that matches the ISF business concept is found, the name of the mapper in the <mapName> child element is used to map the body of the outgoing message. If no <subtype> child element has a value that matches the outgoing ISF business concept is found, a mapper not found error occurs.
Note: The value table entry with IP_CONFIG as the category and IP_SCHEME_VER as the key identifies the version of the TCH Real-Time Payment (RTP) system that Financial Transaction Manager for Immediate Payments supports.
The following list shows the values that can be in this value table entry to identify the version of TCH that Immediate Payments supports.
v29
This value indicates that the version that Financial Transaction Manager for Immediate Payments supports is 2.9 or later.
NULL
This value indicates that the version that Financial Transaction Manager for Immediate Payments supports is 2.3.
If the version value in the entry is not NULL, it is appended to the end of the value of the channel config parameter. For example, IP_MAP_CFG_STATUS_TO_CHANNEL_v29. This new value for the channel config parameter is used as the category to retrieve the <msgTypeCfg> element. The value of the channel config parameter is also stored in Environment.PMP.Variables.Rules.*[1].MAP_CONFIG, which is used by the mapper that maps the body of the message.
Table 2. Sample configuration value table entries
Category Key Configuration value
IP_MAP_CFG_STATUS_TO_CHANNEL msgTypeCfg_IP_TO_CDTR_PSTAT
<msgTypeCfg>
   <class>PACS002</class>
   <subType>IP_TO_CDTR_PSTAT</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>N</value>
   </extendedCfg>
   <pt>
      <class>PACS002</class>
      <subType>IP_TO_CDTR_PSTAT</subType>
   </pt>
   <mapName>ISFToPacs002Mapper</mapName>
   <type>pacs.002.001.07</type>
</msgTypeCfg>
Note: To continue with the example, this entry in the value table has the <subType> child element that matches the ISF business concept. The <mapName> child element in this entry identifies the correct message body mapper to use.
IP_MAP_CFG_STATUS_TO_CHANNEL_v29 msgTypeCfg_IP_TO_CDTR_PSTAT
<msgTypeCfg>
   <class>PACS002</class>
   <subType>IP_TO_CDTR_PSTAT</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>N</value>
   </extendedCfg>
   <pt>
      <class>PACS002</class>
      <subType>IP_TO_CDTR_PSTAT</subType>
   </pt>
   <mapName>ISFToPacs002Mapper</mapName>
   <type>pacs.002.001.10</type>
</msgTypeCfg>

After the ISOMessageRouterOutbound mapper identifies the mapper to use for the body of the outgoing message, it sets environment variables that are used by the message body mapper. The message body mapper uses these variables to determine where to start mapping from in the outgoing message. The outgoing message is then redirected to the appropriate dedicated message body mapper from the Route to Label node in ISOMessageRouterOutbound. Then, it is redirected back to ISOMessageRouterOutbound when the message body mapper is finished.

The following figure shows the outbound wrapper mapper. ISOMessageRouterOutbound.subflow diagram

The following figure shows an example outbound ISO mapper. ISFToPacs002Mapper.subflow diagram