Work with B2B schema | creare a custom B2B schema | B2B for oracle Integration

What we can achieve with B2B Schema:

• We can create a customized B2B schema based on a standard document schema to match the business requirememts.
• We can create a schema by importing a Standard Exchange Format(SEF) file.
• Generate implementation guides for custom or standard schemas.

B2B Schema Constructs:

A B2B schema represents the message format of an EDI X12 or EDIFACT document which is a hierarchical structure based on four types of constructs:

• Element: The smallest unit that represents a single data field of primitive type such as alphanumeric text, integer, decimal, date, time or binary.
• Composite: A complex data type consisting of onw or more elements.
• Segment: The next higher level construct, consisting of a sequence of elements and composites.
• Loop or Loop segment: A container for a specific set of segments or child loops.

Note: The schema for all EDI X12 document starts with a segment named ST and ends with the segment SE across all document types. The schema for all EDIFACT documents starts with a segment named UNH and ends with the segment UNT. These segments are called Transaction set envelope segments and they can not be deleted in the B2B schema editor.

How to create a custom B2B schema:

Steps:

Oracle  Integration Home paage >> B2B

Select B2B schemas

Click Create

Note: you can see import SEF and generate implementation buttons.

Provide B2B schema name, document standard, version and type >> click create

Now we can see all the segments of the document type.

Select a segment and edit to customize the details like segment/element  should be mandatory or optional, usage, Length and repeat etc.

In each segment, we can alsk add new element, new child composite, new segmwnt, new loop etc.

SAVE and generate Implementation Guide.

AS2 vs FTP transport protocols | B2B for Oracle Integration

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.

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.

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.

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.

What is B2B for Oracle Integration | Oracle Integration cloud services

Oracle Integration provides support for B2B e-commerce with B2B for Oracle Integration.

B2B for Oracle Integration features(OIC Generation 2):

• A trading partner management interface.
• An EDI schema editor for customization.
• A specialized B2B tracking user interface for viewing messages exchanged with trading partners.
• Adapters to support B2B protocols such as AS2 and FTP. 
• Actions you place within your integrations for EDI processing. 

Business Protocols supported in B2B for Oracle Integration:

These are used for business document exchange between Oracle integration and trading partners. Electronic data interchange (EDI) covers a set of data formats used to exchange formal business documents between companies.

• EDIX12 : 
• version 4010 to 8010
• Governed by the ANSI X12 standards body.
• EDIFACT: 
• version D96A(1996) to D20A(2020)
• Governed by the United Nations Economic Commission for Europe(UNECE).

Transport protocols supported in B2B for oracle integration:

The transport protocol defines the underlying support used to send and receive data between trading partners.

• AS2(Applicability Statement 2)
• FTP and SFTP

In case for stansalone mode, It supports following protocols:

• AQ
• File
• REST
• SOAP
• JMS

Patterns for using B2B for Oracle Integration:

Standalone mode:

• Uses the basic building blocks such as the AS2, FTP, SOAP, or REST Adapters along with the B2B action to process B2B messages. This is the same as any other integration.
• You build the B2B integrations yourself and track the processing of B2B messages as integration instances on the Track Instances page. 
• In this mode, the B2B trading partner definitions are not used.

B2B trading partner mode:

• Extends standalone mode and provides a fully declarative and configuration-driven setup with trading partner management and a specialized B2B message tracking user interface (the Track B2B Messages page). 
• You define trading partner profiles at design-time and use them during runtime. 
• You only create integrations to interface with your backend applications. Behind the scenes, however, message processing still occurs through integrations. The integrations are automatically created for you using templates available with B2B for Oracle Integration. 
• In short, this mode provides you with a ready-to-use solution that you simply configure and use.

** B2B trading partner mode is only available in Oracle Integration Generarion 2 pack.

Reference:

https://docs.oracle.com/en/cloud/paas/integration-cloud/integration-b2b/introduction-b2b-oracle-integration.html

OIC - Import an OIC integration using REST API | Import an Integration | REST API for Oracle Integration Migration | How to use multipart/form-data media type in REST adapter

Use Case: Import an already exported OIC integration using Oracle provided REST APIs.

Integration style: App Driven Orchestration

Connections used:

• Rest Trigger
• Rest OIC self Invoke connection
• FTP 

Verb used: POST

REST API used:/ic/api/integration/v1/integrations/archive

For how to export an integration using REST API, follow my blog:

https://soalicious.blogspot.com/2022/05/oic-export-integration-using-rest-api.html

Oracle provided Rest api links:

We can get all the Rest APIs in docs.oracle.com site under integrations section.

https://docs.oracle.com/en/cloud/paas/integration-cloud/rest-api/index.html

Flow details:

1. The Integration will take 2 request parameters Identifier and Version and 1 response parameter as Status.
2. It will calll FTP adapter to poll the exported .iar file using the file name as concat(Identifier,"_",Version,".iar")
3. It will then call the OIC REST self connection and use IMPORT REST API URI and choose multipart/form-data media type and map the ftp response .iar file reference to attachment reference to import the file to OIC instance.
4. During import call mapping, we added the following:
1. Read file response (file reference) >> Attachment Reference
2. Content-Type: "multipart/form-data"
3. File Input Html Field Name: "file"

Steps with POC Screenshots:

Rest Trigger config:

Already exported .iar file polling using FTP adapter

Call OIC Self REST adapter and configure to import integration

Map a status like " Success" or based on the import response we can take a switch and take decision for the status.

Add Tracking

Delete the integration which is already exported and to import again using this POC

 

We can see the exported files.

Test with the inputs.

Check Activity stream.

See response status = 204 that means its successfully imported to OIC instance.

Hurrah!! Its imported and in configured state.

Now change the state from Configured to Active and check and configure all the imported connections, lookups etc.

Similarly, we not only can export and import integrations using REST apis, there are others functions like delete/clone/import replace/retreive errors/retrieve status/update integrations and same we can do for connections, lookups, Libraries etc.