Oracle® Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) E17364-02 |
|
![]() Previous |
![]() Next |
This chapter 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:
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.
Oracle Application Integration Architecture (AIA) leverages canonical patterns and direct patterns to connect applications for implementing business processes.
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 23-1 illustrates how a canonical pattern is implemented in AIA.
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 22, "Using Oracle Data Integrator for Bulk Processing."
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 23-2 shows the layout of the XSLT Mapper.
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.
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.
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 23-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 23-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>
Transformation logic and xpath should be designed with the possibility of missing or empty elements, as shown in Example 23-2.
Example 23-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.
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 23-3, and the source node does not exist in the input document, then an empty node is created in the target document.
Example 23-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 23-4.
Example 23-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>
ABCS and XSL scripts should not be hard-coded to work against one specific logical application instance, as shown in Example 23-5. No hard-coded system IDs should exist in XSL Scripts and ABCS.
Example 23-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 23-6.
Example 23-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>
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.
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.
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 23.6, "Introducing EBM Header Concepts".
To make transformation maps extension aware:
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
.
Define empty named templates in the extension file for every component in the message.
Include the extension file in the core transformation file.
Add a call-template for each component in core transformation.
Enable the transformation to accommodate transformations for custom element as shown in Example 23-7.
Example 23-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>
Mapping rules pertaining to customer-specific schema extensions are defined in these xsl extension templates.
To make the transformation template industry extensible:
Put the extension templates into a separate transformation file.
Import from the main transformation file. Example 23-8 shows the industry extensible transformation template.
Example 23-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>
This section discusses DVMs, cross-references, and naming standards, and when to use them.
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 29, "Oracle AIA Naming Standards for AIA Development."
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.
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. This means that 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, we recommend key concatenation:
{Key1}::{Key2}::Key3
Most requester ABCSs use the following logic in the transformations:
Look up in Xref for an existing common ID corresponding to the application ID.
If common ID is not found, then generate a new ID and populate the Xref table with the new ID.
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 23-1 lists a cross referencing configuration implemented in the Product synchronization scenario between the Portal BRM and Siebel CRM systems
Table 23-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.
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 29, "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.
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 23-3 illustrates the schema definition for Identification Type.
The Identification Type structure allows you to capture three specific identifiers plus one more general identifier for a single object. Table 23-2 describes each of the identifiers:
Table 23-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 23-3 describes the purpose of each of the attributes.
Table 23-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 23-4 illustrates the Business Component ID:
Example 23-9 provides an example of how the BusinessComponentID is populated in the EBM.
Example 23-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>
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.
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 23-5 illustrates the components of an EBM header:
The following sections provide details about each of the components.
This section discusses the standard elements in a message header.
This element contains a GUID to uniquely identify the EBM, as shown in Example 23-10. The GUID is generated using a provided standard XPath function.
XPath function to generate GUID: orcl:generate-guid()
This element contains the fully qualified name of the EBO in the notation: {namespaceURI}localpart
, as shown in Example 23-11.
This element contains the originating request GUID that uniquely identifies the originating request ID, as shown in Example 23-12. The EBS populates this field in the response message by extracting it from the request message.
This element contains a timestamp that reflects when the EBM was created, as shown in Example 23-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()
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
.
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.
To populate the message processing instruction
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 23-15.
These fields are currently populated by the CAVS.
Usually, the fields are populated in the SOAP Header before initiating a testing request.
The Sender contains information about the originating application system, as shown in Figure 23-6.
Table 23-4 provides details about each element in the Sender element.
Table 23-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 23-16 to populate this value. |
Description |
This is the long description of the Sender System. ReqABCSImpl should call the API detailed in Example 23-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 23-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 23-16 to populate this value. |
Example 23-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>
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.
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.
To populate sender system information:
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
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.
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.
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 23-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.
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.
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.
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.
Table 23-5 describes the elements in the ESBHeaderExtension element.
Table 23-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 23-8 illustrates the structure of the ESBHeaderExtension element.
This component stores the identifier information of the sender objects and the corresponding cross-reference identifier, as shown in Figure 23-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.
Table 23-6 describes the elements in the ObjectCrossReference element.
Table 23-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. |
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.
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.
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 12.6, "Implementing the Fire-and-Forget Message Exchange Pattern."
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 you must define the appropriate target system information in this element if you need to override the routing rule. The overriding target system information is applicable to all the objects in the data area. Note that 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 23-10.
Use this element, shown in Example 23-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.
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 more than one version is supported on the system.
This field, as seen in Example 23-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.
This is the complex type that you can extend to add your own elements when needed.
Example 23-17 shows an example of target element code.
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 23-11 describes how this works.
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.
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.
This element indicates the kind of business scope. Values are:
BusinessScope
(UMM)
BusinessService
(for ebXML)
Message
ReqABCSImpl populates this value.
Name of the EBS where this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.
Name of the action of the EBS this message belongs. Known to the message creator, be it ABCS or EBS. ReqABCSImpl populates this value.
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.
GetAccountBalance: Sends a request message with account number as input and receives account balance as response, as shown in Figure 23-12.
Example 23-18 shows two rows: one for the Process and one for the Request EBM Message involved in the process.
Example 23-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>
Example 23-19 shows two rows: one for the process and one for the Response EBM Message involved in the process.
Example 23-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>
SyncProduct: Portal sends an async message to Siebel to sync the product details, as shown in Figure 23-13.
Example 23-20 shows two rows: one for the process and one for the Request EBM Message involved in the process.
Example 23-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
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 23-14.
Figure 23-15 illustrates the ProcessOrder flow.
Message 1: Create Account Request EBM
Example 23-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 23-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 23-22 shows two rows:
One for the process
One for the Create Account Response Message in the process
Example 23-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 23-23 shows two rows:
One for the process
One for the Create Customer request message in the process
Example 23-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 23-24 shows two rows:
One for the process
One for the Create Customer response message in the process
Example 23-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 23-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 23-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 23-26 shows two rows:
One for the process
One for the Process Order Response in the process
Example 23-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>
EBMTracking contains tracking information about each node that the EBM has been through, a shown in Figure 23-16. EBMTracking may appear multiple times, once for each execution unit it passes through.
This element contains the sequence number of the node the EBM has been through.
This element contains the fully qualified name of the execution unit, node, or process ID.
This element contains the category of the execution unit, which indicates the type of the execution unit such as BPEL, Mediator, or Java Service.
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)?
Add an EBMTracking entry, as shown in Example 23-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 23-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>