This chapter describes the process of creating and deleting document definitions. It also covers the concept of document protocols.
Creating document definitions is the second step in the Oracle B2B process flow. A document definition specifies the document protocol—the document protocol version and document type—that is used to validate the message. The document definition can be an ECS file, in the case of EDI and HL7 messages, or an XSD/DTD, in the case of XML messages.
The same document definition is used by both the host and remote trading partner in a transaction. It must adhere to the standards for document protocols, protocol versions, and document types. This is straightfoward when you use Oracle B2B Document Editor to create the document guideline files (Step 1) and then the Oracle B2B interface to import those files when creating the document definition (Step 2).
This chapter includes the following sections:
For more information on document protocols, see Using Document Protocols .
Using the Custom protocol and the many guideline documents in Oracle B2B Document Editor, you can define most protocols. When you add a new document protocol, it is always a Custom document.
Oracle B2B supports these document protocols:
Custom
EDI_EDIFACT
EDI_X12
HL7
OAG
PositionalFlatFile
RosettaNet
UCCNet
UserDefined
As part of the document definition, you provide the document guideline files, which are typically created in Oracle B2B Document Editor. (For Custom documents, you cannot use Oracle B2B Document Editor.) If validation is enabled, then, at runtime, the payload must conform to the document definition file type you use.
You can think of a document protocol as a hierarchy, as shown in Figure 4-1.
A document protocol can consist of multiple document protocol versions. A document protocol version can consist of multiple document types. A document type can consist of multiple document definitions. Typically, you start with one document definition and customize it for different trading partners.
Figure 4-2 shows a document protocol hierarchy as it applies to EDI X12.
In the Oracle B2B interface, as you create a document definition, the document protocol hierarchy is reflected in the definition:
DocumentProtocol—Version—DocumentType—DocumentDefinitionName
Example 4-1 shows the hierarchy reflected in the definition for an EDI EDIFACT document.
Example 4-2 shows examples of document definitions for a Health Care 7 admit/visit notification and an X12 version 4010 purchase order, respectively.
Example 4-1 Document Definition Name for an EDI EDIFACT Document
Document protocol: EDI_EDIFACT
Document protocol version: D98A
Document type: ORDERS
Document definition: ORDERS_def
The resulting document definition is
EDI_EDIFACT-D98A-ORDERS-ORDERS-def
Example 4-2 Document Definition Names for HL7 and X12 Documents
HL7-2.3.1-ACK_A01-ACK_A01_Doc_Def
EDI_X12-4010-850-850def
For any message flow that involves an acknowledgment, Oracle B2B sends an acknowledgment only after. Resubmission does not generate another acknowledgment if the message has already been acknowledged. If further information about the message state is needed, then the trading partner must be notified by some other means (for example, email).
After using Oracle B2B Document Editor to create the transaction set files, use the Oracle B2B interface to create the document definition and import the transaction set files.
Note:
You cannot edit the document version, document type, and document definition after they are created. You must delete the specific document element (version, type, or definition) and create a new one. Updating the document elements after creation can lead to metadata inconsistency, metadata validation issues, and runtime errors.