Handling a Process that Includes Arbitrary Length Tasks

The inclusion of arbitrary-length tasks can preclude the use of a request-response operation to expose a web service from a process.

See Arbitrary Length Tasks and Request-Response Operations.

In this situation, the process (service provider) and the client application (service consumer) must instead co-operate to construct a conversation that uses two one-way operations - one to allow the process to receive a message from the client application, one to allow the process to return a response to the client application.

The process and the client application swap their roles of service provider and service consumer for the "request" and "return" legs of the conversation.

Using two one-way operations to handle the problem of arbitrary length tasks illustrates this.

Using two one-way operations to handle the problem of arbitrary length tasks

(1) The process (acting as a service provider) exposes a one-way operation to receive a message from a client application (acting as a service consumer). The application can itself be another process.

(2) Both the process and the application continue with their work.

(3) When it is ready to send its response, the process (now acting as a service consumer) invokes a separate one-way operation to send a message to the application (now acting as the service provider).

(4) The application is responsible for connecting the separate one-way operations as a single conversation. If the application is another process, correlation data can be used to do this - see Correlating Separate Request and Response Messages - an Example on page 32.

Correlating Separate Request and Response Messages - an Example

The OrderEnquiry process handles customer enquiries about orders, and uses a piece of data - the Order Reference number - which can be used to uniquely identify each process instance. As part of its work, the OrderEnquiry process calls a separate process, CheckOrderStatus, to check the status of an order.

Note: The example assumes that the "Check order status" part of the CheckOrderStatus process contains arbitrary length tasks, which means that the "Get order enquiry" - "Return order status" pairing cannot be exposed a a request-response operation.

Using correlation data to connect separate one-way operations illustrates how the processes co-operate:

Using correlation data to connect separate one-way operations

(1) The OrderEnquiry process assigns a value for the queried Order Reference to the OrderRef correlation data field as part of the Get Order Ref task (which is a user task in this example).

(2) The OrderEnquiry process uses the Query order status send message task to invoke the Get order enquiry operation provided by the CheckOrderStatus process. The Order Reference value is required as a service input parameter by this operation.

Note: The Order Reference value does not necessarily have to be defined explicitly as a service input parameter. It could simply be part of another data object that is passed as a service input parameter.

(3) Both processes continue with their work.

(4) When it has completed its "Check order status" work, the CheckOrderStatus process uses the Return order status event to invoke the Receive order status operation provided by the OrderEnquiry process. The Order Reference value is again required as a service input parameter by this operation.

(5) On the Receive order status task, the Order Reference value is mapped to

  • The OrderRef correlation data field is defined as a correlation data item on the Interface tab, with Mode "Correlate".
  • The Order Reference value is mapped to the OrderRef correlation data field.

The OrderEnquiry process can then determine which process instance the incoming message relates to, based on the value of the OrderRef correlation data field.