The key parts of EDI processing logic are listed in Table 2–1.
Table 2–1 Key Parts of EDI Processing
Term |
Description |
Language Analogy |
eGate Component |
---|---|---|---|
Structure |
Format, segments, loops |
Syntax rules |
OTD elements and fields |
Validation |
Data contents “edit” rules |
Semantic rules |
Validation methods |
Translation (also called mapping) |
Reformatting or conversion |
Translation |
Collaborations, Java Collaboration Definitions (JCDs) |
Enveloping |
Header and trailer segments |
Envelope for a written letter |
Special “envelope” OTDs: FunctionalGroupEnv and InterchangeEnv |
Ack |
Acknowledgments |
Return receipt |
Specific acknowledgment elements in the OTD |
eGate uses the structures, validations, translations, enveloping, and acknowledgments, as explained in the remainder of this section, to support the X12 standard.
The X12 OTD Library includes pre-built OTDs for all supported X12 versions. These OTDs can be viewed in the OTD Editor, but cannot be modified.
To customize the OTD structure , for example, to add a segment or loop , you must first generate a .sef file (typically using a third-party application). You then use the SEF OTD Wizard to generate the OTD.
Within each X12 OTD are Java methods and Java bean nodes for handling validation. The marshal and unmarshal methods of the two envelope OTDs handle enveloping and de-enveloping.
For more information on these OTDs, see the X12 OTD Library User’s Guide.
No prebuilt translations are supplied with the X12 OTD Library. You build data translations with an eGate Enterprise Designer user interface called the Java Collaboration Editor (JCE).
In eGate, X12 translations are called Java Collaboration Definitions (JCDs).
The following levels of information guide the final format of a specific X12 transaction:
X12 Standard: The Accredited Standards Committee publishes a standard structure for each X12 transaction.
Industry-specific Implementation Guides: Specific industries publish Implementation Guides customized for that industry. Normally, these guidelines are provided as recommendations only. However, for the sake of uniformity and compatibility, it is extremely important to follow these guidelines.
TP Agreements: It is normal for TPs to have individual agreements that supplement the standard guides. The specific processing of the transactions in each TP’s individual system can vary from one site to another. Because of this, additional documentation providing information about the differences is helpful to the site’s TPs and simplifies implementation. For example, although a certain code might be valid in an implementation guide, a specific TP might not use that code in transactions. In such a case, it could be important to include that information in a TP agreement.