Saturday, 24 September 2011

Oracle Application Integration Architecture Enterprise Business Objects (EBO) Concepts – Concepts, Structure, Terminologies and Design Rules

Support for Standards
The Enterprise Business Object (EBO) structure and design is based primarily on the UN/CEFACT
XML Naming and Design Rules. It is also based on the XML Naming and Design Rules provided by
the Open Application Group and UN/CEFACT Core Component Technical Specification. This
UN/CEFACT –Core Components Technical Specification is employed wherever business
information is being shared or exchanged amongst and between enterprises, governmental agencies,
and/or other organizations in an open and worldwide environment. While these specifications
provide a base for design and structure of business objects, they have a larger scope in relation to
mapping rules, rule-by-rule profiling, and more.
Industry Best Practices
One of the components of AIA is the Reference Process Models. These are industry specific process
models that transcend both Oracle and partner applications. These models outline best practices in
customers’ industries and provide a model from which customers can start their process designs. In
that sense these models are similar to Oracle Business Flows with the key differences that the models
are:
• Industry specific
• Application agnostic

The Reference Process Models included in the AIA Foundation Pack follow industry best practices.
These business processes are used to integrate two or more applications through the Enterprise
Business Services/Objects layer.
Oracle AIA's Foundation Pack Extensions for Industries cater to various industry verticals including
Communications, Insurance, and Utilities. The Oracle Application Integration Architecture
Foundation Pack Extension for Communications enables the customers to simplify crossapplication
business process integrations using a productized integration solution designed for reusability
and configurability. With it, customers can create robust integrations on a standardized
framework, leveraging their existing Oracle and non-Oracle application investments. To help
customers accelerate their integration implementation, AIA Foundation Pack Extension for
Communications includes various industry-specific EBOs. Communications industry-specific EBOs
include:
• Communications FulfillmentOrder
An order generated by the service provider for the goods or services purchased by a
customer. The object is used to exchange order data between central fulfillment and
participating applications other than provisioning.
• Communications ProvisioningOrder
An order generated by the product or service provider for the goods or services purchased
by a customer. The object is used to exchange order data between central fulfillment and
provisioning applications.
• Communications CreditAlert
A credit alert is raised to send updates on collection actions between CRM to BRM.
• Communications ServiceUsage

The Service Usage object is used for querying or sending billed usage information for a
service.
• Communications TroubleTicket
A Trouble Ticket is used for sending order failure information from the central fulfillment
systems to the trouble ticketing application in the context of order fallout.
These EBOs are specifically designed for Communications processes and data structure in order to
accelerate the customer’s integration efforts. They include over 200 attributes allowing the customers
to integrate their Oracle Order Management, Billing, and Customer Care systems to many different
systems within their IT environment, such as a financials system, or network operations system.
The Oracle AIA Foundation Pack Extension for Insurance enables insurance companies to
accelerate application integration, especially between claims and financial systems in order to process
claim payments, set up claim reserves, and pursue outstanding debt. It also facilitates integration with
policy administration and other systems, whether it’s Oracle or a third-party. Oracle AIA Foundation
Pack Extension for Insurance helps dramatically minimize costs and risks for insurance companies
by speeding time-to-value. The pre-built insurance claims business objects and services and
insurance-specific enhancements to horizontal objects and services, enable companies to develop
more flexible integrations that increase business and IT efficiencies, and accelerate innovation. With
Oracle AIA Foundation Pack Extension for Insurance, insurance organizations can easily adapt to
changing business needs through optimized business operations using documented insurance
business processes and simplified upgrades via common objects and services.
Utilities customers can easily leverage Oracle AIA Foundation Pack Extension for Utilities to
facilitate integration design and enable composite business processes including Concept to Launch,
Order to Bill, Meter to Cash, and Customer Self Service. These processes span a variety of
applications, including CRM for sales, marketing, and service; customer care and contact center;
customer eBilling, ePayment and eSupport; meter data management; rating, billing and collections;
and financials ERP.
The industry best practices are taken into consideration so that there is compliance to both common
and industry specific standards which is required for interoperability between heterogeneous
applications. The Enterprise Business Objects (EBOs) in the Foundation Pack Industry Extensions
can either be industry specific (e.g. only for Utilities) or can be industry extensions of Core EBOs.
The architecture allows for incorporating industry specific attributes as overlays. An industry specific
object can be created by assembling together a set of business components available at the core with
a set of industry specific components.
AIA in Business Flows
AIA is a complete integration solution for orchestrating agile, user-centric business processes across
enterprise applications. Applications Integration Architecture is responsible for providing industryspecific
solutions for composite business processes leveraging the various software assets that are
available in the Oracle portfolio. Most of these solutions encompass orchestrated process flows, as
well as pre-built data integration scenarios that are meant to seamlessly connect the systems which
were not designed to work together.
AIA offers prebuilt solutions at the data, process, and UI level delivering a more complete process
solution to business end users. All AIA components are designed to work together in a mix and
match fashion and are built for configurability, ultimately lowering the cost and burden on IT of
building, extending, and maintaining integrations. AIA products include:


• Foundation Pack: Business process composition framework that provides the architectural
and programming model, best practices, utilities, and application independent Enterprise
Business Objects and Services on which AIA users can develop standardized, crossapplication
process integrations.
• Process Integration Packs (PIPs): Pre-built, packaged integrations to accelerate the
delivery of composite business processes across both Oracle and non-Oracle applications.
• Direct Integrations: Are used for bulk processing with AIA. Direct Integrations are used
where it is appropriate to augment and support SOA integrations, such as ODI for high
volume batch data
There are numerous features/advantages of Oracle Application Integration Architecture. Some of
them are listed below:
• Defines integration architecture by adopting a service-oriented architecture.
• Leverages various existing assets found in Oracle's portfolio, as well as those of customers.
• Enables extensive access to web services provided by various applications.
• Provides a general infrastructure for consistent integrations that are also extensible and able
to respond to requests from industry strategy.
• Facilitates the use of services in orchestrated process flows.
• Allows a customer to extend various artifacts of the delivered solution.
• Accommodates a loose coupling between systems. This includes the ability to:
o Define loosely bound services that are invoked through communication protocols
that stress location transparency and interoperability.
o Define services that have implementation-independent interfaces.
o Replace one service implementation with another with no impact to the client.
• Incorporates synchronous and asynchronous communication in multi-interaction styles.
• Adopts an applications independent canonical data model to accomplish the decoupling of
data format.
Sample Use Case
It is quite easy to discuss terms in abstract, but things become simpler when a use case is used to
discuss how a solution is designed and deployed. We will use the following sample use case
throughout this paper to illustrate how you can use the Oracle Application Integration Architecture
Foundation Pack to build your own custom integrations to bring together a number of disparate
applications, both internal and external, in a service-oriented way.
In this sample application, Global Company is a retail storefront for ordering electronic devices
through a web-based client application. This diagram outlines the company’s business process for
booking and fulfilling orders:


This flow diagram illustrates the process when a new order is placed:
1. The web client sends a message to a JMS Queue which then routes the message to any
service that has registered an interest in these messages. In this case, it is the order booking
process.
2. This process sets the order to Pending, and writes the order to the order database tables. The
process then calls the customer service system to retrieve customer ID, name, address, and
credit card information, and checks the identified customer against the credit service to
verify if the customer's credit card is valid. The credit service returns the relevant rating for
the customer.
3. If credit is not approved, the process cancels the order.
4. If the order is approved, it is sent to two suppliers for their price quotes. The process
collects the quotes and selects the supplier quoting the lowest price. The process then
invokes the fulfillment service which selects the appropriate fulfillment provider based on a
business rule.
5. After the order is fulfilled, the BPEL process sets the order to Complete, and starts a
notification service, which sends the customer an email with the purchase order information.
In the sample use case, the online portal application only has the responsibility to post the sales order
message in the common AIA Enterprise Business Object format without worrying about how the
order is represented in any of the other end systems. Some of the business objects that come in play
in the use case are Sales Order, Purchase Order, Item, Invoice, etc.

To understand the value of Application Integration Architecture, it’s important to look at the key
principles associated with Service Oriented Architecture (SOA). The following are the advantages of
going to SOA:
• Standards – Compliance to both common and industry specific standards is required for
interoperability between heterogeneous applications.
• Abstraction – Reusable, modular coarse-grained business services provide rapid composite
application development and easier maintenance.
• Loosely coupled – Minimal dependencies with other applications offer durability and agility.
AIA is designed and developed on these first principles of SOA. Let’s take our order booking sample
use case and see how that business process translates into SOA based AIA.
Application Integration Architecture Schematic of Sample Use Case
This diagram shows a technical representation of the order booking sample use case implemented
using the AIA Foundation Pack:


The use case will be referred to in the creation of EBO, EBM and EBS along with extensibility

EBO Concepts
EBO, EBS and EBM Basics
The term Enterprise Business Object (EBO) refers to a data model consisting of standard business
data object definitions and reusable components representing a business object such as Sales Order,
Party, Item, Customer etc. It is the best-in-class definition of the business data, rationalized across
Oracle’s entire application portfolio and industry standards. The Enterprise Business Objects are
delivered as XML Schema Definition (XSD) files.
Enterprise Business Messages (EBMs) are the messages that are exchanged between two applications
or devices. For every EBO, there will be two schema modules – one containing the definition of the
EBO and another containing the definition of the operations that need to be performed on that
EBO (e.g. Read or Update operation).
Enterprise Business Services (EBSs) are basically coarse-grained business service interfaces for
performing a business task.
EBS Features
• Application agnostic interfaces
• Services implemented by applications or cross-functional business processes
• Standardized Enterprise Business Message as payload
o Noun – Enterprise Business Object
o Verb - service operation
o Message Header – message meta data
• Transport agnostic
• SOAP, HTTP, HTTPS, JMS
• Allows for service substitution
Business Objects
Enterprise Business Objects
EBOs are enterprise business objects based on the canonical object model. These, along with
Enterprise Business Services (EBSs), act as the cornerstones of AIA architecture.
The EBO defines a set of generic data structures that support cross-application business processes
and data integration packs, independent of the source or target applications. The model is a
composite of Application Business Objects (ABOs) and industry standards and eliminates the need
to map data directly from one application to another. EBOs contain reusable components that satisfy
the requirements of business objects from the target application data models.
Reusable EBO (Common EBO)
The term EBO refers to a data model consisting of standard business data object definitions and
reusable data components representing a business object such as Sales Order, Party, Item, Customer
etc

10
The Common EBO is an independent business concept very much like an EBO but it may be
contained (in its entirety) within the definition of another EBO and can be shared across multiple
EBOs. For example, Item is a Common EBO because it is part of the ItemComposition EBO.
The following diagram illustrates a Common EBO:


The figure illustrates that the AdvanceShipmentNotice EBO uses the ShipmentUnit Common EBO
in its definition.
Common Components
Shared Components
Shared components are used for containing components and business data types that are applicable
to all EBOs and EBMs. Examples of shared components are:
• Address
• Note
• UnitPrice
• Attachment
• CreditCard
The benefits of using shared components are that they promote reusability and that the common
schema module is imported into each of the EBO schema modules.
Business Components
Business Components are business concepts that are specific to a business object but have no
independent existence.
A Business Component is always a dependent concept that exists in the context of an EBO. It does
not have any existence independently.


 In this example, Invoice is an EBO which can exist independently whereas InvoiceLine and
InvoiceLineAllowance are dependent concepts (Business Components).
Reference Components
Reference Components act as a foreign key. However, more commonly used groups of attributes
could be part of the reference structure. The key features of Reference Components are:
• Reference to other EBOs
• Equivalent to a foreign key
• Group of attributes could become part of the reference structure depending on the business
need
• Share the namespace with Common Components
The benefit of using Reference Components is that they reduce overhead because they can be easily
associated to other EBOs.
Infrastructure Components
Various data types are used for designing the EBOs and common components. These data types
could be simple types that are used to represent the “field level” data content such as DateType,
NumericType, StringType etc., or complex types for groups of fields such as AmountType,
QuantityType etc. The data types are compliant with CCTS guidelines.
The Infrastructure Components are comprised of meta data and code lists. Meta data are elements
used in EBM header and body and code lists are metadata code lists which normally have a list of
values e.g., for language, query operator, debug level etc.
Wherever possible, the EBO is designed with reusable objects by using object types that are inherited
by the different common objects in which they are referenced. Using Address definition typeAs an
example, if the implementation requires customizing this address format by adding a third address
line, the modification of the Address definition type automatically affects the addresses referenced in
EBOs. This design philosophy significantly reduces the design, development, and maintenance of
common objects. Components that are applicable to all EBOs will be defined in a Common

Components schema module. Business components that can be used across various context-specific
definitions for a single EBO will be defined within the EBO schema module.
Apart from creating the complete definition for an EBO, a definition is also created for each of the
contexts in which this EBO will be used. For example, an invoice might be used in three contexts –
process, cancel, and update. In this situation, the context for processing, or creating, the invoice
might warrant the presence of almost all of the elements present in the EBO. However, the context
for canceling the invoice might need only the information necessary to identify the invoice instance
that needs to be cancelled.
The context-specific EBO definitions are created by assembling a set of common components and
EBO-specific business components. These context-specific EBO definitions alone will be used in the
appropriate context-specific Enterprise Business Messages (EBMs). In this scenario, the processspecific
invoice definition will be a part of the ‘ProcessInvoice’ EBM and the cancel-specific invoice
definition will be a part of the ‘CancelInvoice’ EBM.
EBO in the Sample Use Case
Oracle Application Integration Architecture provides a prebuilt Enterprise Object Library that
defines the best-in-class representation of business entities such as Sales Order, Purchase Order,
Item, Invoice, etc. These definitions are rationalized across the entire Oracle application portfolio
and industry standards.
This canonical definition of the object brings together disparate applications using a common
language and drastically reduces the number of transformations required to integrate between
different applications. In our sample use case, the online portal application now only has the
responsibility to post the sales order message in the common AIA Enterprise Business Object format
without worrying about how the order is represented in any of the other end systems, which are
likely to change and evolve over time.
One of the most common challenges in application interoperability is inconsistent business semantics
among the different applications. Let’s use the Sales Order business document from our sample use
case. The definition of the Sales Order object in the order capture system, the online portal in this
case, can be different from the way it is defined in the two fulfillment systems or the suppliers who
may be using third party applications. The business objects can not only differ in terms of content
but also in the naming rules and the meaning of the attributes in each of their systems. As the
number of applications that are involved in the integration grows, this complexity grows
exponentially.
In the use case, the SalesOrder EBO is one of the Enterprise Business Objects that needs to be
created for the integration. Before creation of the EBO, it needs to be defined in such a way that it
becomes application agnostic. In simple terms, the object definition of the SalesOrder EBO should
be such that it is understood by any application, be it Oracle EBusiness Suite or Siebel.
There are various guidelines to follow for identifying a candidate EBO (the SalesOrder EBO in this
case). For specific process integrations between different applications, the EBO identifying guidelines
are:
1) It should be based on a business process
2) It should be aligned with Fusion Applications
3) It must define a unique business concept
4) The EBO name should be unambiguous across business process and industry

In business terminology, a sales order is an order generated by the product or service provider for the
goods or services purchased by a customer. As an analogy in the AIA world, the Sales Order EBO is
the document that is passed from the Order Capture systems to backend systems for order
fulfillment. It’s also the document used by downstream systems to query order status information
Before developing the SalesOrder EBO, it should be defined so that it has a structure which supports
all application flows. The SalesOrder EBO should have the following characteristics:
• Represents business concept of a sales order
• Defined using inputs from multiple applications and content standards
• Common service payload used by all applications
• Designed for extensibility
After the EBO has been identified, the process of its development starts. The reference structure or
its constituent elements and attributes are captured if it has an identity and existence in the reference
application. There is a need for a reference application as it provides the starting point. This
reference structure is used by the all the participating applications (within Oracle along with industry
standards) to add their own unique attributes. This is done in the object mapping sheet which is then
collated to form the final Object Sheet. In summary, the following activities are involved:
• Start gathering client (XYZ Inc.) artifacts
• Get the reference structure of the object from the reference application (e.g. Fusion
Application)
• If the reference application does not have the object, then get the structure from any of the
participating applications.
• First stage of mappings – map the levels (e.g. order lines, order schedules)
• Do mapping at the component level before attempting attribute level
• Involve the business users and start detailed attribute mappings
After development the SalesOrder EBO will look like the following diagram:



EBM Concepts
EBM Basics
The Enterprise Business Message (EBM) defines the elements that are used as messages in service
operations. The EBM payload is a restricted view of the EBO content and it includes only the
content necessary to perform the specific operation. The Web Services accept EBMs as input and
return EBMs as output.
EBM Features
• Application-agnostic encapsulation of an EBO
• Generally coarse-grained that operates either on the whole EBO or a subset
• Payload of a web service operation in an EBS
• Semantically precise - performs a specific action i.e. one EBM for one Verb (Operation)
• A CRUD (create, read/query, update and delete) operation or a special operation
• Comprised of a header, verb and an EBO
• Transport protocol agnostic (e.g. SOAP, HTTP, HTTPS, JMS)
Sample EBMs
• CreateSalesOrder
• ProcessSalesOrderATPCheck
• ValidateSalesOrder
• QueryInvoice
• UpdateInvoice
• DeletePurchaseOrder
The EBM header carries information that can be used for (but not limited to):
• Tracking important information
• Auditing for business and legal purposes
• Indicating source and target systems
• Error handling and tracing


The EBM Data Area contains specific content of the EBO required for an operation. The
advantages of having an EBM are:
• Selective content restriction by operation - e.g. Create SalesOrder may require the entire
EBO, but Cancel SalesOrder only requires the SalesOrder number
• EBM XML schema module defines all operations available for a given EBO
• Enables trace and audit
There are certain standard/critical elements in the EBM Header which are needed. These are:
• EBMID
• EBOName
• Version
• SenderSystem
• TargetSystem
• ProcessInfo
• ReferenceID
• CreationDateTime
Message Assembly- Payload
An EBM encompasses details about the action to be performed using the data, one or more
instances (EBOs) of the same type, and the EBM header. Each service request and response is
represented in an EBM by using a distinct combination of an action and an instance. EBM is the
input/ output for the operations supported by an EBO.
This diagram illustrates that the EBM is comprised of:
• Data area
• Action / verb
• EBM Header (message meta data)


The EBM structure is such that there is one EBM for every combination of EBO and the action, and
that an EBM can support only one verb. The combination of get and update in a single message not
allowed.
The EBM header contains information used to process the message content, correlate requestresponse
messages, apply security, and enable message tracking/ auditing. The Data Area identifies
the operation to be performed by the EBM and contains the content payload. The standard
operations that are defined in the EBM are:
• Create
The Create verb indicates a request to create a business object using the information
provided in the payload of the Create message. It is used in operations that are intended to
create a new instance of a business object.
Operations that use the Sync verb must create content and should not be an orchestration of
other operations.
The “Create” verb is not used for composite operations - it always involves the creation of
one (or more in the case of “List”) instance of a business object.
Generally speaking, a business process would invoke a create operation in cases where the
source event that triggers the invocation is not the creation of the object in the requesting
system. If both the service requester and service provider have the same object, then Sync
would be a more appropriate verb to use. However, usage of Sync would also be conditional
to the service provider having an implementation of a “Sync” operation.
A typical usage of a “Create” operation is a front end customer management system that
could take service requests from customers and based on the information provided, request
a work order system to create a work order for servicing the customer.
• Query/Read
The Query verb is a request to a service provider to execute a query on a business object
using the content provided in the payload of the Query message, and return the query result
using the corresponding response message associated with the query. The requestor has the
ability to optionally request a specific subset of the response payload.
• Update
The Update verb indicates a request to a service provider to update an object using the
payload provided in the Update message. It is used in operations that are intended for
updating one or more properties of a business object or array of business objects.
Operations that use the Update verb must create/ update content and should not be an
orchestration of other operations.
Similar to Create, a business process would invoke an “Update” operation mainly in cases
where the source event that triggers the invocation is not the updating of the object in the
requesting systemIf both the service requester and service provider have the same object,
then Sync would be a more appropriate verb to use. However, usage of Sync is conditional
to the service provider having an implementation of a “Sync” operation.
An example of an “Update” operation is a receiving system updating a Purchase Order line
with the quantity of items received, or an order capture system updating the customer record
with customer address/ other information.
• Delete
The Delete verb is a request to a service provider to delete the business object identified
using the Object Identification provided in the payload of the Delete message. It is used for
operations that are intended to delete a business object.
Operations that use the Delete verb must delete content and should not be an orchestration of
other operations
• Synchronization
The Sync verb indicates a request to a service provider to synchronize information about an
object using the payload provided in the Sync message. It is used where applications provide
operations that have the ability to accept the payload of the operation and create/ update
business objects as necessary
The common CRUD operations are supported by most EBOs. Additionally some EBOs
support more specific business operations









This figure illustrates the data area of an EBM containing the “Verb” and the operation specific
“payload”.
AIA makes an explicit distinction between operations that can process a single instance of a payload
vs. operations that can process multiple instances of a payload. Distinct operations are provided for
both cases. Only the “standard” operations have this distinction implemented.
This distinction is made within the payload structure (single instance of data area vs. multiple
instances of data area) and also by adding a suffix “List” to the payload root element and the content
root element. For example, CreatePurchaseOrderListEBM is a payload root element that has a
CreatePurchaseOrderList content root element.
Special Operations
The common CRUD operations are supported by most EBOs but there might be some specific
business activities that the CRUD operations cannot handle. These specific business activities can be
defined as Special Operations. This is done by extending the Enterprise Business Message (EBM).
The EBM for special operations should have specific content of EBO. For example, the ApproveServiceRequest operation might only require an identifier for its execution. The identifier
can be a complex type. The message structure of special operations can have additional content apart
from the ones defined in the EBO.
Verbs in Use
An Enterprise Business Message (EBM) represents a message that is used in collaboration. An EBM
encompasses one verb, one or more nouns (EBOs) of the same type, and the EBM header. Each of
the service requests and the response is represented in an EBM by using a distinct combination of a
verb and a noun. For example, a single QueryAccount EBM business document sends the request to
a billing system for retrieving account details for one or several accounts. This can be accomplished
by using a single ‘Query’ verb and several Account nouns. The billing application can respond to this
request by sending a response message which is populated with details. The EBM cannot process
details about more than one type of noun or verb. For example, it is not possible to have an Invoice
and Order noun in the same message. Similarly, the presence of a Query and Update verb in the
same message is not allowed.
The verb in the EBM identifies the action that the sender or the requester application wants the
receiver/provider application to perform on the EBM. The verb also stores additional information
pertaining to the action that needs to be carried out on the noun.
For each of the verbs that can be used with an Enterprise Business Object (EBO), an Application
Business Connector Service (ABCS) must be defined by the participating requestor application and
another ABCS must be defined by the service provider application.
Although a single ABCS can be used to handle multiple verbs, it is highly recommended to allow
only a single ABCS per verb. This approach greatly reduces the complexity of designing a generic
ABCS. If a single ABCS is designed to handle multiple verbs, it should be keep in mind that it needs
to have the verb information accepted as a part of the input. This allows the ABCS to decipher the
actual action to be performed and enables it to perform the appropriate transformations and
invocations. In addition, allowing a single client side ABCS to handle multiple verbs means that a
single client-side application specific ABO will encompass all of the information pertaining to all of
the verbs.
The verb would be the same in the case of a synchronous request/response pattern. In the case of a
delayed response pattern, the execution of the request will be implemented by one verb and the
execution of the response will be implemented by another verb.
EBM in Sample Use Case
A SalesOrder Enterprise Business Object is a logical representation of the sales order business entity.
An Enterprise Business Message on the other hand is the implementation of an Enterprise Business
Object. In this case the SalesOrder EBM would be the implementation of the SalesOrder EBM. The
Enterprise Business Message is designed to be operation specific so that there is no overhead of
passing the entire Enterprise Business Object to every service operation. For example, the
CreateOrder service operation requires more attributes to be passed in the Sales Order EBM than a
DeleteOrder operation which may require only a unique identifier. The EBM also contains an EBM
header which has additional attributes that are used to provide robust auditing and exception
management. Any EBO by default supports the CRUD operations. This figure shows the
relationship between the EBO, EBM and EBS.




When the CRUD operations on an EBO are not sufficient to support a specific business process,
special operations might be required. This is done by extending the Enterprise Business Service
(EBS). The following steps are only required if the Enterprise Business Service requires a new
operation. This step is to:
• Create a new WSDL with new operations – XYZSalesOrderEBS.wsdl
• For new operations – define new message types (use one message type per operation as
per the WS-I requirements)
<portType name=“XYZSalesOrderEBS">
<documentation>
<svcdoc:Interface>
<svcdoc:Description>This interface contains operations for the
Request-Response and Request-Only patterns</svcdoc:Description>
<svcdoc:DisplayName>RequestSalesOrder EBS
Interface</svcdoc:DisplayName>
<svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus>
</svcdoc:Interface>
</documentation>
<!-- operation support for creation -->
<operation name="CreateSalesOrderListSync">
<documentation>
EBS Concepts
EBS Basics
Enterprise Business Services (EBSs) are the foundation blocks in AIA. EBS represents the
application independent web service definition for performing a business task. It is self-contained,
that is, it can be used independent of any other services. In addition, it can also be used within
another EBS. EBS’s are standard business level interfaces that can be implemented by the
applications that want to participate in the integration.
EBSs are generally coarse-grained and typically perform a specific business activity such as creating
an account in a billing system, or getting the balance details for an account from a billing system.
Each activity in an EBS has a well-defined interface described via XML. This interface description is
composed of all details required for a client to independently invoke the service.
Standard Message Definition
Enterprise Business Services are first-class objects within the Enterprise Service Bus (ESB). The EBS
is self-contained, that is, it can be used independent of any other services. In addition, it can also be
used within another EBS. EBS's are generally coarse-grained and typically perform a specific business
activity. For example, the activity performed could be one of the following:
• Creating an account in a billing system.
• Checking for the presence of an account in a billing system.
• Getting the balance details for an account from a billing system.
Each EBS has a well-defined interface described via XML. This interface description is composed of
all details required for a client, such as a BPEL process, application business connector (ABC)
service, or Fusion application, to independently invoke the service. Such details include protocol
bindings and transport details. These interfaces are described using an implementation-agnostic
approach. Hence, these interfaces are participating-application agnostic.
Operation Naming
The default operations that are supported by the EBS are the CRUD (Create, Read/Query, Update
and Delete). If an operation cannot be represented by the CRUD, then a specialized operation is
needed.
Payload Definition
As shown in this figure, the EBS has a standardized EBM as payload which consists of the following:
• Noun – Enterprise Business Object
• Verb - Service Operation
• Message Header – message meta data


Interaction Patterns
Interaction patterns that are used in AIA include:
• Request/response
• Notify/request-only (fire-and-forget)
• Delayed response
Request/Response
In this interaction pattern the client-side participating application makes a request to the ABCS and
receives the response from it. In this scenario, the client-side ABCS has two transformations – one
for each direction:
• Transformation of the request details available as an Application Business Object (ABO)
into an EBM that can be handed over to the Enterprise Business Service (EBS).
• Transformation of the response details available in an EBM into ABO that can be returned
to the participating application as response.
The server-side ABCS also has two transformations – one for each direction:
• Transformation of the request details available as an EBM into an application-specific
business object that can be handed over to the application implementing the service.
• Transformation of the response details available in ABOs into an EBM that can be returned
to the EBS as a response.

Notify/Request-Only (Fire-and-Forget)
In this pattern the client-side participating application makes a request to the ABCS and does not
expect to receive any response. In this scenario, the client-side ABC service will have one
transformation:
• Transformation of the request or notification details available as an Application Business
Object (ABO) into an EBM that can be handed over to the Enterprise Business Service
(EBS).
Similar to a client-side ABCS, the server-side ABCS has only one transformation. It receives the
request from the EBS as an EBM. The ABCS needs to pass the request to the application
implementing the service. The transformation occurs as follows:
• Transformation of the request details available as an EBM into an application-specific
business object that can be handed over to application implementing the service.
Delayed Response
In this scenario, the client makes a request to the participating application and the participating
application sends a response back to the calling application at a later point in time. This is the
callback usage scenario. This can be visualized as a composition of two synchronous request /
response usage scenarios, one initiated by the consumer and the other by the producer. In the case of
a delayed response or subscription pattern, the consumer ABCS will have only one transformation:
• Transformation of the response or subscription details available as an EBM into an
Application Business Object (ABO) that can be handed over to a participating application.
In the case of fire-and-forget as well as asynchronous request / response interaction patterns, AIA
leverages queue messaging. The architecture mandates that the pre-built integrations interact using
industry standard JMS interfaces.
EBS in Sample Use Case
The abstraction layer in AIA is provided by the EBS. This service has three key purposes:
• Hides service implementation complexity from the service requester. This way the service
requesters can focus more on solving the business problem than dealing with integration
challenges
• Exposes a service contract that is application-independent. This means any application can
invoke the service in the same way irrespective of who the service provider application is.
• Ensures contract-first development which forces the organization to take a more strategic
enterprise architecture approach than building a tactical point-to-point integration. It
narrows the gap between IT and the business because the coarse-grained EBSis designed to
meet business needs rather than be dictated by the complexity or nuances of the
participating applications.
Standardized service definitions across applications are created so that they can be implemented by
all Oracle applications. The advantages of having standardized service definitions are:
• A single service supports multiple operations – e.g. SalesOrder Service may support Create,
Cancel, Update Operations
• Each operation uses SalesOrder EBO as standard input and/ or output
• Multiple applications may provide the same service e.g. EBS, Siebel, Enterprise and E1 can
support Create Sales Order

• Objective is to be able to switch the service provider without affecting the service e.g. switch
from EBS or E1 to Fusion (or any other partner applications that provide the same service
• Long term, all cross- pillar integrations – data synchronization or business process services
to be implemented using standard services
• Standard services require standard payloads to be truly application independent
• EBOs are standardized representations of business objects that will serve as the payload
(input or output) for standard services
In the architectural schema for the order booking sample use case every service invocation is done
through the EBS. So when the process needs customer details, it invokes the
AIADemoCustomerEBS service and the QueryCustomerParty operation in that service. Taking this
approach ensures that if the legacy application that acts as a customer service provider today is
upgraded to an enterprise CRM application tomorrow, the process doesn’t have to change. The
Enterprise Business Service interface remains the same. This enables customers to leverage their
existing investments and evolve their IT systems at their own pace.
This is an example of how an Enterprise Business Service is implemented using the Foundation Pack
WSDL interfaces:



The following table lists some of the EBOs and EBSs used in the sample use case:
Enterprise Business Service
(Enterprise Business Object)
Operation Enterprise Business
Messages
AIADemoCustomerEBS
(CustomerPartyEBO)
QueryCustomerParty QueryCustomerPartyReqMsg,
QueryCustomerPartyRespMsg
AIADemoOrderEBS (SalesOrderEBO) CreateOrder CreateOrderReqMsg
AIADemoItemEBS (ItemEBO) QueryItem QueryItemReqMsg,
QueryItemRespMsg

Versioning
Versioning is the mechanism for content evolution within the library. All content is versioned.
Versioning is distinguished between major and minor, with specific characteristics for each.
A major version defines a non-backward (breakage) compatible revision from a supporting software,
data structure, or semantic processing perspective. These changes consist of, but are not limited to:
• Changing element, type, and attribute names.
• Changing the structures so as to break polymorphic processing capabilities.
• Deleting or adding mandatory elements or attributes.
• Removing or changing values in enumerations.
A minor version defines a backward-compatible (no breakage) revision from a supporting software,
data structure, and semantic processing perspective. Multiple minor versions may exist within a major
version.
It is imperative that backward compatibility within the minor version sequence be maintained as
minor versions evolve. Each subsequent minor version must incorporate the previous minor version
revisions. These changes consist of, but are not limited to:
• Adding optional elements or attributes.
• Adding values to enumerations.
The versioning mechanism comprises two distinct approaches. In both approaches, the major
version is explicitly identifiable. The two approaches are:
• Group versioning, using directory names
• Individual versioning, using indicators
In both cases, however, major version numbers are always reflected within content name schemes,
and minor version numbers are not reflected.
Group versioning using versioned directory names is used to accumulate major revision changes for
groups of related content, appropriate for evolving together over time. Multiple versions of content
using group versioning may exist within one release. This approach provides revision isolation so that
changes that affect only specific groups of EBOs and the associated EBMs do not affect other
groups of EBOs that do not require the changes. The directory name reflecting the major version of
the group will be the same as the highest major version across the group content. Concerning minor
versioning of this approach, the minor version changes are provided within the content of the group
by overwriting the previous schema module. Group versioning within the library is used for:
• Core/Industry Common information
• Core/Industry Common EBOs
• Core/Industry Custom Common information
• Core/Industry Custom EBOs
Individual versioning consists of the major version and this approach allows revision of content on an
individual basis. Using this approach, the minor version changes are provided within the content by
simply overwriting the previous schema module.
Individual versioning within the library is used for:
• Core/Industry EBOs
• Core/Industry Custom EBOs


Extensibility
Implementations always have unique requirements, either specific to their business or specific to the
industry. The ability to build extensions that are sustained and preserved across new releases and
upgrades is one of the key features of the Oracle Application Integration Architecture. Every single
AIA component can be extended. The following section illustrates the different extensions by using
an order booking sample use case.
Extending an Enterprise Business Object
The EBOs are delivered as a set of XSD files. For every EBO, AIA also provides a custom XSD file
in which all customer extensions are stored.
The SalesOrder Enterprise Business Object that is shipped by Oracle has Supplier Name and
Supplier Price attributes defined at the line level. However, the third party system used by the
company’s supplier requires that these attributes be passed at the header level. To be able to integrate
with those systems, the company’s IT department will have to extend the Sales Order Enterprise
Business Object to add these two new attributes at the header level.
To achieve this, we will extend the custom schema CustomSalesOrderEBO.xsd to add the additional
attributes. As we want to add the attributes on the order header level, the following part of the
schema definition needs to be changed:
<xsd:complexType name="CustomSalesOrderType"/>
After adding the attributes, this section of the schema definition looks like:
<xs:complexType name="CustomSalesOrderType">
<xs:sequence>
<xs:element name="SupplierName" type="xs:Name"/>
<xs:element name="SupplierPrice" type="xs:double"/>
</xs:sequence>
</xs:complexType>
The SalesOrderEBO is now ready to carry the custom attributes.
Note that the extension of the underlying SalesOrderEBO also extends all EBMs that reference the
SalesOrderEBO. In this case, this is CreateOrderReqMsg. As the EBMs are also extended, the
extended message definition also extends all EBS and ABCS that work with these EBMs.
The architecture allows for incorporating industry-specific attributes as overlays. An industry-specific
object can be created by assembling together a set of business components available at the core with
a set of industry-specific components.
It is also possible to have an EBO which is very industry-specific like Communications or Utilities.








1 comment:

  1. Hi,
    It looks like you spent much time and effort in writing this blog. I am appreciating your effort. It Was Very Good Information For oracle community.surely i will refer my friends to read this blog it will help them at certain time. Oracle EBS training
    Thank you

    ReplyDelete