4.11.1. Extra processings on gateway IN

Zip unwrapping

This extra-processing allows to extract multiple files from a zip, and to process each of those files separately.

The parameters are :

File name pattern

Pattern (regular expression) for the file name in the zip of the files that will be extracted.

Note: This extra processing is not executed while resubmitting a message and the message should be received again via the Gateway IN in order to be unwrapped.

X12 splitting

This extra-processing allows to split an X12 interchange and to process each of the transaction files separately.

If the linked message definition requests a 997 acknowledgment, the system will send a single message containing the acknowledgment for all transactions in the incoming interchange.

The parameters are:

Input Charset	Charset to use to decode the file.
User Metadata Transfer Strategy	The strategy that will be used to transfer the user metadata to the message created for the transactions.

Note: This extra processing is not executed while resubmitting a message and the message should be received again via the Gateway IN in order to be splitted.

Edifact splitting

This extra-processing allows to split an Edifact message and to process each of the transactions separately.

The parameters are:

User Metadata Transfer Strategy

The strategy that will be used to transfer the user metadata to the message created for the transactions.

Note: This extra processing is not executed while resubmitting a message and the message should be received again via the Gateway IN in order to be splitted.

Automatically close errors

This extra-processing allows to define criteria to automatically close an error that occurs during the Gateway IN step.

The parameters are :

Error message patterns

The patterns that will be tested against the error message.   If the error message matches at least one of the patterns, the status of the message will automatically be set to Error(closed).

Message identifier

This extra processing analyses the incoming message, and associates the following metadatas to it:

universal_router_type	The type of document, like 'ORDERS', 'INVOIC', 'DESADV', ...
universal_router_format	The format of the message, like 'EDIFACT', 'X12', 'IDOC', ...
universal_router_version	The version of the message format. For example, for EDIFACT, version can be '96A', '01A', ...
universal_router_sender	The identification of the sender of the message.
universal_router_receiver	The identification of the receiver of the message.
universal_router_key	The integration of the five previous fields, separated by '_'. The goal of this field is to simplify the writing or routing rules, or of keys of   messages, that want to use all of the above fields.

Note: For example, When we have "Message In" of type X12 and we receive multiple input messages with different encoding then we can use the universal router encoding {universal_router_encoding} system metadata in the "Input Charset" from the "Properties" of the X12 "Message In" to generate the correct encoding for each received input message with different encoding, as shown below.

Using universal router encoding in the "Input Charset" of X12 "Message In"

Note: The metadata universal_router_encoding is added thanks to the extra processing Message identifier.

The metadata will typically be used by a following routing. As an example, suppose that you receive orders in different formats with the same gateway. This extra processing can be used to identify the following formats: EDIFACT, X12, IDOC (xml or flat file), RND, VDA, cXML, UBL. This information can then be used to route the message to the correct message definition.

Parameters :

Custom identifier

This extra processing can take a custom identifiers XML file definition to import custom extractor.

The XML is defined as followed :

<?xml version="1.0" encoding="UTF-8"?>
<Identifiers>
	<Identifier>
		<IdentifyByRegex length="10000" encoding="UTF8"><![CDATA[<\?xml.*<cbc:UBLVersionID>(.*)<\/cbc:UBLVersionID>.*]]></IdentifyByRegex>
		<Format>UBL_CUSTOM_$1</Format>
		<Version>$1</Version>
		<Sender>
			<Xpath><![CDATA[/Invoice/AccountingSupplierParty/Party/PartyIdentification/ID/text()]]></Xpath>
		</Sender>
		<Receiver>
			<Xpath><![CDATA[/Invoice/AccountingCustomerParty/Party/PartyIdentification/ID/text()]]></Xpath>
		</Receiver>
		<Type>
			<Regex>
				<Expression><![CDATA[<\?xml (version)="1\.0" encoding="UTF-8"\?>\n<\?xml-stylesheet type="text\/xsl" href=".*" \?>\n<([A-Za-z]*) xmlns:.*>.*<cec]]></Expression>
				<Value>$1-$2</Value>
			</Regex>
		</Type>
	</Identifier>
	<Identifier>
		<IdentifyByRegex length="900" encoding="UTF8"><![CDATA[CUSTOM(ISA)\|([0-9]+).*GS\|IN\|([0-9]+)\|([0-9]+)]]></IdentifyByRegex>
		<Format>$1_$2</Format>
		<Version>$2</Version>
		<Sender>$3</Sender>
		<Receiver>$4</Receiver>
		<Type>ISA_HARCODED</Type>
	</Identifier>
</Identifiers>
		

XML tags :

IdentifyByRegex	This XML tag represents the regular expression used to identify a specific message. It takes two attributes: 'length', which   is the number of bytes of the original message that we need to use for identification (try to use the smallest one possible   to increase performance if you have long messages) and 'encoding', which is the encoding of the messages that you will   send.
Format,Version,Type,Sender,Receiver	These are the 5 values that we want to extract from our message. Under those tags, you will find three extraction types,   as described below.

Extractor types :

Regex	This xml tag takes two children tags : 'Expression' which represents the regular expression matching the values you want to extract. Use parentheses in the   regex to create matching group. And 'Value' that will use the matching groups from the Expression to create a value. Use '$1' to insert matching group 1, $2   for matching group 2, etc...
Xpath	You can extract value with an Xpath expression (if the message in input is an XML of course). Just write the xpath expression in the xml content.
Value	You can put a hardcoded value directly within the parent tag. $i can be used to add a matching element from the identifying pattern (IdentifyByRegex tag).

Note: In Babelway, we're using the standard Java version of REGEX, and it's the same used all over the system.

This is another example of how to identify a CSV file

This is a sample of the CSV file

SenderID,ReceiverID,MessageKey,DocumentType , DocumentNumber , Date , Time, ItemNumber, ItemDescription, ItemQuantity, ItemPrice
8431598762018,2139854706451,1ae187a1-afe7-108e-9343-37971a38b936,InvoiceDocument,17052017,0205,01,Item Description 1,3,15.75
8431598762018,2139854706451,108e9343-e187-e933-71a3-187a1afe7108,InvoiceDocument,17052017,0205,02,Item Description 2,1,75
8431598762018,2139854706451,71a3187a-43e1-7a1a-ae18-97a57c17423a,InvoiceDocument,17052017,0205,03,Item Description 3,5,5.5
8431598762018,2139854706451,aae1848c-7618-a0c1-f941-37971a38b936,InvoiceDocument,17052017,0205,04,Item Description 4,7,17
8431598762018,2139854706451,0ca57c1f-c7ff-4952-c5af-12a0c1f941a3,InvoiceDocument,17052017,0205,05,Item Description 5,2,7
		

Below are the positions of the (Sender, Receiver, Type) that we will extract from the CSV file and use to create the Custom Identifier file.

The UniversalRouterSender will be extracted from the second row, first column.

The UniversalRouterReceiver will be extracted from the second row, second column.

The Type will search for "InvoiceDocument" in the CSV file.

The XML is defined as followed :

<?xml version="1.0" encoding="UTF-8"?>
<Identifiers>
	<Identifier>
		<IdentifyByRegex length="10000" encoding="UTF8"><![CDATA[(?i)\s?SenderID\s?,\s?ReceiverID\s?,\s?MessageKey\s?,\s?DocumentType\s?]]></IdentifyByRegex>
		<Format>CSV</Format>
		<Version>CSV-1.0</Version>
		<Sender>
		<Regex>
			<Expression><![CDATA[(?i).*?\n(.*?),]]></Expression>
			<Value>$1</Value>
		</Regex>
		</Sender>
		<Receiver>
		<Regex>
			<Expression><![CDATA[(?i).*?\n(.*?),(.*?),]]></Expression>
			<Value>$2</Value>
		</Regex>
		</Receiver>
		<Type>
			<Regex>
				<Expression><![CDATA[(?i)(\s?(InvoiceDocument)\s?,)]]></Expression>
				<Value>INVOICE</Value>
			</Regex>
		</Type>
	</Identifier>
</Identifiers>
		

Below is a print screen of the "contextOut.xml" file from the CSV file processed by the channel that has this Custom Identifier file showing the extracted information saved in the universal router metadatas.

Universal Router Metadatas

Note: To be able to get the value from an XML file containing a namespace, you will need to use the *: for the prefix in the XML path when using the xpath for the Custom Identifier file.

For example, below is the path to use if you want to get the value in the field "cbc:ID" from the below input message and save it in the "Type" for the custom identifier file.

Input Message With Namespace

The path is /*:Invoice/*:ID

The Path

Note: This extra processing is not executed while running a test case.

Delay execution

Allow to pause execution for some minutes before processing the message.

The parameters are :

Minutes to wait

The number of minutes that the system must wait before processing the message.

Note:

• This extra processing is not executed while resubmitting a message and the message should be received again via the Gateway IN in order to be delayed.
• This extra processing is not executed while running a test case.

- There is a new update of new splitters added in the Gateway In Extra processings recently.

As you can see from the below screenshot that the available splitters are marked with the green box.

 

 

Regex splitting

- To split a message by using regex expression and to process each transaction file separately.

The regex expression is used to split the message. E.g. Expression ','  split aa,bb,cc to aa bb cc

 

Xpath splitting

-  To split an XML type message by using XPath, the expression is used to select the content of the message.

 

Text splitting

- To split a file by many lines, it will split the file by the number of lines inserted on the extra processing.
ex: If you have a CSV files has 300 lines, and the splitter lines is 100 lines, then the CSV file will be splitted to 3 messages every one of them has 100 lines.