• XPDL 2.1 Proposals

Visibility Levels of Audit Information

|Please note: this is a preliminary proposal for XPDL 2.1 which has not yet been adopted by the coalition. Please use this page for discussion of that proposed extension. This proposal may change substantially before adoption, or may possibly never be officially adopted in this form.

Problem Statement

In a BPM environment processes, activities, and resources are the sources of events that may be used for analytic applications. For technical, legal, or organizational reasons it may not be desirable to expose every detail of every process. In order to enable the purposeful filtering of information XPDL 2.1 should have facilities to specify which data fields, activities, or processes, or logical groupings can/should be exposed.

Scope

Exposing Data Fields, Activities, Groups, and Processes

For privacy, confidentiality or other legal reasons it may not be desirable to expose all data fields in a process specification as auditable information.

Proposed Solution

The visibility of Data Fields, Activities, Groups, Processes can be visible, optional, or hidden. By allowing a change of audit fidelity at the process level to max, min or none we could change from exposing everything that is visible and optional to exposing only those items that have been set to visible. Items that are set to hidden will never be exposed.

Extension: We may want to refer to external expressions in determining which information may be logged.

Exposing Process and Activity State

Processes and Activities have state machines associated with them. By specifying which state changes are exposed a designer can control the amount of state-change-events that will potentially be created at runtime.

Discussion at October 11 Meeting

• XPDL is designed to make process definitions portable. It is not designed as a storage format for runtime information. Thus, DataFieldExpose is seen as a useful extension, but should not prescribe a particular state model for processes or activities.