|Oracle® Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack
11g Release 1 (188.8.131.52.0)
Part Number E17364-03
This chapter describes how to define and implement Enterprise Business Flows (EBFs).
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 together 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 15-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 already 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 15-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.
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 already providing some or all of the features identified. Each of the services as well as 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.
Example 15-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>
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 as a result of a subscription to a publish event should use the EBS subscribe pattern.
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:
Identify the EBM.
Construct the WSDL for the EBF.
Annotate the service interface.
Ensure WS-1 basic profile conformance.
To implement the EBF:
Create a new WSDL.
Create a WSDL for the EBF following the EBF naming standards and the WSDL templates provided.
Implement the EBF as a synchronous or asynchronous BPEL process.
For more information about the details of creating BPEL projects in Oracle JDeveloper, see the Oracle BPEL Process Manager Developer's Guide.
Follow Section 12.5, "Implementing the Asynchronous Request Delayed Response MEP" for details on how to use BPEL to implement asynchronous request-delayed response pattern. The difference is that the EBF deals with EBMs.
Enable error handling and logging.
EBSs should handle errors to enable clients or administrators to resubmit or retrigger processes. This is done through a central error handler.
For more information, see Chapter 24, "Configuring Oracle AIA Processes for Error Handling and Trace Logging"
Enable extensibility points in the EBF.