Use B2B for Oracle Integration in Trading Partner Mode | B2B

B2B trading partner mode is only available in Oracle Integration Generarion 2. If you are using Oracle Integration , you must use Standalone mode.

Trading partner mode concepts:

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

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
• 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 infomation in the following tabs:

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

Integrations used for B2B Message Processing:

The actual processing of B2B messages occur in integrations. B2B for Oracle integration uses following 2 integration design pattern for better modularity:

Inbound Message:

A B2B message received from an external trading partner is called an inbound message.

The B2B integration for receiving messages performs the following steps:

• 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.
• Sends a transport level acknowledgment back to the trading partner, if asked by the trading partner.
• Detects the type of payload. If it is a payload that requires translation (for example, an EDI message), parse and translate the message.
• Sends a translator level acknowledgment, if configured.
• 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 backend integration performs these steps:

• Receives an event from a backend application such as ERP for a business document that must be sent to an external trading partner.
• 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:

• 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.
• Transmits the message to the external trading partner's endpoint.
• If the trading partner responds with a transport level acknowledgment, it updates the status of the transmitted message accordingly.

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

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.

Agreements
Define one or more agreements for a B2B trading partner to send or receive only certain types of business documents to or from that trading partner.

We can define the agreements in two ways:

Inbound Agreements

Outbound Agreements

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. 
• Defines the data format for the documents exchanged. 
• 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.

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.


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 FA 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 MDN 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.