Working with Message Transformations 23-15
Routing.[PartnerlinkName].RouteToCAVS property is set to true in AIAConfigurationProperties.xml.
23.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.
23.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 simulationtesting mode, as shown in Example 23–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 23–15 Message Processing Instruction Population
corecom:MessageProcessingInstruction corecom:EnvironmentCode
xsl:text disable-output-escaping=noProductionxsl:text corecom:EnvironmentCode
corecom:MessageProcessingInstruction
23.6.2 Sender
The Sender contains information about the originating application system, as shown in Figure 23–6
.
23-16 Developers Guide for Oracle Application Integration Architecture Foundation Pack
Figure 23–6 Structure of the Sender Element
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.
Working with Message Transformations 23-17
Example 23–16 Sender Element Code Sample
corecom:Sender corecom:IDSEBL_01corecom:ID
corecom:Description corecom:IPAddress
corecom:SenderMessageID33303331343032313534393138393830corecom: SenderMessageID
corecom:CallingServiceName{http:xmlns.oracle.comSampleSiebelApp} CreateCustomerSiebelInputFileReadercorecom:CallingServiceName
corecom:Application corecom:ID
corecom:Version1.0corecom:Version corecom:Application
corecom:ContactName corecom:ContactEmail
corecom:ContactPhoneNumber corecom:Sender
23.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.
23.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.
ApplicationID 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.
ApplicationVersion 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.
Table 23–4 Cont. Elements in the Sender Element
Element Description
23-18 Developers Guide for Oracle Application Integration Architecture Foundation Pack
23.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 IDCode and then
return the data as an XML Node-Set:
ebh:getEBMHeaderSenderSystemNodesenderSystemCode 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.
23.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.
23.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 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.
23.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.
23.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.
23.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
Working with Message Transformations 23-19
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 23–7 Structure of the ESBHeaderExtension Element
Table 23–5 describes the elements in the ESBHeaderExtension element.
Figure 23–8 illustrates the structure of the ESBHeaderExtension element.
Figure 23–8 Structure of the ESBHeaderExtension Element
23.6.2.9 ObjectCrossReference
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–5 Elements in the ESBHeaderExtension Element
Element Description
ESBHeaderExtensionName 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.
ESBHeaderExtensionDataTypeCode ESB Header element data type is populated by
source ABCS. ESBHeaderExtensionValue
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.
23-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack
Figure 23–9 Structure of the ObjectCrossReference Element
Table 23–6 describes the elements in the ObjectCrossReference element.
23.6.2.10 How to Add Object Cross Reference information in the Sender System Information
To add a cross-reference entry in the sender systems 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.
Table 23–6 Elements in the ObjectCrossReference Element
Element Description
ObjectCrossReferenceSenderObjectIdentificat ion
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. ObjectCrossReferenceSenderObjectIdentificat
ionID Identifies the object type of the sender system
for example ORDER ReqABCSImpl has this information and populates this value
ObjectCrossReferenceSenderObjectIdentificat ionName
This identifies the description of the sender system, for example, Purchase Order.
ReqABCSImpl has this information and populates this value.
ObjectCrossReferenceSenderObjectIdentificat ion ContextID
This identifies the sender systems object identifiers. If the senders 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.
ObjectCrossReferenceEBOID This is the corresponding cross-reference
identifier stored in the integration layer. ReqABCSImpl has this information and
populates this value.
Working with Message Transformations 23-21
– 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 systems object identifiers. If the senders
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.
23.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.
23.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 10.6, Implementing the Fire-and-Forget Message Exchange Pattern.
23.6.3 Target
