Payments
R24 AMR | Min(s) read

Introduction to Inward Messaging Framework

Incoming Message Flow is the flow of messages received from the customer feeders or Clearings.

Hover on each component to understand their function

Configuring Inward Messaging Framework

All message flows have a configurable property file which can be used to configure different properties required for the framework. It is available in ESBProjects > PP > ESB_SOURCE > PP_ESBInward > <Flow name> > ESBUtility > Schema path. The table given below lists the configurable properties in the middleware:

Incoming message Flows

Queue Configuration File name(.properties)

Payment Order Inward flow

QueueConfigPO.properties

Instant Inward flow

QueueConfigINST.properties

Non-Instant Inward flow

QueueConfig.properties

Agent Banking Inward flow

QueueConfigIP.properties

CBPR inward Flow QueueConfigSWMX.properties
RequestToPay inward flow QueueConfigInwardRTP.properties

Consuming different payments is the prime responsibility of the message framework. Since there is always a need to consume or send payments from or to the external system by different means, the framework provides an option to configure input or output folders or queues.

The below configurations in Queue config properties can be used to configure folders or queues and its names.

#Configuration of the physical input folder or queue for each clearing
CTIInputFolder=BulkCTIInput
CTEInputQueue=TPH. BULK .CTI. QUEUE
DDIInputFolder=BulkCTInput
DDTInputQueue= TPH. BULK .DDI. QUEUE

Apart from configuring the Input folders or queues, other folders or queues like Backup, Error and so on can be configured.

Given below is the configuration of the folder names:

#Configuration of the folder names
FailedMsgFolder = FailedMsgFolder
ErrorFolder = ErrorFolder
TransformRejectFolder = TransformRejectFolder
BackUpFolder = BackUpFolder
Transformedxml = Transformedxml
SignatureInputFolder=SignatureInput|

For instant payments processing to facilitate synchronous message acceptance and processing, REST API endpoints are provided. 

By using these API endpoints, the confirmation message (like pacs.002) can be synchronously received for incoming credit transfer message from the Clearing (like pacs.008)

The user can configure the API request and reply queue in the QueueConfigInst.properties of the instant message flow. 

 #Request Queue for API
APIEWINSTReqQueue~APIEWINSTReqaue!
APIUKFPSReqQueue—APIUKFPSReqQueue
APIHCTINSTReqQueue~APIHCTINSTReqaqueue
APIEBAINSTReqQueue—APIEBAINSTReqqueue
APICTIINSTReqQueue—APICTIINSTReqQueue
APISAINSTReqQueueAPISAINSTReqqueue
#Response Queue for API
APIReplyqueue—APIReplyqueue

The configuration below is required in the outward message flow (QueueConfigInstOut.properties) for receiving the confirmation response message.

#Routing channel for Final Output File
#FILESYSTEM
#ACTIVEMQ
#API
RoutingChannel-UKFPS=API

The user can configure the time interval to wait for the response as below:

Response Queue for API
APIReplyQueue=APIReplyQueue
 
#Time that API request waits for response
requestTimeout=30000

If the correlation message is not required, then the user can switch off using the configuration below. In this case, the reply queue does not wait for the confirmation message.

The configuration to switch off the correlation message is as follows:

UKFPS-correlationRequired=TRUE
UKFPS-corrAPI-ClassName=

If the Correlation ID is not configured, the framework creates a unique ID for correlation of the message.

Any specific correlation ID can be assigned by using the configuration below:

#API Related Configuration
UKFPS-correlationRequired=true
UKFPS-corrAPI-ClassName=com.temenos.PP.PPINST_InstantInward_DebulkXmlMessage
UKFPS-corrAPI-MethodName = generateCorrelateionID

Payment processing can accept payments from different physical sources but process it in the same way without having any new configuration in the payment system, by assigning logical queues to different input folders or queues.

Logical queue name refers to the ID of the PP.MSG.ACCEPTANCE.PARAM table which is the first entry point into processing messages. The configuration below gives the flexibility to assign the same logical queue to different physical folders or queues: 

#Mapping of Physical Folder to Logical Queue
BulkCTIInput = TPHCTI
BulkDDIInput = TPHDDI
STEP2Input = STEP2
RPSCHQInput = RPSCHQ
RPSSCLInput = RPSSCL

The system provides the capability to perform an end-to-end integrity check for all incoming messages. Configurable APIs can be used to extract the signature from the incoming message and verify the signature based on the Compliance and Key store. 

Given below are the two levels of integrity check:

  • Integrity check on the incoming payments
  • Integrity check after the transformed payment is received in the TPH layer

The table given below lists the configurable Integrity Properties text file in middleware:

Inward Flows

Camel layer integrity properties file name(.properties)

TPH layer integrity properties file name (.properties)

Payment Order Inward flow

PI_POInstantInward_InwardIntegrity

PI_POInstantInward_T24Inward

Instant Inward flow

PPINST_InstantInward_InwardIntegrity

PPINST_InstantInward_T24Inward

Non Instant Inward flow

PP_InwardXML_InwardIntegrity

PP_InwardXML_T24Inward

Agent Banking Inward flow

PPIPCL_CreditTransferIP_OutwardIntegrity

PPIPCL_CreditTransferIP_T24Outward

CBPR Inward flow PPSWMX_SwiftInwardXML_InwardIntegrity PPSWMX_SwiftInwardXML_T24Inward
CBPR Inward flow RF_RTPInward_InwardIntegrity RF_RTPInward_T24Inward

The user can turn the integrity check on or off by setting Foldername-IntegrityRequired or QueueNameIntegrityRequired as True or False in the configurable properties text file for message integrity as given below:     

POInstInput-IntegEityRequirsd=FALSE
POInstInput-Compliance=
POInstInput-APIName=
POInstInput-Intermediatecheck=FALSE
PONonInst-IntegrityRequirsd=FALSE
PONonInst-Compliance=
PONonInst Input-APIName=
PONonInst-Intermediatecheck=FALSE
TPH. PO. BULK. INST-IntegrityRequired=FALSE TPH. PO. BULK.INST-Compliance=
TPH.PO.BULK.INST-APIName=
TPH.PO.BULK.INST-IntermediateCheck=FALSE
TPH.PO.BULK.NP.INST-TIntegrityRequired=FALSE
TPH.PO.BULK.NP. INST-Compliance=
TPH.PO.BULK.NP.INST-APIName=
TPH.PO.BULK.NP.INST-IntexmediateCheck=FALSE
The user can configure the API to extract the signature from the incoming messages which is validated based on defined compliance.

  1. By default, XSD validation is performed for all XML messages and can be switched off using the configuration below:

    2. #Configuration to enable or disable XSDVALIDATION
UKFPS-XSDVALIDATION = FALSE
SAINST-XSDVALIDATION = FALSE

  2. Use the below API hook to add validations to non-XML files.

    3. #configure here for non XML Validation
BECS-ClassName = com.temenos.PP.PP_InwardXML_DebulkXmlMessage
BECS-MethodName = validateBECSFile
BACS-ClassName = com.temenos.PP.PP_InwardXML_DebulkXmlMessage
BACS-MethodName = validateBACSFile

  3. Configure the validation errors description as below.

    4. #Functional Validation Error codes
BACS-10=29-Sum of all Debit Transaction Amount does not match with the Total Debit
BACS-07=30-Sum of all Credit Transaction Amount does not match with the Total Credit
BACS-08=31-Sum of all Debit Transaction does not match with the Total Debit Count
BACS-09=32-Sum of all Credit Transaction does not match with the Total Credit Count
BACS-06=03-Nunber of transactions at the Payment Information level is invalid
BACS-11=33-Debit contra is mandatory for given debit transactions in the file
BACS-12=34- Credit contra is mandatory for given credit transactions in the file
BECS-01=35-Technically invalid file

    If the file is rejected due to an XSD validation error, the error information is logged in Received File Details.

  4. By default, the check sum and control sum validations are performed by the system for all messages and it can be switched off using the configuration below. This validation also includes validating batch customer feeder payments for valid currency. If the bulk of payment initiation file is a batch, all the transaction currencies should be the same, else the bulk is rejected. 

    5. #Configure here for the Default Checksum Validation
LNKCLR-DefaultCheckSumVal = Yes

  5. TPH Messaging Framework can receive RtP messages from an Instant Payments Clearing. The RtP messages received are routed to the RtP module for processing. To receive Rtp messages using instant flow the below configuration is required.

  6. By using the following TPH understandable neutral formats, any type of message can be mapped by the framework into system for processing.

    7. Refer Sample Inward Mapping Sheet for more information.

  7. Any technical failure in the Message Acceptance layer may result in a partial file mapping into the payment system. Such failures require the reprocessing of the whole file again. This can be handled by configuring exception queues or folders and pushing the failed messages. The payment system take cares of the duplicate check, settlement entry creation and auto cancelling the payments if already mapped.

    Configuration for exception cases are given below:

    8. #Configure here for the exception cases
ExceptionClearingInputFolder=ExceptionClearingInput
ExceptionClearingInputQueue= TPH. EXCEPTION. CLEARING. QUEUE
ExceptionInitiationInputFolder=ExceptionInitiationInput
ExceptionInitiationInputQueue= TPH. EXCEPTION. INITIATION
ExceptionInitiationInput = TPHCTI##EXCEPTION
ExceptionClearingInput = STEP2##EXCEPTION

The system provides a capability to perform partial message integrity check for all incoming messages., Configure EB.PARTIAL.SIGN.PARAM to specify the fields to be used from the incoming message details to form the signature. The signature generated is stored and validated before booking.

The ID is combination of originating source and incoming message type configured in Transact EB.PARTIAL.SIGN.PARAM table which extracts the field values from the table and forms the signature to be validated.

The compliance can be configured in EB.SEC.KEY.CONFIGURATION table for signature formation.

If the incoming message fails due to signature mismatch before posting, it is routed to repair to check the validity. 

From the Repair page, the user can do one of the following:

  • Either accept the error and continue the payment processing after verification
  • Cancel
  • Return
  • Reject the payment

The configurations given below provides an overview of the Transact-level determinations required for accepting the payment.

The source and channel of the customer feeder messages and the clearing messages are determined based on the configuration in PP.MSG.ACCEPTANCE.PARAM. By defining different source and channels, consecutive payment processing characteristics can be defined.  

The source can also be changed by using Source Type API inPP.MSG.ACCEPTANCE.PARAM.

The message format which is allowed for any particular channel can be defined by using a MsgFormatPerChannel configuration. This configuration allows only valid message formats to be accepted per channel.  

Apart from validation at the middleware, any further validation can be performed using Validate API in PP.MSG.ACCEPTANCE.PARAM of TPH. 

When the incoming message does not have sufficient or basic information to map to the payment system, the Acceptance Enrich API in PP.MSG.ACCEPTANCE.PARAM can be used to enrich the message.

If the currency of payment is not present in the message which is required for the payment system to process the payment, currency can be enriched in the message.

If a return incoming payment is not coming without reference of the original underlying payment, then the same can be matched using different criteria and enriched.

Enrichment can be performed on the received message using Acceptance Enrich API which is per message format

The user can configure the required clearing transaction type for a specific message from a specific source. The Clearing Transaction Type field determines the flow in TPH that this message has to go through.

If a pacs.008 from STEP2 must take the flow of a credit transfer then a record (as shown below) must be configured in PP.MSGMAPPINGPARAMETER.

File level duplicate can be enabled using Check Duplicate Indictor in PP.MSG.ACCEPTANCE.PARAM based on the following values:

  • File Header Reference
  • File Message Format
  • File Sending Institution
  • Originating source

Bulk level duplicate can be enabled by configuring EB DUPLICATE TYPE Id in PP.MSGMAPPINGPARAMETER

Enrichment can be performed on the mapped message using Enrich API in PP.MSGMAPPINGPARAMETER. The payment object to be mapped to the payment system tables can be enriched using this API.

The PP.IN.CHANNELS table enables definition of folders where the incoming non-XML file has to be placed.

Value

Description

Batch

Indicates the files with multiple payments

Instant

Indicates the files with instant payments

Single

Indicates the files with non-instant single payments
  From R21 non ESB framework is not supported.

The Data field in the Batch record of INWARD.MAPPING service refers to the ID of the records in PP.IN.CHANNELS table.

When no value is set in the Batch record of INWARD.MAPPING, Batch is the default value considered. Hence, a record with Batch ID should be available in PP.IN.CHANNELS in this case.

The table below describes the fields used:

Field

Description

InFolder Name

Indicates the folder where the incoming non-XML file needs to be placed

Queue Name

Indicates the message acceptance queue name (Key to PP.MSG.ACCEPTANCE.PARAM)

Backup Folder

Indicates the folder where all received messages are stored (irrespective of whether they are accepted or rejected) 

 

Schema Folder

Should not be configured for non-XML

Stylesheet Folder

Should not be configured for non-XML

Generic Folder

Should not be configured for non-XML

Error Folder

Indicates the folder of the received message when it encounters an error during initial validation

To run the INWARD.MAPPING service,

  1. Receive the file
  2. The service is internally read in PP.MSG.ACCEPTANCE.PARAM. Invoke Validate API and Debulk API to validate and debulk the message.
  3. Once validation and debulk is successful, the system maps the message to internal POR tables (TPH neutral payment object)

The PP.IN.ENTRY.PARAM table is used to map non-XML messages to TPH. The fields in this table are described below:

Field Name

Description

ID

Indicates the ID which is made up of two components de-limited by a “-“QueueName-TypeOfMessage

  • Queue Name - ID of the record in PP.MSG.ACCEPTANCEPARAM
  • TypeOfMessage - Value returned from DebulkAPI in the position TypeOfMessage
  • SEPA-DDINIT
  • FPS-CTINCOMING

Description

Indicates the description of the record

Field Delimiter

Indicates the delimiter which separates the values in the incoming de-bulked message. It is not mandatory to have a delimiter, as the incoming de-bulked message can be a fixed-length string. In such a case, Field Position and Field Length are used.

F1|F2b|F2c

In this case ‘|’ is the FMDelimitter

The chosen or configured Field Delimiter must be a character which cannot be used in the message itself.

VM Delimiter

Indicates the field to specify the delimiter between multiple values, if the incoming de-bulked message has a field which contains those multiple values.

It is not a mandatory field as the incoming de-bulked message can be a fixed-length string. In such a case,  Field Position and Field Length are used.

F1~F2|F2b|F2c~F3

In this case ‘|’ is the FMDelimitter

In this case ‘~’ is the VMDelimitter

The chosen or configured VMDelimiter must be a character which cannot be used in the message itself.

SM Delimiter

Indicates the filed holding the delimiter between the sub-values, if the incoming de-bulked message has a field, which contains multi values and sub values.

It is not a mandatory field as the incoming de-bulked message can be a fixed-length string. In such a case, Field Position and Field Length are used.

F1~F2:F201:F202:F203|F2b|F2c~F3

In this case ‘|’ is the FMDelimitter

In this case ‘~’ is the VMDelimitter

In this case “:” is the SMDelimitter

The chosen or configured SMDelimiter must be a character which cannot be used in the message itself.

Field Name

Indicates the name of the field in TPH neutral format that needs to be mapped from the input message string.

Field Position

Indicates the starting position of the field’s value

Use this only if it is a fixed-length message. This is associated to the Field Name field. Hence, this specifies the starting position for the field specified in Field Name field.

1001USD100

FieldName : InstdAmtCcy

FieldPosition : 5

Field Length

Indicates the length of the field’s value from the starting position mentioned in Field Position field.

Use this only if it is a fixed-length message. The Field Name, Field Position and Field Length fields are associated. 

1001USD100

FieldName : InstdAmtCcy

FieldPosition : 5

FieldLength : 3

Val Routine

Indicates the API hook triggered to enrich data.

This field is associated to Field Name, Field Position and Field Length. Hence, this API can only enrich data for the field specified in the Field Name to which this API is linked to.

Signature: Only one input or output variable can be supplied. This holds the current fields’s value. Post enriching, in the same variable, send the enriched value for the field.

enrichNonXMLData(ioFieldContent)

Mandatory

Indicates the field configured as Mandatory (value = ‘Y’) and if the content of the corresponding field is empty or blank, then an error is returned by the API.

The transaction is not mapped but it can be viewed in a GUI received file or messages with an error status.

Constant

Indicates the constant value that can be supplied to a field instead of extracting the value from the incoming message. If this field has a value specified, the system does not refer the Field Position, Field Length and Val Routine fields. Value defined here takes the precedence over the others.

In PP.COMPANY.PROPERTIES table, check the CNY TO CNH Conversion Required field if the processing company wants to convert CNY to CNH currency for incoming messages (CBPR+ and Clearing).

The framework is Enterprise Service Bus (ESB) agnostic and can be used in any ESB by calling the appropriate java API’s. Source agnostic implies it can receive messages from any type of source irrespective of its technical nature.

In case of using other ESB, few steps need to be followed to configure and establish connection with Transact. The flow below and Java API’s provide the details for building the flow. 

            

The Inward Java APIs to be used as part of the message flow is given below:

Action Method Name Input Output Additional Information
To retrieve the queue name from the queueConfig.properties file String getQueueNameList() None None QueueConfig.properties file should be available in the XSD root path. Name of the XSD folder and XSLT is based on the namespace if XML or queuename if non Xml
HashMap getQueueNmBasedOnFolderNm() None HashMap - Key value pair of the folder and the queue name Store the queue details in a local variable for future use
To retrieve the name of the XSD folder and the XSLT name, use the Java method void PP_InwardXML_DebulkXmlMessage. getXSLTNameAndXsdFolderName(String namespace) String namespace – Retreive the namespace of the incoming message and pass it None None
To validate the incoming message against the XSD use the Java method String PP_InwardXML_DebulkXmlMessage.validateXMLAgainstXsd (String XSDFolderName, byte[] inputXmlPath) "String XSDFolderName Use the following method to retreive the XSD folder name and then pass that as input String PP_InwardXML_DebulkXmlMessage. getXSDFolderName () Input – byte[] inputXmlPath - Incoming XML message (To be supplied as byte array) " "String Return value is ‘1’ denotes successful validation. Return value ‘0’ denotes validation failure. In such a case, invoke Java method to send the reason for failure to T24 using the method String PP_InwardXML_DebulkXmlMessage. formRejectResponse (String fileInfo, String errorCode,String xsdFailureMsg,String fileName,String queueName) "  
String PP_InwardXML_DebulkXmlMessage. formRejectResponse (String fileInfo, String errorCode,String xsdFailureMsg,String fileName,String queueName) "fileInfo - Null errorCode - Null xsdFailureMsg - actual XSD validation error file name - Name of the file queue name - Use the queue name retrieved earlier on. " "String - Rejected message with tag names and vales to be sent to TPH to store in PPT.RECEIVEDFILEDETAILS. When an incoming file is rejected, reason for rejection needs to known and hence the reason is stored in PPT.RECEIVEDFILEDETAILS along with the file name. Original message received would be in the backup folder."  
Node 2
To retrieve the XSLT dynamically and store the same for future use. String PP_InwardXML_DebulkXmlMessage. getXSLT_Name () None String - XSLT Name "Store the returned value in the ESB specific stylesheet variable so that it can be invoked dynamically "
Node 3
Perform checksum and control sum validation List<String> PP_InwardXML_DebulkXmlMessage. checkNoOfTxnsAndCtrlSum (byte[] fileContent) File content as byte array "0th position - True or False (Validation is successful or failure) 1st position - Error Code (When validation has failed) 2nd position - File Info " "Valid Error Codes : ""01"", ""Total number of transactions does not match with FileNrOfTrx."" ""02"", ""Transactions Total amount does not match with FileCtrlSum."" ""03"", ""Total number of Txns in a bulk does not match with BulkNrOfTrx."" ""04"", ""Total amount of Txns in a bulk does not match with BulkCtrlSum"" ""05"", ""All children must have the same currency for a batch"" Values returned in FileInfo: FileName QueueName ReceivedDate ProcessingStatus ProcessingStatusDescription BulkIndex TransactionIndex UniqueReference"
  Node 4 - Debulk File
Debulk XML message List<StringBuilder> PP_InwardXML_DebulkXmlMessage.splitLargeXmlIntoSmallFiles(byte[] fileContent, String fileName, String queueName) " File content as byte array File name Queue name (Retreived earlier on) " Individual XML payment messages  

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Tuesday, May 28, 2024 4:38:01 PM IST