6 Creating and Deploying Trading Partner Agreements

This chapter describes a trading partner agreement that defines the terms that enable two trading partners, the initiator and the responder, to exchange business documents. It also discusses how to use trading partner agreements to identify the trading partners, trading partner identifiers, document definitions, and channels.

The final steps in the Oracle B2B process flow, shown in Figure 6-1, are to create and deploy the agreement.

Figure 6-1 Oracle B2B Process Flow

Description of "Figure 6-1 Oracle B2B Process Flow"

This chapter contains the following topics:

Section 6.1, "Introduction to Agreements"
Section 6.2, "Creating an Agreement"
Section 6.3, "Deploying an Agreement"
Section 6.4, "Deleting and Exporting Agreements"

See the following for more information:

Chapter 9, "Managing Deployments," for how to export agreements and manage deployment states
Chapter 7, "Importing and Exporting Data," for how to export agreements

6.1 Introduction to Agreements

An agreement consists of two trading partners—the host trading partner and one remote trading partner, and represents one type of business transaction between those partners. For example, if Acme and GlobalChips participate in both EDIFACT and RosettaNet exchanges with each other, you create an agreement for each of the exchanges. Some exchanges are bidirectional, requiring an agreement for each direction.

For example, if Acme sends a sales order to GlobalChips using a Custom document sent using the Generic File protocol, you create an agreement for the outbound direction, where Acme sends the order, and for the inbound direction, where Acme is the receiver. A change to a component of an agreement (for example, a change to the document definition) is effective automatically in the agreement.

Creating an agreement is the last step in the design of a B2B transaction. Before you create an agreement, you must have already created the document definitions and configured the trading partners. See Chapter 4, "Creating Document Definitions," and Chapter 5, "Configuring Trading Partners," for more information.

6.2 Creating an Agreement

Figure 6-2 shows the Oracle B2B interface for working with agreements. Click a remote trading partner name to see its agreements with the host trading partner.

Figure 6-2 Creating an Agreement

Description of "Figure 6-2 Creating an Agreement"

Figure 6-3 shows the steps to create an agreement.

Figure 6-3 Steps to Creating an Agreement (Workflow Overview)

Description of "Figure 6-3 Steps to Creating an Agreement (Workflow Overview)"

Step 1: Identify the remote trading partner

The host trading partner is automatically included in an agreement, so you need only identify the remote trading partner. You can do this in two ways: select the partner from the Partners region before adding the agreement, or select the host trading partner, click Add in the Agreements region, and click the Select Partner icon in the New Agreement region.

Step 2: Select the document definition

The document definition is selected for the host trading partner, as reflected in the Select Document Definition dialog, shown in figure Figure 6-4.

Figure 6-4 Selecting the Document Definition

Description of "Figure 6-4 Selecting the Document Definition"

For an exchange in which you need both outbound and inbound agreements, do the following:

For the outbound agreement, select the document definition in which the host trading partner is the sender (Acme --> Globalchips in Figure 6-4)
For the inbound agreement, select the document definition in which the host trading partner is the receiver (Acme <-- GlobalChips in Figure 6-4)

Step 3: Provide the agreement ID and name

Provide any agreement identifier and agreement name. These fields can have the same value if you need only one for tracking purposes.

Step 4: Select validation, translation, and functional acknowledgment options

Table 6-1 describes the validation, translation, and functional acknowledgments available when you create an agreement.

Table 6-1 Agreement Options

Option	Description
Validate	Select to enable validation of the document against the configured ECS file.
Translate	Select to enable the translation of XML to native format and vice versa (for EDI and HL7, for example). If Translate is not selected (no translation), then B2B cannot correlate the business message with the functional acknowledgment, irrespective of the value of the B2B Handle FA property. See Section C.1, "Properties To Set in Fusion Middleware Control," for information about the property.
Functional Ack	Select to enable the functional acknowledgment for success or error criterion.
FA Handled by B2B	If set to true, then B2B automatically generates the functional acknowledgment (FA) message for inbound EDI and HL7 messages. Inbound FA messages are consumed when this option is true. When this option is set to false, B2B does not automatically generate the FA document. The back-end application (middleware) must generate the FA and provide it to B2B as an outbound message. When option is set to false, inbound FA documents are passed back to the back-end application. If the document does not require an FA (as indicated by the agreement-level setting), then this option is ignored. The default value for this property is true. See Section C.1, "Properties To Set in Fusion Middleware Control," for more information. When Functional Ack Handled by B2B is set to false, then Notify Inbound Functional Acks must be set to false also for the inbound FA to be sent to the back-end application. If Notify Inbound Functional Acks is set to true (while Functional Ack Handled by B2B is set to false), then the incoming 997 (FA doc) generates only a notification and the 997 document itself is not sent back to the back-end application.
Document Retry Interval	Enter the length of time in minutes between document retries. See Section 5.5.5, "Configuring Delivery Retry Options" for more information about configuring retry attempts.
Document Retry Count	Enter the number of times to retry the message. See Section 5.5.5, "Configuring Delivery Retry Options" for more information about configuring retry attempts.

Step 5: Select the channel for the remote trading partner

A list of channels that you created when you set up the remote trading partner is available. (Listening channels are not part of an agreement.)

Step 6: Add identifiers

Identifier types for the host and remote trading partners are listed. Select the identifiers that apply to this agreement. You can shift-click to select multiple identifiers.

For outbound agreements, use the identifier types listed in Table 6-2 with the exchange protocols.

Table 6-2 Identifier Types To Use with Exchange Protocols

Exchange Protocol	Identifier Type
Generic File-1.0	Name
Generic FTP-1.0	Name
Generic SFTP-1.0	Name
Generic AQ-1.0	Name
Generic JMS-1.0	Name
AS2-1.1	Name, AS2 Identifier
AS1-1.0	Name, AS1 Identifier
ebMS-1.0, ebMS-2.0	Name, ebMS Identifier
RosettaNet-V02.00, RosettaNet-01.10	Name, DUNS
MLLP exchange	Name, MLLP ID
Generic HTTP-1.0	Name, Generic Identifier
Generic Email-1.0	Name, Generic Identifier

See Chapter 10, "Creating Types," for more information about identifier types.

Step 7: Save and validate the agreement

Clicking Save also validates the agreement.

To create an agreement:

Click the Partners tab.
In the Agreements region, click Add.
Click Select Partner.
Select a remote trading partner.
Click Select Document Definition.
Select a document definition for the initiator.
Provide an agreement ID and name.
Select from the validation, translation, and functional acknowledgment options, as described in Table 6-1.
Provide an optional description, a callout (if previously created), and start and end dates.

Use callouts to transform the formats of messages exchanged between remote and host trading partners. See Chapter 13, "Managing Callouts."

An agreement cannot be deployed after an end date entered here because the agreement will have expired.
For the host trading partner, click Add and select identifiers.
For the remote trading partner, select a channel.
In the remote trading partner, click Add and select identifiers.
Click Save.

After you create an agreement, it is ready to be deployed. It is listed on the Administration > Deploy page. See Section 6.3, "Deploying an Agreement," to continue.

6.3 Deploying an Agreement

Deployment is the process of activating an agreement from the design-time repository to the run-time repository.

After deploying an agreement, use the Manage Deployments tab and the Reports tab. See the following for more information:

After you create, save, and validate an agreement, you can deploy it as follows:

From the same page (Partners > Agreement tab), using the Deploy button (see Figure 6-2)
From the Administration > Deploy page, as shown in Figure 6-5. Use this option to select multiple agreements to deploy at the same time.

Figure 6-5 The Deploy Tab—Lists Valid Agreements

Description of "Figure 6-5 The Deploy Tab—Lists Valid Agreements"

Note:

Turn off validation during deployment by setting the property b2b.deploy.validation=false.

This property is set in Oracle Enterprise Manager Fusion Middleware Control. Changing the property requires a SOA Server restart. See Section C.1, "Properties To Set in Fusion Middleware Control," for more information.

To deploy an agreement from the Deploy tab:

Click the Administration tab.
Click the Deploy tab.
Use the search parameters to find the agreement you want to deploy and click Search.
Highlight one or more agreements and click Deploy.

6.3.1 Redeploying an Agreement

If you deploy a previously deployed agreement, the first version is moved to an inactive state and the most recently deployed agreement is active.

6.4 Deleting and Exporting Agreements

Only agreements in the draft state can be deleted. Purging an agreement returns its status to the draft state. Agreements that have deployed versions in active, inactive, or retired states cannot be deleted.

An agreement can be exported to a ZIP file by using the Export button on the Agreement tab.