Components of the iWay Integration Solution for EDI
iWay business components used in the construction of
a message flow for EDI transactions include:
- An Ebix (e-Business
Information Exchange)
- A preparser
- An acknowledgement
service
- A preemitter
x
iWay Software provides various e-Business Information
Exchange (Ebix) files used in conjunction with the iWay integration
solutions. In iWay Service Manager, the iWay Integration Solution
for EDI contains several Ebix files, one for each supported EDI ANSI
X12 transaction set.
An Ebix file for EDI-X12 s named X12_transaction_set.ebx,
where transaction_set is the transaction set number. For
example, the Ebix file for EDI X-12 transaction set 4050 is named
X12_4050.ebx.
For details on the supported EDI X-12 transaction sets, see Ebix-Supported Transaction Sets.
An Ebix is a collection of metadata that defines the structure
of data. The Ebix supplied with the iWay Integration Solution for
EDI defines the structure of supported EDI messages.
Each Ebix includes:
x
A preparser is an iWay business component that converts
incoming messages into processable documents.
Typically a preparser converts a non-XML document into XML format.
The preparser for the iWay Integration Solution for EDI converts
an incoming EDI-X12 formatted document to XML format.
The EDIX12SplitterPreParser is provided by iWay Software for
the iWay Integration Solution for EDI.
x
The EDIX12SplitterPreParser (com.ibi.preparsers.EDISplitPP)
parses an EDI input file that contains one or more interchanges
(ISA) and multiple documents, and creates multiple XML output files.
One XML output file is produced for each document.
For example, if the EDI input file contains three documents within
one ISA, the EDIX12SplitterPreParser creates three XML output files,
one per document.
Use the EDIX12SplitterPreParser for large files with multiple
documents within one ISA; if there is a specific business requirement
to create separate XML output files; or if you receive multiple
documents within one ISA and want to separate each document for
further business processing. You can also use the EDIX12SplitterPreParser
if there is only one document within the ISA.
You can also run the EDIX12SplitterPreParser in a splitter
only mode based on configuration. The output files are in X12
format, one document per file with a wrapper consisting of the original
interchange. This option can be used to separate and route documents
prior to transformation, in conjunction with several of the SREG
values that are available. For example, you may receive text-based
documents that you want to simply email rather than transform. Or
you may want to separate your documents by document type, which
would allow you to process all purchase orders immediately and all
sales reports overnight in a batch mode if required.
x
The EDIBatchSplitter (com.ibi.preparsers.XDEDIBatchSplitter)
parses an EDI input file that contains one or more interchanges
(ISA) and multiple documents. You must use this preparser with the
EDIX12PreParser (com.ibi.preparsers.XDEDIpreParser). The EDIBatchSplitter
should not be used as a standalone preparser. To successfully transform
an inbound X12 input file using this preparser, you must also include
the EDIX12PreParser in your channel Inlet.
One XML output file is produced for each document that is processed
through this Inlet definition. For example, if your EDI input contains
three documents within an ISA, the EDIBatchSplitter/EDIX12Preparser
will create three XML output files, one for each document.
x
An acknowledgement service is an iWay business component
used in inbound processing to create a functional acknowledgement
(997) for inbound messages.
An acknowledgement indicates that an inbound document was received
and validated for structure against the appropriate standard. An
acknowledgement does not indicate that a document was processed.
An acknowledgement is typically routed back to the originator
of the inbound document or to the next step in the integration process.
It is a best business practice to send an acknowledgement to the
originator of the inbound document.
The acknowledgement service for the iWay Integration Solution
for EDI is called EDIX12AckAgent (com.ibi.agents.XDX12AckAgent).
The iWay Integration Solution for EDI creates one acknowledgement
for each interchange that is received.
x
A preemitter is a logical process that handles a document
immediately before transmission.
Typically a preemitter is used to convert an XML document to
non-XML format. The XML document is created from EDI input data
in inbound processing. The iWay Integration Solution for EDI uses
a preemitter in outbound processing to convert the XML-formatted
EDI document to an EDI-X12 formatted document.
The XML structure must be compliant with the schema supplied
in the Ebix.
The preemitter for the iWay Integration Solution for EDI is called
EDIX12PreEmitter (com.ibi.preemit.XDX12PreEmitter).
x
Data Segments and Data Elements
The following example shows what an 850 purchase order
looks like. Each line is called a Data Segment and
begins with the Segment Name. For example,
'N1' represents name and address line 1 while 'PO1' represents purchase
order line 1.
Following the Segment Name are a number of Data Elements. In
the N1 segment, the code 'BT' means it's a bill-to name and address.
Data elements are separated by a single character, usually an asterisk
(*). A segment ends with a single character-- in this example a
tilde (~).
Other EDI documents such as an 835 Health Care Claim will have
their own sets of data segments and data elements. Segments such
as the N1 overlap many transaction sets, but an 835 will have its
own segments and elements that are unique to health care.
Any number of data segments come together to form a transaction
set. In this example, there are 32, as shown in the control counter
stored in the very last segment (SE). You will notice that the PO1,
PID and PO4 segments repeat multiple times, just as they would on
a paper-based purchase order.
There is flexibility in how an industry or company uses the EDI
standards. For example, a purchase order going from a retailer to
its supplier will look very different from a purchase order going
from a mining company to its supplier. The drawback is when one
supplier receives purchase orders from five different customers
and they each structure their 850s differently. The supplier is
burdened with the task of handling the five different 850 layouts.