How to Support Trading Partner-Specific Variants

17-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack The reference to the AIA B2B Interface utility service should be annotated in the composite.xml, as shown in Figure 17–16 . Figure 17–16 AIA B2B Interface Utility Service Annotation Elements in composite.xml snippet 3. The AIA_ HOMEInfrastructureB2BsrcB2BConnectorsEDIX12B2BCSAppX12Update SalesOrder ProvB2BCSImplcomposite.xml file has sample provider B2BCS Impl annotations for your reference.

17.3.8 How to Support Trading Partner-Specific Variants

This section includes the following topics: ■ Section 17.3.8.1, Supporting Trading Partner-Specific Custom Extensions ■ Section 17.3.8.2, Supporting Trading Partner-Specific XSLTs ■ Section 17.3.8.3, Supporting Trading Partner-Specific Document Types and Versions Frequently, in B2B implementations different trading partners need to support different versions or mapping guidelines for the same B2B document. If a given B2B document needs to be sent to multiple trading partners, based on the version and mapping guideline determined for that trading partner, the B2BCS of the document can be built to support this trading partner-specific transformation logic. Multiple ways are available by which this can be achieved, as described in the following section.

17.3.8.1 Supporting Trading Partner-Specific Custom Extensions

If the trading partner-specific mappings are an addition to a common core mapping that remains unchanged, explore the possibility of using the custom XSLT template calls to have partner-specific mappings. For more information about support for XSLT extension using callouts to custom XSLT templates, see Section 13.1, Developing Extensible ABCS. Table 17–6 AIA B2B Interface Utility Service Annotation Elements in composite.xml Annotation Element Description AIAReferenceArtifactType Enter value UtilityService AIAReferenceServiceOperationNam e Enter value ProcessB2BDocument Developing and Implementing Outbound B2B Integration Flows 17-21 In short, at the end of every business component mapped in the XSLT file, an invocation to a custom XSLT template is made from the shipped B2BCSs, as shown in Figure 17–17 . Figure 17–17 Business Component Mapped in the XSLT, including an invocation from the Shipped B2BCS to a Custom XSLT template The custom XSLT templates are defined in a custom XSLT file, as shown in Figure 17–18 , which is included in the main XSLT. Figure 17–18 Custom XSLT Templates Defined in a Custom XSLT File During implementation, you can add additional mappings to this custom XSLT file. The trading partner ID can be passed as an input to the custom XSLT template call and can be used to conditionally map to target B2B elements, as shown in Figure 17–19 . Figure 17–19 Trading Partner ID Passed as an Input to the Custom XSLT Template Call 17-22 Developers Guide for Oracle Application Integration Architecture Foundation Pack

17.3.8.2 Supporting Trading Partner-Specific XSLTs

If the trading partner-specific mappings conflict with each other or if the partner-specific mappings need to be added at arbitrary locations in the XML document and not just at the end of each mapping template, the previous approach of using the custom XSLT templates to define partner-specific mappings will not meet requirements. To meet such requirements, you can decide to develop one XSLT file for each trading partner that needs custom mappings. You can make a copy of a shipped XSLT file, edit it to include partner-specific mapping logic, and save it by using a partner prefix in the filename, as shown in Figure 17–20 . Figure 17–20 Copies of Shipped XSLT Files Edited to Include Partner-Specific Mapping Logic and Saved Using a Partner Prefix in the Filename Next, you can define a configuration file that contains information about which XSLT file has to be used for each trading partner. For example, you can use a domain value mapping DVM file to store this configuration information, as shown in Figure 17–21 . Figure 17–21 DVM File Used to Map Trading Partners to XSLT Files In the provider B2BCS Impl BPEL process, as shown in Figure 17–22 , you can do a lookup on this DVM file, as shown in Figure 17–23 , to obtain the XSLT filename, as shown in Figure 17–24 . Developing and Implementing Outbound B2B Integration Flows 17-23 Figure 17–22 Provider B2BCS Implementation BPEL Process Requiring Trading Partner-Specific XSLT Figure 17–23 DVM Lookup to Obtain XSLT Filename Figure 17–24 Retrieval of XSLT Filename

17.3.8.3 Supporting Trading Partner-Specific Document Types and Versions

Along with the need for trading partner-specific XSLTs, a different Document Type may possibly need to be used in Oracle B2B for defining the trading partner agreements for the same external B2B document. For example, trading partner Global might need the 5010 version of the X12 855 B2B document and trading partner ABC Corp might need the 4010 version of the same document. Using the approach described in the previous section, you can use the same provider B2BCS Implementation to generate B2B documents for both the trading partners. However, while the AIA B2B Interface is being invoked based on the trading partner involved for the specific instance of the service, the corresponding B2B document version must be specified, 4010 for Global and 5010 for ABC Corp, for example. To support these requirements, use a DVM file similar to the one used in the previous approach to store the B2B Document Type and Document Revision information for each trading partner, as shown in Figure 17–25 . This information can be looked up by the BPEL process to populate the B2BMHeaderB2BDocumentTypeTypeCode and B2BMHeaderB2BDocumentTypeVersion attributes. 17-24 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 17–25 DVM Used to Store Trading Partner B2B Document Type and Document Revision Information While the configuration files described previously can be created and stored locally within the Oracle JDeveloper project, a best-practice recommendation is to externalize these files, store them in MDS, and refer to them from your B2BCS Implementation BPEL project using oramds lookup. Note that though this approach of using DVM files to store the B2B document preference and trading partner-specific transformation information works, the Trading Partner information between the application and these DVM files must be kept synchronized. Each time a new trading partner is defined in the application, a corresponding record should be created in this DVM to store the B2B document preference of the trading partner. A well-established administrative process to manage these changes should be available.

17.3.9 How to Enable Error Handling