WSO2 Business Process Server v3.1.0 Documentation

##### Overview

- Home
- Release Note
- WS-BPEL Compliance
- License

##### Downloads

- Releases

##### Installation Guide

- Installing WSO2 BPS

##### Quick Start Guide

- Modeling the process
- Deploying the process
- Testing the process

##### User Guide

- Deploying BPEL Processes
- Deploying Human Tasks
- Managing BPEL processes
- Managing BPEL process instances
- QoS for BPEL processes
- Securing BPEL processes
- Invoking secured partner services
- Versioning
- Management API

##### Human Task Guide

- Human Tasks Quick Start Guide
- Deploying HumanTasks
- Managing Tasks
- Developing a Human Task Artifact
- Human Task Management and Configuration
- Human Task Concepts

##### Administrator Guide

- External data sources Configuration
- Registry Configuration
- Events
- Unified Endpoints
- BPEL Extensions
- Transaction Factory Configuration
- Message Exchange Interceptors
- OpenJPA specific properties
- JMS Transport Configuration
- Process Instance Cleanup Tasks
- Process Hydration and Dehydration
- Enabling Peer-to-Peer(P2P) Communication
- Setting up a BPS Cluster

##### Best Practices

- Process Deployment Best Practices

##### Concepts

- Process Versioning
- Process instance events
- Partner links

##### WS-BPEL Extensions

- Activity Failure and Recovery
- Extension Activities and Extensible Assign Operations
- XPath Extensions
- Iterable ForEach
- Flexible Assigns
- BPEL4People Extension

##### Samples

- HelloWorld
- If-Else
- ForEach
- While
- Repeat Until
- Flow and Links
- Pick
- Synchronous and Asynchronous Service Invocations
- Fault Handling
- Split
- XslTransform
- Compensation Handler
- Event Handler

##### Resources

- FAQ
- External Articles
- Library
- Source Code

##### Community

- Forum
- Mailing Lists

##### Project Information

- Issue Tracking

# Implicit Correlations

- Introduction
- Process to Process Interaction Use Case
- Process to Service Interaction Use Case

## Introduction

BPEL process instances are stateful. Therefore, a client interacting with the BPEL engine must identify the particular instance with which it intends to interact in all of its communications. The BPEL specification defines a mechanism (correlation) which allows the process designer to specify which parts of an incoming message (i.e. a message going from a client to the BPEL server) should be used to identify the target process instance. Correlation is a powerful mechanism, however it is a bit complicated and relies on "in-band" message data to associate a messages with a process instance.

To keep simple cases simple, WSO2 Business Process Server provides an alternative correlation mechanism — implicit correlation — that automatically handles correlation through "out-of-band" session identifiers. The mechanism is simple: a unique session identifier is associated with every partner link instance. When a message is sent on a partner link, the session identifier is sent along with the message. The recipient is then able to use the received session identifier in subsequent communications with the process instance. Messages received by the BPEL engine that have a session identifier are routed to the correct instance (and partner link) by that session identifer.

There are two major use cases for the implicit correlation mechanism requiring different levels of familiarity with the mechanism's details: process to process and process to service interactions. The former case deals with situations where the WSO2 Business Process Server BPEL process instance is communicating with another WSO2 Business Process Server process instance. The latter deals with situations where a WSO2 Business Process Server BPEL process instance is communicating with an external service.

## Process to Process Interaction Use Case

When an WSO2 Business Process Server process needs to communicate with other WSO2 Business Process Server processes, using implicit correlations is quite simple. Simply omit the <correlations> element from the <receive>, <pick>, and <invoke> activities. The following is an example showing one process (processA) starting another (processB) and then being called back:

- ProcessA

                .
                .
                .
                <invoke name="initiate" partnerLink="responderPartnerLink" portType="test:MSResponderPortType"
                        operation="initiate" inputVariable="dummy"/>
                <receive name="callback" partnerLink="responderPartnerLink"
                         portType="test:MSMainPortType" operation="callback" variable="dummy"/>
                .
                .
                .

- ProcessB

                .
                .
                .
                <receive name="start" partnerLink="mainPartnerLink" variable="dummy"
                             portType="resp:MSResponderPortType" operation="initiate" createInstance="yes"/>
                <invoke name="callback" partnerLink="mainPartnerLink"
                           portType="resp:MSMainPortType" operation="callback" inputVariable="dummy"/>
                .
                .
                .

In the above example, WSO2 Business Process Server will use the implicit correlation mechanism because no explicit correlations are specified. Communication between the two processes will reach the correct instance as long as the same partner link is used.

## Process to Service Interaction Use Case

TODO