18 Designing and Constructing Enterprise Business Flows

This chapter provides an overview of Enterprise Business Flows (EBF) describes how to define and implement EBFs.

This chapter includes the following sections:

Section 18.1, "Introduction to Enterprise Business Flows"
Section 18.2, "How to Define the Contract for an EBF"
Section 18.3, "How to Create the Contract for an EBF"
Section 18.4, "How to Implement the EBF as a BPEL Service"

18.1 Introduction to Enterprise Business Flows

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 18-1 and Figure 18-2 illustrate how some EBFs in the Order to Cash Process Integration Pack Pre-Built Integration are implemented to leverage existing capabilities.

Figure 18-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 18-1 Example of EBF Orchestrating a Flow from Source to Target

The image is described in the surrounding text

Figure 18-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 18-2 Example of Sales Order Flow

18.2 How to Define the Contract for an EBF

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).

18.2.1 How to Identify the Need for an EBF

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.

18.2.2 How to Identify the Message Pattern for an EBF

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 18-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>
```
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.
2. 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.

18.2.3 How to Identify the Message Structure

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:
1. If the business object is available in the existing Enterprise Business Message (EBM), use it.
2. 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.
3. 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.

18.3 How to Create the Contract for an EBF

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.

18.3.1 Constructing the WSDL for the EBF

Because the EBF development starts with constructing a WSDL, the result of the technical design process is an EBF WSDL.

18.4 How to Implement the EBF as a BPEL Service

To implement the EBF:

Create a 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 15.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 26, "Configuring Oracle AIA Processes for Error Handling and Trace Logging"
Enable extensibility points in the EBF.