When you exchange EDI X12 and EDIFACT messages with your partners, B2B Gateway uses XML interface files between the custom mappings and the pre-packaged EDI processing mappings. The XML interface files use the structure and naming conventions from the EDI X12 and EDIFACT standards.
When you receive EDI and EDIFACT messages from partners, the pre-packaged, EDI processing mappings validate the inbound messages and convert them to XML interface files, one file for each message type.
To send messages to partners, you create interface files and place them on B2B Gateway. You create an interface file for each type of message that you send to partners. The gateway creates a valid EDI message file for each interface file and sends the message files to the partners.
The structure and elements of an interface file reflect the structure and elements of the relevant EDI X12 or EDIFACT standard for the specific message type. For example:
•For an EDI X12 outbound message for message type 810, the interface file reflects the structure for message type 810.
•For an EDIFACT inbound message for message type ORDERS, the interface file reflects the structure for message type ORDERS.
The pre-packaged schemas for B2B Gateway can be loaded into Data Integration during organization provisioning, or any time after provisioning. The pre-packaged schemas are used in the Hierarchy Parser and the Hierarchy Builder transformations to define the expected structure of an inbound or outbound interface file. Each message type and version has its own schema. Before you create an interface file, study the schema for the message type so that you structure the hierarchy correctly.
Structure of the interface file for EDI messages
The interface file for a specific EDI message uses the structure and naming conventions from the EDI X12 or EDIFACT standard for that message.
The EDI interface file contains the following root element:
•EDI X12: <interchanges> element.
•EDIFACT: <interchange> element.
Within the root element is a message type element, for example <x12:TS_810> in EDI X12 or <TS_INVOIC> in EDIFACT, and loop elements, segment elements, and data elements. For each element in the standard, there is a matching element in the interface file. The loop, segment, and data elements use the naming conventions in the EDI X12 or EDIFACT standard.
Structure of segment
In the interface file, the segment element uses the segment ID as the name of the corresponding XML element. Data elements within the segment use the reference element ID with the prefix R as the name of the corresponding XML element.
The following XML shows the syntax of a segment element that contains data elements:
<segment ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> ... </segment ID>
Example of an EDI X12 segment
As an example, in the 810 message, the segment ID for the Transaction Set Header segment is ST. The segment contains three data elements. The following table describes the data elements according to the EDI X12 standard:
Name of data element
Reference element ID
Transaction Set Identifier Code
01
Transaction Set Control Number
02
Implementation Convention Reference
03
The following XML represents the Transaction Set Header segment in the interface file:
As an example, in the INVOIC message, the segment ID for the UNH Message Header segment is UNH. The segment contains seven data elements. The following table describes the data elements according to the EDIFACT standard:
Name of data element
Reference element ID
Message reference number
010
MESSAGE IDENTIFIER
020
Common access reference
030
STATUS OF THE TRANSFER
040
MESSAGE SUBJECT IDENTIFICATION
050
MESSAGE IMPLEMENTATION GUIDELINE IDENTIFICATION
060
SCENARIO IDENTIFICATION
070
The following XML represents the UNH Message Header segment in the interface file:
The loop element uses the loop ID from the EDI standard as the name of the corresponding loop XML element with the prefix LOOP_.
The following XML shows the syntax of a loop element that contains segments with data elements:
<LOOP_loop ID> <segment ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> ... </segment ID> <segment ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> ... </segment ID> ... </LOOP_loop ID>
Example of an EDI X12 loop
As an example, in the outbound EDI X12 810 message, the Baseline Item Data loop (IT1) contains two segments, IT1 and TX1, and another loop, the Product/Item Description loop (PID).
The following XML represents an IT1 loop in the interface file:
As an example, in the outbound EDIFACT INVOIC message, loop 26 contains three segments, LIN, IMD_1, and QTY_2, and two other loops, loop 27 and loop 29.
The following XML represents loop 26 in the interface file:
Occasionally the EDI standard contains different loops with the same loop ID. In the interface files these loops use the suffix _number to distinguish between them. The number of the loop reflects the order in which it appears in the EDI standard.
The following XML shows the syntax of two different types of loop elements with the same loop ID:
<LOOP_loop ID_1> <segment ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> ... </segment ID> ... </LOOP_loop ID_1> <LOOP_loop ID_2> <segment ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> <data element reference ID>...</data element reference ID> ... </segment ID> ... </LOOP_loop ID_2> ...
Schemas of the interface file for EDI messages
B2B Gateway contains pre-packaged schemas that define the expected structure of an inbound or outbound interface file for EDI messages. Each message type and version has its own schema.
The schemas are located in the directory <secure_agent_installation>\main\rdtmDir\DT\ServiceDB, inside a project folder with the following naming convention:
For EDI X12 messages, the Script object can be either a Parser or a Restricted Serializer (Restricted_Serializer). For EDIFACT messages, the Script object can be a Serializer (Serializer).
If you trace through the schema of an inbound message, you can determine the relationship between the elements of the schema and the interface file. For an outbound message, use the schema to determine the expected structure of an interface file. Before you create an outbound interface file, study the relevant schema for the message type so that you structure the hierarchy correctly.
Example of an outbound interface file for EDI X12 messages
The outbound interface file for EDI X12 messages contains a root element, message type element, loop elements, segment elements, and data elements.
The following XML represents an interface file for an outbound message of type 810:
The root element for an outbound interface file is specified as <x12:interchange> to identify the message as an EDI X12 message. The message type element <x12:TS_810> identifies the message as message type 810.
If you trace through the interface file, you can determine the relationship between the elements of the file. The hierarchy contains different IT1 loop elements that contain PID loop elements, and a SAC loop element.
The interface file also contains segment elements with data elements.
Example of an inbound interface file for EDI X12 messages
The inbound interface file for EDI X12 messages contains a root element, message type element, delimiters, loop elements, segment elements, and data elements.
The following XML represents an interface file for an inbound message of type 850:
If you trace through the hierarchy of the interface file, you can see that there are multiple interchanges. The hierarchy reflects the structure of the relevant message type, the schema, and the type of information that the customer sent.
You can pass the data from this interface file to a backend system for further processing.
Example of an outbound interface file for EDIFACT messages
The outbound interface file for EDIFACT messages contains a root element, message type element, loop elements, segment elements, and data elements.
The root element for an outbound interface file is specified as <interchange> to identify the message as an EDIFACT message. In this example, the message type element <TS_INVOIC> identifies the message as message type INVOIC.
Example of an inbound interface file for EDIFACT messages
The inbound interface file for EDIFACT messages contains a root element, message type element, delimiters, loop elements, segment elements, and data elements.
The root element for an inbound interface file is specified as <interchange> to identify the message as an EDIFACT message. In this example, the message type element <TS_ORDERS> identifies the message as message type ORDERS.
If you trace through the hierarchy of the interface file, you can see that there are multiple interchanges. The hierarchy reflects the structure of the relevant message type, the schema, and the type of information that the customer sent.
You can pass the data from this interface file to a backend system for further processing.