21 Developing and Implementing Inbound B2B Integration Flows

This chapter provides an overview of developing and implementing inbound B2B integration flows and describes how to identify the B2B document and analyze requirements, add inbound routing rules to an AIA B2B interface, develop new requester B2B connector service, develop or extend an existing Enterprise Business Service, develop or extend an existing requester ABCS, configure Oracle B2B and define trading partner agreements, deploy and configure AIA services and finally how to test and go live.

This chapter discusses the following topics:

21.1 Introduction to Developing and Implementing Inbound B2B Integration Flows

Figure 21-1 shows the high-level steps involved in developing a simple inbound business-to-business (B2B) flow from an application to trading partners using Oracle Application Integration Architecture (AIA).

Figure 21-1 High-Level Steps to Develop and Implement a Simple Inbound B2B Flow

This image is described in surrounding text

Most of the preceding steps are described inChapter 20, "Developing and Implementing Outbound B2B Integration Flows." This chapter is referred to whenever applicable.

21.2 Step 1: Identifying the B2B Document and Analyzing Requirements

The first step in building an inbound B2B flow, as shown in Figure 21-2, is to identify the B2B document that must be generated by the flow. As a part of this step, you must also analyze the requirements for the AIA services that must be built or extended to support the flow.

Figure 21-2 Step 1: Identifying B2B Document and Analyzing Service Requirements

This image is described in surrounding text

The only differences in this step for the outbound B2B document flows and the steps for the inbound B2B document flows are as follows:

  1. The source and targets in the mapping are reversed. The B2B document received from trading partners is the source of the mapping. The AIA Enterprise Business Message (EBM) is the target of the mapping.

  2. At the end of this step:

    1. The B2B document is defined in Oracle B2B.

    2. The XML schema of the B2B document is uploaded in the AIA Metadata Repository.

    3. The Enterprise Business Object (EBO) and the EBM to be used in the integration are identified.

    4. Functional mapping between the B2B document and the AIA EBM is complete.

For more information about identifying the B2B document and analyzing requirements, see Section 20.2, "Step 1: Identifying the B2B Document and Analyzing Requirements."

21.3 Step 2: Adding Inbound Routing Rules to an AIA B2B Interface

The next step in building an inbound B2B flow, as shown in Figure 21-3, is to add routing rules to the AIAB2BInterface Infrastructure service.

Figure 21-3 Step 2: Adding Inbound Routing Rules to an AIA B2B Interface

This image is described in surrounding text

In inbound B2B document flows, the AIAB2BInterface service listens for new B2B documents received by Oracle B2B and routes them to the requester B2B services, as shown in Figure 21-4.

Figure 21-4 Oracle B2B Routing New B2B Documents to Requester B2B Services

This image is described in surrounding text

The AIA B2B Interface composite has a JMS adapter to listen for new inbound B2B documents processed by Oracle B2B. The trading partner agreement in Oracle B2B is configured to route inbound B2B documents to the AIA_B2B_IN_QUEUE JMS queue.

The AIA B2B Interface identifies the B2B document type of the inbound B2B document and routes the document to the requester B2B Connector Service (B2BCS) Implementation that is responsible for processing the B2B document.

For example, if the B2B document type is OAG_Process Invoice, then the AIA B2B Interface routes the document to the OAGProcessInvoiceRequesterB2BCSImpl service.

The input to the requester B2BCS Implementation is the B2BM element. The B2BM element is defined in the AIAComponents/EnterpriseObjectLibrary/Infrastructure/V1/Meta.xsd file.

The AIA B2B Interface constructs the B2BM element from the B2B document received from Oracle B2B as described here:

  • /corecom:B2BM /corecom:B2BMHeader /corecom:B2BMID

    • Mapped from: B2B document JMS header property MSG_ID

    • Description: The unique identifier generated by Oracle B2B for the inbound B2B document.

      This field is to correlate the AIA flow with the corresponding transaction in Oracle B2B.

    • Example: 5602359000000

  • /corecom:B2BM /corecom:B2BMHeader /corecom:B2BDocumentType /corecom:TypeCode

    • Mapped from: DOCTYPE_NAME

    • Description: The document type of the inbound document as identified by Oracle B2B.

    • Example: OAG_PROCESS_INVOICE

  • /corecom:B2BM /corecom:B2BMHeader /corecom:B2BDocumentType /corecom:Version

    • Mapped from: DOCTYPE_REVISION

    • Description: The document revision of the inbound document as identified by Oracle B2B.

    • Example: 9.0

  • /corecom:B2BM /corecom:B2BMHeader /corecom:SenderTradingPartner /corecom:TradingPartnerID

    • Mapped from: FROM_PARTY

    • Description: The source (from) trading partner of the B2B document.

      The value is the trading partner name as defined in Oracle B2B.

    • Example: GlobalChips

  • /corecom:B2BM /corecom:B2BMHeader /corecom:ReceiverTradingPartner /corecom:TradingPartnerID

    • Mapped from: TO_PARTY

    • Description: The destination (to) trading partner to whom the inbound B2B document was sent.

      The value is the trading partner name as defined in Oracle B2B.

    • Example: Acme

  • /corecom:B2BM /corecom:Payload

    • Mapped from: JMS payload

    • Description: The actual JMS text payload that contains the B2B document sent by the trading partner.

    • Example: <?xml version="1.0"?> <PROCESS_INVOICE_002> <CONTROLAREA>…

21.3.1 How to Add a New Routing Rule to the AIA B2B Interface

To add a new routing rule to the AIA B2B Interface:

  1. Open the $AIA_HOME/Infrastructure/B2B/AIAB2BInterfaceApp/AIAB2BInterfaceApp.jws application using Oracle JDeveloper.

  2. Open the composite.xml file using Oracle JDeveloper, as shown in Figure 21-5.

    Figure 21-5 composite.xml in Oracle JDeveloper

    This image is described in surrounding text

  3. Add a new service reference to the requester B2BCS that processes the new inbound B2B document type as shown in Figure 21-6. The next section of this document explains how to develop requester B2BCSs.

    Figure 21-6 New Service Reference Added to the Requester B2BCS that Processes the New Inbound B2B Document Type

    This image is described in surrounding text

  4. Add a wiring to the newly added service from the Receive B2BM Mediator component in the composite as shown in Figure 21-7.

    Figure 21-7 Wiring Added to the Newly Added Service from the Receive B2BM Mediator Component in the Composite

    This image is described in surrounding text

  5. Choose the Mediator operation ReceiveB2BMessage as the source of the wiring and the target as the operation exposed by the target requester B2BCS. Save your changes.

  6. Open the file ProcessInbound.mplan as shown in Figure 21-8.

    Figure 21-8 ProcessInbound.mplan

    This image is described in surrounding text

  7. Add a new routing rule to invoke the requester B2BCS using the service reference added to the file composite.xml, as shown in Figure 21-9.

    Figure 21-9 New Routing Rule to Invoke the Requester B2BCS

    This image is described in surrounding text

  8. Add a new routing rule to the ReceiveB2BMessage operation.

  9. Edit the filter operation for the newly added routing rule. Define the filter based on the B2B document type. For example, the routing filter in Figure 21-10 ensures that the EDI X12 Process Sales Order documents are routed to the X12 ProcessSalesOrder B2BCS Implementation.

    Figure 21-10 Routing Filter Ensuring that EDI X12 Process Sales Order Documents are Routed to ProcessSalesOrder B2BCS Implementation

    This image is described in surrounding text

  10. Save your changes.

  11. Deploy the modified SOA composite application.

21.4 Step 3: Developing a New Requester B2B Connector Service

This section includes the following topics:

The next step, as shown in Figure 21-11, is to develop the requester B2BCS to support the outbound B2B integration flow.

Figure 21-11 Step 3: Developing a New Requester B2B Connector Service

This image is described in surrounding text

The requester B2BCS is very similar to a requester Application Business Connector Service (ABCS), with the only difference being that it integrates with trading partners through Oracle B2B instead of integrating with an application. Hence, AIA recommends that you familiarize yourself with the design and development of ABCSs (requester and provider).

For more information about developing ABCSs, see Chapter 15, "Constructing the ABCS."

21.4.1 Introduction to Requester B2B Connector Services

The key function provided by a requester B2BCS is to enable inbound B2B document integration by performing the following tasks:

  • Receive B2B documents sent by trading partners from Oracle B2B.

  • Transform B2B documents into AIA EBMs.

  • Use EBMs as request payloads to invoke AIA Enterprise Business Services (EBSs).

Figure 21-12 illustrates the processing that takes place in a simple fire-and-forget message exchange pattern-based provider B2BCS.

Figure 21-12 Process Flow of a Simple Fire-and-Forget Message Exchange Pattern-Based Provider B2BCS

This image is described in surrounding text

Step-by-step instructions for developing B2BCSs are provided in the following sections.

21.4.2 How to Identify the Message Exchange Pattern

Similar to outbound B2B flows, most inbound B2B flows can be modeled using the fire-and-forget message exchange pattern.

Responses to be sent to trading partners can be modeled using separate outbound fire-and-forget flows.

Also, depending on the protocol involved, Oracle B2B can be configured to automatically send a confirmation or acknowledgement message to trading partners.

For more information, see Section 20.3.2, "How to Identify the Message Exchange Pattern."

For more information about identifying message exchange patterns, see Section 14.3, "Identifying the MEP."

21.4.3 How to Develop a B2BCS Service Contract

First, define the service contract (WSDL) of the requester B2BCS. The service contract of the provider B2BCS specifies how it is invoked by an AIA flow. The service contract specifies the B2B operation being implemented and the B2B document type that it is capable of processing as the input request message.

For more information about creating WSDLs for ABCSs, see Section 14.2, "Defining the ABCS Contract."

Following are the naming conventions recommended for use in the B2BCS WSDL definitions:

  • WSDL File Name:

    • Naming guideline: <B2BStandard><Verb><EBO>ReqB2BCSImpl.wsdl

    • Example: X12ProcessSalesOrderReqB2BCSImpl.wsdl

  • Service Namespace:

    • http://xmlns.oracle.com/B2BCSImpl/{Core|Industry/<IndustryName> }/<B2BStandard><Verb><EBO>ReqB2BCSImpl/<ABCSVersion>

    • Example: http://xmlns.oracle.com/B2BCSImpl/Core/X12ProcessSalesOrderProvB2BCSImpl/V1

      The ABCS Service version is independent of the B2B document/standard version.

      For more information about recommendations on versioning AIA services, see Section 16.8, "Versioning ABCS."

  • Service Name:

    • Naming guideline: <B2BStandard><Verb><EBO>ReqB2BCSImpl

    • Example: X12ProcessSalesOrderProvB2BCSImpl

  • Port Type Name:

    • Naming guideline: <B2BStandard><Verb><EBO> ReqB2BCSImplService

    • Example: X12ProcessSalesOrderProvB2BCSImplService

  • Operation Name:

    • <Verb><EBO>

    • ProcessSalesOrder

  • Request Message Name:

    • <Verb><EBO>ReqMsg

    • ProcessSalesOrderReqMsg

21.4.4 How to Store a WSDL in Oracle Metadata Services Repository

As a SOA best practice, AIA recommends that all shared service artifacts, such as WSDL and XSD files, be stored in a central location that can be accessed by multiple services.

All of the AIA-shared artifacts are stored in the Oracle Metadata Services (MDS) repository. Storage of shared artifacts in the MDS not only makes them globally accessible, but also enables AIA to leverage features in MDS that support caching and clustering.

Provider B2BCS WSDLs are stored at the following location in the MDS: /apps/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls/ <B2B_STANDARD> /ProviderB2BCS/ <VERSION> / <B2B_STANDARD> <VERB> <OBJECT> ReqB2BCSImpl.wsdl

To store a WSDL in MDS:

  1. Copy the handcrafted WSDL to the following location: $AIA_HOME/aia_instances/$INSTANCE_

    NAME/AIAMetaData/AIAComponents/B2BServiceLibrary

    /Connectors/wsdls/<B2B_STANDARD>/RequesterB2BCS

    /<VERSION>/<wsdl file>.wsdl

  2. Run the UpdateMetaDataDP.xml file present in $AIA_HOME/aia_instances/$INSTANCE_NAME/config/.

  3. Using a SOA-MDS server connection to MDS, verify that AIA Metadata has been supplied, as shown in Figure 21-13.

    Figure 21-13 AIA Metadata in the MDS

    This image is described in surrounding text

  4. The WSDL can now be accessed using a URL similar to the following: oramds:/apps/AIAMetaData/AIAComponents/B2BServiceLibrary/ Connectors/wsdls/EDI_X12/RequesterB2BCS/V1/ X12ProcessSalesOrderProvB2BCSImpl.wsdl

21.4.5 How to Develop a B2B Connector Service

The next step in the process is to develop the B2BCS. The requester B2BCS WSDL created in the previous step is used as the interface while you are developing the concrete B2BCS.

Because Service Constructor does not support the autogeneration of B2B services, use Oracle JDeveloper to develop the B2BCS. Develop a composite with a BPEL process based on the abstract WSDL created in the previous step.

Following are the key activities that must be developed in the B2BCS implementation BPEL.

To develop a B2B connector service:

  1. Create a SOA Composite application containing a SOA project with a BPEL component.

  2. Choose the WSDL created in the previous step as the interface for the SOA composite.

  3. The values to be used for creating the SOA application and project are listed in Table 21-1.

    Table 21-1 Values Used to Create the SOA Application and Project

    Activity Value

    Application Name

    <B2BStandard> <Verb> <EBO> ReqB2BCSApp

    Project Name

    <B2BStandard> <Verb> <EBO> ReqB2BCSImpl

    Project Namespace

    http://xmlns.oracle.com/B2BCSImpl/Core/ <Standard> <Verb> <Object> ReqB2BCSImpl/V1

    (Same as B2BCS WSDL namespace)

    Composite Name

    <B2BStandard> <Verb> <EBO> ReqB2BCSImpl

    Composite Template

    Composite with BPEL

    BPEL Process Name

    <B2BStandard> <Verb> <EBO> ReqB2BCSImpl

    Namespace

    http://xmlns.oracle.com/B2BCSImpl/Core/ <Standard> <Verb> <Object> ReqB2BCSImpl/V1

    (Same as B2BCS WSDL namespace)

    Template

    Base on WSDL

    WSDL URL

    URL of B2BCS service WSDL referred from MDS

  4. Define variable <B2BM>_Var.

    This is the input variable to the BPEL process and is used in the receive activity.

    Define the variable based on the corecom:B2BM global element defined in the Meta.xsd.

  5. Define variable EBM_HEADER of type corecom:EBMHeader.

    This variable is used to store the AIA process context information and is used by the fault-handling mechanism.

    Define the variable based on the corecom:B2BM global element defined in the Meta.xsd.

  6. Define variable B2BM_HEADER of type corecom:B2BMHeader.

    This variable is used to store the B2B-specific AIA process context information and is used by the fault-handling mechanism.

    Define the variable based on the corecom:B2BMHeader global element defined in the Meta.xsd.

  7. Define variable <B2BDoc>_Var using the external B2BDocument definition.

    This is used as the source of the transformation from EBM. This variable is then assigned to the <B2BDoc>B2BM_Var/Payload.

  8. Define a partner link to the EBS.

    This is the AIA EBS that is invoked by the requester B2BCS.

    The abstract EBS WSDL can be referenced from: oramds:/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/<EBO>/V<x>/<EBOName>.wsdl.

  9. Transform the EBM to the B2B Document.

    Use a transform activity to transform the EBM to the B2B Document format. Invoke an XSLT developed per the mapping created in the previous step.

  10. Assign B2B-specific EBMHeader variables as shown here:

    • Element: corecom:EBMHeader/corecom:B2BProfile/corecom:SenderTradingPartner/corecom:TradingPartnerID

      Source B2BM XPATH: corecom:B2BM/corecom:B2BMHeader/corecom:SenderTradingPartner/corecom:TradingPartnerID

    • Element: corecom:EBMHeader/corecom:B2BProfile/corecom:ReceiverTradingPartner/corecom:TradingPartnerID

      Source B2BM XPATH: corecom:B2BM/corecom:B2BMHeader/corecom:ReceiverTradingPartner/corecom:TradingPartnerID

    This way, the sender and receiver trading-partner information identified by Oracle B2B is passed on to the EBM.

  11. Invoke the EBS.

    Invoke the AIA EBS to process the EBM.

  12. Compile the BPEL process and ensure that no errors occurred. You can use Oracle JDeveloper to deploy the BPEL process to a development server that has AIA Foundation Pack installed.

21.4.6 How to Annotate B2B Connector Services

To make key metadata about the B2BCS available to the Project Lifecycle Workbench and Oracle Enterprise Repository, the composite.xml file of the B2BCS Implementation SOA composite must be annotated in a specific manner.

For more information about the Project Lifecycle Workbench, see Chapter 3, "Working with Project Lifecycle Workbench."

For more information about annotating B2B services, see Chapter 12, "Annotating Composites."

To annotate requester B2B Connector Services:

  1. Table 21-2 lists the annotation elements that must be added to the service element composite.xml, as described subsequently.

    Table 21-2 Service Annotation Elements in composite.xml

    Annotation Element Description Example

    AIA/Service/InterfaceDetails/Service Operation

    <Verb><EBOName>

    ProcessSalesOrder

    AIA/Service/ImplementationDetails/ArtifactType

    RequesterB2BCSImplementation

    RequesterB2BCSImplementation

    AIA/Service/ImplementationDetails/ServiceOperation/Name

    <Verb><EBOName>

    ProcessSalesOrder

    AIA/Service/ImplementationDetails/B2BDocument

    B2B Document Type processed by this B2BCS

    850

    AIA/Service/ImplementationDetails/B2BDocumentVersion

    B2B Document Version processed by this B2BCS

    4010

    AIA/Service/ImplementationDetails/B2BStandard

    B2B Standard processed by this B2BCS

    X12

    AIA/Service/ImplementationDetails/B2BStandardVersion

    B2B Standard Version processed by this B2BCS

    4010

    The following XML snippet, as shown in Figure 21-14, is an example of an annotated B2BCS called X12ProcessSalesOrderReqB2BCSImpl composite.xml.

    Figure 21-14 Example Snippet of an Annotated B2BCS Called X12ProcessSalesOrderReqB2BCSImpl composite.xml

    This image is described in surrounding text

  2. The reference to the AIA EBS invoked by this B2BCS should also be annotated in the composite.xml. Annotation elements are listed in Table 21-3.

    Table 21-3 composite.xml Annotations Used to Reference the AIA EBS Invoked by the B2BCS

    Annotation Element Description Example

    AIA/Reference/ArtifactType

    Enter value "EnterpriseBusinessService"

    EnterpriseBusinessService

    AIA/Reference/ServiceOperation/Name

    EBS operation name

    ProcessSalesOrder

    Annotations as they appear in composite.xml are shown in Figure 21-15.

    Figure 21-15 Reference to the AIA EBS Invoked by the B2BCS Annotated in the composite.xml

    This image is described in surrounding text

    For your reference, the $AIA_HOME/Infrastructure/B2B/src/B2BConnectors/EDIX12B2BCSApp/X12Process SalesOrder ReqB2BCSImpl/composite.xml file contains sample Requester B2BCS Impl annotations.

21.4.7 How to Support Trading Partner-Specific Variants

Support for Trading Partner-specific processing can be built into the requester B2BCS in a manner similar to the way they are built into the provider B2BCS.

For more information about how to build trading partner-specific support in B2BCSs, see Section 20.3.8, "How to Support Trading Partner-Specific Variants."

21.4.8 How to Enable Error Handling

For more information about how to enable AIA services for error handling and recovery, see "Setting Up Error Handling" in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.

In short, the following steps must be taken:

  • Associate a fault-policy.xml with the B2BCS composite.

  • Invoke the AIAAsyncErrorHandlingBPELProcess for business faults, as shown in Figure 21-16 and Figure 21-17.

Figure 21-16 B2BCS Composite Defined to Invoke AIAAsyncErrorHandlingBPELProcess

This image is described in surrounding text

Figure 21-17 Invocation of the AIAAsyncEHService

This image is described in surrounding text

While invoking the AIAAsyncErrorHandlingBPELProcess, the B2B-specific elements in the fault schema can be populated as shown in Table 21-4.

Table 21-4 B2B-Specific Elements in the Fault Schema That Can Be Populated by AIAAsyncErrorHandlingBPELProcess

Fault Element Schema Description Example

Fault/B2BMReference/B2BMID

Unique identifier of the B2B document

13232325

Fault/B2BMReference/B2BDocumentType/TypeCode

Document type of the B2B document being processed by the requester B2BCS

855

Fault/B2BMReference/B2BDocumentType/Version

Document version of the B2B document being processed by the Requester B2BCS

4010

Fault/B2BMReference/B2BDocumentType/TypeCode/@listAgencyID

Standard of the B2B document being processed by the Requester B2BCS

X12

Fault/B2BMReference/GatewayID

Name of the B2B software being used.

Oracle B2B

Fault/B2BMReference/SenderTradingPartner/TradingPartnerID

Sender trading partner, mapped from the B2BM

MyCompany

Fault/B2BMReference/ReceiverTradingPartner/TradingPartnerID

Receiver trading partner, mapped from the B2BM

Global

Figure 21-18 provides the B2B-specific elements in the corecom:Fault.

Figure 21-18 B2B-Specific Elements in corecom:Fault

This image is described in surrounding text

The B2B details of the failed AIA service that are available in the fault instance are logged and available for debugging the failed flow.

21.5 Step 4: Developing or Extending an Existing Enterprise Business Service

The next step, as shown in Figure 21-19, is to develop a new EBS or use an existing EBS that is invoked by the requester B2BCS.

Figure 21-19 Step 4: Developing or Extending an Existing Enterprise Business Service

This image is described in surrounding text

For more information about creating a new EBS, see Chapter 13, "Designing and Developing Enterprise Business Services."

21.6 Step 5: Developing or Extending an Existing Provider ABCS

The next step, as shown in Figure 21-20, is to develop a new or extend an existing provider ABCS. The provider ABCS processes the AIA EBM by invoking application APIs or web-services.

Figure 21-20 Step 5: Developing or Extending an Existing Provider ABCS

This image is described in surrounding text

For more information about how to design and construct a provider ABCS, see Chapter 14, "Designing Application Business Connector Services" and Chapter 15, "Constructing the ABCS."

21.6.1 What You Must Know About Transformations

While you are developing this transformation from EBM to ABM, the Sender and Receiver Trading Partner information can be mapped to appropriate fields in the ABM to capture the source and target of the B2B message, as shown in Table 21-5.

Table 21-5 Sender and Receiver Trading Partner Fields in the EBM

EBM Header Element Description Example Value

/EBMHeader/B2BProfile/SenderTradingPartner/TradingPartnerID

ID of the sending trading partner as defined in Oracle B2B. For inbound flows, this is the remote trading partner.

GlobalChips

/EBMHeader/B2BProfile/ReceiverTradingPartner/TradingPartnerID

ID of the receiving trading partner as defined in Oracle B2B. For inbound flows, this is the host trading partner.

Acme

At the end of this step, all of the required AIA services for developing an outbound B2B integration flow are ready.

21.7 Step 6: Configuring Oracle B2B and Defining Trading Partner Agreements

The next step, as shown in Figure 21-21, is to create trading partner agreements in Oracle B2B.

Figure 21-21 Step 6: Configuring Oracle B2B and Defining Trading Partner Agreements

This image is described in surrounding text

For more information about how to define trading partners and associate B2B capabilities with them, see "Configuring Trading Partners" in Oracle Fusion Middleware User's Guide for Oracle B2B.

In addition, for EDI-based outbound B2B flows, Oracle B2B can be configured for batch processing of outbound documents. Parameters such as the batch size and time-out can be configured in Oracle B2B without having to make any changes to the AIA layer.

21.8 Step 7: Deploying and Configuring AIA Services

The next step, as shown in Figure 21-22, is to deploy the AIA services. You can deploy the services to a target Oracle SOA server using Oracle JDeveloper.

Figure 21-22 Step 7: Deploying and Configuring AIA Services

This image is described in surrounding text

If any domain value mapping (DVM) and configuration files are used by the AIA services required for the outbound integration, you must enter data corresponding to your B2B configuration.

You can also use the Project Lifecycle Workbench application to create a bill of material XML file for the AIA project, which can be used to autogenerate a deployment plan. This deployment plan can be used to deploy the AIA services and resources that constitute the integration project in multiple development, test, and production environments.

For more information about generating bills of material, see Chapter 3, "Working with Project Lifecycle Workbench."

For more information about generating deployment plans, see Chapter 8, "Generating Deployment Plans and Deploying Artifacts."

In addition, configure the AIA Error Handling framework and set up appropriate roles to be notified of errors in AIA flows.

For more information about error handling, see "Setting Up Error Handling" in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.

21.9 Step 8: Testing and Verifying

The next step, as shown in Figure 21-23, is to test and verify. Before you go live with your B2B integration flows with your trading partners, Oracle AIA recommends that you complete a sequence of tests for your newly developed or deployed AIA services, which constitute the B2B integration flow.

Figure 21-23 Step 8: Testing and Verifying

This image is described in surrounding text

For more information, see Section 20.8, "Step 7: Testing and Verifying."

21.10 Step 9: Going Live and Monitoring

The final step, as shown in Figure 21-24, is to go live with your trading partner for the outbound B2B document flow. The AIA and Oracle B2B deployments are duplicated in the product servers and rolled out to the end users.

Figure 21-24 Step 9: Going Live and Monitoring

This image is described in surrounding text

For more information, see Section 20.9, "Step 8: Going Live and Monitoring."