|
Oracle® Application Server ProcessConnect User’s Guide
10g (9.0.4) Part No. B12121-02 |
|
|
|
|
Oracle® Application Server ProcessConnect User’s Guide
10g (9.0.4) Part No. B12121-02 |
|
|
|
|
This chapter describes the RosettaNet business-to-business (B2B) protocol standard and its implementation of trading partner agreements, and how Oracle Application Server ProcessConnect provides support for both.
This chapter contains these topics:
Oracle Application Server ProcessConnect Support for RosettaNet
Oracle Application Server ProcessConnect Support for Trading Partner Agreements
RosettaNet and Oracle Application Server ProcessConnect Terminology Differences
|
See Also:
|
B2B integrations enable trading partners to communicate with other trading partners outside an enterprise and over a network. B2B integrations use B2B protocol standards. B2B protocol standards provide guidelines for trading partners to follow when conducting business between enterprises. One B2B protocol standard is RosettaNet. Figure 24-1 shows RosettaNet’s role in a B2B integration.
This chapter provides key details about the RosettaNet B2B protocol.
|
See Also:
|
RosettaNet is a group of leading technology companies that have created and implemented a common set of nonproprietary, XML-based, e-business standards. These standards define how trading partners conduct business through the exchange of business documents over the Internet.
The following sections describe key details about RosettaNet, as shown in Figure 24-2:
|
See Also: "Oracle Application Server ProcessConnect Support for RosettaNet" for details on how Oracle Application Server ProcessConnect supports these key RosettaNet details |
The RosettaNet Implementation Framework (RNIF) defines implementation guidelines for creating software applications that provide for the reliable transport of partner interface processes (PIPs) in XML-format business documents between trading partners. Guidelines are provided for transport, routing, packaging, security, signals, and trading partner agreements.
These sections describe features of the following RNIF versions:
|
See Also: "Oracle Application Server ProcessConnect Support for the RosettaNet Implementation Framework" for additional details on how Oracle Application Server ProcessConnect supports RNIF implementation guidelines |
Table 24-1 describes several RNIF version 1.1 implementation guidelines.
Table 24-1 RNIF Version 1.1 Guidelines
|
See Also: Version 1.1 of the RosettaNet Implementation Framework: Core Specification available at the RosettaNet home page: |
Table 24-2 describes several RNIF version 2.0 implementation guidelines.
Table 24-2 RNIF Version 2.0 Guidelines
|
See Also: Version 2.0 of the RosettaNet Implementation Framework: Core Specification available at the RosettaNet home page: |
This section contains the following PIP topics:
The exchange of business data between trading partners is the fundamental purpose of PIPs. PIPs are specialized, XML-based dialogs that define the structure, sequence of steps, role (buyer and seller) activities, data elements, values, and value types for each business document message exchanged between trading partners. Conformance to these specifications enables trading partners to achieve the business objective.
PIPs require the following:
A definite business outcome (for example, the receipt of a purchase order from a trading partner)
A role to perform at least one activity (for example, a buyer role requests a purchase order from a seller role and a seller role submits a purchase order acknowledgment to the buyer role)
A measurable unit of work that can be connected to other PIPs to achieve a larger business outcome (for example, one PIP involves a buyer role requesting and receiving a purchase order from a seller role, while another PIP is coordinated with the first PIP to send a failure notification message to a buyer role if a purchase order is not received from the seller role)
Trading partners agree on the set of PIPs to support to conduct business. Each partner must fulfill their specific requirements of the PIP. If one trading partner does not fulfill all requirements, then the business transaction is voided for all participating PIP trading partners.
PIPs consist of the following major views:
Business operational view (BOV)
Describes the flow between roles as they perform business activities
Functional service view (FSV)
Describes the design of and interactions between network components as they execute a PIP. Network components are also known as services, and include buyers and sellers.
Implementation framework view (IFV)
Describes the message structures of actions performed by roles (for example, the XML DTDs and message guidelines) and communication requirements for network components (for example, for the use of Secure Socket Layer (SSL) and digital signatures)
PIPs are classified into clusters, segments, and individual PIPs. The following PIP clusters are provided:
Cluster 0: RosettaNet Support
Cluster 1: Partner, Product, and Service Review
Cluster 2: Product Introduction
Cluster 3: Order Management
Cluster 4: Inventory Management
Cluster 5: Marketing Information Management
Cluster 6: Service and Support
Cluster 7: Manufacturing
Each cluster is subdivided into segments. Each segment includes individual PIPs. Individual PIPs contain one or more activities, which specify actions to be performed.
For example, Table 24-3 identifies PIP3A4 features.
Table 24-3 PIP3A4 Features
| Element | Description |
|---|---|
| 3 | Order management cluster, which lets trading partners:
|
| 3A | Quote and order entry segment |
| 3A4 | Specific PIP type. This PIP supports the:
|
Figure 24-3 shows the message flow when a buyer and seller use PIP3A4 V02.00. This PIP enables a buyer to request a purchase order and a seller to acknowledge if the order request is accepted, rejected, or pending. An acknowledgment can also include details about delivery expectations. A purchase order acceptance is typically sent after checks for price and availability occur.
|
See Also:
|
The RosettaNet dictionaries define and describe a common set of properties for use in PIP messages. These properties define a common vocabulary for conducting business. This ensures that the data exchanged between trading partners is consistent, overlapping efforts of trading partners are eliminated, and confusion caused by the uniquely defined terminology of each trading partner is reduced. Two dictionary types are provided:
Business Dictionary
Designates the properties used in basic business transactions between trading partners. The Business Dictionary defines the business properties, business data entities, and fundamental business data entities in PIP messages.
Technical Dictionary
Provides properties for defining products and services. The Technical Dictionary eliminates the need for trading partners to use separate dictionaries when implementing PIPs.
For example, if two trading partners are engaged in a business transaction involving the sale of personal computers, the Technical Dictionary describes the computer features in a text document, such as:
Amount of RAM
Amount of hard disk space
Number of CPUs
|
Note: The RosettaNet Technical Dictionary is not currently supported with Oracle Application Server ProcessConnect. |
|
See Also:
|
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.
|
See Also:
|
Oracle Application Server ProcessConnect provides RosettaNet B2B protocol standard support with the B2B adapter. Figure 24-4 shows the role of the B2B adapter in a B2B integration.
Figure 24-4 Oracle Application Server ProcessConnect in a B2B Integration
The B2B adapter is a plug-in component to the Oracle Application Server ProcessConnect adapter framework. The adapter framework enables communication between the Oracle Application Server ProcessConnect runtime system (the component that executes integrations) and various adapters. These adapters enable Oracle Application Server ProcessConnect to communicate with applications and trading partners, enabling integration types such as B2B to be executed. The B2B adapter supports the features of the RosettaNet B2B protocol standard.
|
See Also: The following documentation for additional details about adapters and the adapter framework:
|
Oracle Application Server ProcessConnect supports the following RNIF versions:
Table 24-4 describes several RNIF version 1.1 features supported by the B2B adapter during Oracle Application Server ProcessConnect runtime.
Table 24-4 RNIF Version 1.1 Guidelines
Table 24-5 describes several RNIF version 2.0 features supported by the B2B adapter during Oracle Application Server ProcessConnect runtime.
Table 24-5 RNIF Version 2.0 Guidelines
The B2B adapter supports the RosettaNet PIPs shown in Table 24-6.
Table 24-6 PIPs Supported by the B2B Adapter
| PIP | Type | Version | This PIP Supports the... |
|---|---|---|---|
| 0A1 | Notification of Failure | V02.00 | Detection by either involved party of the failure of a business activity to complete successfully |
| 3A4 | Request Purchase Order | V02.00 | Following sequence of events:
|
| 3A6 | Distribute Order Status | V02.00 | Sellers to send the status of open orders to buyers |
|
See Also:
|
Oracle Application Server ProcessConnect supports the RosettaNet Business Dictionary described in "RosettaNet Dictionaries". The RosettaNet Technical Dictionary is not currently supported. Only PIP2A9 (not supported by Oracle Application Server ProcessConnect) currently uses the RosettaNet Technical Dictionary.
Oracle Application Server ProcessConnect supports RosettaNet validation, as described in "RosettaNet Validation". This support is preseeded in Oracle Application Server ProcessConnect and cannot be changed. RosettaNet Business Dictionary validation of RosettaNet documents is also supported. RosettaNet Technical Dictionary validation of RosettaNet documents is not currently supported.
A trading partner agreement is an electronic agreement that defines the way in which two trading partners agree to interact when performing an agreed-on business collaboration. An example of a business collaboration is RosettaNet PIP3A4 (purchase order request), where one trading partner acts as the role of buyer to request a purchase order and another trading partner acts as the role of seller to send a purchase order acceptance. (See "PIP Message Flow Example" for details.) Trading partner agreements essentially define the terms and agreements that enable business documents to be exchanged between trading partners.
The trading partner agreement is independent of the internal processes executed at each trading partner’s individual site. The trading partner agreement does not expose the internal processes of a trading partner to other trading partners.
The contents of a trading partner agreement include the following elements. Each element includes data essential to a trading partner agreement. After these elements of data are fully defined, you assign them to a trading partner agreement.
Figure 24-5 provides a specific example of trading partner agreement elements and the types of data that can be defined in these elements.
A trading partner is an organization or enterprise that engages in business transactions with another trading partner. The trading partner agreement captures the agreed-on capabilities of both trading partners to conduct a business transaction. Trading partners include the following elements of data for identification and communication capabilities:
The party ID defines the agreed-on identification to be used to conduct the business collaboration. RosettaNet sends the party ID data as part of the business protocol header. One example is the data universal numbering system (DUNS) number. Trading partners must obtain a DUNS number themselves. Other examples can include an e-mail address or any other standard that a company decides to use.
The delivery channel describes the communication capabilities. To conduct a business collaboration, messages must be exchanged in a sequence. Messages must follow an agreed-on, predefined exchange mechanism and must be sent over an agreed-on transport. Message exchange details are defined by the document exchange. The delivery channel also provides security details to ensure a secure message exchange. These capabilities are described in the following sections:
The document exchange provides data about the supported exchange protocol. The document exchange layer receives a business document, encrypts it (if specified), adds a digital signature for nonrepudiation (if specified), and sends it to the transport for transmission to the other trading partner. The document exchange elements essentially describe a trading partner’s message receiving characteristics. Examples of document exchange types include the following:
RNIF 1.1
RNIF 2.0
The transport is responsible for message delivery using the selected transport protocol. The transport defines the trading partner’s capabilities with regards to the following:
Communication protocols that enable trading partners to interact (for example, HTTP, SMTP, and FTP)
Transport security for inbound and outbound messages transported over the communication protocol used
Collaborations describe how message processing occurs, including the message exchange order, the documents exchanged, role exchange order, and the actions. Collaborations consist of business activities. Business activities are conducted between the roles authorized to participate in a collaboration. A business activity can be either a business transaction or a business collaboration. Collaborations include the following elements of data that you assign to a trading partner agreement:
A business transaction is a unit of business conducted by two or more trading partners that generates a definite state of success or failure. A business transaction is conducted between two parties playing opposite roles in a transaction. The roles are always an initiating role (the from role) and a responding role (the to role). Trading partners participate in the business collaboration through roles. The business transactions are sequenced to occur in a predefined order.
A business transaction consists of a set of business data and business signal exchanges between trading partners that occur in an agreed-on format, sequence, and time period. If any of the agreements are violated, the transaction is terminated and all business data and business signal exchanges are discarded.
For example, a trading partner acting as the role of buyer submits a purchase order request message to a trading partner acting as the role of seller. The trading partner acting as the role of seller receives the message and delivers a purchase order response message acknowledging the receipt.
A business collaboration consists of a set of roles (buyer and seller) collaborating through a set of agreed-on business transactions by exchanging business documents. Trading partners participate in a business collaboration through roles. This business collaboration must achieve a specified outcome.
PIPs are mapped to business collaborations. Examples of business collaborations include the following:
PIP3A4
PIP3A6
|
See Also:
|
Roles represent the actors (such as a buyer and seller) authorized to participate in a collaboration (for example, PIP3A4). A collaboration includes the following:
Two roles (for example, there is a buyer role and a seller role for PIP3A4)
One or more business transactions
The business actions define the documentation types to be exchanged. For example, the following business actions occur when a request purchase order business transaction is initiated by a buyer role and responded to by a seller role:
One requesting action (for example, a purchase order requesting action called purchase order request action that uses the purchase order request document type)
One responding action (for example, a purchase order acceptance action called purchase order response action that uses the purchase order acceptance document type)
Oracle Application Server ProcessConnect provides support for the elements comprising a trading partner agreement. This section first describes Oracle Application Server ProcessConnect support for trading partner agreement elements and then provides an overview of how the Oracle Application Server ProcessConnect user interface tool supports these elements.
This section contains these topics:
Oracle Application Server ProcessConnect Support for Trading Partners
Oracle Application Server ProcessConnect Support for Collaborations
The B2B adapter supports the following elements:
The B2B adapter uses the party ID to identify the trading partner agreement. The Oracle Application Server ProcessConnect user interface tool identifies the party ID through the concept of the trading partner identification type. Examples of trading partner identification type include a DUNS number, an e-mail address, or any identifier that you chose to use.
|
See Also: The following sections for instructions on performing these tasks:
|
The B2B adapter supports the following elements of data:
|
See Also: The following sections for instructions on performing these tasks:
|
The B2B adapter supports the document exchange features shown in Table 24-7. These features are included with RNIF 1.1 and RNIF 2.0 unless otherwise stated.
Table 24-7 Document Exchange Features Supported by the B2B Adapter
| Feature | Description |
|---|---|
| Delivery semantics | Supports the following message delivery semantics between trading partners:
|
| Acknowledgment mode | Supports the asynchronous mode for recipients of messages. In asynchronous mode, acknowledgments are sent back in a separate transport connection in which the message was received. |
| Acknowledgment level | Supports acknowledgment messages sent at the following levels:
|
| Time to acknowledge level | If an acknowledgment does not arrive before the expiration time, the B2B adapter sends the request or response again. |
| Packaging | The B2B adapter supports RosettaNet requirements for packaging, formatting, encrypting (for RNIF 2.0 only), and signing messages. |
| Messaging formats | The B2B adapter supports RNO for RNIF 1.1 and MIME for RNIF 2.0. |
| Digitally secure messages | The B2B adapter supports digitally secure messages. Some of the message packaging aspects supported by the B2B adapter include:
|
The transport is responsible for message delivery using the selected transport protocol. The B2B adapter uses the HTTP and secure HTTP transport communication protocols.
For outgoing messages sent from the B2B adapter to a trading partner, the B2B adapter calls the transport with the message to send and provides the necessary transport protocol-specific bindings. For incoming messages received from a trading partner, the transport receives the messages and calls the B2B adapter with the received message and transport binding data for processing. The transport binding data specifies the protocol-specific status data and a list of protocol headers with their values.
Oracle Application Server ProcessConnect provides support for collaborations. Collaborations consist of business activities. Business activities are conducted between the roles authorized to participate in a collaboration. The B2B adapter supports the following elements.
A business transaction consists of a request message (for example, a request purchase order) and an optional response message (for example, respond to a purchase order request). The B2B adapter provides support for one business transaction. The B2B adapter supports request and response messages. The B2B adapter enforces the time limit to perform the business transaction.
The B2B adapter provides the following additional collaboration support:
Validates the state of a collaboration. A collaboration defines a set of business transactions. Messages are exchanged based on the collaboration definition.
Enforces the trading partner agreement-specified collaboration limits. A trading partner agreement can specify the maximum number of collaborations allowed and the maximum number of concurrent collaborations allowed for that trading partner agreement.
Supports the PIPs shown in "Oracle Application Server ProcessConnect Support for Partner Interface Processes"
Roles represent the actors (such as a buyer and seller) authorized to participate in a collaboration (for example, PIP3A4). The B2B adapter provides support for roles.
|
See Also: "Creating a Supported Actor" for instructions on assigning a role to a trading partner (such as the role of a seller using PIP3A4 with RNIF 2.0) |
RosettaNet and Oracle Application Server ProcessConnect differ slightly in the use of terminology. Table 24-8 identifies these differences.
Table 24-8 Terminology Differences
| RosettaNet Terminology | Oracle Application Server ProcessConnect Terminology |
|---|---|
| PIP | Collaboration |
| Role, collaboration name, and collaboration revision | Supported actor
The supported actor comprises the role, collaboration name, and collaboration revision of a trading partner. You select the supported actor in the Oracle Application Server ProcessConnect user interface tool. The supported actor consists of three elements. For example, Buyer - 3A4 - V02.00 is one type of supported actor that is available. This actor consists of the following parts:
|
| Activity | Business transaction |
| Action | Business action |
