1. Using B2B for Oracle Integration 3
  2. Use B2B for Oracle Integration in Trading Partner Mode
  3. Manage B2B Trading Partners

Manage B2B Trading Partners

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

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
    Application Partner ID Not used. This identifier from the host profile is not used. Not used.
    AS2 Identifier Under Trading Partners, then Transports & agreements, then AS2, then AS2 identifiers, and then 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 Under Trading Partner, then Transports & agreements, then Outbound agreement, and then 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.
    DUNS Same as above.

    Only used for RosettaNet.

    		A nine digit, numerical value.
    LocationID Same as above. This is a free text field and used to populate the Service Header if it is provided. Free text field.
  • 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, X12 HIPAA, EDIFACT, or RosettaNet 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, 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 life cycle 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 navigation pane, click B2B, then Host profile.
  2. Click Create.
  3. In the Host company name field, enter your company name. The name is currently only for reference and not used elsewhere.
  4. Select a host identifier or, if none are defined, click Add Install 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
  5. Select a host identifier name and specify a value. You can specify multiple name and value pairs for the host.
  6. 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.

  7. If you want to delete any unneeded host identifiers, click Delete 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. To create a trading partner in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to create the trading partners.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click Add.
  2. To create a trading partner in a standalone environment.
    1. In the navigation pane, click B2B, then 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.


      The Trading partners page shows columns for Name, Usage, and Last updated. Import and Create buttons appear in the upper right corner.

    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.

See the following sections:

View Properties

  1. Click Properties 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 Properties, Contacts, B2B Identifiers, and Transports & Agreements tabs appear at the top. Below are the Name and Description fields. In the upper right is the Save button.

  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 Properties, 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 upper right is the Save button.

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, then Host profile, and then 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
    Application Partner ID Implicitly used by all outbound agreements (** See the note at the bottom of the table.) 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
    AS2 Identifier Trading partners, then Transports & agreements, then AS2, then AS2 identifiers, and then 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, then Outbound agreements, then 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.
    DUNS Same as above.

    Only used for RosettaNet.

    		A nine digit, numerical value.
    LocationID Same as above. This is a free text field and used to populate the Service Header if it is provided. Free text field.
    Name Same as above. This identifier is used in the Partner’s identifier and Host identifier fields when defining the transport. For example:
    • Partner’s identifier: Used as the Responder Party ID for outbound messages and as the expected Initiator Party ID for inbound messages. The identifier type is used as the Party ID type.
    • Host identifier: Used as the Initiator Party ID for outbound messages and as the expected Responder Party ID for inbound messages. The identifier type is used as the Party ID type.
    		Free text field.
    Role Same as above. This identifier is used to populate the Initiator/Responder role fields in the AS4 message. Free text field.

    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, X12 HIPAA, EDIFACT, or RosettaNet 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 life cycle 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 Install icon to add a new identifier, selecting an identifier type and entering a value.
  3. In the Control numbers section, enter the initial control numbers in the Interchange, Group, and Transaction fields. These numbers are automatically incremented within the ISA and GS segments for each external trading partner. This feature is only applicable for outbound X12, X12 HIPAA, RosettaNet, and EDIFACT documents.

    For example, assume the last control number used for trading partner A in a development environment was 100004. When migrating to a test environment, they want to start incrementing the initial control number for trading partner A with 200001. This eliminates the possibility of duplicate control numbers and enables them to identify the environment from which EDI messages are being sent.


    The Properties, Contacts, B2B identifiers (which is selected), and Transports & agreements tabs appear at the top. Below is the B2B Identifiers title and plus (add) icon, Below is a table with columns for B2B Identifier and Value. To the right is the Control numbers section, with fields for Interchange, Group, and Transaction.

  4. Click Save.

Configure Error Rules for EDI Translation

You can select specific errors to ignore during EDI translation. You create a group of errors to ignore and associate that group with inbound/outbound trading partner agreements. These errors are ignored if encountered during runtime. Processing completes successfully and the errors are logged as warnings in the business messages log.

For example, assume you don't want to show any errors if a mandatory segment is missing during validation of EDI translation. You can create an error group at the trading partner level in which you select the error codes to ignore that are related to the missing segment. EDI translation is successfully validated and no errors occur.

Capabilities

Error rules configuration provides the following capabilities:
  • The error group only impacts the X12, X12 HIPPA, and EDIFACT documents.
  • You can select all errors or specific errors from the following categories to ignore during EDI translation.
    • Consistency
    • Data code list
    • Data invalid
    • Data size
    • Extra data
    • Fatal errors
    • Information
    • Miscellaneous
    • Structural
  • You associate the error group with inbound and outbound trading partner agreements. During configuration, the error group you created is displayed for selection in two lists:
    • Accepted list: When an error group selected from the accepted list is associated with an agreement, and the errors occur during translation processing, the errors are ignored with warnings (mentioning what error occurred and specifying the error code and error details) and translation passes successfully.
    • Rejected list: When an error group selected from the rejected list is associated with an agreement, and the errors occur during translation processing, the errors are considered fatal, translation is rejected, and the error code and details are specified.
  • The accepted list contents takes precedence over the rejected list contents. If the same error code is associated with the accept and reject lists, the accept list takes precedence and translation is successful even when that error occurs.
  • The error group is honored at runtime when the trading partner agreement is deployed.
  • If the error group is modified, the trading partner agreement must be redeployed.
  • The error group cannot be deleted if it is part of a trading partner agreement. This is regardless of whether the agreement is deployed.

Create and Associate an Error Group with a Trading Partner Agreement

  1. To configure error rules in a project:
    1. In the navigation pane, click Projects.
    2. Click the project in which to configure error rules.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to configure error rules.
  2. To configure error rules in a standalone environment:
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to configure error rules, click Edit Edit icon.
  3. Click Error groups.
  4. Click Add Install icon.

    The Create error group panel is displayed.

  5. Enter a name and optional description.
  6. Select the errors to ignore during EDI validation at runtime.
    • Select a category to ignore all errors in that category.
    • Expand a category, then select the individual errors in that category to ignore.

    For example:


    The Create error codes page shows a table with columns for Name and Summary. The Name column shows the supported categories. Some categories are selected, whereas other categories are expanded to show individual error codes selected and not selected.

  7. Click Create.
  8. Click Transports & Agreements.
  9. For an inbound and/or outbound agreement, click Add Install icon.
  10. Under Configure agreement settings, select the Enable validations check box. The two lists show the error groups you created under the Error groups tab. You can select up to one error group from each list.
    • Accept error group
    • Reject error group

    For a description of these lists, see Capabilities.

  11. Select the error group to ignore during EDI validation at runtime.


    The Add outbound agreement panel shows fields for Select trading partner identifiers, Select host identifiers, and Select a transport. Below this is the Configure agreement settings section shows a check box for Enable validations. Below this are drop-down lists for Accept error group an Reject error group.

  12. Deploy the agreements and run the integration.

    The activity stream shows that processing completed successfully because any errors in the error group that were encountered were ignored.

  13. In the navigation pane, click Observability, then B2B tracking.
  14. Click Business messages.
  15. View the business message details for this message. The errors you defined in the error group are listed and were ignored during EDI validation. Translation was successful.


    The Business message details panel shows the message ID at the top. Two icons appear to the right. Below this is the Primary Information section. Below this are tabs for Properties, Message logs, Payloads, and Correlations. Message logs is selected. Below this is the Translated EDI X12 section. The error codes that were ignored are displayed.

See Create Agreements.

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, AS4, RosettaNet, FTP, and REST 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, AS4, FTP, RosettaNet, or REST) 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 Edit transport panel shows the status of the two integrations.


The B2B integrations page shows the Integration name prefix field and Integration identifier prefix field. Below this is a table with columns for Integration name and Integration status.

Life Cycle 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.

Life cycle 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.
  • Export a transport: Exports a transport for import into a different transport.
  • 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, AS4, RosettaNet, REST, or FTP settings), including changes to the values of identifiers Redeploy the transport.
Changes to the connection properties (other than user name/password) Undeploy and then deploy the transport.
Changes to the user name/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.
The following sections describe transport configuration details:

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

In the navigation pane, click Settings, then Certificates. See Certificates.

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

Upload the private key 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.

In the navigation pane, click Settings, then Certificates. See Certificates.

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 3 .
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. To define an AS2 transport in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to define an AS2 transport.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to define an AS2 transport.
  2. To define an AS2 transport in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to define an AS2 transport, click Edit Edit icon.
  3. Click Transports & agreements.

Define Transports to Create Integrations

  1. In the Transports section, click Add Install 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 Properties, 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
    Properties section
    • Name

    Enter a name for the transport. The name 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.
    • Description

    Enter an optional description of the transport. The description is used for display purposes only.
    • Trading partner's connection (Trigger and invoke)

    Select an existing AS2 Adapter connection configured for connectivity to your trading partner. If you are outside of a project, you can click Add Install 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 3 .

    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's 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 check box 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 check box 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.

  4. Select Actions Actions icon, then 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 Actions Actions icon, then select Undeploy. Undeploying the transport also undeploys the integrations.

Collect RosettaNet Transport Details

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

Collect RosettaNet Transport Details

RosettaNet is an HTTP-based, point-to-point protocol typically used for real-time transactions. A bidirectional RosettaNet message exchange involves two RosettaNet endpoints, as shown below:

While creating this transport, you must collect information from your trading partner about their RosettaNet endpoint. You also may need to provide information about your RosettaNet 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 RosettaNet service URL.
  • An SSL certificate with a public key, if a self-signed certificate was used.
  • Username/password credentials for HTTP basic authentication, if enabled.
  • Your RosettaNet service URL
  • Username/password credentials
Two-way SSL for outbound connections (an optional feature) If you select the 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 RosettaNet Adapter with Oracle Integration 3.
Signed or encrypted RosettaNet 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 RosettaNet. 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 RosettaNet 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 RosettaNet 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 RosettaNet endpoint information from your trading partner, follow these steps:
Step Description
1 Upload each of the partner's certificates. 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.

In the navigation pane, click Settings, then Certificates. See Certificates.

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

Upload the private key 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.

In the navigation pane, click Settings, then Certificates. See Certificates.

3 Create a RosettaNet connection with the Trigger or Invokerole. In the Connections page, enter:
  • The partner's RosettaNet URL in the RosettaNet service URL field
  • The username/password in the corresponding fields

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

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

  • For RosettaNet Basic Policy, enter the partner's certificate alias, corresponding to the identity certificate from step 1.
  • For RosettaNet Basic Policy, enter the private key alias and key password, corresponding to the identity certificate from step 2.
  • For RosettaNet Advanced Policy, enter each of the certificate aliases into the fields. See Configure Connection Security in Using the RosettaNet Adapter with Oracle Integration 3.
4 Test the RosettaNet Adapter connection, to make sure it succeeds. If it fails, review the errors, verify that the RosettaNet URL entered is correct, and verify that the certificate aliases are correct. Save the RosettaNet Adapter connection.
5 Create a RosettaNet transport, selecting the RosettaNet connection created in step 3. Complete the configuration. See Define a RosettaNet Transport.
6 Deploy the RosettaNet transport. After the state changes to deployed, the transport is ready for use.
If you do not yet have the RosettaNet endpoint information from your trading partner, but want to get your side ready for receiving RosettaNet 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 RosettaNet URL is not yet available, enter a temporary placeholder URL in the RosettaNet 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 RosettaNet messages do not work with this placeholder, but inbound messages can be received (since the RosettaNet 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 a RosettaNet Adapter connection is shown below.
  • Connection properties:


    The Connection Properties section includes the RosettaNet 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 (RosettaNet 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 RosettaNet 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 a RosettaNet message.

For internal testing you may use the same credentials that you use to log in to Oracle Integration to send test RosettaNet 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 RosettaNet communication, you must create a key pair and certificate following your company's process and generate a CA-signed certificate that you use for RosettaNet 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.

RosettaNet URL for Receiving

You need the RosettaNet URL for your RosettaNet endpoint to share with your trading partner. Once the transport is deployed (indicating it is ready to receive and/or send messages), your RosettaNet endpoint URL is displayed in the RosettaNet endpoint URL for receiving transport field. Copy this RosettaNet URL to share with your trading partner. This RosettaNet 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 RosettaNet messages to this URL.

The RosettaNet URL is the URL to invoke the RosettaNet 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 a RosettaNet Transport

Once you have collected RosettaNet transport details, you can define a RosettaNet transport in Oracle Integration.

  1. To define a RosettaNet transport in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to define a RosettaNet transport.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to define a RosettaNet transport.
  2. To define a RosettaNet transport in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to define a RosettaNet transport, click Edit Edit icon.
  3. Click Transports & agreements.

Define Transports to Create Integrations

  1. In the Transports section, click Add Install 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 Properties, 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
    Properties section
    • Name

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

    Select RosettaNet from the drop-down list. This represents the communication protocol you use to exchange messages with your trading partner.

    Based on selecting RosettaNet, the appropriate configuration settings for the RosettaNet transport are displayed.
    • Description

    Enter an optional description of the transport. The description is used for display purposes only.
    • Trading partner's connection (trigger and invoke)

    Select an existing RosettaNet Adapter connection configured for connectivity to your trading partner. If you are outside of a project, you can click Add Install icon to create a new RosettaNet Adapter trigger or invoke connection on the Connections page.

    See Create a RosettaNet Connection in Using the RosettaNet Adapter with Oracle Integration 3.

    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's identifier

    Specify a DUNS value that is used in the delivery header of the outbound payload. See Define B2B Identifiers.

    • Host identifier

    Specify a DUNS value that is used in the delivery 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.
    • RosettaNet 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 RosettaNet endpoint URL is displayed. You may share this URL with your trading partner. This RosettaNet URL is not common across all trading partners. It is specific to the current trading partner that you are viewing or editing.
    Send section
    • Additional transport headers
    		 Manually enter any additional transport headers separated by a comma and a single blank space. For example: header1, header2, header3.
    • 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 RosettaNet 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 RosettaNet 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 RosettaNet 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 RosettaNet Adapter connection with the correct certificates for that to work also.

    • Compression
    		 Optionally select to compress the outbound message.
    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 RosettaNet transport, it forms the integration names: your_prefix RosettaNet Receive and your_prefix RosettaNet 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 RosettaNet transport, it forms the integration identifiers: your_prefix_RosettaNet_Receive and your_prefix_RosettaNet_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.

  4. Select Actions Actions icon, then 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 Actions Actions icon, then select Undeploy. Undeploying the transport also undeploys the integrations.

Collect REST Transport Details

You must configure REST Adapter connections to exchange inbound and outbound messages with a trading partner. You can create the connection either before or during configuration of the REST transport.

Note:

Only XML documents are currently tested and certified.

Define a REST Transport

Once you have collected REST transport details, you can completely define a REST transport in Oracle Integration.

  1. To define a REST transport in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to define a REST transport.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to define a REST transport.
  2. To define a REST transport in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to define a REST transport, click Edit Edit icon.
  3. Click Transports & agreements.

Define Transports to Create Integrations

  1. In the Transports section, click Add Install 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 Properties, 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
    Properties section
    • Name

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

    Select REST from the drop-down list. This represents the communication protocol you use to exchange messages with your trading partner.

    Based on selecting REST, the appropriate configuration settings for the REST transport are displayed.
    • Description

    Enter an optional description of the transport. The description is used for display purposes only.
    • Trading partner's connection (trigger and invoke)

    Select an existing REST Adapter connection configured for connectivity to your trading partner. If you are outside of a project, you can click Add Install icon to create a new REST Adapter trigger or invoke connection on the Connections page.

    Note: Only XML documents are currently tested and certified.

    See Create a REST Connection in Using the RosettaNet Adapter with Oracle Integration 3.

    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
    • REST transport URL for receiving

    This is a display-only field. After the transport is deployed, indicating it is ready to receive and send messages, your REST endpoint URL is displayed. You may share this URL with your trading partner. This REST URL is not common across all trading partners. It is specific to the current trading partner that you are viewing or editing.
    Send section
    • Enter Send URI
    		 Enter the send URI. This value is appended to the REST Adapter connection URL.
    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 REST transport, it forms the integration names: your_prefix REST Receive and your_prefix REST 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 REST transport, it forms the integration identifiers: your_prefix_REST_Receive and your_prefix_REST_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.

  4. Select Actions Actions icon, then 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 Actions Actions icon, then select Undeploy. 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 3.

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. To define an FTP transport in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to define an FTP transport.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to define an FTP transport.
  2. To an FTP transport in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to define an FTP transport, click Edit Edit icon.
  3. Click Transports & agreements.
  4. In the Transports section, click Add Install 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 Properties, 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
    Properties section
    • Name
    		 Enter a name for the transport.

    The name 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.

    • Description
    		Enter a description of the transport.

    The description is used for display purposes only.
    • Trading partner's connection (trigger and invoke)

    Select an existing FTP Adapter connection to use. If you are outside of a project, you can click Add Install icon to create a new FTP Adapter connection on the Connections page. Use a Trigger and invoke connection.

    If the Trigger and invoke connection fails with an error that mentions an FTP connection role mismatch, select Invoke only. Trigger only connections cannot be used for transports.

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

    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 time stamp 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 3.

    • 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 Orchestration Integrations in Using Integrations in Oracle Integration 3.

    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 time stamp.

    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.

    You can override the value you set for the outbound directory name during runtime. If not specified in the integration payload at runtime, the value falls back to that specified on this page. See Specify File Name and Directory Name Values at Runtime for Outbound FTP Transport Integrations.

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

    You can override the value you set for the output file name during runtime. If not specified in the integration payload at runtime, the value falls back to that specified on this page. See Specify File Name and Directory Name Values at Runtime for Outbound FTP Transport Integrations.

    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.

  7. If you selected FTP as the transport protocol, select Actions Actions icon, then select Receive schedule to define a schedule.
  8. Return to the Transports & agreements section. See Define the Integration Schedule in Using Integrations in Oracle Integration 3.
  9. Select Actions Actions icon, then select Deploy.
  10. 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.
  11. Go to the Integrations page and note that both integrations are created and activated.
  12. If you need to undeploy the transport, select Actions Actions icon, then select Undeploy. 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 option 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 panel.

  1. Hover over the row of the integration to update.
  2. Select Actions Actions icon, then select Update property values.
  3. In the Update property values panel, select the property to change and enter a value in the New value field.
  4. Select Submit to make the new values effective for future runs.
  5. To change the behavior for all transports created in the future, edit the integration (for this example, named B2B Integration Template FTP Receive).
  6. For the schedule action in the integration canvas, select Actions Actions icon, then select Edit integration properties and change the default values.

Collect AS4 Transport Details

You must configure AS4 Adapter connections to exchange inbound and outbound messages with a trading partner. You can create the connection either before or during configuration of the AS4 transport. You must collect AS4 transport details before you can define the AS4 transport in Oracle Integration.

Collect AS4 Transport Details

AS4 is an HTTP-based, point-to-point protocol typically used for real-time transactions. A bidirectional AS4 message exchange involves two AS4 endpoints.

While creating this transport, you must collect information from your trading partner about their AS4 endpoint. You also may need to provide information about your AS4 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 AS4 URL.
  • An SSL certificate with a public key, if a self-signed certificate was used.
  • User name/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 in Using the AS4 Adapter with Oracle Integration 3.Prerequisites for Creating a Connection
Signed or encrypted AS4 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 AS4. 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 AS4 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 AS4 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 AS4 endpoint information from your trading partner, follow these steps:
Step Description
1 Upload each of the partner's certificates. 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.

In the navigation pane, click Settings, then Certificates. See Certificates.

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

Upload the private key 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.

In the navigation pane, click Settings, then Certificates. See Certificates.

3 Create an AS4 connection with the Trigger and invoke role. In the Connections page, enter:
  • The partner's AS4 URL in the AS4 service URL field
  • The user name/password in the corresponding fields

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

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

  • For AS4 Basic Policy, enter the partner's certificate alias, corresponding to the identity certificate from step 1.
  • For AS4 Basic Policy, enter the private key alias and key password, corresponding to the identity certificate from step 2.
  • For AS4 Advanced Policy, enter each of the certificate aliases into the fields. See Configure Connection Security in Using the AS4 Adapter with Oracle Integration 3.
4 Test the AS4 Adapter connection, to make sure it succeeds. If it fails, review the errors, verify that the AS4 URL entered is correct, and verify that the certificate aliases are correct. Save the AS4 Adapter connection.
5 Create an AS4 transport, selecting the AS4 Connection created in step 3. Complete the configuration. See Define an AS4 Transport.
6 Deploy the AS4 transport. After the state changes to deployed, the transport is ready for use.
If you do not yet have the AS4 endpoint information from your trading partner, but want to get your side ready for receiving AS4 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 AS4 URL is not yet available, enter a temporary placeholder URL in the AS4 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 AS4 messages do not work with this placeholder, but inbound messages can be received (since the AS4 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.

Credentials

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

For internal testing you may use the same credentials that you use to log in to Oracle Integration to send test AS4 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 user name and password of this new user with the trading partner.

Certificates

If you want to enable encryption or signing for the AS4 communication, you must create a key pair and certificate following your company's process and generate a CA-signed certificate that you use for AS4 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.

AS4 URL for Receiving

You need the AS4 URL for your AS4 endpoint to share with your trading partner. Once the transport is deployed (indicating it is ready to receive and/or send messages), your AS4 endpoint URL is displayed in the AS4 endpoint URL for receiving transport field. Copy this AS4 URL to share with your trading partner. This AS4 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 AS4 messages to this URL.

The AS4 URL is the URL to invoke the AS4 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 AS4 Transport

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

  1. To define an AS4 transport in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to define an AS4 transport.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to define an AS4 transport.
  2. To define an AS4 transport in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. In the row of the trading partner for which to define an AS4 transport, click Edit Edit icon.
  3. Click Transports & agreements.

Define Transports to Create Integrations

  1. In the Transports section, click Add Install 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 Properties, 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
    Properties section
    • Name

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

    Select AS4 from the drop-down. This represents the communication protocol you use to exchange messages with your trading partner.

    Based on selecting AS4, the appropriate configuration settings for the AS4 transport are displayed.
    • Description

    Enter an optional description of the transport. The description is used for display purposes only.
    • Trading partner's connection (trigger and invoke)

    Select an existing AS4 Adapter connection configured for connectivity to your trading partner. If you are outside of a project, you can click Add Install icon to create a new AS4 Adapter connection on the Connections page. It must be a Trigger and invoke connection. Invoke Only connections cannot be used for transports.

    See Create a Connection in Using the AS4 Adapter with Oracle Integration 3.

    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's identifier

    Used as the Responder Party ID for outbound messages and as the expected Initiator Party ID for inbound messages. The identifier type is used as the Party ID type.

    • Host identifier

    Used as the Initiator Party ID for outbound messages and as the expected Responder Party ID for inbound messages. The identifier type is used as the Party ID type.
    • 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
    • AS4 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 AS4 endpoint URL is displayed. You may share this URL with your trading partner. This AS4 URL is not common across all trading partners. It is specific to the current trading partner that you are viewing or editing.
    • 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.
    • PMode.Id
    		 Enter the trading partner identifier.
    • PMode.AgreementRef
    		 Enter the trading partner agreement ID.
    • Send payload as attachment
    		Select the check box to send the payload as an attachment.
    • 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 AS4 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 AS4 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 AS4 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 AS4 Adapter connection with the correct certificates for that to work also.
    • Compression
    		 Optionally select Yes to compress the outbound message. Otherwise, select No.
    • 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 AS4 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 AS4 transport automatically handles the MDN processing.

    • 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.
    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 AS4 transport, it forms the integration names: your_prefix AS4 Receive and your_prefix AS4 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 AS4 transport, it forms the integration identifiers: your_prefix_AS4_RECEIVE and your_prefix_AS4_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.

  4. Select Actions Actions icon, then 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 Actions Actions icon, then select Undeploy. Undeploying the transport also undeploys the integrations.

Create Agreements

This section 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. To create an agreement in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to create the agreement.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click the trading partner in which to create the agreement.
  2. To create an agreement in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.

      The Trading partners page is displayed.


      Description of trading_partners3.png follows
      Description of the illustration trading_partners3.png

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

Define Inbound and Outbound Agreements

  1. Click Transports & agreements.
  2. In the Inbound agreements section, click Add Install 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. See Create a Custom B2B Document Definition.
      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 drop-down 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 acknowledgment 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.

      If you created an error group under the Error groups tab, the following lists are displayed.

      • Accept error group
      • Reject error group

      See Configure Error Rules for EDI Translation.

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

      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 Actions Actions icon 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 Actions Actions icon menu.
    6. Click Edit Edit icon to make any updates.
  3. In the Outbound agreements section, click Add Install 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. See Create a Custom B2B Document Definition.
      Select identifiers Certain mandatory and optional identifiers, such as EDI Interchange ID or DUNS (for RosettaNet), are inserted into EDI envelope segments during the outbound translation. Select the identifiers you want inserted into the envelopes. The Role identifier is used to populate the Initiator/Responder role fields in the AS4 message.

      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, Responder Role, and others).
      • 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, Initiator Role, and others).
      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.

      If you created an error group under the Error groups tab, the following lists are displayed.

      • Accept error group
      • Reject error group

      See Configure Error Rules for EDI Translation.

      Functional acknowledgment 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 acknowledgment 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 Actions Actions icon 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 Actions Actions icon menu.
    6. Click Edit Edit icon to make any updates.

Life Cycle Actions for Agreements

Click Actions Actions icon on a row to view available actions.

Life cycle 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 life cycle 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. Select Trading partner, then B2B identifiers or Host profile, and then 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.

Configure Batching for Outbound EDIFACT and X12 Documents

You can configure batching for outbound EDIFACT and X12 documents as part of trading partner configuration. Batching enables you to group messages by document type and send them as a batch. For example, you may want to send a batch of X12 purchase orders or EDIFACT invoices.

Use Case

A common use case is to batch and send all transactions of a specific document type to a trading partner at a scheduled time. For example, you want to send a batch of purchase orders or a batch of invoices at the end of the day.

Guidelines

  • Batching is only applicable for outbound EDI documents (EDIFACT and X12) per trading partner.
  • Batching is applicable only for the same document type and version.
  • Batching is based on a batch schedule that you create per an outbound agreement.
  • You can manage (view, edit, and delete) the batch schedules.
  • When you deploy the agreement, the batch schedule is started.
  • When you undeploy the agreement, the batch schedule is stopped.
  • You cannot add a batch schedule to a deployed outbound agreement. The agreement must first be undeployed.
  • If you delete the outbound agreement or the trading partner agreement that includes the outbound agreement, the batch schedule is deleted.
  • The following behavior occurs at runtime:
    • A message is written to the logs indicating that a batch delivery occurred.
    • When the batch completes processing, a wire message is created and associated with all relevant business messages.
    • Resubmitting an outbound business message again follows the batching process because the agreement is set to batching.
    • Resubmitting an outbound wire message sends the batched messages.

Configure Document Batching

  1. Open the trading partner.
  2. Click Transports & agreements.
  3. In the Outbound agreements section, find the agreement on which to configure outbound EDIFACT or X12 document batching.
  4. From the Actions Actions icon menu, select Add batch.
  5. Enter the following information, then click Add.
    Element Description
    Batching type Based on schedule is the only option available and cannot be deselected.
    Define recurrence Specify the Frequency for running the schedule:
    • Days: Select a daily value in the range of 1 to 7.
    • Hours and minutes:
      • Select an hourly value in the range of 0 to 23.
      • Select a minute value in the range of 0 to 59.

    Note: There is no iCal expression support for creating a batch schedule.

    This schedule is effective
    • From:
      • When agreement is deployed: Select to start the batching schedule when the outbound agreement is deployed.
      • Modify start date: Specify a start time at which to begin the batching schedule.
    • Until:
      • Never (repeat indefinitely): The batching schedule always runs.
      • Choose expiry date: Select and then specify an end date for the batching schedule.
    • Time zone: Select the time zone in which to run the batching schedule.
  6. Once created, you can perform the following batching tasks from the Actions Actions icon menu:
    1. Select Edit batch to edit the batch. This option is only available if the outbound agreement has not been deployed.
    2. Select Delete batch to delete the batch.
    3. Select View batch to view the batch contents.

For an overview of designing a switch action route when batching is enabled on the outbound agreement, see Outbound Message Processing.

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. To export a trading partner in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to export a trading partner.
    3. Click B2B B2B icon.
    4. In the Trading partners section, hover your cursor over the row of the trading partner to export.
    5. Click Actions Actions icon, then select Export.

      This action downloads the ZIP file.

  2. To export a trading partner in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. Hover your cursor over the row of the trading partner to export.
    3. Click Actions Actions icon, then select Export.

      This action downloads the ZIP file.

  3. Download the ZIP file.

Import a Trading Partner

  1. To import a trading partner in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to import a trading partner.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click Add Install icon.
    5. Click Import.
  2. To import a trading partner in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.
    2. Click Import.
  3. If you want to overwrite an existing trading partner agreement of the same name, click Overwrite the trading partner definition, if it exists.

    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 check box explicitly for the import to overwrite the existing trading partner, associated documents, and schemas. If the check box 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.
  6. Click Close.
  7. Click Edit Edit icon, then click Transports & agreements.
  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.