Step 1: Identifying the B2B Document and Analyzing Requirements The B2B document is defined in Oracle B2B. The XML schema of the B2B document is uploaded in the AIA Metadata The Enterprise Business Object EBO and the EBM to be used in the Functional mappi

18-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–1 High-Level Steps to Develop and Implement a Simple Inbound B2B Flow Most of the preceding steps are already described in Chapter 17, Developing and Implementing Outbound B2B Integration Flows. This chapter will be referred to whenever applicable.

18.2 Step 1: Identifying the B2B Document and Analyzing Requirements

The first step in building an inbound B2B flow, as shown in Figure 18–2 , is to identify the B2B document that needs to be generated by the flow. As a part of this step, you must also analyze the requirements for the AIA services that need to be built or extended to support the flow. Developing and Implementing Inbound B2B Integration Flows 18-3 Figure 18–2 Step 1: Identifying B2B Document and Analyzing Service Requirements 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:

a. The B2B document is defined in Oracle B2B.

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

Repository.

c. The Enterprise Business Object EBO and the EBM to be used in the

integration are identified.

d. 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 17.2, Step 1: Identifying the B2B Document and Analyzing Requirements.

18.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 18–3 , is to add routing rules to the AIAB2BInterface Infrastructure service. 18-4 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–3 Step 2: Adding Inbound Routing Rules to an AIA B2B Interface 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 18–4 . Figure 18–4 Oracle B2B Routing New B2B Documents to Requester B2B Services 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 will route the document to the OAGProcessInvoiceRequesterB2BCSImpl service. The input to the requester B2BCS Implementation is the B2BM element. The B2BM element is defined in the AIAComponentsEnterpriseObjectLibraryInfrastructureV1Meta.xsd file. Developing and Implementing Inbound B2B Integration Flows 18-5 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… 18-6 Developers Guide for Oracle Application Integration Architecture Foundation Pack

18.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_ HOMEInfrastructureB2BAIAB2BInterfaceAppAIAB2BInterfaceApp.jws application using Oracle JDeveloper. 2. Open the composite.xml file using Oracle JDeveloper, as shown in Figure 18–5 . Figure 18–5 composite.xml in Oracle JDeveloper 3. Add a new service reference to the requester B2BCS that processes the new inbound B2B document type as shown in Figure 18–6 . The next section of this document explains how to develop requester B2BCSs. Developing and Implementing Inbound B2B Integration Flows 18-7 Figure 18–6 New Service Reference Added to the Requester B2BCS that Processes the New Inbound B2B Document Type

4. Add a wiring to the newly added service from the Receive B2BM Mediator

component in the composite as shown in Figure 18–7 . Figure 18–7 Wiring Added to the Newly Added Service from the Receive B2BM Mediator Component in the Composite 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 18–8 . 18-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–8 ProcessInbound.mplan 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 18–9 . Figure 18–9 New Routing Rule to Invoke the Requester B2BCS 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 18–10 ensures that the EDI X12 Process Sales Order documents are routed to the X12 ProcessSalesOrder B2BCS Implementation. Developing and Implementing Inbound B2B Integration Flows 18-9 Figure 18–10 Routing Filter Ensuring that EDI X12 Process Sales Order Documents are Routed to ProcessSalesOrder B2BCS Implementation

10. Save your changes.

11. Deploy the modified SOA composite application.

18.4 Step 3: Developing a New Requester B2B Connector Service

This section includes the following topics: ■ Section 18.4.1, Introduction to Requester B2B Connector Services ■ Section 18.4.2, How to Identify the Message Exchange Pattern ■ Section 18.4.3, How to Develop a B2BCS Service Contract ■ Section 18.4.4, How to Store a WSDL in Oracle Metadata Services Repository ■ Section 18.4.5, How to Develop a B2B Connector Service ■ Section 18.4.6, How to Annotate B2B Connector Services ■ Section 18.4.7, How to Support Trading Partner-Specific Variants ■ Section 18.4.8, How to Enable Error Handling The next step, as shown in Figure 18–11 , is to develop the requester B2BCS to support the outbound B2B integration flow. 18-10 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–11 Step 3: Developing a New Requester B2B Connector Service 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 via Oracle B2B instead of integrating with an application. Hence, we recommend that you familiarize yourself with the design and development of ABCSs requester and provider. For more information about developing ABCSs, see Chapter 12, Constructing the ABCS.

18.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 18–12 illustrates the processing that takes place in a simple fire-and-forget message exchange pattern-based provider B2BCS. Developing and Implementing Inbound B2B Integration Flows 18-11 Figure 18–12 Process Flow of a Simple Fire-and-Forget Message Exchange Pattern-Based Provider B2BCS Step-by-step instructions for developing B2BCSs are provided in the following sections.

18.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 17.3.2, How to Identify the Message Exchange Pattern. For more information about identifying message exchange patterns, see Section 11.3, Identifying the MEP.

18.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 18-12 Developers Guide for Oracle Application Integration Architecture Foundation Pack 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 11.2, Defining the ABCS Contract. Following are the naming conventions recommended for use in the B2BCS WSDL definitions: ■ WSDL File Name: ■ Naming guideline: B2BStandardVerbEBOReqB2BCSImpl.wsdl ■ Example: X12ProcessSalesOrderReqB2BCSImpl.wsdl ■ Service Namespace: ■ http:xmlns.oracle.comB2BCSImpl{Core|IndustryIndustryName }B2BStandardVerbEBOReqB2BCSImplABCSVersion ■ Example: http:xmlns.oracle.comB2BCSImplCoreX12ProcessSalesOrderProvB2BC SImplV1 Please note that the ABCS Service version is independent of the B2B documentstandard version. For more information about recommendations on versioning AIA services, see Section 13.8, Versioning ABCS. ■ Service Name: ■ Naming guideline: B2BStandardVerbEBOReqB2BCSImpl ■ Example: X12ProcessSalesOrderProvB2BCSImpl ■ Port Type Name: ■ Naming guideline: B2BStandardVerbEBO ReqB2BCSImplService ■ Example: X12ProcessSalesOrderProvB2BCSImplService ■ Operation Name: ■ VerbEBO ■ ProcessSalesOrder ■ Request Message Name: ■ VerbEBOReqMsg ■ ProcessSalesOrderReqMsg

18.4.4 How to Store a WSDL in Oracle Metadata Services Repository

As a SOA best practice, we recommend 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: appsAIAMetaDataAIAComponentsB2BServiceLibraryConnectorswsdls Developing and Implementing Inbound B2B Integration Flows 18-13 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_HOMEaia_ instancesINSTANCE_ NAMEAIAMetaDataAIAComponentsB2BServiceLibrary ConnectorswsdlsB2B_STANDARDRequesterB2BCS VERSIONwsdl file.wsdl 2. Run the UpdateMetaDataDP.xml file present in AIA_HOMEaia_ instancesINSTANCE_NAMEconfig. 3. Using a SOA-MDS server connection to MDS, verify that AIA Metadata has been supplied, as shown in Figure 18–13 . Figure 18–13 AIA Metadata in the MDS

4. The WSDL can now be accessed using a URL similar to the following:

oramds:appsAIAMetaDataAIAComponentsB2BServiceLibrary ConnectorswsdlsEDI_X12RequesterB2BCSV1 X12ProcessSalesOrderProvB2BCSImpl.wsdl

18.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 need to be developed in the B2BCS implementation BPEL. 18-14 Developers Guide for Oracle Application Integration Architecture Foundation Pack 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 18–1 . 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 B2BDocB2BM_VarPayload.

8. Define a partner link to the EBS.

This is the AIA EBS that is invoked by the requester B2BCS. Table 18–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.comB2BCSImplCore Standard Verb Object ReqB2BCSImplV1 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.comB2BCSImplCore Standard Verb Object ReqB2BCSImplV1 Same as B2BCS WSDL namespace Template Base on WSDL WSDL URL URL of B2BCS service WSDL referred from MDS Developing and Implementing Inbound B2B Integration Flows 18-15 The abstract EBS WSDL can be referenced from: oramds:appsAIAMetaDataAIAComponentsEnterpriseBusinessServiceLibrar yCoreEBOVxEBOName.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:EBMHeadercorecom:B2BProfilecorecom:SenderTradingPartnerco recom:TradingPartnerID Source B2BM XPATH: corecom:B2BMcorecom:B2BMHeadercorecom:SenderTradingPartnercorec om:TradingPartnerID ■ Element: corecom:EBMHeadercorecom:B2BProfilecorecom:ReceiverTradingPartnerc orecom:TradingPartnerID Source B2BM XPATH: corecom:B2BMcorecom:B2BMHeadercorecom:ReceiverTradingPartnercore com: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.

18.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 2, Working with Project Lifecycle Workbench. For more information about annotating B2B services, see Chapter 9, Annotating Composites. To annotate requester B2B Connector Services: 1. Table 18–2 lists the annotation elements that must be added to the service element composite.xml, as described subsequently. Table 18–2 Service Annotation Elements in composite.xml Annotation Element Description Example AIAServiceInterfaceDetails Service Operation VerbEBOName ProcessSalesOrder AIAServiceImplementation DetailsArtifactType RequesterB2BCSImplementati on RequesterB2BCSImplementati on 18-16 Developers Guide for Oracle Application Integration Architecture Foundation Pack The following XML snippet, as shown in Figure 18–14 , is an example of an annotated B2BCS called X12ProcessSalesOrderReqB2BCSImpl composite.xml. Figure 18–14 Example Snippet of an Annotated B2BCS Called X12ProcessSalesOrderReqB2BCSImpl composite.xml 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 18–3 . Annotations as they appear in composite.xml are shown in Figure 18–15 . AIAServiceImplementation DetailsServiceOperationNa me VerbEBOName ProcessSalesOrder AIAServiceImplementation DetailsB2BDocument B2B Document Type processed by this B2BCS 850 AIAServiceImplementation DetailsB2BDocumentVersion B2B Document Version processed by this B2BCS 4010 AIAServiceImplementation DetailsB2BStandard B2B Standard processed by this B2BCS X12 AIAServiceImplementation DetailsB2BStandardVersion B2B Standard Version processed by this B2BCS 4010 Table 18–3 composite.xml Annotations Used to Reference the AIA EBS Invoked by the B2BCS Annotation Element Description Example AIAReferenceArtifactType Enter value EnterpriseBusinessService EnterpriseBusinessService AIAReferenceServiceOpera tionName EBS operation name ProcessSalesOrder Table 18–2 Cont. Service Annotation Elements in composite.xml Annotation Element Description Example Developing and Implementing Inbound B2B Integration Flows 18-17 Figure 18–15 Reference to the AIA EBS Invoked by the B2BCS Annotated in the composite.xml For your reference, the AIA_ HOMEInfrastructureB2BsrcB2BConnectorsEDIX12B2BCSAppX12Process SalesOrder ReqB2BCSImplcomposite.xml file contains sample Requester B2BCS Impl annotations.

18.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 17.3.8, How to Support Trading Partner-Specific Variants.

18.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 Users 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 18–16 and Figure 18–17 . 18-18 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–16 B2BCS Composite Defined to Invoke AIAAsyncErrorHandlingBPELProcess Figure 18–17 Invocation of the AIAAsyncEHService While invoking the AIAAsyncErrorHandlingBPELProcess, the B2B-specific elements in the fault schema can be populated as shown in Table 18–4 . Table 18–4 B2B-Specific Elements in the Fault Schema That Can Be Populated by AIAAsyncErrorHandlingBPELProcess Fault Element Schema Description Example FaultB2BMReferenceB2BMI D Unique identifier of the B2B document 13232325 FaultB2BMReferenceB2BDo cumentTypeTypeCode Document type of the B2B document being processed by the requester B2BCS 855 FaultB2BMReferenceB2BDo cumentTypeVersion Document version of the B2B document being processed by the Requester B2BCS 4010 FaultB2BMReferenceB2BDo cumentTypeTypeCodelist AgencyID Standard of the B2B document being processed by the Requester B2BCS X12 FaultB2BMReferenceGatew ayID Name of the B2B software being used. Oracle B2B FaultB2BMReferenceSender TradingPartnerTradingPartn erID Sender trading partner, mapped from the B2BM MyCompany Developing and Implementing Inbound B2B Integration Flows 18-19 Figure 18–18 provides the B2B-specific elements in the corecom:Fault. Figure 18–18 B2B-Specific Elements in corecom:Fault The B2B details of the failed AIA service now available in the fault instance will be logged and available for debugging the failed flow.

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

The next step, as shown in Figure 18–19 , is to develop a new EBS or use an existing EBS that is invoked by the requester B2BCS. FaultB2BMReferenceReceiv erTradingPartnerTradingPart nerID Receiver trading partner, mapped from the B2BM Global Table 18–4 Cont. B2B-Specific Elements in the Fault Schema That Can Be Populated by AIAAsyncErrorHandlingBPELProcess Fault Element Schema Description Example 18-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 18–19 Step 4: Developing or Extending an Existing Enterprise Business Service For more information about creating a new EBS, see Chapter 10, Designing and Developing Enterprise Business Services.

18.6 Step 5: Developing or Extending an Existing Provider ABCS