This chapter introduces Enterprise Business Objects (EBOs) and explains what an EBO is and why you need an EBO to facilitate an integration. The chapter then introduces Enterprise Business Messages (EBMs) and discusses architecture, uses, and creation of context-specific EBO views.
This chapter includes the following sections:
An EBO is a standard business data object composed of reusable data components. The library of all EBOs comprises a data model. The EBO represents a layer of abstraction on top of the logical data model. Developers, business users, and system integrators use EBOs. In the integrations developed using Oracle Application Integration Architecture (AIA), the EBO data model serves as a common data abstraction across systems. It supports the loose coupling of systems in Oracle AIA and eliminates the need for one-to-one mappings of the disparate data schemas between each set of systems. Each application data schema is mapped to the EBO data model only once. This significantly minimizes manual coding for data transformation and validation because it eliminates the need to map data directly from one application to another.
EBOs have the following characteristics:
They contain components that satisfy the requirements of business objects from the source and target application data models.
They are not data repositories.
Instead, they provide the structure for exchanging data. XML provides the vocabulary for expressing business data. The XML schema is an XSD file that contains the application-independent data structure to describe the common object.
An EBO represents a business concept, such as a customer, a sales order, a payment, and so forth. Each EBO has a primary business component that identifies the object, and optionally multiple supplementary components required to complete the definition of the EBO. Sales Order Header and Purchase Order Header are examples of primary business components; Sales Order Line and Sales Order Schedule are examples of supplementary business components. The following sections describe the various components that form the EBO.
An EBO business component is a subset of an EBO that has complex content (many properties) and exists only within the context of the EBO. These components are the high-level building blocks of any EBO.
Examples include Sales Order Header and Invoice Line.
An EBO business component may have a primary or a supplementary role in defining an EBO. Business components that can be used across various context-specific definitions for a single EBO are defined within the EBO schema module.
Common components are reused by many EBO business components. A common business component is a subset of an EBO business component that has complex content (many properties). Examples of common business components include concepts such as tax, charge, status, address, and so forth. Generally speaking, the content within a common business component is complete enough to both identify and define the component. This implies that applications could use the common components associated with an EBO to create or update application objects. For example, Address is a common business component used by many different EBOs. The content model of Address contains sufficient information for an application to identify, create, and update it as necessary when it is supplied as part of an EBO's content. For this to happen, the application that creates the EBO instance must ensure that the address information is complete. No one-to-one relationship exists between a common business component and a data model entity such as table or a foreign key. A set of attributes or a foreign key relationship in a table could resolve to a common business component. Foreign keys by themselves could resolve to either common business components, reference business components, or other business components within the EBO definition.
A customization of one of these common objects is automatically reflected in all EBOs that reference that object. For example, if your implementation requires customizing an Address format by adding a third address line, this modification automatically affects EBOs that reference the Address. This design philosophy significantly reduces the design, development, and maintenance of common objects.
Components applicable to all EBOs are defined in a common components schema module.
The same attributes identify both an EBO business component and its associated reference business component, but the latter includes a minimal subset of attributes required to qualify the EBO business component. PurchaseOrderLineReference and InvoiceLineReference are examples of reference business components. Reference business components by definition are not meant to contain all the attributes necessary to define an EBO. They are expected to contain at the least all the attributes necessary to identify a supplementary business component. Beyond this, they generally contain additional attributes that help consumers of an EBO to better understand and interpret the EBO instance that uses the reference business component.
Wherever possible and practical, the EBO leverages widely adopted international standards for modeling and naming, such as the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Core Components Technical Specification (CCTS), UN/CEFACT XML Naming and Design Rules (NDR), Open Applications Group Interoperability Standard (OAGIS), and ISO 11179.
In addition to the complete definition of an EBO, each context in which the EBO is used has its own definition.
At the most basic level, EBMs are the messages exchanged between two applications. The EBM represents the specific content of an EBO needed for performing a specific activity. For example, an invoice might be used in three contexts: add, cancel, and update. The context for processing the invoice might require most elements present in the EBO. However, the context for canceling the invoice might require only the specific invoice instance to be canceled.
To create context-specific EBM definitions, assemble common and EBO-specific business components. You can often obtain business components from multipls EBOs. You can then use these context-specific EBO definitions in context-specific EBMs. In this scenario, the ProcessInvoice EBM includes the process-specific invoice definition and the CancelInvoice EBM includes the cancel-specific invoice definition. Use these EBMs as request or response parameters.
The definitions for these context-specific EBMs are present in the EBM schema module. Hence, for every EBO, two schema modules are available; one containing the definition of the EBO and another containing the definition of the context-specific definitions for that EBO. For example, a Customer Party EBO schema module is available and a Customer Party EBM schema module represents the entire concept for the business object.
For more information, see Chapter 6, "Understanding Extensibility".
Every EBM has the same message architecture. 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 using a distinct combination of an action and an instance. For example, a single Query Customer Party EBM business document sends the request to a billing system for retrieving account details for one or several customer accounts. You can accomplish this using a single Query action and several Customer Party instances. The billing application can respond to this request by sending a Query Customer Party Response EBM business document that comprises the Query Response action and Customer Party instances, which are populated with details.
The EBM cannot process details about multiple types of action. For example, you cannot have Query and Update actions in the same message.
When using EBMs, consider the following points:
Any application invoking the Enterprise Business Services (EBSs) has to generate the EBM to pass the EBM as a payload to the EBS.
The action in the EBM identifies the action that the sender or the requester application wants the receiver or provider application to perform on the EBM.
The action also stores additional information that must be carried out on the EBO instance. For example, the Create action may carry information about whether it wants the target application to send a confirmation message. The Query action may carry information about the document header section of the original EBM that resulted in the performance of this action.
The business object portion of the data area element contains the business object data element definitions that can or must be sent in the message.
This is the content that is carried from one point to another. The element reflects the action-specific view of the EBO.
An EBM can be defined to carry multiple instances. Only the actions that support bulk processing use EBMs that support multiple instances.
The information present in an EBM header is common to all EBMs.
The information present in the data area and the action are very specific to a particular EBM.
The message architecture is detached from the underlying transport protocol.
Any transport protocol such as HTTP, HTTPS, SMTP, SOAP, and JMS should be able to carry these documents.
The EBM header is an integral part of every EBM. The EBM header is like a wrapper or envelope around transactional data messages. It comprises functional data representations. For example, Involved Parties might include Sender, Provider, intermediary services, Security, and Transaction Rules (Transaction State and Exceptions).
The EBM header provides the ability to:
Carry information that associates the message with the originator.
Uniquely identify the message for auditing, logging, security, and error handling.
Associate the message with the specific instance of the sender system that resulted in the origination of the document.
Store environment-specific or system-specific information.
Infrastructure-related service requirements such as auditing, logging, error handling, and security necessitate additional attributes in the EBM message header section.
For more information, see "Working with Message Transformations" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.