25 Working with Message Transformations

This chapter provides an overview of Transformation Maps and describes how to create transformation maps, work with domain value maps (DVMs) and cross-references, and populate Enterprise Business Message (EBM) headers.

This chapter includes the following sections:

25.1 Introduction to Transformation Maps

Use transformation maps when the document expected by a source or target application varies from the document generated by a source or target application in terms of data shape and semantics. Transformation maps resolve these structural and semantic differences.

25.1.1 Connecting Applications to Implement Business Processes

Oracle Application Integration Architecture (AIA) leverages canonical patterns and direct patterns to connect applications for implementing business processes.

25.1.1.1 Canonical Patterns

AIA introduces a set of generic data structures called Enterprise Business Objects (EBOs). An EBO represents a common object definition for business concepts such as Account, Sales Order, Item and so on. The business integration processes work only on messages that are either a complete EBO or a subset of an EBO. This approach allows the cross-industry application processes to be independent of participating applications. EBOs contain components that satisfy the requirements of business objects from the target application data models. Transformations map the application business-specific message to the EBM which is AIA canonical data model.

Figure 25-1 illustrates how a canonical pattern is implemented in AIA.

Figure 25-1 Canonical Pattern Implemented in AIA

Canonical Pattern Implemented in AIA

25.1.1.2 When to Use Direct Integrations

When data integration involves either a large batch of records, or very large data, you can choose to implement a direct integration specializing on the movement of data with high performance with a trade-off of reusability. Direct integrations can encompass bulk processing and trickle feeds which focus only on implementation decoupling and not data decoupling.

For bulk processing, the ETL tool is used and transformations are done at the data layer using the tool. Although application agnostic objects are not used in trickle feed implementations, the requester application still must transform the content that is produced into the data shape expected by the provider application.

For more information, see Chapter 24, "Using Oracle Data Integrator for Bulk Processing."

25.1.2 Using Tools and Technologies to Perform Message Transformations

AIA recommends the use of XSLT vocabulary for constructing the transformation maps.

The XSLT Mapper in JDeveloper enables you to create data transformations between source schema elements and target schema elements within the context of services developed using either Oracle BPEL Process Manager or Oracle Mediator.

You use the XSLT Mapper transformation tool to create the contents of a map file. Figure 25-2 shows the layout of the XSLT Mapper.

Figure 25-2 Layout of the XSLT Mapper

The image is described in the surrounding text

For more information about the XSLT Mapper, see "Creating Transformations with the XSLT Mapper" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

25.2 Creating Transformation Maps

One of the steps in configuring the integration objects for your integration process is to map the components and fields in your internal integration object to the message elements in the external integration object. You use these maps to move the data from one integration object to another.

25.2.1 Considerations for Creating Transformation Maps

When creating transformation maps, consider the following guidelines:

  • Do not make unnecessary or redundant AIAConfigurationProperties.xml lookup calls.

    Retrieve static configuration properties once in the very beginning of transformation.

    To externalize configuration for deployment time using AIAConfigurationProperties.xml, refer to Section 2.1.3.9, "How to Work with AIAConfigurationProperties.xml in $AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config."

  • Ensure that your design does not include infinite loops.

  • Develop transformation maps for each component.

    You should build reusable component-specific transformation maps that can be used across applications.

  • Create transformation templates for every custom element.

  • Keep the transformation maps clutter free.

  • Use domain value maps only for static lookups, not for storing configuration or setup data.

    Example 25-1 illustrates the domain value map lookup call to fetch Currency Code. The domain value maps should be used only for static lookup calls such as Currency Codes, Location Codes, and so on.

    Example 25-1 Domain Value Map Lookup Call to Fetch Currency Code

    <corecom:PreferredFunctionalCurrencyCode>

<xsl:value-of select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_
CODE.dvm',$SenderSystemId,/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/
xsdLocal:CurrencyCode,$TargetSystemId,'')"/>

</corecom:PreferredFunctionalCurrencyCode>

25.2.2 Handling Missing or Empty Elements

Transformation logic and xpath should be designed with the possibility of missing or empty elements, as shown in Example 25-2.

Example 25-2 Sample Code Illustrating Logic Designed to Handle Missing or Empty Elements

<xsl:iftest="normalize-
space="/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:AccountId/
text() )">
<corecom:ApplicationObjectKey>
     <corecom:ID>
           <xsl:value-of 
select="/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:
AccountId"/>
     </corecom:ID>        
</corecom:ApplicationObjectKey>
  </xsl:if>

In this example, an if condition exists to check the empty elements. You should adopt such transformation logic to avoid transporting empty elements across the wire.

25.2.3 How to Map an Optional Source Node to an Optional Target Node

When mapping an optional source node to an optional target node, you should surround the mapping with an xsl:if statement that tests for the existence of the source node. If you do not do this, as shown in Example 25-3, and the source node does not exist in the input document, then an empty node is created in the target document.

Example 25-3 Statement Without xsl:If

<portal:PHONE>
            <xsl:value-of 
select="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom: WorkContactNumber"/>
          </portal:PHONE>

If the PHONE field is optional in both the source and target and the WorkContactNumber does not exist in the source document, then an empty PHONE element is created in the target document. To avoid this situation, add an if statement to test for the existence of the source node before the target node is created, as shown in Example 25-4.

Example 25-4 Statement With xsl:If

<xsl:if
test="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom:WorkContactNumber">
        <portal:PHONE>
            <xsl:value-of 
select="corecom:Contact/corecom:ContactPhoneCommunication[1]/corecom:
PhoneCommunication/corecom:WorkContactNumber"/>
         </portal:PHONE>
  </xsl:if>

25.2.4 How to Load System IDs Dynamically

ABCS and XSL scripts should not be hard-coded to work against one specific logical application instance, as shown in Example 25-5. No hard-coded system IDs should exist in XSL Scripts and ABCS.

Example 25-5 Sample Code Showing Hard-Coded System IDs - Not Recommended

<corecom:PreferredFunctionalCurrencyCode>
              <xsl:value-of 
select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_CODES.
dvm','SEBL_01',
/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:Account/xsdLocal:CurrencyCode,
'COMMON','")"/>
</corecom:PreferredFunctionalCurrencyCode>

The recommended approach is to load the system IDs dynamically, as shown in Example 25-6.

Example 25-6 Sample Code Showing Use of Variables Instead of Hard-coded System IDs - Recommended

<corecom:PreferredFunctionalCurrencyCode>
<xsl:value-of select="dvm:lookupValue('oramds:/apps/AIAMetaData/dvm/CURRENCY_
CODES.dvm',$SenderSystemId,/xsdLocal:ListOfCmuAccsyncAccountIo/xsdLocal:
Account/xsdLocal:CurrencyCode,$TargetSystemId'")"/>
</corecom:PreferredFunctionalCurrencyCode>

25.2.5 Using XSLT Transformations on Large Payloads

For BPEL and Oracle Mediator, Oracle recommends that you do not apply the XSLT transformation on large payloads because it results in out-of-memory errors when XSLT must traverse the entire document.

25.2.6 When to Populate the LanguageCode Attribute

Every EBM should populate the languagecode element, which specifies the locale in which the request has to be sent. Language sensitive data elements must have the languageCode attribute populated if it is different from the one set at EBM root element. The languageCode specified in the DataArea takes precedence.

25.2.7 How to Name Transformations

Place each transformation type in a separate core XSL file.

The file name should follow this convention:

<Source Schema Type>_to_<Destination Schema Type>.xsl

Example: CreateOrderEBM_to_CreateOrderSiebelABO.xsl

25.3 Making Transformation Maps Extension Aware

Every component in the EBM, including the EBM header, contains a custom area that can be configured to add the necessary elements. You should develop the core transformation XSL file to provide extension capabilities using the guidelines in the following section.

For more information about the EBM header, see Section 25.6, "Introducing EBM Header Concepts".

25.3.1 How to Make Transformation Maps Extension Aware

To make transformation maps extension aware:

  1. Create an extension XSL file for every transformation.

    An example of a core transformation XSL file: PurchaseOrder_to_PurchaseOrder.xsl

    Every core XSL file name has one extension XSL file, for example: PurchaseOrder_to_PurchaseOrder_Custom.xsl.

  2. Define empty named templates in the extension file for every component in the message.

  3. Include the extension file in the core transformation file.

  4. Add a call-template for each component in core transformation.

  5. Enable the transformation to accommodate transformations for custom element as shown in Example 25-7.

Example 25-7 Transformation Enabled to Accommodate Transformations for Custom Element

<!-XSL template to transform Address-->
<xsl: template name="Core_AddressTemplate">
<xsl:param name = "context" select ="."/>
<xsl:param name = "contextType" select ="'CORE'"/>
<address1><xsl:value-of select="$context/address1"><address1>
<address2><xsl:value-of select="$context/address1"></address2>
<city><xsl:value-of select="$context/city"></city>
<state><xsl:value-of select="$context/state"></state>
<zip><xsl:value-of select="$context/zip"></zip>

   <xsl:if test="$contextType!='CORE'">
<xsl:call-template name="Vertical_AddressTemplate">
<xsl:with-param name="context" select="$context"/>
<xsl:with-param name="contextType" select="$contextType">
      </xsl:call-template>
</xsl:if>
</xsl: template>

25.3.2 How to Make the Transformation Template Industry Extensible

Mapping rules pertaining to customer-specific schema extensions are defined in these xsl extension templates.

To make the transformation template industry extensible:

  1. Put the extension templates into a separate transformation file.

  2. Import from the main transformation file. Example 25-8 shows the industry extensible transformation template.

    Example 25-8 Industry Extensible Transformation Template

    <xsl: template name="Core_AddressTemplate">
<xsl:param name = "context" select ="."/>
<xsl:param name = "contextType" select ="'CORE'"/>
<address1><xsl:value-of select="$context/address1"><address1>
<address2><xsl:value-of select="$context/address1"></address2>
<city><xsl:value-of select="$context/city"></city>
<state><xsl:value-of select="$context/state"></state>
<zip><xsl:value-of select="$context/zip"></zip>
   <xsl:if test="$contextType!='CORE'">
         <xsl:call-template name="Vertical_AddressTemplate">
<xsl:with-param name="context" select="$context"/>
<xsl:with-param name="contextType" select="$contextType">
</xsl:call-template>
</xsl:if>
</xsl: template>

25.4 Working with DVMs and Cross-References

This section discusses DVMs, cross-references, and naming standards, and when to use them.

25.4.1 Introduction to DVMs

Use domain values only for static lookups. Do not use them to store configuration or setup data. A separate facility is provided to store and retrieve parameterized configuration information.

To access the DVM at run time, use the lookup-dvm XSL function found in the JDeveloper XSL Mapper.

DVMs are stored in the MDS repository, which uses the database persistence, and are managed using tools provided by JDeveloper or Foundation Pack.

For more information about naming standards, see Chapter 31, "Oracle AIA Naming Standards for AIA Development."

25.4.2 When to Use DVMs

DVMs can be categorized into three groups:

  • 100 percent of the possible values are seeded, and you are not permitted to define any more.

    Since logic is added to these values and they are defined by the participating applications, you cannot add values.

  • All or a few samples are seeded based on the seeded values found in the participating applications.

    You can add more to the participating applications and can add more to the DVMs in the middle to accommodate.

    Typically, logic is not added to these values; a match gets the value and passes it on to the receiving application. You must enhance the list to include all possible values that you have defined in your participating applications.

  • Customized.

    A naming convention is provided for you to define your own DVM types and values in case you have added a column that depends on it. These types or values are not affected during an upgrade.

When creating cross-reference virtual tables in the cross-reference tables, follow the naming standards described in the following section.

25.4.3 Using Cross-Referencing

One of the core design tasks of ABCS is maintaining cross references for unique identifiers from the loosely coupled applications.

AIA does not support hierarchical cross-references. Child object common keys are unique on their own without being under the parent's context. The child objects have their own entry within the cross-references table with a GUID used for the common ID.

The Cross References API does not support multi-part keys. In cases where the application does not have a single unique key, AIA recommends key concatenation:

{Key1}::{Key2}::Key3

Most requester ABCSs use the following logic in the transformations:

  1. Look up in Xref for an existing common ID corresponding to the application ID.

  2. If common ID is not found, then generate a new ID and populate the Xref table with the new ID.

  3. Use the found or new common ID in the transformation.

Cross referencing is achieved using EBM Object identification elements and the cross referencing APIs (Populate Xref, Lookup Xref, Delete Xref) provided by Oracle Mediator.

Table 25-1 lists a cross referencing configuration implemented in the Product synchronization scenario between the Portal BRM and Siebel CRM systems

Table 25-1 Cross Referencing Configuration

Entity Siebel CRM ID Common ID Oracle BRM ID

Item ID

Product ID

Auto Generated GUID

Product ID

Price Line ID

Price Line ID

Auto Generated GUID

Product ID

ITEM_ID cross-references the BRM (Portal) ProductID and the Siebel ProductID.

PRICELINE _ID cross-references the BRM (Portal) Product ID to Siebel PriceLineID.

25.4.4 How to Set Up Cross References

Oracle SOA Suite provides a cross-reference infrastructure that consists of these components:

  • A single Xref database table that contains virtual tables for the different cross-reference object types and command line utilities to import/export data.

  • XPath functions to query, add, and delete cross-references.

For more information about naming standards, see Chapter 31, "Oracle AIA Naming Standards for AIA Development."

For more information about cross-references, see "Working with Cross References" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

25.5 Mapping and Populating the Identification Type

Each of the EBMs has at least one element to hold an object's instance identifying information. An EBM containing details about multiple objects might have elements dedicated to holding object instance identifying details for each one of them. In the EBM, there is a scheme to uniquely identify the top-level object's instance and the child and the grandchild instances of the business components embedded within the overall object. The identification scheme is the same regardless of whether the identification is for the top-level instance (for example - Order Instance Identification) or for a grandchild instance (for example - Schedule Line Item Identification).

The commonly practice is to adopt the identification theme as defined in the data type Identification Type that is made available in the Common Components schema module. Each of the objects can have representations in various applications and at the integration layer. Each of the representations is uniquely identified using identifying keys. For example, Order Number can uniquely identify either an Order ID or an Order instance in a Siebel application; whereas in a PeopleSoft application, the order instance is uniquely identified with the combination of Business Unit and Order ID.

As you can see in the example, the identifying keys of these representations found across various applications and systems are quite different. The Identification Type enables you to capture the identifying keys of these representations for a single object instance. Figure 25-3 illustrates the schema definition for Identification Type.

Figure 25-3 Structure of the Identification Type Element

Structure of the Identification Type Element

The Identification Type structure enables you to capture three specific identifiers plus one more general identifier for a single object. Table 25-2 describes each of the identifiers:

Table 25-2 Identifiers in the Identification Type Structure

Name Purpose Details

BusinessComponentID

Unique Key for the application-agnostic representation of the object instance

Business documents generated by Oracle AIA applications have the BusinessComponentID populated.

The BusinessComponentID is generated using the API provided by Oracle AIA infrastructure.

ID

Business friendly identifier found in the participating application for this object instance

Business documents generated by Oracle AIA applications have these populated wherever they are applicable.

PO Number and Order Number are examples.

ContextID

Optional element to identify additional qualifiers for the ID. Used for multi-part keys - for example if an Item is unique within a set, then the Item Number would be the ID and the SetID value would be a ContextID value

Business documents generated by Oracle AIA applications have these populated wherever they are applicable.

SetID within a set is an example

ApplicationObjectKey

Participating application specific internally generated unique identifier for this object instance

Business documents generated by Oracle AIA applications populate this information.

This represents the primary key of the object at the participating application.

AlternateObjectKey

One or more ways of additionally identifying the object's instance.

Optional

Use this element to capture additional identifying details if necessary.

To define the context in which an identifier is valid, a set of attributes that describes the context of the key is supported in addition to the actual key value.

Table 25-3 describes the purpose of each of the attributes.

Table 25-3 Key Context Attributes

Name Type Description

BusinessComponentID/ID

ApplicationObjectKey/ID

AlternateObjectKey/ID

Element

The element is used to store the actual object ID.

schemeID

Optional attribute

Identification scheme of the identifier.

Attribute schemeID provides information about the object type identified by the ID, for example ItemGUID for the GUID of an item and PartyGUID for the GUID of a party.

For the BusinessComponentID, the schemeID is set to the name of the object followed by ' GUID. For the ID, the schemeID is set to the name of the element as known in the participating application.

scheme VersionID

Optional attribute

Version of the identification scheme.

schemeAgencyID

Optional attribute

ID of the agency that manages the identification scheme of the identifier.

The GUIDs generated by Oracle AIA have AIA 01 populated in this attribute. For identifiers generated by participating applications, the short code for that of the participating application is stored in this attribute.

Figure 25-4 illustrates the Business Component ID:

Figure 25-4 Structure of the Business Component ID

Structure of the Business Component ID

Example 25-9 provides an example of how the BusinessComponentID is populated in the EBM.

Example 25-9 BusinessComponentID Populated by the EBM

<telcoitem:Identification>
<corecom:BusinessComponentID 
mlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1" 
schemeID="ITEM_ID_COMMON" schemeAgencyID="AIA_
20">31303838373539343330313937393531
</corecom:BusinessComponentID>
<corecom:ID 
xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1" 
schemeID="ItemNumber" schemeAgencyID="PORTAL">0.0.0.1 /product 
349330 1</corecom:ID>
<corecom:ApplicationObjectKey xmlns:corecom="http://xmlns.oracle.com/Enterpriser
Objects/Core/Common/V1">
<corecom:ID schemeID="PortalPoid" schemeAgencyID="PORTAL">0.0.0.1 /product 
349330 1</corecom:ID>
 </corecom:ApplicationObjectKey>
</telcoitem:Identification>

25.5.1 How to Populate Values for corecom:Identification

Follow these guidelines for corecom:Identification or any of its derivations.

  • SchemeAgencyID for Common is COMMON.

  • SchemeAgencyID for ID/ContextID/ApplicationObjectKey is the same as exsl:node-set ($senderNodeVariable)/ID, which is also used as Column Name for lookupXref and lookupDVM.

  • Scheme ID for BusinessComponentID is the same as XrefTableName in lookupXref/populateXref.

25.6 Introducing EBM Header Concepts

Every EBM that is processed by ABCS and Enterprise Business Service (EBS) contains an EBM header in addition to object-specific information. The objective of the EBM header is to carry information that can be used to:

  • Track important information

  • Audit

  • Indicate source and target systems

  • Handle errors and traces

Figure 25-5 illustrates the components of an EBM header:

Figure 25-5 EBM Header Components

EBM Header Components

The following sections provide details about each of the components.

25.6.1 Standard Elements

This section discusses the standard elements in a message header.

25.6.1.1 EBMID

This element contains a GUID to uniquely identify the EBM, as shown in Example 25-10. The GUID is generated using a provided standard XPath function.

XPath function to generate GUID: orcl:generate-guid()

Example 25-10 EBMID

<EBMHeader>
<EBMID>33303331343032313534393138393830</EBMID>
. . .
</EBMHeader>

25.6.1.2 EBOName

This element contains the fully qualified name of the EBO in the notation: {namespaceURI}localpart, as shown in Example 25-11.

Example 25-11 EBOName

<EBMHeader>
<EBOName>{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Invoice/V1}Query
Invoice</EBOName>
. . .
</EBMHeader>

25.6.1.3 RequestEBMID

This element contains the originating request GUID that uniquely identifies the originating request ID, as shown in Example 25-12. The EBS populates this field in the response message by extracting it from the request message.

Example 25-12 RequestEBMID

<EBMHeader>
<RequestEBMID>33303331343032313534393138393830</RequestEBMID>
. . .
</EBMHeader>

25.6.1.4 CreationDateTime

This element contains a timestamp that reflects when the EBM was created, as shown in Example 25-13. The timestamp should be presented in UTC, which can be presented in current datetime and GMT offset as:

yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s +)? (zzzzzz)?
XPath function to generate CreationDateTime:
xp20:current-dateTime()

Example 25-13 CreationDateTime

<EBMHeader>
<CreationDateTime>200 7-04-2 7T12:22:17-08:00</CreationDateTime>
. . .
</EBMHeader>

25.6.1.5 VerbCode

This element contains the verb represented by the EBM, as shown in Example 25-14.

Example 25-14 VerbCode

<EBMHeader>
<VerbCode >Query</VerbCode>
. . .
</EBMHeader>

25.6.1.6 MessageProcessingInstruction

This element contains instructions on how the message should be processed. This section indicates if the EBM is a production system-level message that should go through its standard path, or if it is a testing-level message that should go through the testing or simulation path.

MessageProcessingInstruction contains two fields:

  • EnvironmentCode:

    Can be set to either CAVS or PRODUCTION. The default is PRODUCTION. Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator.

  • DefinitionID:

    Specifies the test definition ID.

    It should be populated with the value of the property "Routing.[PartnerlinkName].CAVS.EndpointURI" from AIAConfigurationProperties.xml when the "Routing.[PartnerlinkName].RouteToCAVS" property is set to true in AIAConfigurationProperties.xml.

25.6.1.7 When to Populate Standard Header Fields

The standard header elements should be populated whenever a message is created. This occurs when:

  • Transforming an application request ABM into an EBM in a requester ABC implementation service.

  • Transforming an application response ABM into an EBM in a provider ABC implementation service.

25.6.1.8 How to Populate the Message Processing Instruction

To populate the message processing instruction

  1. Add instructions to indicate how a message is to be processed.

    This instruction is normally used to tell the system to run the message in production mode or in simulation/testing mode, as shown in Example 25-15.

  2. These fields are currently populated by the CAVS.

    Usually, the fields are populated in the SOAP Header before initiating a testing request.

    Example 25-15 Message Processing Instruction Population

    <corecom:MessageProcessingInstruction>
    <corecom:EnvironmentCode>
 <xsl:text disable-output-escaping="no">Production</xsl:text>
    </corecom:EnvironmentCode >
</corecom:MessageProcessingInstruction>

25.6.2 Sender

The Sender contains information about the originating application system, as shown in Figure 25-6.

Figure 25-6 Structure of the Sender Element

Structure of the Sender Element

Table 25-4 provides details about each element in the Sender element.

Table 25-4 Elements in the Sender Element

Element Description

ID

Contains the sender system identifier code. This is a mandatory element. This element represents the unique identifier of each source system. ReqABCSImpl should call the API detailed in Example 25-16 to populate this value.

Description

This is the long description of the Sender System. ReqABCSImpl should call the API detailed in Example 25-16 to populate this value.

IPAddress

Represents the IP address of the sender system. ReqABCSImpl can call the API detailed below to populate this value.

SenderMessageID

This is the ID that can uniquely identify the message sent by the sender system. ReqABCSImpl may have this information and that information can be used to populate this element.

Transaction Code

This is the task code in the sender system that is used to generate this message. ReqABCSImpl has this information and should use that while preparing the EBM.

CallingServiceName

Name for the calling ABCS. Populated by source ABCS.

Application

Holds information about the originating application.

Application/ID

The sender system can designate the originating application code in this element. ReqABCSImpl should call the API detailed in Example 25-16 to populate this value.

Application/Version

The sender system can designate the version of the originating application in this element. ReqABCSImpl should call the API detailed in Example 25-16 to populate this value.

Example 25-16 Sender Element Code Sample

<corecom:Sender>
<corecom:ID>SEBL_01</corecom:ID>
<corecom:Description/>
<corecom:IPAddress/>
<corecom:SenderMessageID>33303331343032313534393138393830</corecom:
SenderMessageID>
<corecom:CallingServiceName>{http://xmlns.oracle.com/SampleSiebelApp}
CreateCustomerSiebelInputFileReader</corecom:CallingServiceName>
<corecom:Application>
<corecom:ID/>
<corecom:Version>1.0</corecom:Version>
</corecom:Application>
<corecom:ContactName/>
<corecom:ContactEmail/>
<corecom:ContactPhoneNumber/>
</corecom:Sender>

25.6.2.1 SenderMessageID

This element uniquely identifies the message that originated in the source application. Inbound request message is one of the potential sources for this element. The Application Business Message (ABM) (payload sent by the source application) can either have SenderMessageID populated in the payload or stored in ABM Header. Populated during the inbound message transformation from ABM into EBM in the ReqABCSImpl.

This information could subsequently be used by downstream services that are planning to send a message to the same sender application to establish the context.

25.6.2.2 When to Populate Sender System Information

The Sender System information should be populated whenever an EBM is created. This occurs when:

  • Transforming a request ABM into an EBM in a requester ABC implementation service.

  • Transforming a response ABM into an EBM in a provider ABC implementation service.

25.6.2.3 How to Populate Sender System Information

To populate sender system information:

  1. Use the following XPath function to retrieve the Sender System information from AIA System Registration Repository based on the system ID/Code and then return the data as an XML Node-Set:

    ebh:getEBMHeaderSenderSystemNode(senderSystemCode as string,
senderSystemID as string,
) return senderSystem as node-set

  2. Pass either the senderSystemCode or the senderSystemID.

    The function locates the system information in AIA System Registration Repository based on either the code or the ID.

25.6.2.4 TransactionCode

The TransactionCode is used to identify the operation in the sender system that generated the sender message.

The inbound request message is one of the potential sources for this element.

To preserve the context, the value of this element is used when constructing the 'AIAFaultMessage' in the catch of a fault handler.

This information could subsequently be used by downstream services that are planning to send a message to the same sender application to establish the context.

25.6.2.5 ContactName

This element is the name of the contact of the sender system. The value is retrieved from AIA System Registration Repository by doing a lookup. ReqABCSImpl should call the API detailed in Example 25-16 to populate this value. This information can be made available in the fault message or in the request message to be sent to external businesses by the downstream services.

25.6.2.6 ContactEmail

This element is the email of the contact of the sender system. The value is retrieved from AIA System Registration Repository by doing a lookup. ReqABCSImpl should call the API to populate this value. This information can be made available in the fault message or in the request message to be sent to external businesses by the downstream services.

25.6.2.7 ContactPhoneNumber

This element is the phone number of the contact of the sender system. The value is retrieved from AIA System Registration Repository by doing a lookup. ReqABCSImpl should call the API to populate this value. This information can be made available in the fault message or in the request message to be sent to external businesses by the downstream services.

25.6.2.8 ESBHeaderExtension

This element accommodates the transmission of additional information from the source application. Some data passed from the sender system must be transported through the EBM message life cycle and is needed for identifying and processing the target system. The target Application Business Message (ABM) may not have a placeholder for those kinds of data. Since they cannot be forced to provide a placeholder for every such element, this Enterprise Service Bus (ESB) header is used to hold that information. ESB has name and value pair and this component can have as many of those elements as required.

Figure 25-7 Structure of the ESBHeaderExtension Element

The image is described in the surrounding text

Table 25-5 describes the elements in the ESBHeaderExtension element.

Table 25-5 Elements in the ESBHeaderExtension Element

Element Description

ESBHeaderExtension/Name

ESB Header element name is the same as the ID. Even though it allows multiple names for EBM header scenarios there is only one value that is same as the ID.

Any transformation in the life cycle of the EBM header can populate this field.

ESBHeaderExtension/DataTypeCode

ESB Header element data type is populated by source ABCS.

ESBHeaderExtension/Value

ESB Header element value is populated by source ABCS. Even though it allows different placeholders for different data types, for simplicity only this element is populated.

Any transformation in the life cycle of the EBM header can populate this field.

Figure 25-8 illustrates the structure of the ESBHeaderExtension element.

Figure 25-8 Structure of the ESBHeaderExtension Element

Structure of the ESBHeaderExtension Element

25.6.2.9 ObjectCrossReference

This component stores the identifier information of the sender objects and the corresponding cross-reference identifier, as shown in Figure 25-9. Since the EBM can be used for bulk processing this element can be repeated as well. This data may be repeated in the data area but to maintain uniform XPath location information about them, they are maintained here as well. ReqABCSImpl populates this value.

Figure 25-9 Structure of the ObjectCrossReference Element

Structure of the ObjectCrossReference Element

Table 25-6 describes the elements in the ObjectCrossReference element.

Table 25-6 Elements in the ObjectCrossReference Element

Element Description

ObjectCrossReference/SenderObjectIdentification

Contains all the key field names and key field values for the object. The data is provided by the sender system.

ReqABCSImpl has this information and populates this value.

ObjectCrossReference/SenderObjectIdentification/ID

Identifies the object type of the sender system for example ORDER ReqABCSImpl has this information and populates this value

ObjectCrossReference/SenderObjectIdentification/Name

This identifies the description of the sender system, for example, Purchase Order.

ReqABCSImpl has this information and populates this value.

ObjectCrossReference/SenderObjectIdentification /ContextID

This identifies the sender system's object identifiers. If the sender's object has multiple values then repeat this as many times. Use the attribute schemeID to set the Key Name and the Key value should be stored in the element itself. ReqABCSImpl has this information and populates this value.

ObjectCrossReference/EBOID

This is the corresponding cross-reference identifier stored in the integration layer.

ReqABCSImpl has this information and populates this value.

25.6.2.10 How to Add Object Cross Reference information in the Sender System Information

To add a cross-reference entry in the sender system's ObjectCrossReference:

You must add the identifier information of the sender objects and the corresponding cross-reference identifier.

  • EBOID - Provide the corresponding cross-reference identifier in the integration layer. ReqABCSImpl has this information and populates this value.

  • SenderObjectIdentification - Populate the key field name and key field values for the object. The data is provided by the Sender System.

    • ID - Identifies the object type of the sender system, for example, Order. ReqABCSImpl has this information and populates this value

    • NAME - Identifies the description of the sender system, for example, Purchase Order. ReqABCSImpl has this information and populates this value.

    • ContextID - Identifies the sender system's object identifiers. If the sender's object has multiple values then repeat this as many times. Use the attribute SchemeID to set the key name and store the key value in the element itself. ReqABCSImpl has this value and populates the value.

25.6.2.11 WS Address

This element holds all WS-Addressing elements and transports WS-Addressing elements and exchanges WS-Addressing elements between the requester and target system. A local version of WS-Address schema is stored in a specified directory and ReqABCSImpl populates this. This element must be populated in the request EBM only when the provider application sends the response in an asynchronous mode. The provider application sending an asynchronous response leverages the value of this element to identify the callback address.

25.6.2.12 Custom

This element is the complex type that you can extend to add your own elements.

For more information about specific usage of this element, see Section 13.6, "Implementing the Fire-and-Forget Message Exchange Pattern."

25.6.3 Target

The Target section is populated only when there is a need to override the routing rules for the target system defined in Oracle Mediator. For bulk processing it is assumed that all objects reach the same target system defined in a routing rule. In that scenario define the appropriate target system information in this element to override the routing rule. The overriding target system information is applicable to all the objects in the data area. The requester ABCS should never populate the target system. The Enterprise Business Flow (EBF) or an EBS alone can populate the details.

The Target element contains information regarding the target or receiving system and has the elements shown in Figure 25-10.

Figure 25-10 Structure of the Target Element

Target Element

25.6.3.1 ID

Use this element, shown in Example 25-17, to identify target systems to route to when the routing rules are overridden. It is populated by the EBS when the target system must be overridden with the value of the participating application instance code.

25.6.3.2 ApplicationTypeCode

This element identifies the type of application. An identifier for the application type where multiple instances of the same application type may be registered in the integration platform. The application type may contain the version number of the application if multiple versions are supported on the system.

This field, as seen in Example 25-17, should be populated at the same time as the Target/ID field is populated in the EBS (or in an EBF), usually in the ABCS. The value of this field should come from the function aia:getSystemType(<ID>), where ID is the system ID value that is populated in Target/ID. EBS routing rules almost always check this field for a value or lack of value when determining the routing target.

25.6.3.3 Custom

This is the complex type that you can extend to add your own elements when needed.

Example 25-17 shows an example of target element code.

Example 25-17 Target Element Code Sample

<corecom:Target>
<corecom:ID>PORTAL_01</corecom:ID>
<corecom:ApplicationTypeCode>PORTAL_01</corecom:ApplicationTypeCode>
</corecom:Target>

25.6.4 BusinessScope

This section captures business scope specification related information defined in UN/CEFACT Standard business definition header.

Every EBM must contain at least two rows for these elements.

  • One row with type Business Scope describes the end-to-end business process that the message is part of.

  • The second row describes the main message associated in the flow (for example, order message in ProcessOrder flow).

For most of the cases, each end-to-end process has one message only. However in complex business scenarios there could be multiple messages spawned or forked from the process. In that case each spawned message must be a row in this section. Figure 25-11 describes how this works.

Figure 25-11 Structure of the BusinessScope Element

The image is described in the surrounding text

25.6.4.1 ID

An optional identifier that identifies the contract this instance relates to. ReqABCSImpl populates this value. This is the name of the process or message given by the applications.

25.6.4.2 InstanceID

A unique identifier that references the instance of the scope (for example, process execution instance of document instance). This is an alpha numeric code assigned by the application team concatenated with a GUID. For message type business scope section use the same EBMID as used in the top section.

25.6.4.3 BusinessScopeTypeCode

This element indicates the kind of business scope. Values are:

  • BusinessScope (UMM)

  • BusinessService (for ebXML)

  • Message

ReqABCSImpl populates this value.

25.6.4.4 EnterpriseServiceName

Name of the EBS where this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.

25.6.4.5 EnterpriseServiceOperationName

Name of the action of the EBS this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.

25.6.4.6 Custom

A complex type for you to extend to add extra elements.

25.6.4.7 How to Add Business Process Information

Every EBM must contain at least two rows for these elements:

  • One row with type Business Process describes the end-to-end business process the message is part of.

  • The second row describes the main message associated in the flow, for example, the order message in ProcessOrder flow.

In most cases, each end-to-end process has only one message. However in complex business scenarios there could be multiple messages spawned or forked from the process. In that case each spawned message must be a row in this section.

The use case example below describes how this works. To keep things simple the example limits the messages to the immediate child of the process and the subsequent chaining of messages is not taken into account.

25.6.5 Use Case: Request-Response

GetAccountBalance: Sends a request message with account number as input and receives account balance as response, as shown in Figure 25-12.

Figure 25-12 Use Case: Request-Response

Use Case: Request/Response

25.6.5.1 Request EBM

Example 25-18 shows two rows: one for the Process and one for the Request EBM Message involved in the process.

Example 25-18 Request EBM for Request-Response Use Case

<BusinessScope>
<ID>Siebel- Portal-Get -Account-Balance</ID>
<InstanceID>GETACCTBAL/1001</InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>GetAccountBalance</
EnterpriseServiceOperationName>
  <BusinessScope>
  <BusinessScope>
<ID> AccountBalanceReqMessage </ID>
<InstanceID> ACCTBALMSG/9001[the EBMID in the top element to be used here] 
</InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>GetAccountBalance
</EnterpriseServiceOperationName>
</BusinessScope>

25.6.5.2 Response EBM

Example 25-19 shows two rows: one for the process and one for the Response EBM Message involved in the process.

Example 25-19 Response EBM for Request-Response Use Case

<BusinessScope>
<ID>Siebel- Portal-Get -Account-Balance</ID>
<InstanceID>GETACCTBAL/10 01</InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>GetAccountBalance
</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID>] AccountBalanceResMessage </ID>
<InstanceID> ACCTBALMSG/9002[the EBMID in the top element to be used here 
</InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>GetAccountBalance</
EnterpriseServiceOperationName>
</BusinessScope>

25.6.6 Use Case: Asynchronous Process

SyncProduct: Portal sends an async message to Siebel to sync the product details, as shown in Figure 25-13.

Figure 25-13 Use Case: Asynchronous Process

Use Case: Asynchronous Process

25.6.6.1 Request EBM

Example 25-20 shows two rows: one for the process and one for the Request EBM Message involved in the process.

Example 25-20 Request EBM for Asynchronous Use Case

<BusinessScope>
<ID>Portal-Siebel-Product-Sync</ID>
<InstanceID>PRODSYNC/1003</InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>ProductEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>SyncProduct</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID>  ProductSyncReqMessage </ID>
<InstanceID> PRODSYNCREQ/9003 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>ProductEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>SyncProduct</EnterpriseServiceOperationName>
</BusinessScope

25.6.7 Use Case: Synchronous Process with Spawning Child Processes

ProcessOrder: Siebel sends an order. It first spawns CreateAccount in the portal, and then it processes the order in the portal, as shown in Figure 25-14.

Figure 25-14 Synchronous Process with Spawning Child Processes

The image is described in the surrounding text

Figure 25-15 illustrates the ProcessOrder flow.

Figure 25-15 ProcessOrder flow

The image is described in the surrounding text

Message 1: Create Account Request EBM

Example 25-21 shows four rows:

  • One for the process

  • One for the Create Account Request Message in the process

  • One for the create customer request message in the process (spawned immediate child)

  • One for the create customer response message in the process (spawned immediate child)

Example 25-21 Create Account Request EBM

<BusinessScope>
<ID> Portal-Account-Creation </ID>
<InstanceID> CREATEACCT/1008 </InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Account-Request-Message </ID>
<InstanceID> CREATEACCTREQMSG/9008 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Customer-Request-Message </ID>
<InstanceID> CREATECUSTREQMSG/9009 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Customer-Response-Message </ID>
<InstanceID> CREATECUSTRESPMSG/9021 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessInstruction>

Message 2: Create Account Response EBM

Example 25-22 shows two rows:

  • One for the process

  • One for the Create Account Response Message in the process

Example 25-22 Create Account Response EBM

<BusinessScope>
<ID> Portal-Account-Creation-Response </ID>
<InstanceID> CREATEACCTRESP/1008 </InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Account-Response-Message </ID>
<InstanceID> CREATEACCTRESPMSG/9020 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>

Message 3: Create Customer Request EBM

Example 25-23 shows two rows:

  • One for the process

  • One for the Create Customer request message in the process

Example 25-23 Create Customer Request EBM

<BusinessScope>
<ID> Oracle-Customer-Create </ID>
<InstanceID> CREATECUST/1009 </InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Customer-Request-Message </ID>
<InstanceID> CREATECUSTREQMSG/9009 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessScope>

Message 4: Create Customer Response EBM

Example 25-24 shows two rows:

  • One for the process

  • One for the Create Customer response message in the process

Example 25-24 Create Customer Response EBM

<BusinessScope>
<ID> Oracle-Customer-Create-Response </ID>
<InstanceID> CREATECUSTRESP/10 09 </InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>        
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Customer-Response-Message </ID>
<InstanceID> CREATECUSTREQMSG/9021 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>CustomerEBS</EnterpriseServiceName>    
<EnterpriseServiceOperationName>CreateCustomer</EnterpriseServiceOperationName>
</BusinessScope>

Message 5: ProcessOrder Request EBM

Example 25-25 shows four rows:

  • One for the process

  • One for the Process Order Request Message in the process

  • One for the create account request message in the process (spawned immediate child)

  • One for the create account response message in the process (spawned immediate child)

Example 25-25 ProcessOrder Request EBM

<BusinessScope>
<ID>End-to-End-Order-Processing </ID>
<InstanceID> ORDPROCESSING/1004 </InstanceID> 
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> 
<EnterpriseServiceName>OrderEBS</EnterpriseServiceName>
<EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Process-Order-Request-Message </ID>
<InstanceID> PROCESSORDERREQMSG /9004 </InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode> 
<EnterpriseServiceName>OrderEBS</EnterpriseServiceName>
<EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID>Create-Account-Request-Message </ID>
<InstanceID> CREATEACCTREQMSG /9005 </InstanceID> 
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Create-Account-Response-Message </ID>
<InstanceID> CREATEACCTRESPMSG /9020</InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>AccountEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>CreateAccount</EnterpriseServiceOperationName>
</BusinessScope>

Message 6: Process Order Response EBM

Example 25-26 shows two rows:

  • One for the process

  • One for the Process Order Response in the process

Example 25-26 Process Order Response EBM

<BusinessScope>
<ID>End-to-End-Order-Processing </ID>
<InstanceID> ORDPROCESSING/1004 </InstanceID>
<BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode>
<EnterpriseServiceName>OrderEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName>
</BusinessScope>
<BusinessScope>
<ID> Process-Order-Response-Message</ID>
<InstanceID> PROCESSORDERRESPMSG /9019</InstanceID>
<BusinessScopeTypeCode>Message</BusinessScopeTypeCode>
<EnterpriseServiceName>OrderEBS</EnterpriseServiceName>  
<EnterpriseServiceOperationName>ProcessOrder</EnterpriseServiceOperationName>
</BusinessScope>

25.6.8 EBMTracking

EBMTracking contains tracking information about each node that the EBM has been through, a shown in Figure 25-16. EBMTracking may appear multiple times, once for each execution unit it passes through.

Figure 25-16 Structure of the EBMTracking element

Structure of the EBMTracking element

25.6.8.1 SequenceNumber

This element contains the sequence number of the node the EBM has been through.

25.6.8.2 ExecutionUnitID

This element contains the ID of the execution unit, node, or process ID.

25.6.8.3 ExecutionUnitName

This element contains the fully qualified name of the execution unit, node, or process ID.

25.6.8.4 ImplementationCode

This element contains the category of the execution unit, which indicates the type of the execution unit such as BPEL, Mediator, or Java Service.

25.6.8.5 ActivityDateTime

This element contains the timestamp indicating when the EBM was processed by the execution unit. The timestamp should be presented in UTC, which can be presented in current datetime, and GMT offset as: yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?

25.6.8.6 When to Populate EBM Tracking Information

Add an EBMTracking entry, as shown in Example 25-27, to the EBM header whenever a message is processed by a service.

This section should be populated when:

  • Transforming a request ABM into an EBM in a requester ABC implementation service.

  • Transforming a response ABM into an EBM is a provider ABC implementation service.

  • The message passes through a BPEL process.

Example 25-27 Populating EBM Tracking Information

<EBMTracking>
<SequenceNumber>1</SequenceNumber>
<ExecutionUnitID>6 8 56 8</ExecutionUnitID>
<ExecutionUnitName>{http://xmlns.oracle.com/ABCSImpl/Siebel/Invoice/v0}
QueryInvoiceSiebelReqABCSImpl</ExecutionUnitName>
<CategoryCode>BPEL</CategoryCode>
<ActivityDateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>
<EBMTracking>
<SequenceNumber>2</SequenceNumber>
<ExecutionUnitID>4435</ExecutionUnitID>
<ExecutionUnitName>OrderEBS</ExecutionUnitName>
<ExecutionUnitName>{http://xmlns.oracle.com/EnterpriseServices/Core/Invoice/v0}
QueryInvoiceEBS</ExecutionUnitName>
<CategoryCode>ESB</CategoryCode>
<ActivityDateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>
<EBMTracking>
<SequenceNumber>3</SequenceNumber>
<ExecutionUnitID>6 8 594</ExecutionUnitID>
<ExecutionUnitName>{http://xmlns.oracle.com/ABCSImpl/Portal/Invoice/v0}Query
InvoicePortalProvABCSImpl</ExecutionUnitName>
<CategoryCode>BPEL</CategoryCode>
<Activity DateTime>2 001-12-17T09:30:47-05:00</ActivityDateTime>
</EBMTracking>

25.6.9 Custom

You can extend the custom types to add any extra elements or attributes you may need. You can also take advantage of the XSLT file extensibility features to add the necessary code to either populate or read values or both from the custom section.