Metadata

<workflow-process id="100" process-version="2" 
                    language-version="1.0"
                    released="false" category="PC5" 
                    createdBy="testuser" 
                    creationDate="20050812T135800">
    <name>ApprovePlannedItem</name>
    <description>
      <localized-text>
        <locale language="en">This workflow process may be 
        enacted to approve a planned item.</locale>
      </localized-text>
    </description>
    <documentation>Refer to the approve planned 
                   item documentation.
    </documentation>
    <web-service expose="true">
      <callback-service>wsconnector.ApprovePlannedItem
      </callback-service>
    </web-service>
    <failure-allocation-strategy>
      <allocation-strategy type="target" 
       identifier="FAILUREALLOCATIONSTRATEGY" />
    </failure-allocation-strategy>    

  ...

  </workflow-process>

workflow-process

This is the parent tag of all process definition metadata.

id: This is a 64-bit identifier supplied by the Cúram key server when a process is created in the process definition tool. The process identifier is required to be unique in the Cúram workflow system. The reason for this is that the process identifier in conjunction with the process version number is how the workflow engine distinguishes one process definition record from another for the purpose of database reads.
process-version: This number represents the version of a workflow process definition. A workflow process definition record is uniquely identified by it's identifier and version number. A process definition may have many released versions and one version that is in edit. Once a process definition has been released, a new version is created and it can no longer be updated. Any subsequent updates will require a new version to be created and this version will not be active until it is released. When a process is enacted the highest released version number is used. Process instances that begin with a given version number remain bound to that version until completion.
language-version: The process definition metadata is the Cúram workflow language. As new features and enhancements are added, this language may change. This version number will allow either the workflow engine to run old language versions different to newer ones or more likely upgrade tools to convert old process definitions to new language versions.
released: This represents a boolean flag indicating whether or not the process definition has been released. Only process definitions that have been released can be enacted or selected as sub-processes in a subflow activity (see: Subflow).
category: A process definition must be placed into a category. The category must be selected in the Process Definition Tool and is taken from the ProcessCategory code-table. This attribute is intended to be used for process definition search functionality and has no functional effect on the process in the workflow engine.
createdBy: This represents the name of the user that created the workflow process definition. This attribute is intended to be used for process definition search functionality and has no functional effect on the process in the workflow engine.
creationDate: This represents the date and time that the workflow process definition was created. This attribute is intended to be used for process definition search functionality and has no functional effect on the process in the workflow engine.

name

The name of the process definition is the means by which the process is identified for the purpose of enactment. The enactment service (the API used to enact a process in code) identifies the process to enact by it's name. As such this name is required to be unique within the workflow system and cannot be changed once the process is created. Since the process name is effectively a constant it is not localizable like an activity name.

description

A process can also have an optional description that briefly specifies what the process does for the benefit of those editing the process definition in the future. This is localizable text field in the same format as all localizable fields in a process definition (see: Localized Text).

documentation

A process can also have a link to some documentation that may explain the process in a more descriptive fashion. This is a free-form text field where the developer can enter the name of a document pertinent to the workflow process or indeed a link to such a document.

web-service

This optional element describes the web service details of a workflow process. A process can be marked as a Web Service by setting this metadata value which indicates that the process should be exposed as a Web Service. This allows the process to be able to participate in a BPEL (Business Process Execution Language) orchestrated process and means that the process can be called from a BPEL process. Further details on this functionality may be seen in Workflow Web Services.

expose: This attribute represents a boolean flag indicating whether or not the process definition should be exposed as a Web Service. A workflow process definition is not exposed as a Web Service by default.
callback-service: This is an optional element because not all invocations from a BPEL process require a callback. The value is a the fully qualified name of a class extending the org.apache.axis.client.Service class (which is part of the Service (Axis API) of the Apache Axis project). The org.apache.axis.client.Service class is generated by the Cúram web services connector functionality for outbound web services.

failure-allocation-strategy

A process can also have an optional failure allocation strategy specified for it. When allocating a task (associated with a Manual or Decision activity), the workflow engine invokes the associated allocation strategy to retrieve the list of allocation targets. If no allocation targets are returned from this invocation, the workflow engine will then check for the presence of a failure allocation strategy and will use this strategy to attempt to allocate the task. Since the allocation strategy of type TARGET specifies an allocation target directly there is never a need to fall back to the failure allocation strategy. The failure allocation strategy is a process-wide strategy and if specified will be used for all the manual and decision activities in the process when required.

allocation-strategy: This describes the failure allocation strategy being used for the process. The failure allocation strategy must be of type TARGET. If the work resolver cannot assign the task to a user, an organizational object (e.g. organization unit, position or job) or a work queue using the specified allocation target the task will be assigned to the default work queue. The identifier attribute represents the identifier of the allocation target being used as the failure allocation strategy.