Introduction to Enterprise Business Messages

(For more resources on Oracle, see here.)

Before we jump into the AIA Enterprise Business Message (EBM) standards, let us understand a little more about Business Messages. In general, Business Message is information shared between people, organizations, systems, or processes. Any information communicated to any object in a standard understandable format are called messages.

In the application integration world, there are various information-sharing approaches that are followed. Therefore, we need not go through it again, but in a service-oriented environment, message-sharing between systems is the fundamental characteristic. There should be a standard approach followed across an enterprise, so that every existing or new business system could understand and follow the uniform method. XML technology is a widely-accepted message format by all the technologies and tools.

Oracle AIA framework provides a standard messaging format to share the information between AIA components.

Overview of Enterprise Business Message (EBM)

Enterprise Business Messages (EBMs) are business information exchanged between enterprise business systems as messages. EBMs define the elements that are used to form the messages in service-oriented operations. EBM payloads represent specific content of an EBO that is required to perform a specific service. In an AIA infrastructure, EBMs are messages exchanged between all components in the Canonical Layer. Enterprise Business Services (EBS) accepts EBM as a request message and responds back to EBM as an output payload. However, in Application Business Connector Service (ABCS), the provider ABCS accepts messages in the EBM format and translates them into the application provider's Application Business Message (ABM) format. Alternatively, the requester ABCS receives ABM as a request message, transforms it into an EBS, and calls the EBS to submit the EBM message. Therefore, EBM has been a widely-accepted message standard within AIA components.

The context-oriented EBMs are built using a set of common components and EBO business components. Some EBMs may require more than one EBO to fulfill the business integration needs. The following diagram describes the role of an EBM in the AIA architecture:

EBM characteristics

The fundamentals of EBM and its characteristics are as follows:

  • Each business service request and response should be represented in an EBM format using a unique combination of an action and an EBO instance.
  • One EBM can support only one action or verb.
  • EBM component should import the common component to make use of metadata and data types across the EBM structure.
  • EBMs are application interdependencies. Any requester application that invokes Enterprise Business Services (EBS) through ABCS should follow the EBM format standards to pass as payload in integration.
  • The action that is embedded in the EBM is the only action that sender or requester application can execute to perform integration.
  • The action in the EBM may also carry additional data that has to be done as part of service execution. For example, the update action may carry information about whether the system should notify after successful execution of update.
  • The information that exists in the EBM header is common to all EBMs. However, information existing in the data area and corresponding actions are specific to only one EBM.
  • EBM headers may carry tracking information, auditing information, source and target system information, and error-handling information.
  • EBM components do not rely on the underlying transport protocol. Any service protocols such as HTTP, HTTPs, SMTP, SOAP, and JMS should carry EBM payload documents.

Exploring AIA EBMs

We explored the physical structure of the Oracle AIA EBO in the previous chapter; EBMs do not have a separate structure. EBMs are also part of the EBO's physical package structure. Every EBO is bound with an EBM. The following screenshot will show the physical structure of the EBM groups as directories:

Intoduction to Enterprise Business Messages

As EBOs are grouped as packages based on the business model, EBMs are also a part of that structure and can be located along with the EBO schema under the Core EBO package.

(For more resources on Oracle, see here.)

Structure of EBM

In Oracle AIA, EBOs and EBMs follow standard structures to meet best practice in business integration. EBMs follow a messaging architecture for all business integration requirements. The following screenshot will show the structure of an EBM (for example, a Bank Account EBM): QueryBankAccountEBMType

Intoduction to Enterprise Business Messages

Basically EBMs are divided into two parts, (EBM) Header and Data Area. The primary structure of EBM includes EBM Header, action to be executed using the given data (Data Area), and global attributes. Every service request and response is presented in the EBM by a combination of operation and instance. EBM cannot process more than one type of operation. For example, both query and update operations cannot be executed in the same message or a single request. In AIA, EBM carries the message payload in both service requests and responses. Each EBM is associated with a specific EBO and thus an EBO package structure includes the EBM schema as well. Let us explore EBM and EBO physical structure and references further.

For our case, we will explore Bank Account EBO and EBM in its physical package location. Go to $AIA_Home/AIAMetaData\AIAComponents\ EnterpriseObjectLibrary\Core\EBO\BankAccount\V1 folder. In this folder we can find both BankAccountEBO and BankAccountEBM schema definitions. Open the BankAccountEBM in the JDeveloper.

The first part of the EBM includes the reference schema elements of include and import parts where we can see the schema location reference of BankAccountEBO. xsd in the xsd:include element shown as follows:

<xsd:include schemaLocation="BankAccountEBO.xsd"/> .......... .......... <xsd:import namespace=" Core/Custom/EBO/BankAccount/V1" schemaLocation="../../../Custom/EBO/ BankAccount/V1/CustomBankAccountEBO.xsd"/> ........... ........... <xsd:annotation> <xsd:documentation> <svcdoc:EBO> <svcdoc:Description>BankAccount…</svcdoc:Description> <svcdoc:Type>EBM</svcdoc:Type> <svcdoc:Industry/> <svcdoc:EBOName>BankAccountEBO</svcdoc:EBOName> </svcdoc:EBO> </xsd:documentation> </xsd:annotation>

The preceding script shows how the common and custom EBOs are included in the EBM.

EBM global attributes

Each and every EBM has two global attributes apart from EBM Header and Data Area elements. They are used to maintain information about that EBM. These two attributes are shown in the following diagram:

Intoduction to Enterprise Business Messages

  • versionID: This attribute is used to maintain the version number of the EBM. Since Oracle AIA, EBM, and EBO supports many versions of business objects and messages, it is necessary to maintain the version number as a global attribute.
  • languageCode: This attribute is used to hold the EBM message language information from the Meta.xsd schema definition. Oracle AIA supports carrying a variety of language-specific information through EBM and EBOs. The default language code is en-US.


In Oracle AIA, every EBM should have a header in addition to a data area. An EBM header basically provides information to identify the source and target of the message, to log and trace the messages, and additional information to help in the routing and processing of the message. Understanding EBM and EBM header is very important in order to handle different integration scenarios. The goal of the EBM header is to hold the information that can be used for:

  • Audit information
  • Header errors and traces
  • Source and target system information

The following image will show the EBM header from one of the Oracle AIA EBMs:

Intoduction to Enterprise Business Messages

EBMHeader components

EBM header components are grouped as two sets of components. They are primary header components and secondary header components. The primary header components hold raw information about the EBM payload. However, the secondary components of the EBM header holds information about the messages, systems, and processes involved in the EBM payload.


This element contains identity information about the EBM. This element's data type should be IdentifierType. An ID can be generated by using the XPath function , shown as follows:

orcl:generate-guid(). <EBMHeader> <EBMID>8883838383838383883838383838</EBMID> . . . </EBMHeader>


This element contains the name of the EBM. This element's data type should be NameType:

<EBMHeader> <EBMName>...</EBMName> ...... </EBMHeader>


This element contains the fully-qualified EBO name in the following notation. The datatype of this element is NameType:

{namespaceURI}localpart <EBMHeader> <EBOName>{ BankAccount/V1}CreateAccount</EBOName> .. </EBMHeader>


As the name expresses the meaning, this element contains a timestamp about the EBM when created. This element supports the DateTimeType data type . This timestamp should be UTC, which is also used to present the current timestamp and GMT offsets. The current timestamp can be generated by using the XPath expression function current-datetime()


This element contains the GUID that identifies the service requester identity and the unique request ID. The data type for the request ID should be IdentifierType. The enterprise business service responds back this request ID as part of the response:

<EBMHeader> <CreationDateTime>2011-08-02T10:19:23.45-04:00</CreationDateTime> <RequestEBMID>...</RequestEBMID> . . . </EBMHeader>


The element contains the verb code of the EBM. The data type supported by this element is CodeType. Some of the common verb codes used in EBM are Query, Create, Delete, and so on:

<EBMHeader> <VerbCode >Query</VerbCode> . . . </EBMHeader> The overall EBM Header structure should be looks like below. <EBMHeader> <EBMID>8883838383838383883838383838</EBMID> <EBMName>ProcessFulfillmentOrderUpdateEBM</EBMName> <EBOName>{ FulfillmentOrder/V1}FulfillmentOrderEBO</EBOName> <CreationDateTime>2011-08-02T10:19:23.45-04:00</CreationDateTime> <RequestEBMID>61e315eb-a1e0-4d14-89aa-fa4ff282c4b6<RequestEBMID> <VerbCode >process</VerbCode>

EBMHeader child components

In this section, we are going to explore some of the common header and child components that are used in the EBM.


This element contains information or instructions about the message processing method. This element is used to identify whether this instance of message should be considered as a production message, and if it should go through standard process or is it a test level message and should just pass the test case. Message processing instruction element has the following three attributes:

  • EnvironmentCode
  • DefinitionID
  • InstanceID

EnvironmentCode: This attribute could be set as Composite Application Validation System (CAVS) or PRODUCTION. The default value of this attribute should be PRODUCTION. If value of this attribute is set as PRODUCTION then it means the request must be sent to the concrete service endpoint. If it is a CAVS then service request should be sent to the CAVS simulator.

Note that the Composite Application Validation Systems (CAVS) are testing simulator utility tools provided by Oracle AIA to validate the business integration created by using Oracle AIA FP.

DefinitionID: This property is used to define the test definition ID created in the CAVS. This attribute property should be populated with the value of property from AIAConfigurationProperties.xml.

Note that the AIAConfigurationProperties.xml can be located after deploying AIA in the SOA Domain environment. However, the template version of the configuration properties file can be located under the $AIA_Home\AIAMetaData\config folder.

InstanceID: This attribute should contain information about the instance of the message processing instruction. This attribute may be populated automatically (may be through Xpath) by the AIA infrastructure. Please make sure that the corecom namespace is declared properly in the schema.

This is explained in the following example:

<BusinessScope> <ID> Banking-Account-Creation </ID> <InstanceID> BANKACCT/10002121 </InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>BankAccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName> CreateBankAccount</EnterpriseServiceOperationName> </BusinessScope>

Sender element

This element is used to contain information about the service requester application. The Sender element has a separate set of sub elements to capture and carry forward elaborate information about the requesting application:

Intoduction to Enterprise Business Messages

The following table shows details about each sub element of the Sender element:

Attribute Name



It contains sender system's unique

identification code. It is a mandatory



Description about the sender system.


This element contains the IP address of

the sender system.


This ID can be used to identify the

unique message sent by the sender



This is a task identification code.

This elementhould be used to generate

the message by the sender system.


Name of the application business

component service.


This element should have information

about the originating application.


Sender application's contact name.


Sender application's contact e-mail ID.


Sender application's contact phone number.


This element contains more detail

about the EBM header. It acts as an

extension of the EBM header. This

element has attributes such as Name,

DataTypeCode and Value.


This element contains an identifier of

the sender object and corresponding

cross-reference identifier. This

element can be used for bulk processing



This element is a complex type which

can be extended to use custom elements.

The following sample format shows the header elements of the EBM structure:

<corecom:ID>PPLS_101</corecom:ID> <corecom:Description/> <corecom:IPAddress/> <corecom:SenderMessageID>8989898989898989898889</corecom: SenderMessageID> <corecom:CallingServiceName>{ SamplePeopleApp} CreateCustomerSiebelInputFileReader</corecom:CallingServiceName> <corecom:Application> <corecom:ID/> <corecom:Version>1.0</corecom:Version> </corecom:Application> <corecom:ContactName/> <corecom:ContactEmail/> <corecom:ContactPhoneNumber/> </corecom:Sender>

Target Element

The Target element will be used to send the target system information while sending the EBM. Usually, the Oracle Mediator will be used to define routing rules in the composite application. So, all the messages received from the source system should follow the same routing rule. But for the bulk processing scenario, there may be a use case where the routing rules should be overridden with exception. Such exceptional routing rule could be handled by this target element:

<corecom:Target> <corecom:ID>PORTAL_101</corecom:ID> <corecom:OverrideRoutingIndicator>...</corecom:OverrideRoutingIndic ator> <corecom:ServiceName>Service1</corecom:ServiceName> <corecom:ApplicationTypeCode>PORTAL_101</ corecom:ApplicationTypeCode> </corecom:Target>


The BusinessScope section of the EBM header captures information related to the scope of the business specification. As per Oracle the AIA standard, every EBM must have at least two BusinessScope elements. One of the BusinessScope elements must be described at the end to end business process that the EBM engaged. The second one should describe as the message associated in the process flow:

Intoduction to Enterprise Business Messages

The following elements are used in the business scope as part of EBM header:

  • ID: This element is an optional identifier for the execution service contract.
  • InstanceID: This element is used to carry unique identification for a particular scope instance. This could be an alpha numeric code provided by application.
  • BusinessScopeTypeCode: This element should hold the information about the business scope of the particular message instance. This value should be BusinessScope or BusinessService or Message.
  • EnterpriseServiceName: This is basically the message creator name. It could be either ABCS or EBS name.
  • EnterpriseServiceOperationName: This element should store the name of the EBS operation that triggered this message.
  • Custom: This is a custom element, which can be extended to carry any other information along with scope details.


As the element name expresses the purpose, the EBMTracking elements are used to track the message passing through the various nodes of integration. So the tracking element may populate multiple times in the EBM in order to record all the execution units that the message passes through. The following are the elements of EBMTracking.

  • SequenceNumber: This element contains the sequence number of the execution node.
  • ExecutionUnitID: This element contains the ID of the execution node or process.
  • ExecutionUnitName: This element contains the execution unit name that the EBM passes through.
  • ImplementationCode: This element references the type of the execution such as BPEL, Mediator, or Java Service.
  • ActivityDateTime: This element records the execution date and time.

The below sample schema model shows the structure of the EBMTracking:

<EBMTracking> <SequenceNumber>1</SequenceNumber> <ExecutionUnitID>110</ExecutionUnitID> <ExecutionUnitName>{ BankAccount/v1}Query BankPortalABCSImpl</ExecutionUnitName> <CategoryCode>Mediator</CategoryCode> <ActivityDateTime>..</ActivityDateTime> </EBMTracking>


In a Web Service-based integration approach, the fault element is used to populate exception that occurs during message transfer. Integration is more vulnerable due to the independence of each system. In order to build more robotic integration, exception and error should be properly captured, and necessary action should be taken to handle it. In Oracle AIA EBM, the FaultNotification element can be used to populate the fault messages while transferring EBM between ABCS and EBS.


This element contains information about the batch processes. This element helps to capture collection of instances, which is treated as one entity or processed as a group.


This element contains the sending and receiving trading partner information for the B2B integration document flows. This element introduced an Oracle AIA FP 11g along with the B2B integration feature. This element has child elements, which are as follows:

  • SendingTradingPartner: This element contains information about sending a trading partner.
  • ReceiverTradingPartner: This element contains information about EBM receiver trading partner.


This element is used to extend the EBM header by adding an extra custom element, which it may require. However, we have to ensure that the data type used by custom elements should be in compliance with common data types defined by Oracle AIA FP.


So far we have seen a very elaborative view of the EBM header and its elements. DataArea is also an important part of EBM. In EBM, DataArea contains information about the message to be processed along with necessary action identifications. Also the DataArea will contain the business objects and references. In AIA, the business objects are instances of EBO. The following image will show a high level view of DataArea in EBM:

Intoduction to Enterprise Business Messages

One of the fundamental rules of EBM is that each message request and response should be represented in an EBM by a unique action and an EBO type instance. According to that rule, each DataArea (DataArea element is sequential) should have one element that represents the action to be taken and another element should represent the context-specific object required to execute that action. So for each service, there should be a request EBM object and response EBM object.

Let us take the example of the create bank account service and its EBMs. In create bank account service request message, DataArea of CreateBankAccountResponseEBMType has two elements in a sequence. One is corecom:CreateRequestResponse and another one is the CreateBankAccount object and its attribute. In this, CreateBankAccount is an object of CreateBankAccountType EBO.

Similarly, in the response EBM of create bank account, there should be an action element that should represent corecom:CreateResponse and a response object of the CreateBankAccountType element.

The following diagram shows the typical EBM message structure:

Intoduction to Enterprise Business Messages

EBM use cases

In this section, we are going to explore one of the message exchange types and how EBM supports these scenarios.

EBM request and response message

The most common message exchange model that every integration project might have is request-response type. The requester requests information from another system and the responder system responds with the information based on the request parameters. This model is typically used in the web systems.

Intoduction to Enterprise Business Messages

From the preceding diagram, we can see that source ABCS system sends CreateBankAccountEBM to the Bank Account EBS service using BankAccountEBO. The request has been sent to the target system by EBS in the request EBM format. The target ABCS system generates the output in the BankAccountResponseEBM with BankAccountEBO. The same response message forwards back to the source ABCS service through bank account service. The diagram shows the simple version of EBM use case in the AIA model. Basically, it forces to use the standard format within AIA implementation except the area where application requires ABM format.

The following code shows the request EBM format:

<BusinessScope> <ID>Source System Bank Account</ID> <InstanceID>CREATEBankAccount/10081</InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>BankAccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateBankAccount</ EnterpriseServiceOperationName> <BusinessScope> <BusinessScope> <ID>CreateBankAccountReqMessage</ID> <InstanceID> ACCTMSG/10101</InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>BankAccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateBankAccount </EnterpriseServiceOperationName> </BusinessScope>

The following code shows the response EBM format:

<BusinessScope> <ID>Source System Bank Account</ID> <InstanceID>CREATEBANKACCT/10081</InstanceID> <BusinessScopeTypeCode>BusinessScope</BusinessScopeTypeCode> <EnterpriseServiceName>BankAccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateBankAccount</ EnterpriseServiceOperationName> <BusinessScope> <BusinessScope> <ID>] CreateBankAccountResMessage</ID> <InstanceID> ACCTMSG/10110</InstanceID> <BusinessScopeTypeCode>Message</BusinessScopeTypeCode> <EnterpriseServiceName>BankAccountEBS</EnterpriseServiceName> <EnterpriseServiceOperationName>CreateBankAccount</ EnterpriseServiceOperationName> </BusinessScope>

In our use case, if we notice the request EBM and response EBM, then the primary difference is the message ID. The message ID is considered as a key change in the EBM header, which will help to keep track of the difference between request and response EBMs. We are going to explore EBM and EBO further in the next chapter, along with EBS.


So far we have seen fundamental details about the Oracle AIA EBO and EBM structures and their purpose. EBO and EBM are fundamentals of the Oracle AIA data integration. In the following chapter we are going to see more details about Enterprise Business Services (EBS) and Application Business Connector Services (ABCS), which are used to create service interfaces. EBO and EBM are populated as payload in the EBS and ABCS. Before we proceed to further chapters, it is good to refresh our knowledge in the fundamentals of Web Services and Interfaces since EBS and ABCS are based on service interface and contracts.

You've been reading an excerpt of:

Oracle Application Integration Architecture (AIA) Foundation Pack 11gR1: Essentials

Explore Title