Design

Back Next

Correlated Message Events

When you design a process, you can use message events in connection with the Receive step to interact with a process after the process has started execution. For example, you might want to:

Query the status of a process

Update data or provide control to the process

Based on one or more input parameters that uniquely identify the process, the process engine matches the correlated message events with their intended business process instances.

For example, a purchase ordering process might have an OrderId property. Messages can store the value of OrderId in different parts of the order process using different names and you associate a specific process instance with a unique OrderId. When a message arrives with the correlated OrderId, it is dispatched to the correct process instance. You can create as many correlation sets as you need.

Correlation matches incoming messages with their intended business process instances, so business processes can support asynchronous request/response patterns. (By comparison, synchronous calls need not rely on correlation because the message context is maintained on the stack or across a TCP connection.)

You define message events at the process level. A message event can be either interrupting or non-interrupting.

Before You Use Correlation

Take these steps before you define a set of correlated message receive events:

Identify the Process Designer steps that need to be correlated. They should share one or more pieces of common data.

Define a property that identifies the piece of common data.

Define a correlation set of data so you can implement this in Process Designer.

Message Event Design Guidelines

When you define correlated message events, note that:

For each message event you define in the process properties, at least one input field should be designated as

Use for Correlation

. If this Input field is a Reference type (a process object), also specify a path to a simple-typed field (with a choice of "field" or "formula").

You can use event inputs and outputs as fields in the process but they are available only downstream of the Receive step (similar to outputs of

Service

steps).

If you use multiple message event definitions and two input parameters in different message events have the same name, they should have the same type and same correlation path, if the input parameters are used for correlation. This ensures that you can have a single correlation value for a step.

You also specify whether it is interrupting or non-interrupting.

With an interrupting
message event:

The event terminates the step.

The event path can merge with main path.

The event path must have a milestone, which serves as the reply to the message event receive step.

With a non-interrupting
message event:

The process does not wait for the message event.

The event path must end with an end step, which serves as the reply to the message event receive step.

Client Interaction to Invoke a Message Event

You can invoke a message event similar to a process, but using a different endpoint. For example, the endpoint to start a process might be:

 …/active-bpel/public/rt/00000I/OrderProcessor

To invoke a specific message event, you would use an endpoint similar to:

…/active-bpel/public/rt/00000I/OrderProcessor/event/CheckOrderStatus

To learn more about concepts related to correlated message events, also see the Process Developer Guide
.

Messages Properties

Download Guide

Watch

Comments

Cloud Application Integration Homepage

0 COMMENTS

We’d like to hear from you! Log in to comment.

Rename Saved Search

Table of Contents

Design

Design

Correlated Message Events

Correlated Message Events

Before You Use Correlation

Message Event Design Guidelines

Client Interaction to Invoke a Message Event