Introduction

The Citeck EcoS Citeck ECOS processes are mainly intended to ensure that a document follows its life cycle. That is, a certain type of document (for example, Incoming one) may have its life cycle from entering the system to, for example, moving to the archive, when no actions are performed in respect of the document.

There are four tools to create processes in the Citeck EcoSECOS:

1. Alfresco Activiti processes (http://activiti.org/);
2. Flowable BPM engine (Citeck ECOS Flowable integration);
3. Adaptive Case Management;
4. The life cycle of the Citeck EcoS Citeck ECOS document.

Activiti processes

The Activiti processes are one of the standard ways of defining the processes in Alfresco. The process definition is an xml file. Nearly always, the process definition is accompanied with an Alfresco subordinate data model defining the properties of tasks, localization of the task model and form. Despite the fact that the process is defined as a simple xml file, it is inconvenient to be edited in an editor’s text because of the coordinates to be indicated for graphic imaging and because of text links from one parts of the process to others. The processes are created/edited using an Activiti Designer application, which is an IDE Eclipse plug-in.

...

Here is how the process chart opened in the Activiti Designer looks like:

where:

• Round-cornered rectangles are the task for users. As the user completes the task, the process goes on.
• Boldface-edged rectangles are subprocesses invocation;
• Arrows are transitions;
• Diamond with + inside is a parallel gateway. The process synchronizes all inputs and runs parallel in all the outputs;
• Diamond with x inside is a gateway with output selection. The process is directed to the output where a condition is satisfied;
• Circle with a triangle inside – a process stops and waits for a signal from the outside.

The Citeck EcoS Citeck ECOS has a developed standard set of atomic processes, which perform a specific function and are conveniently combined with each other.

• Confirmation (confirm);
• Additional confirmation (additional-confirm);
• Contractor approval (contractor-approval);
• Signing (sign);
• Performance (perform);
• Registration (registration);
• Resolving (resolve);
• Correction (correction);
• Familiarization (familiar);

Tools for working with the Activiti processes

As already mentioned, the Activiti Designer is useful to develop the processes. To control the processes in Alfresco Workflow Console is used: http://localhost:8080/alfresco/faces/jsp/admin/workflow-console.jsp. To run the process you can use the following page http://localhost:8080/share/page/start-specified-workflow?workflowId=activiti$[definition-id]. To view the process information you can use the following page http://localhost:8080/share/page/workflow-details?workflowId=activiti$[instance-id].

...

After clicking the link, you can see the confirmation process form. After filling in the mandatory fields and clicking "Start process", we run it.

Running the process from JavaScript

You can use JavaScript to run the process. See an example of the process run below:

var action = actions.create("start-workflow");
action.parameters.workflowName = "activiti$sign";
action.parameters["bpm:workflowDescription"] = "Sign the document";
action.parameters["bpm:workflowPriority"] = 1;
action.execute(document);

The parameters are transferred via object action.parameters. The following parameters can be transferred to each Alfresco process:

• bpm:workflowDescription – process definition (line);
• bpm:workflowDueDate – process due date;
• bpm:workflowPriority – process priority (1 – high, 2 – medium, 3 – low).

The Citeck EcoS Citeck ECOS processes additionally support the following parameters:

• cwf:sendNotifications – whether to send the process notification (according to Citeck EcoS Citeck ECOS notifications templates).

Confirmation processes

A confirmation process is the most common and most complex one of the Citeck EcoS Citeck ECOS standard processes. Here is its chart:

...

• wfacf:confirmers – confirmers list (ScriptNode objects);

Single-task processes

Many processes are simple and consist of a single task. It is for convenient combining. Here is a signing process:

...

You can find the parameters for these processes in the corresponding data models.

Performance process

Identifier - activiti$perform. Two tasks: Check and Correct.

...

• wfperf:performers – performers –  users and groups (roles) array;
• wfperf:controller – controller – user or group (role);
• wfperf:enableControl – if false, Control Task is not available (on default true);
• wfperf:performerPermission – performer permission (on default Consumer);
• wfperf:controllerPermission – controller permission (on default Consumer).

Resolution process

Identifier - activiti$resolve. Two tasks: Prepare resolution (for originator – assistant resolver) and Resolve document (for the resolver).

...

The resolution draft parameters allow to offer the resolver a completely or partially filled resolution.

Document life cycle

The document life cycle functionality allows to transfer the document from one state to another under certain conditions and to attach certain actions on the document to the transitions.

Transitions table

The document transitions from one state to another are determined using the transitions table. The transition table itself is a csv file. Using XML format is planned. In the Citeck EcoS ECOS system one transition table can be attached to the document type. The table consists of the following columns:

...

action (JS) – JS with features like those of transitionCondition, but the point is not in the returned value, but in performing certain actions which accompany the transition.

How to select a transition if several options are possible.

This is possible for all transitions, except for userTransition. If there are several transitions from a certain state for a certain type of event, the transitions with non-empty condition (transitionCondition) are checked first. Select the first one for which the condition is satisfied. If the condition is not satisfied for any of the transitions, the first transition, where transitionCondition is empty, is selected. If there is no such transition, no transition is performed and the document remains in the current state.

Downloading the transition table for document type

To download the transition table a webscript is made. The table must be csv.

...

Later we will make downloading and auto-deploy via bootstrap and deploy when placing into a certain folder in the runtime.

Transition table example

Let us create a table for the life cycle shown on the picture, as an example:

...

fromState

event

toState

transitionCondition

action

start

{"eventType":"userTransition",
"dateTimeExpression":
"document.properties
['cm:modified']",
"actionName":"Отправить на согласование"}

confirmx1

document.properties.creator == person.properties.userName

confirmx1

{"eventType":"automaticTransition"}

confirmx2

confirmx1

{"eventType":"automaticTransition"}

confirm1

(orgstruct.getTypedGroupsForUser
(person.properties
['cm:userName'], "role", "department_manager").
length > 0) || (orgstruct.getTypedGroupsForUser
(person.properties
['cm:userName'], "role", "branch_manager").
length > 0)

startWorkflow ("activiti$confirm", {"wfcf_precedence": person.nodeRef.toString()});

confirm1

{"eventType":"onEndProcess",
"workflowId":"activiti$confirm"}

declined

process.wfcf_confirmed == false

confirm1

{"eventType":"onEndProcess",
"workflowId":"activiti$confirm"}

confirmx2

confirmx2

{"eventType":"automaticTransition"}

confirmed

confirmx2

{"eventType":"automaticTransition"}

confirm2

orgstruct.getTypedGroupsForUser
(person.properties
['cm:userName'], "role", "division_manager").
length > 0

startWorkflow ("activiti$confirm", {"wfcf_precedence": person.nodeRef.toString()});

confirm2

{"eventType":"onEndProcess",
"workflowId":"activiti$confirm"}

declined

process.wfcf_confirmed == false

confirm2

{"eventType":"onEndProcess",
"workflowId":"activiti$confirm"}

confirmed

confirmed

{"eventType":"userTransition",
"actionName":"Отправить на подписание"}

on-signing

document.properties.creator == person.properties.userName

startWorkflow ("activiti$sign", {"wfsgn_signer": person.nodeRef.toString()});

on-signing

{"eventType":"onEndProcess",
"workflowId":"activiti$sign"}

declined

process.outcome == 'Declined'

on-signing

{"eventType":"onEndProcess",
"workflowId":"activiti$sign"}

signed

signed

{"eventType":"userTransition",
"actionName":"Списать в архив"}

archived

orgstruct.getTypedGroupsForUser
(person.properties\['cm:userName'], "role", "archive_manager").
length > 0

...