24
RosettaNet B2B Protocol Standard

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:

• What is a B2B Protocol Standard?

• What Is RosettaNet?

• Oracle Application Server ProcessConnect Support for RosettaNet

• What Is a Trading Partner Agreement?

• Oracle Application Server ProcessConnect Support for Trading Partner Agreements

• RosettaNet and Oracle Application Server ProcessConnect Terminology Differences

• Chapter Summary

  See Also: The RosettaNet home page for more details on RosettaNet concepts discussed in this chapter: http://www.rosettanet.org Chapter 25, "Managing Host and Remote Trading Partner Capabilities" for instructions on managing trading partner capabilities Chapter 26, "Managing Trading Partners and Trading Partners Agreements" for instructions on managing trading partner agreements

What is a B2B Protocol Standard?

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.

Figure 24-1 RosettaNet Role in a B2B Integration

Text description of the illustration b2bstandardsa.gif

This chapter provides key details about the RosettaNet B2B protocol.

See Also: Figure 24-4, "Oracle Application Server ProcessConnect in a B2B Integration" for details on how Oracle Application Server ProcessConnect support is integrated into Figure 24-1 "Executing the Adapter Framework: Overview" for additional details on how a B2B protocol standard is integrated into the Oracle Application Server ProcessConnect architecture

What Is RosettaNet?

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:

• Partner Interface Processes

• RosettaNet Implementation Framework

• RosettaNet Dictionaries

• RosettaNet Validation

Figure 24-2 Key RosettaNet Standards

Text description of the illustration b2bstandards2.gif

See Also: "Oracle Application Server ProcessConnect Support for RosettaNet" for details on how Oracle Application Server ProcessConnect supports these key RosettaNet details

RosettaNet Implementation Framework

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:

• RNIF Version 1.1

• RNIF Version 2.0

  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

RNIF Version 1.1

Table 24-1 describes several RNIF version 1.1 implementation guidelines.

Table 24-1  RNIF Version 1.1 Guidelines

Guideline	Description
Transport	Supports the secure HTTP transport protocol for delivering business messages between trading partners
Packaging	Supports the RosettaNet Object (RNO) 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
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: Nonrepudiation of origin requires a message sender to digitally sign a message. This protects against attempts by a sender to deny sending a message. The message recipient must store the message for an agreed-on period of time (typically three to seven years). Nonrepudiation of receipt requires a message recipient to send back a digitally-signed acknowledgment. The message recipient must store both the receipt and the original message for an agreed-on period of time (typically three to seven years). This protects against any attempt by a message recipient to deny receiving a message.

See Also: Version 1.1 of the RosettaNet Implementation Framework: Core Specification available at the RosettaNet home page: http://www.rosettanet.org

RNIF Version 2.0

Table 24-2 describes several RNIF version 2.0 implementation guidelines.

Table 24-2  RNIF Version 2.0 Guidelines

Guideline	Description
Transport	Supports multiple transport protocols (such as secure HTTP and SMTP) for delivering business messages between trading partners
Packaging	Supports the multi-purpose 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 Note: Encryption is not available with RNIF version 1.1.
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: Nonrepudiation of origin requires a message sender to digitally sign a message. This protects against attempts by a sender to deny sending a message. The message recipient must store the message for an agreed-on period of time (typically three to seven years). Nonrepudiation of receipt requires a message recipient to send back a digitally-signed acknowledgment. The message recipient must store both the receipt and the original message for an agreed-on period of time (typically three to seven years). This protects against any attempt by a message recipient to deny receiving a message.

See Also: Version 2.0 of the RosettaNet Implementation Framework: Core Specification available at the RosettaNet home page: http://www.rosettanet.org

Partner Interface Processes

This section contains the following PIP topics:

• What Is a Partner Interface Process?

• PIP Components

• PIP Classifications

• PIP Message Flow Example

What Is a Partner Interface Process?

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.

PIP Components

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)

PIP Classifications

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: Order catalog products Create custom orders Manage product distribution and delivery Support product returns and financial transactions
3A	Quote and order entry segment
3A4	Specific PIP type. This PIP supports the: Submittal of a purchase order by a buyer Submittal of an acceptance purchase order by a seller Ability of a buyer to cancel or change a purchase order based on the acknowledgment response

PIP Message Flow Example

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.

Figure 24-3 RosettaNet PIP3A4 Message Flow

Text description of the illustration b2bstandards3.gif

See Also: "Oracle Application Server ProcessConnect Support for Partner Interface Processes" for additional details on how Oracle Application Server ProcessConnect supports PIPs The search facility of the RosettaNet home page for more details on PIPs: http://www.rosettanet.org

RosettaNet Dictionaries

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: "Oracle Application Server ProcessConnect Support for RosettaNet Dictionaries" for additional details on how Oracle Application Server ProcessConnect supports the RosettaNet dictionaries The search facility of the RosettaNet home page for more details on the RosettaNet Business Dictionary and the RosettaNet Technical Dictionary: http://www.rosettanet.org

RosettaNet Validation

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.

1. The XML-format business document requires compliance with its DTD.

2. Elements with datatypes, lengths, or both that are specified in the RosettaNet Message Guideline specification require validation against this specification.

3. An element's list of values specified in the entity instance list in the corresponding RosettaNet Message Guideline specification requires validation against this specification.

4. If the Message Guideline specification defines the cardinality specification of an element differently from the corresponding DTD specification, the Message Guideline specification takes precedence.

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

6. Cross-tag validation is based on message guidelines.

   See Also: "Oracle Application Server ProcessConnect Support for RosettaNet Validation" for additional details on how the Oracle Application Server ProcessConnect supports RosettaNet validation RosettaNet Implementation Framework: Core Specification available at the RosettaNet home page for more details on validation rules, preambles, delivery headers, service headers, and service contents: http://www.rosettanet.org

Oracle Application Server ProcessConnect Support for RosettaNet

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

Text description of the illustration b2bstandards4.gif

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: "B2B Protocol Adapters" for additional details on Oracle Application Server ProcessConnect support for business protocol adapters "Executing the Adapter Framework: Overview"

Oracle Application Server ProcessConnect Support for the RosettaNet Implementation Framework

Oracle Application Server ProcessConnect supports the following RNIF versions:

• RNIF Version 1.1

• RNIF Version 2.0

  See Also: "Adding a Business Protocol" for instructions on adding RNIF 1.1 or RNIF 2.0 support

RNIF Version 1.1

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

Feature	Description
Transport	Supports the HTTP and secure HTTP transport protocols for delivering business data messages between trading partners
Packaging	Supports the RNO format
Authorization	Receives an incoming message and uses the identity of the message sender to determine which services the sender can perform
Authentication	Requires a message sender to digitally sign a message
Nonrepudiation	Provides absolute evidence that a specific action occurred. Two nonrepudiation types are supported by the B2B adapter: Nonrepudiation of origin Nonrepudiation of receipt

RNIF Version 2.0

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

Feature	Description
Transport	Supports the HTTP and secure HTTP transport protocols for delivering business data messages between trading partners
Packaging	Supports RINIF 2.0 MIME packaging
Authorization	Receives an incoming message and uses the identity of the message sender to determine which services the sender can perform
Authentication	Requires a message sender to digitally sign a message
Encryption	Ensures that messages being transmitted can only be seen by the expected recipient, who is able to decrypt and extract the business data
Nonrepudiation	Provides absolute evidence that a specific action occurred. Two nonrepudiation types are supported by the B2B adapter: Nonrepudiation of origin Nonrepudiation of receipt

Oracle Application Server ProcessConnect Support for Partner Interface Processes

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: Submittal of a purchase order request by a buyer Submittal of a receipt acknowledgment confirmation by a seller Submittal of a purchase order confirmation by a seller Submittal of receipt of a purchase order confirmation by a buyer
3A6	Distribute Order Status	V02.00	Sellers to send the status of open orders to buyers

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) "Creating a Trading Partner Agreement" for instructions on creating a trading partner agreement "Oracle Application Server ProcessConnect Support for Trading Partner Agreements" The Oracle Technology Network (OTN) for instructions on downloading the supported RosettaNet PIPs shown in Table 24-6: http://otn.oracle.com The RosettaNet PIPs are not prepackaged with Oracle Application Server ProcessConnect.

Oracle Application Server ProcessConnect Support for RosettaNet Dictionaries

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 Support for RosettaNet Validation

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.

What Is a Trading Partner Agreement?

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.

• What Are Trading Partners?

• What Are Collaborations?

Figure 24-5 provides a specific example of trading partner agreement elements and the types of data that can be defined in these elements.

Figure 24-5 Trading Partner Agreement Example

Text description of the illustration b2bstandards5.gif

What Are Trading Partners?

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:

• Party ID

• Delivery Channel

Party ID

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.

Delivery Channel

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:

• Document Exchange Protocol

• Transport

  See Also: "Business Collaboration"

Document Exchange Protocol

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

  See Also: "RosettaNet Implementation Framework" for a description of RNIF capabilities

Transport

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

What Are Collaborations?

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:

• Business Transaction

• Business Collaboration

• Roles

• Business Actions

Business Transaction

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.

Business Collaboration

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: "Partner Interface Processes" "Oracle Application Server ProcessConnect Support for Partner Interface Processes" for definitions of PIP0A1, PIP3A4, and PIP3A6

Roles

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

Business Actions

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 Support for Trading Partner Agreements

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

Oracle Application Server ProcessConnect Support for Trading Partners

The B2B adapter supports the following elements:

• Party ID

• Delivery Channel

Party ID

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: "Creating Trading Partner Identification" to select a trading partner identifier "Administering Trading Partner Identification Types" to create a trading partner identifier that can be selected

Delivery Channel

The B2B adapter supports the following elements of data:

• Document Exchange Protocol

• Transport

  See Also: The following sections for instructions on performing these tasks: "Managing Delivery and Security" to create delivery channels, document exchanges, transport parameters, and remote trading partner certificates "Creating a Protocol Endpoint" to assign a transport protocol and an endpoint address (such as a Web site) to a trading partner

Document Exchange Protocol

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: Guaranteed (once and only once) message delivery
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: Transport level (such as at the HTTP or secure HTTP transport level) Business protocol level
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: Messaging format Verification of digital signatures, message encryption and decryption, and enveloping for the digital signature formats (S/MIME) of digitally secure messages.

Transport

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 Support for Collaborations

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.

• Business Transaction

• Business Collaboration

• Roles

• Business Actions

Business Transaction

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.

Business Collaboration

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

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)

Business Actions

The B2B adapter provides support for actions through the concept of business actions. The business action defines the documentation types to be exchanged.

RosettaNet and Oracle Application Server ProcessConnect Terminology Differences

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: Actor name (buyer role) PIP collaboration name (3A4) Collaboration revision (V02.00)
Activity	Business transaction
Action	Business action

Chapter Summary

This chapter describes Oracle Application Server ProcessConnect support for the following RosettaNet features:

• RNIF

• PIPs

• RosettaNet dictionaries

• RosettaNet validation

Oracle Application Server ProcessConnect support for trading partner agreements is also described.