Manage B2B Trading Partners

This section describes how to configure trading partners in B2B for Oracle Integration.

Note:

This feature is only available on Oracle Integration Generation 2.

Trading partner concepts are provided. See Trading Partners.

Define the Host Profile

This section describes how to define the host profile (host company) in B2B for Oracle Integration.

Host trading partner concepts are provided. See Host Company.

Define Identifiers in the Host Profile

You specify the host identifier and value when configuring the host profile. Understand the following details about how the identifier is used.

  • Where the identifiers are used:
    The following table lists where each type of identifier is used and its purpose.
    Identifier Type Where Used Purpose Value Restrictions
    AS2 Identifier Trading Partners > Transports & Agreements > AS2 > AS2 Identifiers > Host Identifier

    Mandatory only when the AS2 transport protocol is used.

    This identifier type is not used for the FTP transport protocol.

    For an outbound message, this value is inserted as the AS2-From HTTP header of the AS2 message.

    For an inbound message, this value is used for validation against the AS2-To header of the incoming message.

    Up to 128 printable ASCII characters except double quotes or back slashes. This value can be any value agreed upon with the trading partner as a value with which they can identify your company.

    The value is case sensitive.

    EDI Interchange ID Trading Partner > Transports & Agreements > Outbound Agreement > Select Host Identifiers

    Mandatory for all EDI data formats.

    This identifier is used as the Interchange Sender ID field of the interchange envelope (ISA segment for X12 and UNB segment for EDIFACT).

    For an outbound message, this value is inserted as the Interchange Sender ID.

    For an inbound message, this identifier (from the host profile) is not used.

    Up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Interchange ID Qualifier Same as above.

    Mandatory for X12 and optional for EDIFACT.

    This identifier is used as the Interchange Sender ID Qualifier field of the interchange envelope of the EDI payload.

    It's a code to indicate the category of the value specified in the EDI Interchange ID (for example, DUNS number, IATA number, and so on).

    For an outbound message, this value is inserted as the Interchange Sender ID Qualifier.

    For an inbound message, the value (from the host profile) is not used.

    Must be exactly two characters for X12. The value must be from an X12 code list. See EDI Standards Reference. A generic sample value for X12 is ZZ.

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value for EDIFACT is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Interchange Internal ID Same as above.

    Only used for EDIFACT. In that, it is also optional.

    EDIFACT defines this field as an identification (for example, a division, branch, or computer system/process) specified by the sender of the interchange to be included if agreed to by the recipient in response interchanges to facilitate internal routing.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.

    EDI Interchange Internal Sub ID Same as above.

    Only used for EDIFACT syntax version 4. In that, it is also optional.

    EDIFACT defines this field as the sublevel of sender internal identification when further sublevel identification is required.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any of the delimiter characters.

    EDI Group ID Same as above.

    Mandatory for X12 and optional for EDIFACT.

    EDIFACT defines this field as an identification of the sender's division, department, and so on from which a group of messages is sent.

    X12 has a similar definition.

    For an outbound X12 message, this value is inserted in the GS segment as the Application Sender's Code.

    For an outbound EDIFACT message, this value is inserted in the UNG segment as the sender identification (a UNG is only generated when this identifier is selected in an outbound agreement; otherwise not).

    For an inbound message, the value from the host profile is not used.

    Minimum of two characters and up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.

    EDI Group ID Qualifier Same as above.

    Only used for EDIFACT. In that, it is also optional.

    It's a code to indicate the category of the value specified in the EDI Group ID (for example, DUNS number, IATA number, and so on).

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.

    Application Partner ID Not used. This identifier from the host profile is not used. Not used.
  • Host identifiers in use are protected:

    You cannot delete host identifiers referenced in transports or agreements. The associations must be removed from the transports or agreements before you can delete the host identifier from the host profile page.

  • Multiple identifiers of the same type:

    You may add multiple identifiers of the same identifier type. For example, you may want to add identifiers based on X12 or EDIFACT usage, based on business units within your company, or based on an environment such as development, test, production, and so on. The combination of identifier type and value must be unique, and this validation is enforced in the user interface.

    Even though you may define multiple identifiers of the same type, in outbound agreements, you must choose specific unique types so that B2B for Oracle Integration knows exactly which identifiers to insert in an outbound message without ambiguity.

    In the following example, two different rows, both with EDI Interchange ID and EDI Group ID, are defined.


    The Host Profile tab is shown. The Host Company Names field shows a value of Acme. Below this is the Add Identifiers section, with a + sign. Below this is a table with columns for Identifier Type lists and Value fields.

  • Updating values and applying changes to runtime:
    You can update existing identifier values any time. However, they are not used in runtime B2B processing until:
    • Each transport where an identifier value was referenced is redeployed.
    • Each outbound agreement where an identifier value was referenced is redeployed.

    Redeployment is a lifecycle action available for transports and agreements. It applies changes to the runtime on-the-fly, without disruption of message processing.

Create the Host Profile

  1. In the left navigation pane, click B2B > Host Profile.
  2. In the Host Company Name field, enter your company name. The name is currently only for reference and not used elsewhere.
  3. Select a host identifier or, if none are defined, click Add icon. You add identifiers to the host profile on behalf of your company. This is typically a one-time activity that you perform before adding your first trading partner.
    Host identifiers define your company when acting as the host interacting with other trading partners. They identify and validate the source of the document when sent by the host. Identifiers defined here are used in two places:
    • Transports
    • Outbound agreements
  4. Select a host identifier name and specify a value. You can specify multiple name and value pairs for the host.
  5. Click Save.

    If you change the host identifier value used in a deployed agreement, the changes only take effect after you explicitly redeploy the agreement between the host and the trading partner.

  6. If you want to delete any unneeded host identifiers, click Delete icon. You cannot delete host identifiers referenced by active agreements. The associations must be removed from the agreements before you can delete the host identifier from the host profile page.

Create Trading Partners

You can create and manage 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.

Trading partner concepts are provided. See Trading Partners.

  1. In the left navigation pane, click B2B > Trading Partners.

    The Trading Partners page is displayed. The Usage column shows the number of agreements associated with the trading partner. Click the entry to show the number of inbound and outbound agreements for that trading partner.



  2. Click Create.
  3. Enter the trading partner name and an optional description. The Identifier field is automatically populated with the name you enter. The values for both must be unique.

    Note:

    The identifier cannot be changed after creation.
  4. Create.

    A details panel is displayed that enables you to configure additional information about the newly created trading partner.

View Primary Information

  1. Click Primary Information to view the same information you entered when you created the new trading partner. Both the name and identifier of a trading partner must be unique across all trading partners.
    The Primary Information, Contacts, B2B Identifiers, and Agreements tabs appear at the top. Below are the Name, Identifier, Description, Updated, and Updated By fields. In the lower right are the Cancel and Save buttons.

  2. If needed, change the name of the trading partner.

    The trading partner name can be changed at any time. There are valid scenarios for renaming an actively-used trading partner. In the real world, companies change their names, have mergers and acquisitions, sell business units, and so on. You need the ability to reflect the new name here.

    Implications of renaming an active trading partner:

    The trading partner's name is displayed in a column of the Track B2B Messages page for messages received from or sent to this trading partner. If you change the name of an actively-used trading partner with one or more runtime messages processed, then any existing messages on the Track B2B Messages page still show the old name of the trading partner prior to the renaming. Any new runtime messages record the new name of the trading partner. While this is intentionally done for auditing purposes, when you filter messages by a trading partner, it shows all messages (both old and new) for that trading partner correctly. Old messages show the old name and new messages show the new name.

Select Contacts

You can add ways to contact the trading partner, such as their name, email, phone number, or short message service (SMS) number. The Contact Type and Value fields are both free text fields. This enables you to enter custom text. Use this information to contact individuals offline, as needed. The Contacts field is currently provided only for reference and is not used in B2B for Oracle Integration.

  1. Click Contacts.
  2. From the Contact Type list, select a method for contacting the trading partner, such as their name, email, phone number, or SMS number. Use this information to contact individuals offline as needed, and not from within B2B for Oracle Integration.
  3. Add a corresponding value, then click Save.
    The Primary Information, Contacts, B2B Identifiers, and Transports & Agreements tabs appear at the top. Below are the Add Contacts icon, Contact Type list, and Value field. In the lower right are the Cancel and Save buttons.

Define B2B Identifiers

You collect identifying information from your external trading partner and enter it on their behalf in the B2B Identifiers section. This is very similar, in concept, to the identifiers specified under B2B > Host Profile > Identifiers. In a message exchange, the host's identifiers and trading partner's identifiers are used in the role of a sender or receiver, depending on the message direction.

Direction Sender Receiver
Inbound message

Trading Partner

(The trading partner's identifiers are used as Sender ID or From Party.)

Your company (that is, the host)

(Host identifiers are used as Receiver ID or To Party.)

Outbound message

Your Company (that is, the host)

(Host identifiers are used as Sender ID or From Party.)

Trading Partner

(The trading partner's identifiers are used as Receiver ID or To Party.)

B2B Identifiers defined here are used in two places:
  • Transports
  • Outbound agreements
Understand the following details about how the identifier is used.
  • The following table lists where each type of identifier is used and its purpose.
    Identifier Type Where Used Purpose Value Restrictions
    AS2 Identifier Trading Partners > Transports & Agreements > AS2 > AS2 Identifiers > Partner's Identifier

    Mandatory only when the AS2 transport protocol is used.

    This identifier type is not used for the FTP transport protocol.

    For an outbound message, this value is inserted as the AS2-To HTTP header of the AS2 message.

    For an inbound message, this value is used for validation against the AS2-From header of the incoming message.

    Up to 128 printable ASCII characters except double quotes or backslashes. It can be any value agreed upon with the trading partner as a value with which you can identify the trading partner.

    The value is case sensitive.

    EDI Interchange ID Trading Partner > Outbound Agreement > Select Trading Partner Identifiers

    Also used implicitly for all inbound agreements (** see the note)

    Mandatory for all EDI data formats. This identifier is used as either the Interchange Sender or Receiver ID field of the interchange envelope (ISA segment for X12, and UNB segment for EDIFACT).

    For an outbound message, this value is inserted as the Interchange Receiver ID.

    For an inbound message, this identifier is used as the Interchange Sender ID to identity a trading partner as a sender of a message. If the EDI Interchange ID on its own does not uniquely identify a trading partner, it is used in combination with the EDI Group ID to locate a unique trading partner.

    Up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case-sensitive and must not contain any of the delimiter characters.

    EDI Interchange ID Qualifier Same as above.

    Mandatory for X12 and optional for EDIFACT. This identifier is used as the Interchange Sender or Receiver ID Qualifier field of the interchange envelope of the EDI payload.

    It is a code to indicate the category of the value specified in the EDI Interchange ID (for example, DUNS number, IATA number, and so on).

    For an outbound message, this value is inserted as the Interchange Receiver ID Qualifier.

    For an inbound message, the value is not currently used (if it were used, it would be treated as the Interchange Sender ID Qualifier).

    Must be exactly two characters for X12. The value must be from an X12 code list. See EDI Standards Reference. A generic sample value for X12 is ZZ.

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value for EDIFACT is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Interchange Internal ID Same as above. Only used for EDIFACT, and in that too, it is optional.

    EDIFACT defines this field as an identification (for example, a division, branch or computer system/process) specified by the sender of the interchange to be included if agreed by the recipient in response interchanges to facilitate internal routing.

    For an outbound message, this value is inserted as the EDI Interchange Internal ID field in the EDIFACT UNB envelope.

    For an inbound message, this value is not used.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.

    EDI Interchange Internal Sub ID Same as above.

    Only used for EDIFACT syntax version 4. In that, it is also optional.

    EDIFACT defines this field as the sublevel of sender internal identification when further sublevel identification is required.

    For an outbound message, this value is inserted as the EDI Interchange Internal Sub ID field in the EDIFACT UNB envelope, only if the message follows the Syntax Version 4 (which is the default).

    For an inbound message, this value is not used.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any of the delimiter characters.

    EDI Group ID Same as above.

    This is mandatory for X12 and optional for EDIFACT.

    EDIFACT defines this field as an identification of the sender's division, department, and so on from which a group of messages is sent.

    X12 has a similar definition.

    For an outbound X12 message, this value is inserted in the GS segment as the Application Receiver's Code.

    For an outbound EDIFACT message, this value is inserted in the UNG segment as the Receiver's Identification (a UNG is only generated when this identifier is selected in an outbound agreement; otherwise, not).

    For an inbound message, this value is used only in case the EDI Interchange ID, on its own, is not enough to uniquely identify a trading partner. In that case, a combination of the EDI Interchange ID and the EDI Group ID is used to locate a unique trading partner.

    Minimum of two characters and up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.

    EDI Group ID Qualifier Same as above. Only used for EDIFACT. In that, it is optional.

    It is a code to indicate the category of the value specified in the EDI Group ID (for example, DUNS number, IATA number, and so on).

    Only used for an outbound message, to insert as EDI Group ID Qualifier, if specified.

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.

    Application Partner ID Implicitly used by all outbound agreements (** see the note) Optionally used as an alternate way to specify which trading partner to which to route an outbound message.

    For an outbound message, you can specify either a Trading Partner ID or an Application Partner ID for trading partner identification. See Create Backend Integrations for more details on this usage.

    N/A

    Note:

    ** An implicit usage means you don't explicitly select the identifier in an inbound or outbound agreement. Instead, when you deploy an agreement, the identifier is automatically used in the runtime processing.
  • Used B2B identifiers are protected:

    You cannot delete trading partner's B2B identifiers that are explicitly referenced in transports or agreements. The associations must be removed from the transports or agreements before you can delete an identifier from the trading partner's B2B Identifiers section.

  • Multiple identifiers of the same type:

    The concept is similar to defining multiple identifiers in the host profile.

    You may add multiple B2B identifiers of the same identifier type. For example, you may want to add identifiers based on X12 or EDIFACT usage, based on business units within the trading partner, or based on an environment such as development, test, production, and so on. The combination of identifier type and value must be unique. This validation is enforced in the user interface.

    Even though you may define multiple identifiers of the same type, in outbound agreements, you must select specific unique types so that B2B knows exactly which identifiers to insert in an outbound message without ambiguity.

  • Updating values and applying changes to runtime:
    You can update existing trading partner's B2B identifier values at any time. However, they are not used in runtime B2B processing, until:
    • Each transport where an identifier value was referenced is redeployed.
    • Each outbound agreement where an identifier value was referenced is redeployed.
    • For B2B identifiers that are implicitly used, any of the agreements is redeployed (it can be any one of the inbound or outbound agreements).

    Redeployment is a lifecycle action available for transports and agreements. It applies changes to the runtime, on-the-fly, without disruption of message processing.

  1. Click B2B Identifiers to define the identifiers that uniquely identify a trading partner. This information is similar to what you defined for the host. See Define the Host Profile.
  2. Select an identifier name and specify a value. You can specify multiple name and value pairs. If no identifiers are defined, click Add icon to add a new identifier, selecting an identifier type and entering a value.
    The Primary Information, Contacts, B2B Identifiers, and Transports & Agreements tabs appear at the top. Below is the Add Identifiers title and plus (add) icon, Below is a table with columns for Identifier Name and Value. In the lower right are Cancel and Save buttons.

  3. Click Save.
  4. Click Back icon to return to the Trading Partners page.

Define Transports

A transport maps to a technical communication protocol. In most cases, you add one transport per trading partner to receive or send messages from the partner. The AS2 and FTP transport protocols are currently supported.

The Transports & Agreements page shows a list of transports for a trading partner.
The Primary Information, Contacts, B2B Identifiers, and Transports & Agreements (which is selected) are shown. Below is the Transports section, with a + sign. Below is a table with columns for Name, Direction/Type, Status, and Last Updated.

Each transport is listed with its name, direction and type, status, and last updated time. The direction is an indicator of whether it is configured to receive (down arrow), send (up arrow), or both. Status can be:
  • Not deployed
  • Deploying
  • Deployed
  • Failed
Hover the cursor over a row to see additional icon buttons to view configuration, edit configuration, and open an action menu. When you define the transport protocol (AS2 or FTP) and transport parameters to use, you automatically create two integrations (to receive and send messages from or to the trading partner).
A transport includes the following configuration settings:
  • A mandatory connection that you must separately create and select in the transport
  • Protocol-specific settings (for example, AS2 settings, FTP settings)

Transport concepts are provided. See Transports for Communication.

B2B Integrations

Two integrations are created automatically under-the-covers when a transport is created. These integrations are the heart of the transport for its runtime functioning. The two integrations actually process the runtime messages that pass through the transport.
  • B2B integration for receiving messages
  • B2B integration for sending messages
See Integrations Used for B2B Message Processing.

The B2B Integrations section of the Transport details panel shows the status of the two integrations.
The Integration name prefix field appears at the top. Below this is the Integration identifier prefix field. Below this is a table with columns for Integration Name and Integration Status.

Lifecycle Actions for Transports

Click the action menu on a row to view available actions.
A table is displayed with columns for Name, Direction/Type, Status, and Last Updated. To the right of the Last Updated column are three icons for view, edit, and actions. The actions icon is selected to show options for Deploy and Delete.

Lifecycle actions for transports are:
  • Create a transport: Adds a definition for the transport. The pair of B2B integrations are automatically created and permanently linked to this transport.
  • Receive schedule: Only available for the FTP transport. This action navigates you to the schedule configuration page where you can define the polling schedule for the B2B integration for receiving messages. You should add a schedule prior to deploying the transport. This enables the deploy action to also automatically start your schedule.
  • 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 (some types of configuration changes require undeployment and redeployment). See Apply Configuration Changes To Runtime.
  • 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.

After a transport is deployed, the status column displayed in the user interface is an overall view of the status of the two integrations.

A failed status for a transport usually means one of these integrations failed to activate or was (unexpectedly) manually deactivated.

Apply Configuration Changes To Runtime

Configuration changes to a transport are not applied to runtime processing unless you execute an action. The following table lists the type of change and the action needed.
Type of Configuration Change Actions to Take to Apply the Changes at Runtime
Common configuration settings in a transport Redeploy the transport.
Protocol-specific configuration changes in a transport (that is, AS2 or FTP settings), including changes to the values of identifiers Redeploy the transport.
Changes to the connection properties (other than username/password) Undeploy and then deploy the transport.
Changes to the username/password credentials in the connection

No actions are needed. The transport automatically uses the updated credentials if authentication failure occurs at runtime (older, cached credentials are discarded).

If you want to force the change, undeploy and then deploy the transport.

Changes to certificates in the Certificate management page Undeploy and then deploy the transport.

Collect AS2 Transport Details

You must collect AS2 transport details before you can define the AS2 transport in Oracle Integration.

Collect AS2 Transport Details

AS2 is an HTTP-based, point-to-point protocol typically used for real-time transactions. A bidirectional AS2 message exchange involves two AS2 endpoints, as shown below:
A box labeled Trading Partner = Sender connects with an inbound arrow labeled Inbound AS2 message to a box labeled Your Company (Host) = Receiver. Above the box is the label Your AS2 URL, with a URL value. Below this interaction, a box labeled Trading Partner = Receiver receives an incoming arrow on its right side labeled Outbound AS2 message. This arrow is coming from a box labeled Your Company (Host) = Sender. Above the Trading Partner = Receiver box is the label Partner's AS2 URL, with a URL value.

While creating this transport, you must collect information from your trading partner about their AS2 endpoint. You also may need to provide information about your AS2 endpoint to your trading partner. The following table describes the information you need to collect:
For... What You Need From Your Trading Partner What You Need to Provide to Your Trading Partner
Basic connectivity
  • The partner's AS2 URL.
  • An SSL certificate with a public key, if a self-signed certificate was used.
  • Username/password credentials for HTTP basic authentication, if enabled.
Two-way SSL for outbound connections (an optional feature) If you select the Invoke or Trigger and Invoke role, you can create a certificate alias to use for establishing client identity during two-way SSL communication. See Prerequisites for Creating a Connection in Using the AS2 Adapter with Oracle Integration Generation 2 .
Signed or encrypted AS2 messages (an optional feature)
  • The partner's public certificate for signing and encryption. (Typically the same certificate is used for both signing and encryption, but if the partner prefers to use different ones, you should get two separate public certificates from them.)
  • Your public certificate for signing and encryption (see Certificates)

Signing and encryption are optional features in AS2. You can start with only the basic connectivity first and add signing/encryption later. Signing/encryption provide nonrepudiation, message integrity, and security features and are recommended for production environments. However, there is a bit more complexity in setting those up.

The following table shows which PKI key is used in each scenario:
Message Configuration Inbound Message Outbound Message
Signed AS2 message Partner's public key for signing is used to verify a signed message. Your company's private key for signing is used to digitally sign the message.
Encrypted AS2 message Your company's private key for encryption is used to decrypt the message. Partner's public key for encryption is used to encrypt the message.
If you already have the AS2 endpoint information from your trading partner, follow these steps:
Step Description
1 Upload each of the partner's certificates to Home > Settings > Certificate. Upload SSL certificates as X.509 Trust, whereas upload signing and encryption as X.509 Identity. For identity certificates, you decide and enter a unique alias. Note the aliases.

See Manage Security Certificates in Using Integrations in Oracle Integration Generation 2.

2 If signing/encryption is a requirement, acquire or generate a key-pair for signing and encryption (or two separate key-pairs, if you want to use separate keys for signing and encryption).

See Certificates. Upload the private key to Home > Settings > Certificate as X.509 Identity and note the alias and password you enter. Share the public key with your trading partner. However, never share the private key.

3 Create an AS2 connection with the Trigger and Invoke role. In the Connections page, enter:
  • The partner's AS2 URL in the AS2 Service URL field
  • The username/password in the corresponding fields

If signing/encryption are a requirement, configure the AS2 connection further.

If both your partner and your company use one certificate for signing and encryption, select AS2 Basic Policy. If either of you use different certificates, select AS2 Advanced Policy.

  • For AS2 Basic Policy, enter the partner's certificate alias, corresponding to the identity certificate from step 1.
  • For AS2 Basic Policy, enter the private key alias and key password, corresponding to the identity certificate from step 2.
  • For AS2 Advanced Policy, enter each of the certificate aliases into the fields. See Configure Connection Security in Using the AS2 Adapter with Oracle Integration Generation 2 .
4 Test the AS2 Adapter connection, to make sure it succeeds. If it fails, review the errors, verify that the AS2 URL entered is correct, and verify that the certificate aliases are correct. Save the AS2 Adapter connection.
5 Create an AS2 transport, selecting the AS2 Connection created in step 3. Complete the configuration. See Define an AS2 Transport.
6 Deploy the AS2 transport. After the state changes to deployed, the transport is ready for use.
If you do not yet have the AS2 endpoint information from your trading partner, but want to get your side ready for receiving AS2 messages, follow these steps:
Step Description
1 Same as Step 1 in the previous table. Skip this step for now, but you can perform it when the information becomes available from the trading partner
2 Same as Step 2 in the previous table.
3 Same as Step 3 in the previous table, but given that the partner's AS2 URL is not yet available, enter a temporary placeholder URL in the AS2 Service URL field. This can be the URL of your Oracle Integration instance, copy and pasted from the browser URL address or any other valid URL. This placeholder is only needed to pass the connection test (which fails if the URL is invalid). Outbound AS2 messages do not work with this placeholder, but inbound messages can be received (since the AS2 service URL is not used when receiving inbound messages).
4 Same as Step 4 in the previous table.
5 Same as Step 5 in the previous table.
6 Same as Step 6 in the previous table.
An example of an AS2 Adapter connection is shown below.
  • Connection properties:
    The Connection Properties section includes the AS2 Server UR field, Enable two way SSL for outbound connections field, and Client Identity Key Alias (Two Way SSL) field.

  • Connection security:
    The Security section includes the Security Policy field (AS2 Basic Policy is selected), the Username field, the Password field, the Private Key Alias field, the Key Password field, and Partner Certificate Alias field.

Credentials

To receive messages over AS2 from an external trading partner, HTTP basic authentication is enforced. Your trading partner is required to send the Authorization HTTP header with username/password credentials you provide them in an AS2 message.

For internal testing you may use the same credentials that you use to log in to Oracle Integration to send test AS2 messages. However, it is not safe to share these credentials with an external trading partner because they can also log in to Oracle Integration with these credentials.

Instead, create a new user account in the Oracle Integration Identity Management application. Grant the Service Invoker role to this user account. This account is enough to send messages, but does not grant permissions to access any user interface pages in Oracle Integration. Share the username and password of this new user with the trading partner.

Certificates

If you want to enable encryption or signing for the AS2 communication, you must create a key pair and certificate following your company's process and generate a CA-signed certificate that you use for AS2 decryption and signing.

For testing with a self-signed certificate, here are simple steps to generate a key-pair using the Java keytool:
  1. Generate public/private key pair using keytool.
    1. Specify any alias and a keystore file name, replacing b2b-private-key-alias and b2b.jks with your values.
    2. Enter a keystore password when prompted and note it.
    3. Enter your organization's information when prompted.
    This generates a key pair (a public key and associated private key) and self-signed digital certificate in a keystore. If the keystore does not exist, it is created.
    keytool -genkey -keyalg RSA -alias b2b-private-key-alias -validity 1095 -keystore b2b.jks
  2. Upload the JKS into Oracle Integration as the X.509 type (SSL transport) and Identity category using the same alias and password as entered above (this is part of Step 3 from the table of steps above).
  3. Export the public key from this keystore as follows.
    1. Replace b2b.jks, b2b-private-key-alias, and public.cer with your keystore file name, alias that was used previously, and a file name to store the public certificate.
      keytool -export -keystore <b2b.jks> -alias <b2b-private-key-alias> -file <public.cer>
  4. Convert it to any other industry-standard format using keytool as per your preference, if necessary. Share only the public certificate public.cer with your trading partner (never share the private key with anyone). Your trading partner uses the public key certificate for signature verification and encryption.

AS2 URL for Receiving

You need the AS2 URL for your AS2 endpoint to share with your trading partner. Once the transport is deployed (indicating it is ready to receive and/or send messages), your AS2 endpoint URL is displayed in the AS2 Endpoint URL for Receiving transport field. Copy this AS2 URL to share with your trading partner. This AS2 URL is not common across all trading partners; it is specific to the current trading partner that you are viewing or editing. Only that specific trading partner may send AS2 messages to this URL.

The AS2 URL is the URL to invoke the AS2 integration for receiving messages for this transport. While you can also get the same from the Integrations page, this provides an easier way to access it.

Define an AS2 Transport

Once you have collected AS2 transport details, you can define an AS2 transport in Oracle Integration.

  1. In the left navigation pane, click B2B > Trading Partners.

    The Trading Partners page is displayed.

  2. In the row of the trading partner for which to define transports, click Edit icon.
  3. Click Transports & Agreements.

Define Transports to Create Integrations

  1. In the Transports section, click Add icon to define how a message is delivered to or received from this trading partner. The configuration panel is opened:
    The Add Transport page shows tabs for Primary Information, Receive, Send, and B2B Integrations. Below are the Name, Type, and Description fields. The Cancel and Add buttons are in the lower right.

  2. Define the following details.
    Section Description
    Primary Information section
    • Name

    Enter a name for the transport. The name is used for display purposes only.

    • Description

    Enter an optional description of the transport. The description is used for display purposes only.

    • Type

    Select AS2 from the dropdown. This represents the communication protocol you use to exchange messages with your trading partner.

    Based on selecting AS2, the appropriate configuration settings for the AS2 transport are displayed.

    • Trading partner's connection (Trigger and Invoke)

    Select an existing AS2 Adapter connection configured for connectivity to your trading partner or click Add icon to create a new AS2 Adapter connection on the Connections page. It must be a Trigger and Invoke connection. Trigger Only and Invoke Only connections cannot be used for transports.

    See Create a Connection in Using the AS2 Adapter with Oracle Integration Generation 2 .

    If you want to select another connection, you can do so when this transport is not deployed. Once you deploy the transport, the connection selection cannot be changed.

    You can modify the configuration properties inside the connection at any time. However, if you modify the connection settings after this transport is deployed, you must undeploy and then redeploy the transport for the changes to take effect.

    • Partner Identifier

    Used as an AS2-To header for outbound messages and as the expected AS2-From header for inbound messages. See Define B2B Identifiers.

    • Host Identifier

    Used as the AS2-From header for outbound messages and as the expected AS2-To header for inbound messages.

    See Host Profile.

    • Character Encoding

    Select the character encoding to apply to all payloads processed through this transport.

    The character encoding is used at the EDI parsing (inbound) or EDI generation (outbound) step.

    Receive section
    • Allow any AS2 Identifier defined for this trading partner

    Enable this checkbox if you want to accept an AS2-From header value from within a set of possible values (as opposed to accepting just one value). A typical case for this is when different business units within the trading partner's organization use different AS2 identifiers, and you want to accept messages from all of them. For this to work, you must also add all acceptable AS2-From values as B2B identifiers to the trading partner.

    If this is disabled, only one specific AS2 identifier selected for Partner's Identifier is accepted at runtime for inbound processing.

    • Do not validate the AS2-To header
    Enable this if you want to allow any value for the AS2-To header, effectively disabling the strict validation otherwise done against the host's AS2 identifier.
    • AS2 Endpoint URL for Receiving

    This is a display-only field. After the transport is deployed, indicating it is ready to receive and send messages, your AS2 endpoint URL is displayed. You may share this URL with your trading partner. This AS2 URL is not common across all trading partners. It is specific to the current trading partner that you are viewing or editing.

    Send section
    • AS2 Subject
    An optional field that is inserted into all outbound messages that use this transport, as the Subject HTTP header.
    • Content-Type
    The payload's type for outbound messages. Typically for EDI payloads, use application/EDI-Consent as a generic way to specify that the payload can be either X12 or EDIFACT.
    • User-defined Content-Type
    To enter another value not already available in the Content-Type drop-down list, select User-defined Type and enter your value.
    • Signature
    If you want to enable message signing for outbound messages, select the appropriate signing algorithm from the drop-down list. For signing, you must configure the AS2 Adapter connection appropriately with certificates, as described in Step 3 of the above table.

    This field does not apply for inbound message processing. Signature verification of signed inbound messages is done automatically and there is no configurable option to enable or disable it. You must configure the AS2 connection with the right certificates for that to work also.

    • Encryption
    If you want to enable message encryption for outbound messages, select the appropriate encryption algorithm from the drop-down list. For encryption, you must configure the AS2 Adapter connection appropriately with certificates as described in Step 3 of the above table.

    This field does not apply for inbound message processing. Decryption of encrypted inbound messages is done automatically and there is no configurable option to enable or disable it. You need to configure the AS2 Adapter connection with the correct certificates for that to work also.

    • Compression
    Optionally select to compress the outbound message.
    • None
    • Digitally sign first, then compress: Sign the outbound message before compressing it.
    • Compress first, then digitally sign: Compress the outbound message before signing it.
    • Request MDN
    Select a value in the drop-down list to request a synchronous or asynchronous MDN (or None for no MDN) when sending outbound messages.

    This field does not apply to inbound message processing. MDN is automatically generated and sent back to the trading partner based on whether your trading partner has requested an MDN as part of an inbound message. There is no configuration required. The AS2 HTTP headers Disposition-Notification-To, Disposition-Notification-Options, and Receipt-Delivery-Option convey whether the partner wants to receive an MDN back, whether it should be synchronous or asynchronous, and whether it needs to be signed. The AS2 transport automatically handles the MDN processing. See the AS2 specification (RFC 4130) to understand more technical details.

    • None: Request that no MDN be sent back.
    • Async MDN: Request that the MDN be sent separately from the outbound message.
    • Sync MDN: Request that the MDN be sent immediately in the response.
    • Request Signed MDN
    If you choose to request an MDN for an outbound message, select the checkbox to ask the trading partner to send signed MDNs. You must configure the AS2 Adapter connection appropriately with certificates as described in Step 2 of the table of steps above, so that the signed MDNs can be validated.
    B2B Integrations section
    • Integration name prefix
    Enter a short prefix that is used to form the complete integration names for receiving messages and sending messages.

    For the AS2 transport, it forms the integration names: your_prefix AS2 Receive and your_prefix AS2 Send.

    Details about these integrations are provided. See Create B2B Integrations for Receiving and Sending.

    • Integration identifier prefix
    Enter a short prefix that is used to form complete integration identifiers for receiving messages and sending messages.

    For the AS2 transport, it forms the integration identifiers: your_prefix_AS2_RECEIVE and your_prefix_AS2_SEND.

    The final integration identifier must be unique across all integrations. Therefore, ensure that you enter a prefix that is unique.

    If the uniqueness check fails, you get the opportunity to try with a different prefix.

  3. Click Add.

    The new transport is displayed.
    The Primary Information, Contacts, B2B Identifiers, and Transports & Agreements tabs (which is selected) are shown. Below is the Transports section, with a + sign. Below is a table with columns for Name, Direction/Type, Status, and Last Updated. To the upper right of the Last Updated column is the refresh button.

  4. From the Action menu menu, select Deploy.
  5. Select Deploy again when prompted.
    If successful, the following message is displayed.
    Transport transport_name was deployed successfully.
    The transport status is changed to Active.
  6. Go to the Integrations page and note that both integrations are created and activated.
  7. If you need to undeploy the transport, select Undeploy from the Action menu menu in the Transports & Agreements section. Undeploying the transport also undeploys the integrations.

Collect FTP Transport Details

FTP is a file-based transfer protocol that requires an external FTP server. The FTP transport only acts as an FTP client that connects directly to your trading partner's FTP server or an FTP server hosted by your company (which the trading partner also connects to as a client). In either case, the FTP transport pulls files from (or pushes files to) an FTP server.

An FTP transport works on a time-based schedule when receiving files (as file polling), and in real-time when sending files. FTP is typically used in a batch mode (for example, processing a batch of purchase orders or a sales catalog on a nightly schedule).

Before creating this transport, you need to create an FTP Adapter connection with the Trigger and Invoke role. Review all prerequisites and details to create an FTP Adapter connection. See Create an FTP Adapter Connection in Using the FTP Adapter with Oracle Integration Generation 2.

Note:

Note these FTP transport restrictions (although these features are provided in the FTP Adapter in standalone mode):
  • Connectivity to an on-premises FTP server through the connectivity agent is not currently supported.
  • PGP encryption and decryption are not currently supported.
  • Signing and signature verification for files is not currently supported.
  • Processing of .zip files is not currently supported.

Define an FTP Transport

Once you have collected FTP transport details, you can define an FTP transport in Oracle Integration.

  1. In the left navigation pane, click B2B > Trading Partners.

    The Trading Partners page is displayed.

  2. In the row of the trading partner for which to define transports, click Edit icon.
  3. Click Transports & Agreements.
  4. In the Transports section, click Add icon to define how a message is delivered to or received from this trading partner. The configuration panel is opened:
    The Add Transport page shows tabs for Primary Information, Receive, Send, and B2B Integrations. Below are the Name, Type, and Description fields. The Cancel and Add buttons are in the lower right.

  5. Define the following details.
    Section Description
    Primary Information section
    • Name
    Enter a name for the transport.

    The name is used for display purposes only.

    • Description
    Enter a description of the transport.

    The description is used for display purposes only.

    • Type
    Select FTP from the drop-down list.

    This represents the communication protocol you use to exchange messages with your trading partner. Based on selecting FTP, the appropriate configuration settings for the FTP transport are displayed.

    • Trading partner's connection (Trigger and Invoke)
    Select an existing FTP Adapter connection to use or click Add icon to create a new FTP Adapter connection on the Connections page. It must be a Trigger and Invoke connection. Trigger Only and Invoke Only connections cannot be used for transports.

    See Create a Connection in Using the FTP Adapter with Oracle Integration Generation 2.

    If you want to select another connection, you can do so when this transport is not deployed. Once you deploy the transport, the connection selection cannot be changed.

    You can modify the configuration properties inside the connection at any time. However, if you modify the connection settings after this transport is deployed, you must undeploy and then redeploy the transport for the changes to take effect.

    • Character Encoding
    Select the character encoding to apply to all payloads processed through this transport.

    The character encoding is used at the EDI parsing (inbound) or EDI generation (outbound) step.

    Receive section
    • Input Directory
    Specify a directory path on the FTP server to poll for files (inbound). For example:
    /b2b/inbound

    If the input directory is specified, the FTP transport is considered capable of receiving, and the direction indicates a darker up-arrow in the transports listing.

    • Scan Recursively

    Select to scan all subdirectories to look for files.

    Deselect to only scan the immediate input directory, ignoring any subdirectories.

    File Name Filter Enter a wildcard expression that the FTP server understands to match files.

    For example, *.edi.

    • Minimum Age (Seconds)
    Specify a delay in seconds. The value specified indicates how long to ignore newly created files, relative to their creation time. For example, if a file is created at 11:02:00 and a minimum age of 60 seconds is specified, that file is ignored and not picked up for processing until 11:03:00, when it becomes 60 seconds old.

    This delay allows the writer of a file to complete its transfer of bytes and avoid situations where not enough time was given to complete the file transfer. As a result, a half-written file was picked up for processing.

    If you specify a nonzero minimum age, make sure to also select an appropriate value for the FTP server time zone drop-down in the FTP Connections page. The time zone calculates the current age of a file, based on the current time and the creation timestamp of the file. If you do not select a time zone, then it defaults to the time zone of the Oracle Integration server. The mismatch can delay the processing of files for up to 12 hours. See Configure Connection Properties in Using the FTP Adapter with Oracle Integration Generation 2.

    • Max Count of Files
    Specify the maximum number of files to be processed in one scheduled call. If the schedule is every hour, then every hour up to the maximum number of files are processed and any remaining files are picked up in a future run. See Create Scheduled Integrations in Using Integrations in Oracle Integration Generation 2.

    Limit this to a reasonable number so that the processing integration does not run for a very long time and consume precious resources just for one trading partner.

    The maximum value is 1000. The default is 100.

    Note: The file list is returned in a sorted order according to the last modified time. If you selected 10 as the maximum number of files and the last modified time of the eleventh file is the same as the tenth file, then the eleventh file is also added. This continues until you get a file with a different timestamp.

    Send section
    • Output Directory
    Specify the directory path on the FTP server in which to put outbound files. For example:
    /b2b/outbound

    If the output directory is specified, the FTP transport is considered capable of sending, and the direction indicates a darker down-arrow in the transports listing.

    • Output File Name
    Specify an output file name.

    The file name can include substitution patterns, for example, (Out%SEQ%.edi creates files with names like: Out1.edi, Out2.edi, and so on).

    The following patterns are supported (surround them inside % chars):
    • SEQ
    • yyyyMMdd
    • MMddyyyy
    • yyMMddHHmmss
    • yyMMddHHmmssSS
    • yyMMddHHmmssz
    • yyMMddHHmmssSSz
    Note: Use %SEQ% with caution because concurrent processing of messages may generate duplicate sequence numbers in some cases. This causes files to be overwritten.
    B2B Integrations section
    • Integration name prefix
    Enter a short prefix that is used to form the complete integration names for receiving messages and sending messages.

    For the FTP transport, it forms the integration names: your_prefix FTP Receive and your_prefix FTP Send.

    Details about these integrations are provided. See Create B2B Integrations for Receiving and Sending.

    • Integration identifier prefix
    Enter a short prefix that is used to form complete integration identifiers for receiving messages and sending messages.

    For the AS2 transport, it forms the integration identifiers: your_prefix_FTP_RECEIVE and your_prefix_FTP_SEND.

    The final integration identifier must be unique across all integrations. Therefore, ensure that you enter a prefix that is unique.

    If the uniqueness check fails, you get the opportunity to try with a different prefix.

    Note:

    There is one behavior not exposed in the transport configuration for FTP. It controls what should happen to an inbound file after processing is complete. You can alter this behavior by changing a property for the FTP receive integration. See FTP Receive Integration Postprocessing Behavior.
  6. Click Add.

    The new transport is displayed.
    The Primary Information, Contacts, B2B Identifiers, and Transports & Agreements (which is selected) tabs are shown at the top. Below is the Transports section and + icon. Below this is a table with columns for Name, Direction/Type, Status, and Last Updated. Just above and to the right is the refresh icon.

  7. If you selected FTP as the transport protocol, select Receive Schedule from the Action menu menu to define a schedule. Once the schedule is created and saved, click Back button to return to the Transports & Agreements section. See Define the Integration Schedule in Using Integrations in Oracle Integration Generation 2.
  8. From the Action menu menu, select Deploy.
  9. Select Deploy again when prompted.
    If successful, the following message is displayed.
    Transport transport_name was deployed successfully.
    The transport status is changed to Active.
  10. Go to the Integrations page and note that both integrations are created and activated.
  11. If you need to undeploy the transport, select Undeploy from the Action menu menu in the Transports & Agreements section. Undeploying the transport also undeploys the integrations.

FTP Receive Integration Postprocessing Behavior

By default, files that are processed by the FTP Receive integration are moved to a backup directory. The backup directory name is assumed to be original-input-directory_backup and is created automatically provided the correct permissions are granted to create it.

You can customize this behavior as follows. To locate these properties, use the Update Property Values menu as described below.
Permission Description Values
Delete-Or-Keep-Processed-Files Controls whether processed files are retained or deleted.
  • deleteAlways: Deletes a processed file regardless of whether processing succeeded or failed.
  • keepOnError: Deletes a processed file only on success. If the processed file failed, the file is retained and moved to a different directory.
  • keepAlways: (default) Retains a processed file, regardless of whether processing succeeded or failed by moving it to a different directory.
Error-File-Extension

If a processing error occurs, rename the file by appending the Error-File-Extension value (for example, _error), depending on the Delete-Or-Keep-Processed-Files setting.

For example, if an input file name was 850_po.edi, then the default value after processing the file is renamed to 850_po.edi_error.

  • _error (default).
  • You can set the value for Error-File-Extension to any string. However, the combination of original-input-filenameError-File-Extension must result in a valid directory path on the FTP server.
Move-To-Directory

Processed files are moved to another directory depending on the Delete-Or-Keep-Processed-Files value. The backup directory is assumed to be original-input-directoryMove-To-Directory.

For example, if the input directory was /b2b/inbound, then with the default value, processed files are moved to the /b2b/inbound_backup directory.

  • _backup (default).
  • You can set the value for Move-To-Directory to any string. However, the combination of original-input-directoryMove-To-Directory must result in a valid directory path on the FTP server.
Processed-File-Extension

If processing is successful, rename the file by appending the Processed-File-Extension value (for example, _processed), depending on the Delete-Or-Keep-Processed-Files setting.

For example, if an input file name was 850_po.edi, then with the default value, after processing, the file is renamed to 850_po.edi_processed.

  • _processed (default).
  • You can set the value for Error-File-Extension to any string. However, the combination of original-input-filenameError-File-Extension must result in a valid directory path on the FTP server.

To change the behavior for one specific FTP transport, locate its FTP Receive Integration, and navigate to the Update Property Values dialog.
The Integrations page shows a search icon, filter icon, and number of integrations in the upper left. A table is displayed with columns for Name, Version, Style, Last Updated, and Status. At the far right, the actions menu is selected to show options for View, Edit, Clone, Create New Version, Update Property Values (which is selected), Export, Add Schedule, Tracing, Asserter Recordings, Enable Asserter Recording, Submit Asserter Recordings, and Configure. In the upper right is the Import button.

  1. In the Update Property Values dialog, select the property to change and enter a value in the New Value field.
  2. Select Submit to make the new values effective for future runs.
    The Update Property Values dialog is shown. From top to bottom are the Learn More link, the Property Name field, the Default Value field, Current Value field, and New Value field.

  3. To change the behavior for all transports created in the future, edit the integration named B2B Integration Template FTP Receive.
  4. In the schedule action in the integration canvas, select Edit Integration Properties and change the default values.
    The actions menu of the schedule is selected. The menu includes selections for Edit Schedule Definition, Edit Integration Properties (which is selected), View Integration Properties, and Convert to REST Trigger.

Create Agreements

This chapter providing details about creating and managing 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.

Detailed agreement concepts are provided. See Agreements.

You can view a list of inbound agreements and outbound agreements from the trading partner's Transports & Agreements tab.

  1. In the left navigation pane, click B2B > Trading Partners.

    The Trading Partners page is displayed.



    Note the following details:
    • You cannot delete a trading partner with active agreements.
    • Click Details icon to view specific details about the trading partner, including any associated trading partner agreements.
  2. In the row of the trading partner for which to create agreements, click Edit icon.

Define Inbound and Outbound Agreements

  1. Click Transports & Agreements.
  2. In the Inbound Agreements section, click Add icon to add a new agreement.
    1. Define the following details.
      Field Description
      Name Enter a name.

      This is only used for your reference. Your trading partner does not see any of the agreement names or configuration details you define.

      Description Enter an optional description.
      Select a Document Select the type of document to receive. You can select an existing B2B document or create a new B2B document.
      Select a backend integration Select a backend integration to which to route this document after B2B processing. Either select one from the list or, if you know the identifier and version of your backend integration, enter it in the following format:
      INTEGRATION_IDENTIFIER|01.00.0000

      Backend integration concepts are provided. See Integrations Used for B2B Message Processing.

      Ensure that you have created a backend integration. See Create Backend Integrations.

      The dropdown list of integrations is filtered and only shows integrations that use the B2B action. It also currently shows all B2B system integrations. Do not select a B2B system integration. You must select a backend integration that you created separately to handle this type of document. A backend integration interfaces with your backend application, such as Oracle ERP Cloud.

      Note: Integrations specific to B2B for Oracle Integration can be displayed by entering ediadapter in the Search field on the Integrations page.

      Enable Validations Select to perform syntactical validations on the received EDI payload and reject it if validation errors are found. If Generate Functional Ack is also enabled, the functional acknowledgment sent back to the trading partner conveys the acceptance or rejection, including any validation errors found.

      Deselect to skip syntactical validation checks and always accept the EDI payload.

      Generate Functional Ack Select to generate and send a functional acknowledgment back to your trading partner.
      • For EDI X12, a 997 document is generated.
      • For EDIFACT, a CONTRL document is generated to relay the outcome of the EDI translation.

      The generated functional acknowledgment is automatically routed to the B2B Integration for sending messages that is linked to the transport from which the incoming document was received.

      Deselect to not generate or send functional acknowledgments.

      This setting requires your company and trading partner to mutually decide up front whether or not to use functional acknowledgments. A problem scenario is when one party expects these acknowledgments, but the other party does not send them.

      Enable Checks for Duplicate Control Numbers Select to check for duplicate control numbers in B2B transactions in inbound agreements. This prevents processing of transactions with duplicate control numbers. For example, if duplication exists between the control numbers in two transactions, the first message is successfully processed because the number is unique, but the second transaction is caught and not processed. Transaction failure is visible in the Message Logs section of the transaction on the Track B2B Messages page. For example, here is part of the message for a duplicate control number that was caught and not processed:
      This EDI transaction with 
      document type [850], version [4010] 
      was not translated because it was 
      determined to be a duplicate of a 
      transaction. 
    2. Click Add.
    3. From the Action menu menu, select Deploy.
    4. Select Deploy again when prompted.

      The inbound agreement status is changed to Active.

    5. If you need to undeploy the agreement, select Undeploy from the Action menu menu.
    6. Click Edit icon to make any updates.
  3. In the Outbound Agreements section, click Add icon to add a new agreement.
    1. Define the following details.
      Field Description
      Name Enter a name.

      This is only used for your reference. Your trading partner does not see any of the agreement names or configuration details you define.

      Description Enter an optional description.
      Select a Document Select the type of document to send. You can select an existing B2B document or create a new B2B document.
      Select identifiers Certain mandatory and optional identifiers, such as EDI Interchange ID, are inserted into EDI envelope segments during the outbound translation. Select the identifiers you want inserted into the EDI envelopes.

      See Define B2B Identifiers and Define Identifiers in the Host Profile.

      • Select Trading Partner Identifiers: Identifies the trading partner receiving the document. Select trading partner identifiers that you want to insert as the receiver-side values (for example, Interchange Receiver ID).
      • Select Host Identifiers: Identifies the host sending the document. Select host identifiers that you want to insert as the sender-side values (for example, Interchange Sender ID).
      Select a Transport Select a transport to route messages processed through the current outbound agreement to that transport for final delivery to the external trading partner.

      Selecting a transport defines a routing rule that controls how a message gets routed from a backend integration to a B2B integration for sending messages.

      Details about how outbound messages are routed are provided. See Message Routing Between Integrations.

      Enable Validations
      • Select to perform syntactical validations on the canonical XML payload during the outbound EDI translation.

        If validation errors are detected at this step, it means that the output EDI is syntactically invalid and must not be sent to the trading partner. Therefore, it is rejected during the translation phase and not routed to the B2B integration for sending messages.

      • Deselect to skip syntactical validation checks and send the EDI payload to the trading partner even if it has errors.

      Functional Ack Required
      • Select to require (and expect) that your trading partner always send back functional acknowledgments. When an acknowledgment is required, an outbound business message goes into a Pending Functional Ack state after transmission and is marked as Successful or Failed only when an acknowledgments is received.
      • Deselect to not require (or expect) functional acknowledgments. Outbound business messages are immediately marked as Successful.

      This setting requires your company and your trading partner to mutually decide up front whether or not to use functional acknowledgments. A problem scenario is when one party expects these acknowledgments, but the other party does not send them.

    2. Click Add.
    3. From the Action menu menu, select Deploy.
    4. Select Deploy again when prompted. The outbound agreement status is changed to Active.
    5. If you need to undeploy the agreement, select Undeploy from the Action menu menu.
    6. Click Edit icon to make any updates.

Lifecycle Actions for Agreements

Click on the action menu on a row to view available actions.
The Inbound Agreements section shows a + sign. Below this is a table with columns for Name, Description, Status, Backend Integration, and Last Updated. At the far right of a selected trading partner are the view icon, edit icon, and action icon, which is selected to show options for Deploy and Delete.

Lifecycle actions for agreements are:
  • Create an agreement: Adds the definition in design-time only (but unless deployed, the new agreement is not enforced at runtime).
  • Deploy an agreement: Makes the agreement visible for runtime processing and is immediately enforced.
  • Redeploy an agreement: Applies configuration changes to the runtime on-the-fly without disrupting message processing.
  • Undeploy an agreement: Hides the agreement from runtime processing, making it no longer effective, starting immediately.
  • Delete an agreement: Removes it from design-time.

Updating Values and Applying Changes To Runtime

You can update existing agreement settings at any time. However, the changes are not applied to the runtime processing until the agreement is redeployed.

Redeployment is a lifecycle action available for agreements. It applies changes to the runtime, on-the-fly, without disruption to message processing.

Changes to Identifier Values

Even if you don't directly change the agreement's settings, you cause an indirect change to an agreement if you modify values for an identifier from Trading Partner > B2B Identifiers or Host Profile > Identifiers.

To apply indirect changes, redeploy the agreement.

There is one special case for inbound agreements, because B2B identifiers are implicitly used by inbound agreements:
  • If you add, update, or delete trading partner's identifiers, redeploy any of the agreements to apply the identifier changes to runtime.

Export and Import a Trading Partner

You can export an individual trading partner and import it into another instance of Oracle Integration. Importing a trading partner also imports the associated agreement references (for example, documents, schemas, and identifier references).

Note:

Ensure that you also separately import any backend integrations referenced in the trading partner agreement.

Export a Trading Partner

You can export or import a trading partner definition from the trading partners listing page.
The Trading Partners page shows Import and Create buttons in the upper right. Below this is a table with columns for Name, Usage, and Last Updated. At the far right of a selected trading partner are the view icon, edit icon, and action icon, which is selected to show options for Export and Delete.

  1. In the left navigation pane, click B2B > Trading Partners.
  2. From the Action menu menu, select Export.
  3. Download the ZIP file.

Import a Trading Partner

  1. In the left navigation pane, click B2B > Trading Partners.
  2. Click Import.
  3. If you want to overwrite an existing trading partner agreement of the same name, click Overwrite Any Existing Drafts.

    This selection overwrites the trading partner and all associated artifacts (identifiers and agreements) when there are no active agreements. Associated documents and schemas are also overwritten if they do not have any active agreement references for other trading partners.

    If you select to overwrite, you must click the checkbox explicitly for the import to overwrite the existing trading partner, associated documents, and schemas. If the checkbox is not selected, the artifact import is skipped (that is, the document and schemas are skipped during the import if they already exist in the system).

    If these documents and schemas have other references (that is, if another agreement for a different trading partner refers to the same document or schema), then regardless of whether you selected to overwrite, the import action is skipped for the document and schemas. Artifacts can be overwritten only if they do not have any other dependencies. For example, a schema cannot be overwritten because it is referenced by another B2B document used by another trading partner.

  4. If import is successful, a message is displayed:
    B2B Trading Partner import successfully for trading_partner_name. More Information.
  5. Click More Information to view the Trading Partner Import Report, which provides details about what was overwritten and not overwritten.
    The Trading Partner Import Report includes the trading partner name, and sections for Trading Partner (Overwritten), Documents, and Schemas.

  6. Click Close.
  7. Click Edit icon, then click the Agreements tab.
  8. Verify that all references are intact (for example, if any backend integrations require importing and reactivating) and make any necessary updates.
  9. Redeploy the agreements.