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 the architecture and usages as well as how the context-specific views of the EBO can be created.
This chapter includes the following sections:
An EBO is the definition for a standard business data object and is composed of reusable data components. The library of all EBOs makes up a data model. The EBO represents a layer of abstraction on top of the logical data model and is targeted for use by developers, business users, and system integrators. 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. The adoption of the EBO facilitates the mapping of each application data schema only once to the EBO data model. This significantly minimizes the 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.
EBOs differ from other data models in that 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 business concepts 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. Each EBO is built from one or more EBO business components.
An EBO business component may have a primary or a supplementary role in defining an EBO. Each EBO is built from one or more EBO business components. Business components that can be used across various context-specific definitions for a single EBO are defined within the EBO schema module.
These are reusable common components that are used 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 that is used by many different EBOs. The content model of Address contains sufficient information for an application to identify as well as create and update the address as necessary when the address is supplied as part of an EBO's content. Note that 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 data model entity such as table or a foreign key relationship to a common business component. 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 to one of these common objects is automatically reflected in all EBOs that reference that object. An example would be an Address definition type. If your 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 are defined in a common components schema module.
A reference business component shares the same identification properties as the corresponding EBO business component (that is, both the EBO business component and its associated reference business component can be identified by the same attributes), but additionally includes a minimal subset of attributes required to qualify the EBO business component. PurchaseOrderLineReference and InvoiceLineReference are examples of reference business components. Note that 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.
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.
At the most basic level, EBMs are the messages that are 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 warrant the presence of almost all of the elements present in the EBO; however, canceling the invoice might need to identify only the invoice instance to be canceled.
The context-specific EBM definitions are created by assembling a set of common components and EBO-specific business components. In some scenarios, the business components can be obtained from more than one EBO. These context-specific EBO definitions are then used in the appropriate context-specific EBMs. In this scenario, the process-specific invoice definition would be part of the ProcessInvoice EBM and the cancel-specific invoice definition would be a part of the CancelInvoice EBM. These EBMs can be used either as the 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. In the case of the Customer Party EBO, a Customer Party EBO schema module is available as well as a Customer Party EBM schema module to represent the entire concept for the business object.
For more information, see Chapter 6, "Understanding Extensibility".
Every EBM possesses 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 by 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 by 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 more than one type of action. For example, you cannot have a Query and Update action in the same message.
When using EBMs, consider the following points:
Application interdependencies.
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 that is present in an EBM header is common to all EBMs.
The information that is 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. You can consider the EBM header as a wrapper or an envelope around transactional data messages. It comprises representations of functional data such as Document Identification, Involved Parties (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.
The requirements pertaining to infrastructure-related services such as auditing, logging, error handling, and security necessitate the introduction of additional attributes to the message header section of the EBM.
For more information, see "Working with Message Transformations" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.