4.2.6. Gateway IN extra processings – Babelway

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.

Set custom metadata

Allow you to define some user defined metadata at the "Gateway In" step to be used in the next channel elements or in the next channels if exists.

The "Value" field can be an XPath formula allowing to calculate the value dynamically, And when needed to use simple static text then the static text value will need to be surrounded by a single quote to use this value as a string value.

The Babelway functions can be used in the formulas for the "Value" field.

Note: Please make sure that the expression implemented in the "Value" field is valid based on xpath specification for XPath formula, Babelway function and simple static text value.

Ex:

1-Simple static text

Name: EmailList

Value: 'exemple@xyz.com'

2-XPath formula

Name: Current date

Value: current-date( )

Replace message content by metadata

Allow you to the message content by using metadata.

Metadata name: That contains the new content of the message.

New in filename: Allow to change the in file name by a new one.

Error if empty: If checked, the message will be set to error if the metadata is empty, otherwise the message continue with unchanged data.

Decode Base64 message content

This Extra processing doesn't need any parameter.

Report success

This extra processing allows the system to generate a success report of the message status and sends it to another channel after the successful processing of the message.

The parameters are :

Target Gateways

Gateways in which the message report should be sent.

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

Report success by mail (deprecated)

This extra processing allows the system to generate a success report of the message status and sends it by email to the previously defined emails after the successful processing of the message.

The parameters are :

Add original message as attachment	Check in order to attach the original message to the email.
Receivers	List emails of your recipients.
Sender	Email that will be used as sender of the email. Note that if you use another domain than babelway's that there is network configuration involved to make sure that the emails aren't flagged as spam when sent by our servers for your domain.
Subject	Subject of the email.
Body	Body of the email.

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

Report error

This extra processing allows the system to generate an error report of the message status and sends it to another channel after the message processing failure.

The parameters are :

Target Gateways

Gateways in which the message report should be sent.

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

: A notification will be send regardless at which level the message fail on error

Report error by mail (deprecated)

This extra processing allows the system to generate an error report of the message status and sends it by email to the previously defined emails after the message processing failure.

The parameters are :

Add original message as attachment	Check in order to attach the original message to the email.
Receivers	List emails of your recipients.
Sender	Email that will be used as sender of the email. Note that if you use another domain other than babelway domain that there is network configuration involved to make sure that the emails aren't flagged as spam when sent by our servers for your domain.
Subject	Subject of the email.
Body	Body of the email.

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

: A notification will be send regardless at which level the message fail on error