Home > Workflow

Workflow Definition

• Defining a process
• Steps declaration
• Script tasks
  • Library script tasks
  • Specific script tasks
• Conditions
  • Library conditions
  • Specific conditions
• User Tasks
  • Built-in services
  • Specific UI services
  • Input variables
  • Output variables
  • Optional reject
  • Temporal tasks
• Link between steps

Defining a process

A process is defined through three steps, within the branch Workflow - definitions.

• Process declaration

  • Each process matches an adaptation in the branch Workflow - definitions. To create a new adaptation, the standard functionality can be used.

    The process consists of:

    • the documentation associated with the adaptation,

    • adaptation nodes for the general description of the process (used variables, access rights),

    • a table defining the steps of the process,

    • a table defining the links between steps; this table is hidden because it is updated automatically.

  • Definition of the process steps. There are different types of step:

    • Script tasks,

    • User tasks,

    • Conditions.

  • Definition of the links between steps.

The image below shows this definition:

Steps declaration

A step is attached to a process, and defined within the process by a unique identifier.

The step can be specialized by specific properties of its type (one associated object by type). A step is associated to only one type.

Script tasks

Two script task types are available:

• Library script task: it must be declared in module.xml (see example above): a library script task defines its label, description and parameters. In a definition script task, when a user selects a library script task, its associated parameters are displayed dynamically.

• Specific script task: it specifies only its class name in the definition script task. Display is not dynamic. The associated class must belong to the module of workflow definition.

Library script tasks

Library script tasks are classes extending ScriptTaskBean .

The method executeScript() is called when the process reaches the matching step as in the following example . This method must not start any Thread because the process goes forward when this method is over. So, each operation must be synchronous in this method.

It is possible to dynamically set variables of the bean if the bean follows the Java Bean Specification. Variables must be declared as parameters of the bean in module.xml. Data context is not accessible in Java Bean.

EBX.Platform provides built-in script tasks:

• Create a branch.

• Close a branch.

• Create a version.

• Merge a branch.

• Import an archive.

Specific script tasks

Specific script tasks are classes extending ScriptTask .

The method executeScript() is called when the process reaches the matching step as in the following example . This method must not start any Thread because the process goes forward when this method is over. So, each operation must be synchronous in this method.

It is not possible to dynamically set variables of the bean for specific script tasks. But the data context is accessible in Java Bean.

Conditions

Two condition types are available:

• Library condition: it must be declared in module.xml (see example above): a library condition defines its label, description and parameters. In definition condition, when a user selects a library condition, the associated parameters are dynamically displayed.

• Specific condition: it specifies only its class name in definition condition. Display is not dynamic. The associated class must belong to the module of workflow definition.

Library conditions

Library conditions are classes extending ConditionBean as shown in the following example .

It is possible to dynamically set variables of the bean if the bean follows the Java Bean Specification. Variables must be declared as parameters of the bean in module.xml. Data context is not accessible in Java Bean.

EBX.Platform provides built-in conditions:

• Check if a branch is valid.

• Check if a branch is modified.

• Check if last user task was accepted.

• Check if two values are equal.

Specific conditions

Specific conditions are classes extending Condition as shown in the following example .

It is not possible to set variables of the bean dynamically for specific conditions. But the data context is accessible in the Java Bean.

User Tasks

User tasks are classes extending UserTask .

The method handleCreate is called to initiate the user transaction. This method will create and allocate as many work items as necessary: if this method has not been overridden, its default behavior is to use the list of selected profiles. In concrete terms, for each selected profile, a work item is created.

At runtime, by default, the user task is considered as completed when all its work items are accepted. It is possible to change this behavior by selecting an other completion strategy:

• Terminate the user task as soon as all its work items are accepted (default strategy).

• Terminate the user task as soon as one of its work items is accepted.

• Terminate the user task as soon as half of its work items is accepted.

• Terminate the user task as soon as all its work items, but one, are accepted.

• Terminate the user task as soon as all its work items are accepted or as soon as one work item is rejected.

• Terminate the user task as soon as all its work items are completed (accepted or rejected).

If no error threshold is defined for the user task, the workflow stops if a work item is rejected at runtime: this field defines the number of rejects that is allowed at runtime. An exception is made for strategies which handle reject ('Terminate the user task as soon as all its work items are completed' and 'Terminate the user task as soon as all its work items are accepted or as soon as one work item is rejected'). For these strategies, rejects are always allowed.

The method handleCreate can be overridden as shown in the following example .

A User Task matches a Manager Component .

Built-in services

The following built-in services are provided:

• Access to a content.

• Create a new record.

• Validate a branch, a version or an adaptation instance.

• Merge a branch.

• Compare contents.

• Export data from a table IN XML files.

• Export data from a table in CSV Files.

• Import data into a table from an XML file.

• Import data into a table from a CSV file.

Specific UI services

In addition to built-in services, the user can define a specific UI Service, on adaptation or on branch or on version.

UI service declaration

Specific UI services must be declared in module.xml in order to be available in user task definition, as in the following example .

For more information, see also InteractionHelper .

Service extensions

It is possible to extend services in module.xml. Extension is available for all service types (built-in, module, adaptation). Thanks to extension, the user can create a new service from an existing service with its own description, label and additional properties. In this way, the user can add specific parameters to built-in services (only input parameters for built-in services).

Except for built-in services, the service extension and the extended service must be declared in the same module.xml file.

Service extensions cannot be extended. Overwriting properties is not allowed.

For more information, see too InteractionHelper .

Input variables

Variable names represent the input variables of the service to be invoked. They are automatically displayed when the user selects a service in a drop-down list (the display is based on service declaration in module.xml).

The value can be either a variable from the Data Context as ${variable} or a constant.

Output variables

Output values describe the mapping to do into the DataContext. For instance, the output parameter could be named xpath , and be set into the Data Context as code . 

Output variables are automatically displayed when the user selects a service in the drop-down list (the display is based on the service declaration in module.xml).

Optional reject

By default, reject is disabled. In this mode, during work item execution, only the 'Accept' button is displayed.

It is possible to enable reject for a user task, in user task definition.

Temporal tasks

Workflow provides two functionalities for verifying that user tasks are completed on time.

Mail reminder

It is possible to specify a periodicity (in days) for the mail reminder. When this time period is elapsed, notifications are sent again for non completed tasks. Mail reminders are sent as long as the task is not completed (one mail by day at most).

Deadline

A user task can have a deadline. When this date is passed and the associated task is not completed, a specific mail is sent to the concerned users. This mail will then be re-sent once a day until task completion.

The periodicity of checks can be specified: for more information, see the workflow configuration.

There are two deadline types:

• Absolute deadline: calendar date.

• Relative deadline: duration (in hours, days or months). The duration is evaluated from the reference date: beginning of the user task or beginning of the process instance.

Link between steps

Two steps may be linked together. A relation can be qualified in three different ways:

• OTHER: default case, links two steps without condition.

• ifTrue: after a condition, links two steps if the condition result is true.

• ifFalse: after a condition, links two steps if the condition result is false.

Home > Workflow