Key Parts of EDI Processing Logic

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.

OTD Message Structures

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.

Validations, Translations, Enveloping, and Acknowledgments

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.

---

Note –

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).

---

Note –

In eGate, X12 translations are called Java Collaboration Definitions (JCDs).

---

Message Information Levels

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.