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

Define Inbound and Outbound Agreements

1. Click Transports & agreements.
2. In the Inbound agreements section, click Add 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 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 menu.
   6. Click Edit to make any updates.
3. In the Outbound agreements section, click Add 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 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 menu.
   6. Click Edit to make any updates.

Life Cycle Actions for Agreements

Click Actions on a row to view available actions.

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.

Watch a video to learn more: