The Oracle Database Adapter enables a BPEL process to communicate with Oracle databases or any third-party databases such as MS SQL and MySQL through JDBC drivers. One can use a vendor's database for design time and another for runtime because BPEL processes are database-platform neutral.

In order to leverage Database Adapter to create composite web services, one needs to establish database connections. One can establish all the database connections by navigating to File | New | Connections, or alternatively one can create database connections on step 3 of the Adapter Configuration Wizard. In order to create a database connection, you need to provide the database details such as Connection Type, Username, Password, Host Name, JDBC port, and Service Name, as shown in the following screenshot:

When the Database Adapter is used to poll for database events (usually an INSERT operation into an input table) and to initiate a process; in Oracle BPEL process, it is a partner link tied to a Receive activity. The expression inbound (from database into SOA) is commonly used.

When the Database Adapter is used to invoke a onetime DML statement such as an INSERT or SELECT, in an Oracle BPEL process, it is a partner link tied to an Invoke activity. The expression outbound (from SOA out to the database) is used.

The following screenshot lists the entire operation types one can leverage as services using Database Adapter to create composite web services within Oracle BPEL Business Process Manager:

The purpose of the File Adapter is to enable the BPEL service to exchange files between BPEL services deployed in SOA Suite and an external filesystem that is a locally mounted NFS. The File Adaptor also can transform an XML file to text file. The File Adapter has a triggering mechanism that enables or activates transfer of the file once the file arrives in a location specified in the configuration. The polling frequency can be defined using the Adapter Configuration Wizard.

The following screenshot lists the File Adaptor operation types: Read File, Write File, Synchronous Read File, and List Files on a local filesystem:

The main purpose of JMS Adapter is to exchange messages between a Message Oriented Middleware (MOM) such as IBM MQ series, Progress SonicMQ or Apache ActiveMQ, and BPEL services deployed in an SOA Suite platform.

Oracle has certified that the JMS Adapter works with AQ JMS (JMS provides OJMS 8.1.7, 9.0.1.4, and 9.2), WebLogic JMS, and third-party services such as TIBCO JMS, IBM WebSphere MQSeries (IBM MQSeries JMS 6.0), and Apache Active MQ.

The JMS Adapter supports three types of operations: Consume Message, Produce Message, and Request/Reply. The Consume Message operation polls for incoming messages from a JMS destination while the Produce Message operation puts outgoing messages to a JMS destination. The Request/Response operation performs both Consume and Produce operations to JMS destinations either synchronously or asynchronously.

Web Service Adapter assists us in creating a SOAP web service binding component for message delivery. Binding components such as web services make service-oriented architecture (SOA) applications accessible to the outside world. The Web Service Adapter provides two types of service bindings: Reference and Service.

Service binding creates an inbound SOAP service in the Exposed Services (left) swim lane that provides the outside world with an entry point to the SOA composite application, as shown in the following screenshot:

Reference binding creates an outbound SOAP web service in the External References (right) swim lane that enables messages to be sent from the SOA composite application to external partners in the outside world, as shown in the following screenshot:

WSDL describes the capabilities of the service that provides an entry point into an SOA composite application or a reference point from an SOA composite application. A service or reference is defined by a port type and, optionally, a callback port type. The WSDL file can define more capabilities (port types) of the target web service, but a service only uses the one defined by the port type.

Transaction Participation configures the level of support for WS-Coordination and WS-AT transactions. WS-AT provides transaction interoperability between WebLogic Server and other external transaction processing systems, such as WebSphere, JBoss, Microsoft .NET, and so on. This enables external transaction managers to coordinate resources hosted on WebLogic Server over WS-AT or vice versa.

There are business use cases that require decision-making by a human as part of the workflow. BPEL provides Human Task to achieve this. The BPEL composite service with Human Task(s) will always be an asynchronous service.

Drag Human Task from Component Palette to a flow activity of a BPEL process. It will open up a Human Task wizard, as shown in the following screenshot:

It will pop up a window to let you configure the Human Task's high-level properties, as shown in the following screenshot:

It will open up a component editor to configure the Human Task in detail. One can also open the component editor by right-clicking on the Human Task icon on the partner links on the right-hand side of the Design panel. On this tab, you can create input data, assignment, notification and events, access, and deadlines to the Human Task.

The following screenshot shows the Design view of the Human Task where you could create the next steps for a REJECT, ACCEPT, or Otherwise outcome for a Human Task: