This chapter provides an overview of Enterprise Business Flows (EBF) describes how to define and implement EBFs.
Note:
Composite Business Processes (CBP) will be deprecated from next release. Oracle advises you to use BPM for modeling human/system interactions.
This chapter includes the following sections:
The EBF is used for implementing a business activity or a task that involves leveraging capabilities available in multiple applications. The EBF is about stringing a set of capabilities available in applications to implement a coarse-grained business activity or task and composing a new service leveraging existing capabilities. The EBF involves only system-to-system or service-to-service interaction. The EBF has no activity that needs human intervention.
In a canonical integration, the EBF is an implementation of an Enterprise Business Service (EBS) operation and calls other EBSs. It never calls an Application Business Connector Service (ABCS) or the applications directly. In other integration styles, the caller invoking the EBF can be either an application or any other service.
Figure 9-1 and Figure 9-2 illustrate how some EBFs in the Order to Cash Process Integration Pack Pre-Built Integration are implemented to leverage existing capabilities.
Figure 9-1 shows that the EBF is orchestrating a flow for syncing customers between the source application and the target application. When the sync operation is invoked from the source application, the EBF first checks whether the customer exists in the target application. If so, it updates the customer in the target application; otherwise, it creates the customer in the target application.
Figure 9-1 Example of EBF Orchestrating a Flow from Source to Target
Figure 9-2 demonstrates a flow that is receiving the sales order and orchestrating across customer creation, fulfillment, and update back in the source application with response.
Figure 9-2 Example of Sales Order Flow
The Oracle Application Integration Architecture (AIA) methodology for designing and implementing an EBF is contract first methodology. Hence, the contract must be defined and created before the implementation of the EBF.
To define the contract:
Identify the EBF.
Identify the pattern for the EBF.
Identify the Enterprise Business Message (EBM) to be used for the requests and responses (if any).
The first task involved in designing a new service is to verify whether it is necessary.
Situations may occur in which other services exist that are providing some or all of the features identified. Each of the services and the operation's description and any metadata should be reviewed before you decide to create either a new service or an operation.
An EBF is needed when an EBS operation must be implemented with a set of tasks and involves invoking of multiple services.
In a canonical based integration, an EBF can invoke only another EBS.
The Enterprise Business Flow is modeled to implement a single operation.
To identify the message exchange pattern (MEP) for an EBF:
Based on the understanding of the business process requirement from the Functional Design Document (FDD), identify the triggering event for the EBF. See Example 9-1.
If the control is to be blocked until a response is returned to the point of invocation, choose EBF Request-Reply pattern. This would be a synchronous call.
If after the EBF is invoked the triggering point does not wait for the response and continues on, this invocation of the EBF would be an asynchronous call.
Check whether the processing of the EBF results in a response.
Is there a need to correlate the request and the response?
If the answer is yes, this is a case of delayed response. Use the EBF request-delayed response pattern. If the answer is no, then choose the EBF fire-and-forget pattern.
Any EBF operation invoked because of a subscription to a publish event should use the EBS subscribe pattern.
Example 9-1 Example of Message Exchange Pattern Identification for EBF
<operation name="InterfaceSalesOrderToCustomer"> <documentation> <svcdoc:Operation> <svcdoc:Description>This operation is used to interface sales order to customer</svcdoc:Description> <svcdoc:MEP>ASYNC_REQ_RESPONSE</svcdoc:MEP> <svcdoc:DisplayName>InterfaceSalesOrderToCustomer</svcdoc:DisplayName> <svcdoc:LifecycleStatus>Active</svcdoc:LifecycleStatus> <svcdoc:Scope>Public</svcdoc:Scope> </svcdoc:Operation> </documentation> <input message="client:InterfaceSalesOrderToCustomerReqMsg"/> </operation>
To identify the message structure:
A CBP is implemented by orchestrating calls to external services. The event triggering the CBP indicates the business object with which the CBP will be dealing.
Depending on the integration style, the message structure is decided as described below:
If the business object is available in the existing Enterprise Business Message (EBM), use it.
If the business object is not available in the existing EBM but can be assembled from the existing Enterprise Business Object (EBO) Library, construct it.
If the business object is not available in the EBO Library, identify a payload suitable for capturing all relevant information and processing in the CBP.
To create the contract for an EBF: