Cape Clear Server 7.5 What's New

Cape Clear 7.5 provides unified, Spring-based assembly configurations — collections of transports, mediation components such as mediation steps, routes, Web services and error-handlers, which flexibly and bi-directionally link clients to servers (see “Assembly Overview”). The Assembly Overview Sample also provides a good introduction to assembly concepts.

It is possible to associate messages and process instances with a specific customer ID. The Cape Clear Orchestration Manager has been updated to support on-demand monitoring of individual customer requests. Each process now contains a customerID field and instances can now be searched and sorted based on this value.

Customer ID values are set either within an assembly, using the assign-customer-id step (see “assign-customer-id”), or within a BPEL process using a setCustomerId BPEL function (see “Managing Customer IDs within a BPEL Process”).

Cape Clear 7.5 makes it easier than ever to work in environments where there are a mix of SOAP-based Web services and REST-style services. Support for REST-style services has been improved in a number of areas of the product. See the following sections for details:

The following samples also demonstrate support for REST-style services:

The ability to re-submit any message previously delivered to the BPEL engine, even if the original process failed, or stalled processes, as well as the ability to manually edit process instance state information. The Assembly Sample with Failed Message Redelivery sample demonstrates this behavior.

The BPEL engine and tools have been significantly enhanced based on user feedback. Cape Clear 7.5 introduces a new Invoke-Retry service. This provides a greater degree of resilience to intermittent connection problems when communicating over HTTP from BPEL. Using the Invoke-Retry service means that the BPEL itself does not need to be modified to handle communication retries – this simplifies significantly the BPEL that needs to be written by our customers. Note that although this is not reliable messaging and there are no delivery guarantees – it is possible to add significantly to the overall application stability using this service. See “Configuring an Invoke-Retry BPEL Web Service” for more details. The Assembly Sample with REST-Style BPEL Partner Links and Invoke-Retry Behavior sample also demonstrates this behavior.

The BPEL runtime is able to recreate a variable which was not defined in the BPEL script at the time when a process instance was created. It is therefore possible to add a new variable into a BPEL process and redeploy the process without failing active instances.

The BPEL flow activity allows parallel processing (see “BPEL Control Activities”). The “BPEL Flow Sample ” demonstrates this behavior.