Pattern 14 (Case to Case)

FLASH animation of Data Interaction - Case to Case pattern

Description

The passing of data elements from one case of a process during its execution to another case that is executing concurrently.

Example

During execution of a case of the Re-balance Portfolio workflow the best price identified for each security is passed to other cases currently executing.

Motivation

Where the results obtained during the course of one process instance are likely to be of use to other cases, a means of communicating them to both currently executing and subsequent cases is required.

Overview

Direct support for this pattern requires the availability of a function within the PAIS that enables a given case to initiate the communication (and possibly updating) of data elements with a distinct process instance. Alternatively, it is possible to achieve the same outcome indirectly by writing them back to a shared store of persistent data known to both the initiating and receiving cases. This may be either an internally maintained facility at process level or an external data repository (footnote 5). Both of these scenarios are illustrated in Figure 13.

Figure 13: Data interaction between workflow cases

Each of these approaches requires the communicating cases to have a priori knowledge of the location of the data element that is to be used for data passing. They also require the availability of a solution to address the potential concurrency issues that may arise where multiple cases wish to communicate.

Context

There are no specific context conditions associated with this pattern.

Implementation

COSA is the only offering examined that supports a direct method for communicating data elements between cases. It achieves this using shared "folder" data elements (cf. the Folder Data pattern (WDP-6)). In the case of the other offerings, it is possible to achieve the same result indirectly for each of them using the methods described above.

Issues

The main consideration associated with this pattern is in establishing an effective means of linking related cases and their associated data together in a meaningful way.

Solutions

None of the offerings examined address this need, however there are PAIS that provide solutions to the issue. In Vectus (footnote 6) it is possible to relate cases. There are four types of relationships "parent", "child", "sibling", and "master". These relationships can be used to navigate through cases at runtime. For example, one case can schedule tasks in another flow, terminate a task in another flow, create new cases, etc. It is also possible to share data using a dot notation similar to Object Constraint Language [OMG03]. The "master" relation can be used to create a proxy shared among related cases to show all tasks related to these cases. A similar construct is also present in the BizAgi (footnote 7) product.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description for the pattern. It rates as partial support if it is necessary to store the data element in an intermediate location to pass it between cases.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.

Summary of Evaluation