17 Designing and Constructing Composite Business Processes

This chapter provides an overview of Composite Business Processes (CBP) and discusses how to define the contract for CBP, create a contract for a CBP, implement the CBP as a BPEL service.

This chapter includes the following sections:

17.1 Introduction to Composite Business Processes

Composite Business Processes (CBPs) are the implementation of process services. Process services orchestrate a series of human and automated steps, including enterprise-wide policies captured in business rules. These services run the implementations of the business processes in the Oracle Application Integration Architecture (AIA) Reference Process Models.

AIA recommends using BPEL for implementing CBPs. CBPs are long-running processes that may run from few seconds to days. A CBP has an interface and message structure that is detailed enough to capture all of the information about the source of the triggering event. In most cases, the event is triggered by customer-facing applications.

For more information about detailed definition and high-level design and development guidelines, see "The AIA Shared Service Inventory" in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

17.2 How to Define the Contract for a CBP

The AIA methodology for designing and implementing a CBP is contract first methodology. Therefore, the contract must be defined and created before the CBP is implemented.

To define the contract for a CBP:

  1. Identify the CBP.

  2. Identify the pattern for the CBP.

17.2.1 How to Identify the CBP

The first task involved in designing a new service is to verify whether it is necessary. After the need for the CBP is established, review each of the services and the description of the operation and any metadata in the Oracle Enterprise Repository before deciding to create a service or an operation.

A CBP may be needed when an enterprise-wide business process is needed for a business event. This process is described in the Reference Process Model and spans multiple operational units for enterprises.

To identify a CBP:

  1. From the BPA Reference Process Model, identify the business process to implement.

  2. Click the link to Oracle Enterprise Repository (OER), and review the details in the OER.

  3. If no link is available, create a definition for the CBP as part of the relevant AIA Project in the AIA Project Lifecycle Workbench application.

17.2.2 How to Identify the Message Pattern for a CBP

The CBP is always modeled to implement a single operation with one-way patterns. No responses to the client are made. Any error situation or response is modeled as an update operation back to the client.

17.3 How to Create the Contract for a CBP

To create the contract for a CBP:

  1. Identify the message structure.

  2. Construct the WSDL for the CBP.

  3. Annotate the service interface.

    See Chapter 12, "Annotating Composites".

  4. Ensure WS-1 basic profile conformance.

17.3.1 How to Construct the WSDL for the CBP

The CBP development starts with constructing a WSDL, and the result of the technical design process is a CBP WSDL.

17.4 How to Implement the CBP as a BPEL Service

To implement the CBP:

  1. Create a WSDL.

    Create a WSDL for the CBP following the CBP naming standards and the WSDL templates provided.

  2. Implement the CBP as a one-way BPEL process.

    For more information about the details of creating BPEL projects in Oracle JDeveloper, see the Oracle BPEL Process Manager Developer's Guide.

    Refer to Chapter 15, "Constructing the ABCS" for details about implementing a one-way pattern

  3. Enable error handling and logging.

    Enterprise Business Services (EBSs) should handle errors to allow clients or administrators to resubmit or re-trigger processes. This is accomplished using a central error handler.

    For more information, see Chapter 26, "Configuring Oracle AIA Processes for Error Handling and Trace Logging".

  4. Enable extensibility points in CBP.

    For more information, see Section 16.1, "Developing Extensible ABCS".