Trading Partner Mode Concepts

This section describes trading partner mode concepts in B2B for Oracle Integration.

Topics:

• Host Company
• Trading Partners
• Integrations Used for B2B Message Processing
• Message Routing Between Integrations
• Transports for Communication
• Agreements
• B2B Documents and Schemas
• Message Persistence and Tracking

Host Company

There are two parties involved in any document exchange in B2B for Oracle Integration: your company (the host company) and an external trading partner.

In Oracle Integration, selecting B2B > Host Profile from the left navigation menu invokes the configuration page you must complete on behalf of your company.

You only need to enter B2B identifiers for the host profile. You enter your company's identity information such as the EDI Interchange ID and the AS2 Identifier. Other types of configuration, such as signing certificates for your company, are entered later.

When you send electronic documents to an external trading partner, some of the B2B identifiers you enter in the host profile are inserted into the message. This enables the recipient party to identify your company as the sender of the message.

See Define the Host Profile.

Trading Partners

A trading partner is the external business entity with which your company interacts to send or receive business documents, such as orders and invoices, in electronic form.

You select B2B > Trading Partners from the left navigation menu to access pages to register all your external trading partners and enter information on their behalf. The trading partners cannot access these pages in your Oracle Integration instance. Therefore, as the B2B system administrator, you gather information offline from your external trading partners and enter the information in these pages.

Similar to B2B for Oracle Integration, your external trading partner has a B2B application of their own. Your trading partners collect information offline about your company and enter it into their B2B application, which you cannot directly access.

Once setup is completed and tested on both ends, the two parties (your company and the external trading partner) are ready to send and receive documents.

You create and register an external trading partner by entering information in the following tabs, each of which are explained in subsequent sections.

• Primary Information
• Contacts
• B2B Identifiers
• Transports & Agreements

See Create Trading Partners.

Integrations Used for B2B Message Processing

The actual processing of B2B messages occurs in integrations. B2B for Oracle Integration uses a two-integration design pattern for better modularity.

Inbound Message

A B2B message received from an external trading partner is called an inbound message. The following diagram shows how an inbound message is processed through two integrations.

In the two-integration pattern, the B2B integration for receiving messages performs the following steps:

1. Receives the message from the trading partner and performs various validity checks, for example:
   • Is the message received from a known (that is, registered) trading partner? Verify this based on the authentication credentials, SSL certificates, HTTP headers, and so on.
   • Is the message signed or encrypted? If so, verify the signature and decrypt the message. This step is called unpackaging, which is similar to removing an object from its packaging.
2. Sends a transport level acknowledgment back to the trading partner, if asked by the trading partner.
3. Detects the type of payload. If it is a payload that requires translation (for example, an EDI message), parse and translate the message.
4. Sends a translator level acknowledgment, if configured.
5. The backend integration converts the message into a format that a backend application, such as ERP, can directly consume (for example, XML, JSON, CSV, and so on) and forwards the message to a backend system for further processing.

Outbound Message

A B2B message sent to an external trading partner is called as an outbound message.

The following diagram shows how an outbound message is processed through two integrations.

In the two-integration pattern, the backend integration performs these steps:

1. Receives an event from a backend application such as ERP for a business document that must be sent to an external trading partner.
2. Translates the message to an industry-standard B2B format (for example, Electronic Data Interchange (EDI) format).

The B2B integration for sending messages performs these steps:

1. Adds headers, encrypts, signs, and compresses the payload, as per your required configuration. This step is called packaging, which is similar to wrapping an object into an envelope and making it ready for delivery.
2. Transmits the message to the external trading partner's endpoint.
3. If the trading partner responds with a transport level acknowledgment, it updates the status of the transmitted message accordingly.

The following table summarizes the two-integration pattern for B2B message processing:

Concept	B2B Integrations for Receiving and Sending Messages	Backend Integration
Purpose	Handles the low-level technical interaction with an external trading partner, including B2B layer acknowledgments. This is provided by Oracle.	Handles the complete interaction with your backend application, such as ERP, and the message transformation between B2B canonical format and the backend application format. This is developed by your company and is typically specific to your backend application. There may be recipes and/or accelerators available for specific backend applications to get you started. See Get Started with Integration Accelerators and Recipes in Getting Started with Oracle Integration Generation 2.
Creation	These integrations are automatically created for each trading partner from a template. Details about how to automatically create integrations are provided. See Create B2B Integrations for Receiving and Sending.	You create this integration manually and use any available application adapters to interface with your backend application. Details about how to build this integration are provided. See Create Backend Integrations.
What does it do	Handles packaging/unpackaging of a message and performs receipt or transmission from or to a trading partner using an agreed-upon protocol. Performs handshakes with the trading partner's system, generating or consuming acknowledgments as needed by a typical B2B gateway. For an inbound message, the B2B integration for receiving messages also translates the message (for example, from EDI to XML). If the inbound message contains batched transactions, those are split individually before handing them to the backend integration. However, for an outbound message, the translation is not performed in the B2B integration for sending messages. (It is performed in the backend integration.)	Handles interfacing with a backend application, such as ERP, both for the inbound and outbound sides. For an inbound message, the backend integration gets a B2B message that is already translated to a canonical format. It must convert it further and forward it to your backend application. For an outbound message, the backend integration is the entry point where an event notification from a backend application triggers this integration to perform a translation to a B2B format (for example, XML to EDI) and call the B2B integration for sending messages.
How many integrations are needed	A pair of integrations are required per B2B trading partner and transport. For example, if you have 10 B2B trading partners, each with one transport, then 20 integrations are needed (one each for receiving and sending messages). These integrations are automatically created for you. See Trading Partner Mode Concepts.	A pair of integrations are required per business document type. For example, if you have three types of business documents (purchase orders, invoices, and shipment notifications), you need six integrations (three on the inbound side and three on the outbound side), regardless of the number of trading partners. Typically, you share these integrations across many trading partners as long as they use the same document format. You may actually need fewer than six integrations if some types of business documents are only used in one direction. For example, if purchase orders are only received, but never sent, you need only one backend integration for inbound purchase orders and none for outbound purchase orders. You may also need fewer integrations if you design the integrations to handle multiple document types. This is because in the simplest case, the assumption is that one backend integration handles only one type of business document. You need to create these integrations manually. See Create Backend Integrations.

Message Routing Between Integrations

The B2B integrations and backend integrations are not hard-wired to each other. They are instead dynamically wired to follow routing rules that you add declaratively. This section describes how the routing rules work using the concept of inbound and outbound agreements.

Inbound

Assume one of your trading partners is sending multiple types of documents: purchase orders and invoices. For this trading partner, one B2B integration receives messages, and it receives both types of documents. You define routing rules by adding two inbound agreements to this trading partner. When you add an inbound agreement, you must select one B2B document and one backend integration.

You add the following two inbound agreements:

• Inbound agreement 1 for selecting a purchase order type document and a backend integration called X.
• Inbound agreement 2 for selecting an invoice type document and a backend integration called Y.

These two agreements express the following intentions to the system:

• When a purchase order type document is received from this trading partner, it's routed to backend integration X.
• When an invoice type document is received from this trading partner, it's routed to backend integration Y.

While inbound agreements do more than routing, the routing is a primary concept. The B2B integration for receiving messages honors the routing rules at runtime and dynamically invokes backend integration X or Y, depending on the identified document type, as shown below.

Note:

You can create a single, generic backend integration that handles multiple types of documents, if you think there is enough commonality and it is easier for maintenance. In this case, select the same backend integration in the two inbound agreements.

Outbound

Assume you have two trading partners and want to route a purchase order document to one of those trading partners. In this case, the backend integration must make a routing choice to select the correct B2B integration for sending messages between two integrations.

In the outbound case, inside your backend integration, you must specify the trading partner to which you want to deliver the message. This is specified by providing a trading partner ID or an application partner ID. See Design an Outbound Backend Integration.

You define routing rules by adding two outbound agreements, one per trading partner. When you add an outbound agreement, you must select one B2B document and one transport. See Transports for Communication. Be aware for now that a transport maps to B2B integrations for receiving and sending messages for a given trading partner.

You add the following two outbound agreements:

• Outbound agreement 1 for selecting a purchase order type document and transport X for trading partner X.
• Outbound agreement 2 for selecting a purchase order type document and transport Y for trading partner Y.

These two agreements express the intention to the system that when a purchase order type document is sent to trading partner X, route it to the B2B integration for sending messages X. When the document is sent to trading partner Y, route it to the B2B integration for sending messages Y.

Outbound agreements do more than routing, but this section only focuses on the routing aspect.

Further concepts about agreements are provided. See Agreements.

Details are provided for creating agreements. See Create Agreements.

Note:

In the outbound case also, you can create a common backend integration that handles multiple types of documents, if that is your design preference.

Transports for Communication

Transports are configuration objects that represent a concrete communication channel to a trading partner using a specific protocol such as AS2 or FTP. You add one or more transports to a trading partner to send or receive business documents from the partner.

AS2 and FTP (which includes SFTP) are the currently supported protocols for B2B trading partner mode. If you want to use another protocol adapter in B2B for Oracle Integration, you can do so only using the standalone mode.

You define a transport for a B2B trading partner from the B2B > Trading Partners > Transports & Agreements tab. The following example shows a trading partner with one AS2 transport and one FTP transport.

A transport requires the following entities to work:

• A connection that you create and configure to point to the external trading partner's endpoint. As part of this configuration, you provide the host name, port, URL, username/password credentials, and other details that your trading partner provides to you.
• Additional configurations (for example, a directory path for FTP or an encryption algorithm for AS2).
• A pair of integrations, one for receiving messages and another for sending messages. These integrations are automatically created for you. See Integrations Used For B2B Processing.

You enter the following configuration details when you define a transport (for this example, AS2).

Description of the illustration transport_ui.png

The transport lifecycle consists of the following actions:

• Create a transport: Adds a definition for the transport. The pair of B2B integrations are automatically created and permanently linked to this transport.
• Deploy a transport: Makes the transport visible for runtime processing and also activates the B2B integrations. This transport can now receive and send messages.
• Redeploy a transport: Applies configuration changes to the runtime on-the-fly without disrupting message processing (with some restrictions).
• Undeploy a transport: Hides the transport from runtime processing and also deactivates the B2B integrations. This transport can no longer receive and send messages.
• Delete a transport: Removes the definition and also deletes the B2B integrations.

See Define Transports.

AS2

Applicability Statement 2 (AS2) is an HTTP-based protocol designed for B2B that adds a comprehensive set of data security features around data confidentiality, data integrity/authenticity, and nonrepudiation.

The AS2 specification is covered by RFC 4130. B2B for Oracle Integration supports AS2 versions 1.0 and 1.1.

An AS2 transport offers configuration options specific to AS2 that work in conjunction with the AS2 connection and the certificate management user interface.

For example, if you want to sign and encrypt the outbound messages:

1. Use the Oracle Integration certificate management capabilities by uploading your certificate under Settings > Certificates.
2. Enter the signing and encryption certificate alias in the AS2 Adapter connection selected in the AS2 transport.
3. Select an encryption and signing algorithm in the AS2 transport configuration.

The simplest AS2 communication uses no encryption, signing, and compression. If you are learning about AS2, you can start simple and add the security layers later.

There is the concept of an electronic read receipt in AS2, officially known as Message Disposition Notification (MDN). It is a transport level acknowledgment used as a confirmation that the other party has received your message intact. B2B for Oracle Integration generates and consumes MDN messages (when enabled) and correlates them to the original transmissions. The Track B2B Messages page, described later, enables you to view the AS2 messages and MDN acknowledgments.

More details about the AS2 transport are provided. See Define Transports.

FTP

File Transfer Protocol (FTP) and Secure File Transfer Protocol (SFTP) are commonly used for B2B communications. An FTP transport also works in conjunction with an FTP Adapter connection.

In an FTP Adapter connection, you specify the hostname, port, credentials, and other security configurations. In the FTP transport, you enter the input and output directories, file name pattern, and other details.

One important aspect of an FTP transport is that the receiving side polls the input directory on a time-based schedule. You can set up the schedule by selecting the Receive Schedule option of the actions menu for an FTP transport.

More details about the FTP transport are provided. See Define Transports.

Agreements

You define one or more agreements for a B2B trading partner with an intent to send or receive only certain types of business documents to or from that trading partner. An agreement literally means that your company and the external trading partner have formally agreed upon the terms for the exchange of specific business documents.

An agreement has the following purposes:

• Armed with the knowledge of which documents to expect from a given trading partner, B2B only accepts one of the agreed-upon documents. Any unexpected document type is rejected both while receiving from or sending to that trading partner.
• Defines the data format for the documents exchanged. For example, for an EDI document, syntax validations and parsing is done based on the B2B document selected in an agreement. Both parties, your company and the external trading partner, must decide in advance on the data format to use for interoperability to work. One of the parties typically shares an implementation guide containing the data format definition and the other party complies with it and creates an equivalent data format definition on their side.
• Defines behavior for message processing. For example, syntax validations on the data format can be turned on or off in an agreement, among other settings.
• Defines rules for the routing of documents. For example, when receiving documents, an inbound agreement defines the backend integration to which to route a document, based on its type. While sending documents, an outbound agreement defines which B2B sending integration to hand over a specific document for delivery to a trading partner.

The agreement lifecycle consists of the following actions:

• Create an agreement: Adds the definition in the design-time only (but unless deployed, the new agreement is not enforced at runtime).
• Deploy and redeploy an agreement: Makes the agreement visible for runtime processing and is immediately enforced.
• Undeploy an agreement: Hides the agreement from runtime processing, making it no longer effective, starting immediately.
• Delete an agreement: Removes it from design time.

The following examples show inbound and outbound agreements defined for a trading partner:

• Inbound agreement:
  
  
  
  
• Outbound agreement:
  
  
  
  

See Create Agreements.

B2B Documents and Schemas

A B2B document is a mandatory object required by an agreement that specifies a data format and some additional configuration pertaining to the data format. A data format is specified using the following properties.

• Document standard: The X12 and EDIFACT EDI standards are currently supported.
• Document version: A version as defined by the standards body.
• Document type: A type as defined by the standards body.
• Document schema: A standard or customized variant defined in a B2B schema object. Standard means the pristine schema defined in the data dictionary published by the standards body.

Additional configuration enables one or more business identifiers for the B2B runtime to be extracted and displayed in the Track B2B Messages page. This page is accessible in the left navigation pane from Monitoring > B2B Tracking > Business Messages.

A B2B schema is an optional object that represents a customized variant of one of the standard schemas.

Additional details about B2B documents and B2B schemas are provided. See B2B Documents and schemas.

Additional details about agreements are provided. See Create Agreements.

Message Persistence and Tracking

As messages flow through the B2B integrations for receiving and sending messages, each inbound and outbound message is persisted separately, in addition to the usual integration instance tracking.

The persisted B2B messages can be viewed from a specialized Track B2B Messages page accessible from the left navigation menu under Monitoring > B2B Tracking.

Business Messages

In this view, you see B2B messages as individual business transactions. Rows marked denote functional acknowledgments. Assume you receive an inbound message containing batched transactions. This view shows individual rows for each individual transaction within that batch.

Wire Messages

An alternate, low-level technical view of B2B messages is provided with the wire messages. In this view, you see messages in the form in which they are transmitted to or received from a trading partner. This view is useful for troubleshooting, in case the message failed to be delivered to a trading partner or a received message failed signature verification. Rows marked with denote AS2 MDNs (electronic return receipts).

In the case where you receive an inbound message containing a batched transaction, you only see one row corresponding to the actual batch message that was received.

More B2B tracking details are provided. See B2B Tracking.