Oracle® Application Server Integration B2B User's Guide
10g Release 2 (10.1.2) B19370-03 |
|
Previous |
Next |
This chapter describes the standard B2B protocols supported by OracleAS Integration B2B.
This chapter contains the following topics:
Table 3-1 lists the protocols—the agreed-upon formats for transmitting data—and the protocol revisions that OracleAS Integration B2B supports, categorized by protocol type. The protocols are described in more detail in subsequent sections.
Table 3-1 B2B Protocols Supported in OracleAS Integration B2B
Protocol Type | Protocol and Revision |
---|---|
The document protocol defines the document type of the message payload, which is based on which standard (RosettaNet, EDI, and so on) you are using as part of the business logic. |
|
The exchange protocol defines the message exchange mechanism—how to exchange the documents defined by the document protocol. It defines the headers, acknowledgments, and packaging that puts the headers and payload together. It also defines the transport protocol and packaging protocol for the exchange. |
|
|
|
|
|
The process protocol defines how you exchange messages, using the document protocol-based business document, and exchanging it based on the exchange protocol. It is the mechanism by which business actions and collaborations are associated with specific document types. |
|
The document protocol defines the document type of the message payload. Business protocols can have multiple document protocols. Document protocols follow the hierarchy shown in Figure 3-1.
A document protocol can consist of multiple document protocol revisions. A document protocol revision can consist of multiple document types. A document type can consist of multiple document definitions, because you can start with one document definition and customize it for different trading partners. For document definition files, you can use the template library of the Windows-based OracleAS Integration B2B - Document Editor to create RosettaNet.xsd
and .dtd
files, EDI X12 and EDI EDIFACT.ecs
files and HL7 files that you then import into the OracleAS Integration B2B user interface. You cannot use OracleAS Integration B2B - Document Editor to define custom documents. See "OracleAS Integration B2B - Document Editor Overview" for more information.
OracleAS Integration B2B supports the following document protocols. The document protocols are discussed in more detail in subsequent sections.
Custom Documents (includes support for UCCnet)
Using Document Protocols in OracleAS Integration B2B
To use the standard document protocols for RosettaNet, EDI X12, EDI EDIFACT, and UCCnet message exchanges, you must import them into OracleAS Integration B2B.
See "Importing Support for Collaborations, Transaction Sets, and UCCnet Standards" for details.
See Also:
|
OracleAS Integration B2B implements the nonproprietary, XML-based RosettaNet standards to exchange documents over the Internet. RosettaNet standards prescribe when information should be exchanged, acknowledged, or confirmed, and how messages in an exchange should be packaged and physically exchanged between trading partners. RosettaNet standards are specified through the use of the RosettaNet Partner Interface Process (PIP), RosettaNet Dictionaries, and RNIF, which are described in subsequent sections.
OracleAS Integration B2B supports message exchanges using the RosettaNet PIPs shown in Table 3-2 when you create a collaboration. See "Process Protocols" for more information about PIPs.
Table 3-2 RosettaNet PIPs Supported in OracleAS Integration B2B
PIP | Description | Version |
---|---|---|
0A1 |
Notification of Failure |
V02.00.00 |
2A1 |
Distribute New Product Information |
V02.00.00 |
2A9 |
Query Technical Product Information |
V01.01.01 |
2A10 |
Distribute Design Engineering Information |
V02.00.00 |
2A12 |
Distribute Product Master |
V01.03.00 |
3A1 |
Request Quote |
V02.01.00 |
3A4 |
Request Purchase Order |
V02.03.00 |
3A6 |
Distribute Order Status |
V02.02.00 |
3A7 |
Notify of Purchase Order Update |
V02.03.00 |
3A8 |
Request Purchase Order Change |
V01.03.00 |
3A9 |
Request Purchase Order Cancellation |
V01.01.00 |
3B2 |
Notify of Advanced Shipment |
V01.01.00 |
3B3 |
Distribute Shipment Status |
R01.00.00 |
3B12 |
Request Shipping Order |
V01.01.00 |
3B13 |
Notify of Shipping Order Confirmation |
V01.01.00 |
3C1 |
Return Product |
V01.00.00 |
3C3 |
Notify of Invoice |
V01.01.00 |
3C4 |
Notify of Invoice Reject |
V01.00.00 |
4A1 |
Notify of Strategic Forecast |
V02.00.00 |
4A3 |
Notify of Threshold Release Forecast |
V02.01.00 |
4A4 |
Notify of Planning Release Forecast |
V03.00.00 |
4A5 |
Notify of Forecast Reply |
V02.00.00 |
4B2 |
Notify of Shipment Receipt |
V01.00.00 |
4C1 |
Distribute Inventory Report |
V02.03.00 |
7B1 |
Distribute Work in Process |
V01.00.00 |
You can see how a collaboration is created using PIP 3A4 in "Acme Server, Task 1: Creating the Collaboration" of tutorial 1.
See http://www.rosettanet.org
for information about the RosettaNet consortium and its history, and for details about RosettaNet standards.
The RosettaNet Business Dictionary provides a common vocabulary and a common set of properties to use in XML documents. For example, trading partners using the RosettaNet Business Dictionary might agree to use the term DRAM for memory chip. The RosettaNet Technical Dictionary is not supported in OracleAS Integration B2B.
RosettaNet validation compares the elements in RosettaNet XML-format business documents to the requirements specified in the RosettaNet Message Guideline specification to determine their validity. This specification defines requirements for details such as element datatypes, element lengths, element value lists, and element cardinality. PIPs that require RosettaNet dictionary validation are also validated when a dictionary is present.The minimum validation-level requirements on the sections of a RosettaNet XML-format business document are as follows. These requirements cover the preamble, delivery header, service header, and service content sections of a document. Documents not following one or more of these requirements are identified as invalid.
The XML-format business document requires compliance with its DTD.
Elements with datatypes, lengths, or both that are specified in the RosettaNet Message Guideline specification require validation against this specification.
An element's list of values specified in the entity instance list in the corresponding RosettaNet Message Guideline specification requires validation against this specification.
If the Message Guideline specification defines the cardinality specification of an element differently from the corresponding DTD specification, the Message Guideline specification takes precedence.
If a PIP requires dictionary validation, and a dictionary is included, the service content requires validation against the dictionary as a part of action performance.
Cross-tag validation is based on message guidelines.
OracleAS Integration B2B supports message exchanges using American National Standards Institute (ANSI) X12. These standards prescribe the formats, character sets, and data elements used in the exchange of documents such as purchase orders and invoices. You can use the X12 transaction sets shown in Table 3-3 when you create a business action.
Table 3-3 EDI X12 Transaction Sets Supported in OracleAS Integration B2B
Set | Description | Version |
---|---|---|
850 |
Purchase Order |
4010 |
855 |
Purchase Order Acknowledgment |
4010 |
997 |
Functional Acknowledgment |
4010 |
You can see how a business action is created using the 850, 855, and 997 transactions in "Acme Server, Task 1: Creating the Business Actions" of tutorial 3.
See http://www.ansi.org
for information about the organization that created and maintains the ANSI X12 standards.
OracleAS Integration B2B supports message exchanges using UN/EDIFACT, the United Nations Electronic Data Interchange for Administration, Commerce and Transport. These standards prescribe the formats, character sets, and data elements used in the exchange of documents such as purchase orders and invoices. You can use the EDI EDIFACT transaction sets shown in Table 3-4 when you create a business action.
Table 3-4 EDI EDIFACT Transaction Sets Supported in OracleAS Integration B2B
Set | Description | Version |
---|---|---|
ORDERS |
Purchase Order Message |
D98A |
ORDRSP |
Purchase Order Response Message |
D98A |
CONTRL |
Syntax and Service Report Message |
D3 |
You can see how a business action is created using the ORDERS, ORDRSP, and CONTRL transactions in "Acme Server, Task 1: Creating the Business Actions" of tutorial 2. See Chapter 14, "Batching and Debatching EDI Transaction Sets" for information about EDI batching support.
See http://www.unece.org
for information about the organization that created and maintains the UN/EDIFACT standards.
You can use the Custom Document protocol to create documents needed for proprietary transaction mechanisms. With the Custom Document option, you can create document definitions for XML and non-XML messages. With XML messages, you have the advantage of schema enforcement (.xsd). With non-XML messages, you can create trading partner agreements for specific message types.
To configure a custom document, you specify the rules to identify the incoming document. For XML documents, you specify an XPath expression and a value, which is the expected result of the expression. See "Configuring the XPath Expression for a Custom XML Document" for more information.
OracleAS Integration B2B provides support for UCCnet under the Custom Document option. UCCnet is a service that enables trading partners to exchange standards-compliant data in the retail and consumer goods industries. When you use Custom Document, the message contents are not translated or validated. You can use the UCCnet standards shown in Table 3-5 when you create a Custom Document protocol.
As with the other protocols, Custom Document has the following features available: authentication, authorization, nonrepudiation of origin and content, nonrepudiation of receipt, time to perform, time to acknowledge, and retry counts.
Table 3-5 UCCnet Standards Supported in OracleAS Integration B2B
Standard | Version |
---|---|
registerCommand |
2.3.1 |
confirmCommand |
2.3.1 |
linkCommand |
2.3.1 |
checkComplianceCommand |
2.3.1 |
documentCommand |
2.3.1 |
documentIdentificationCommand |
2.3.1 |
notificationStateCommand |
2.3.1 |
queryCommand |
2.3.1 |
registerLinkCommand |
2.3.1 |
publicationCommand |
2.3.1 |
publishCommand |
2.3.1 |
catalogueItemMaintenanceCommand |
2.3.1 |
priceCommand |
2.3.1 |
validateCommand |
2.3.1 |
registerOwnershipCommand |
2.3.1 |
subscriptionCommand |
2.3.1 |
notifyCommand' |
2.3.1 |
response' |
2.3.1 |
See http://www.uccnet.org
for further descriptions of UCCnet standards
OracleAS Integration B2B implements the Health Level 7 (HL7) version 2.x standard to exchange documents containing health care information using the Generic exchange or MLLP exchange. When using HL7, the standard OracleAS Integration B2B features, such as validation, translation, automatic generation of outbound envelope headers, and acknowledgments, are available. HL7 BATCH and FILE envelopes are not supported in this release.
You can see how a business action is created using the HL7 over MLLP business protocol in "Acme Server, Task 1: Creating the Business Actions" of the health care tutorial.
See http://www.hl7.org
for more information.
The exchange protocol defines the headers, acknowledgments, and packaging that puts the headers and payload together (the message exchange mechanism). The exchange protocol also defines exchange-level security—signing and encryption—and transport protocols for the exchange.
OracleAS Integration B2B supports the following exchange protocols:
Exchange protocol guidelines are described in Table 3-6.
Table 3-6 Exchange Protocol Guidelines
Guideline | Description |
---|---|
Transport |
Supports multiple transport protocols (such as secure HTTP and SMTP) for delivering business messages between trading partners |
Packaging |
Supports the multipurpose internet mail extensions (MIME) format |
Authorization |
Ensures that a message sender is authorized to send the subject message to the receiving partner |
Authentication |
Requires a message sender to digitally sign a message |
Encryption |
Ensures that messages transmitted can be seen only by the expected recipient, who is able to decrypt and extract the business data |
Nonrepudiation |
Provides absolute evidence that a specific action occurred. This ensures that an originating trading partner cannot deny having sent a message and a receiving partner cannot deny having received a message. The following nonrepudiation types are available:
|
The transport protocol and packaging protocol are components of the exchange protocol. The following transport and packaging protocols are supported in OracleAS Integration B2B:
Transport protocols
HTTP
HTTPS
File
FTP
FTPS
TCP/IP
Packaging protocols
MIME
S/MIME
SOAP
XMLDSig
XMLEncrypt
See the following for more information:
Figure 1-1 for how the protocols fit into the OracleAS Integration B2B architecture
"Viewing Exchange Protocols" for details about exchange protocols
RNIF defines implementation guidelines for creating software applications that provide for the reliable transport of PIPs in XML-format business documents between trading partners. Guidelines are provided for transport, routing, packaging, security, signals, and trading partner agreements.
RNIF specifies the envelope or container format that remains constant when exchanging business documents (the payloads), whereas the document exchange choreography and the XML schemas vary based on which PIP and document type are used. The RNIF envelope format is also independent of the specific transfer protocol you use.
OracleAS Integration B2B supports RNIF revisions 1.1 and 2.0. RNIF 2.0 does not include the proprietary aspects of RNIF 1.1, and adds support for multiple transfer protocols, hub-based routing, attachments, payload encryption, and more.
See http://www.rosettanet.org
for the white paper (in PDF) "RosettaNet Implementation Framework (RNIF) 2.0: Benefits of RNIF 2.0 and Comparison to RNIF 1.1" for a thorough discussion of the two versions
AS2 is a specification for using EDI over the Internet. AS2 provides S/MIME encryption and security over HTTP or HTTPS. AS2 works with non-EDI document types such as .xml
, .txt
, .doc
, and .xls
. AS2 is also called EDI over the Internet, or EDIINT AS2. AS2 interoperability is certified in OracleAS Integration B2B.
You can see how an EDI over the Internet (AS2) transaction is created in "Tutorial 3: Setting Up an EDI X12 over Internet (AS2) Transaction".
See Chapter 9, "Creating Trading Partners" for information about digital signatures, encryption, and signing credentials
Using the Generic option, you can send messages with or without security, using any of the transport protocols listed in Table 3-1. The Generic exchange protocol supports MIME and S/MIME, including S/MIME 3.0-based signing and encryption. There is no receipt acknowledgment support with the Generic exchange protocol (acknowledgment mode must be set to None on the Delivery Channel page of the Create Trading Partner wizard).
Minimum Lower Layer Protocol (MLLP) is used with HL7 or Custom documents. When using this protocol, you can identify the remote trading partner at the MLLP exchange level by creating a new MLLP Trading Partner Identification Type, or you can identify the remote trading partner at the document level. See "Setting Up the Remote Trading Partner (GlobalChips)" for an example of creating an MLLP ID.
Electronic business Extensible Markup Language (ebXML) Messaging Service (ebMS) is used to exchange XML documents. ebMS is built on a SOAP Web services message format. OracleAS Integration B2B implements ebMS 1.0 and 2.0 and uses the HTTP, HTTPS, and Email transport protocols and the SOAP packaging protocol. The ebMS protocol supports correlation between documents. OracleAS Integration B2B also supports XMLDSig, XML Encrypt, and gZip-based compression for large documents. ebMS interoperability is certified.
The process protocol defines how documents are exchanged. OracleAS Integration B2B supports complex processes such the RosettaNet PIP or simple processes, such as exchanging a single EDI business action. OracleAS Integration B2B provides the B2B process protocol, which is included with all business protocols supported in OracleAS Integration B2B. The B2B process protocol defines the business actions (for EDI or Custom Document business protocols) and the collaborations (for the RosettaNet over RNIF business protocol) that are associated with specific document types.
See the following for more information:
Figure 8-7, "Process Protocol Management Tasks for any EDI, HL7, or Custom Document Business Protocol" for an example of business actions defined for the B2B process protocol
Figure 8-8, "Process Protocol Management Tasks for the RosettaNet over RNIF Business Protocol" for an example of collaborations defined for the B2B process protocol
A PIP is an XML-based dialog that defines the business processes between trading partners. It defines the structure, sequence of steps, roles (buyer and seller) activities, data elements, values, and value types for each business document message exchanged between trading partners.
PIPs bundle the steps of the business process together. You can see this in "Tutorial 1: Setting Up a RosettaNet over the Internet Transaction", in which only a few steps are needed to associate the buyer and seller (trading partners) with the 3A4 collaboration.
Using PIP 3A4 as an example, you can see how a PIP defines a dialog between trading partners, as shown in Figure 3-2. The figure shows how the PIP 3A4 messages are exchanged between buyer and seller.
A PIP sequence combines a cluster, segment, and type. The PIP sequence 3A4, for example, encodes the information shown in Table 3-7.
Table 3-7 PIP 3A4 Breakdown
Element | Description |
---|---|
3 |
Order manage cluster, which lets trading partners:
|
3A |
Quote and order entry segment |
3A4 |
Specific PIP type, which supports:
|
See the following for more information:
Table 3-2 for a list of PIPs supported in OracleAS Integration B2B
http://www.rosettanet.org
for a complete list of PIP clusters and segments
OracleAS Integration B2B provides business protocols, which bundle common message exchange options. The business protocols capture combinations needed to integrate typical B2B scenarios. Each business protocol combines a document protocol, an exchange protocol, and the B2B process protocol. OracleAS Integration B2B provides the following business protocols:
Custom Document over Generic Exchange
Custom Document over Internet
Custom Document over MLLP Exchange
Custom Document over ebMS
EDI EDIFACT over Generic Exchange
EDI EDIFACT over Internet
EDI X12 over Generic Exchange
EDI X12 over Internet
HL7 over Generic Exchange
HL7 over MLLP Exchange
RosettaNet over RNIF
You can see this list by clicking Partners, then Protocols.
The business protocols are flexible. After you select a business protocol, you have choices as you define the operational capability and communication capabilities of the business protocol of the remote trading partner and the communication capabilities of the host trading partner.
See "Business Protocol Management Overview"
OracleAS Integration B2B is flexible in how you mix and match protocols (described in Table 3-1) and in allowing you to create your own custom documents. For example, you can create the following:
A custom XML document sent over HTTP or SMTP, with encryption and compression options
An EDI transaction set sent using FTP, with encryption
An EDI X12 transaction set sent over AS2, with signing, compression, and encryption options
A RosettaNet document sent over RNIF 1.1 or RNIF 2.0, with signing
A UCCnet document sent over AS2
See Chapter 8, "Managing Business Protocols" for the options that are available as you create business actions and collaborations for a business protocol.
This chapter describes the support OracleAS Integration B2B offers for standard B2B protocols such as RosettaNet, EDI X12, EDI EDIFACT, HL7, AS2, and UCCnet. The document, exchange, and process protocols are described, as well as the business protocol, which is a combination of the protocols. It also describes options for using Custom Documents to mix and match protocols.