Processes in Citeck ECOS

Owned by Ekaterina Nikitina (Unlicensed)
Last updated: Dec 11, 2018 by Irina Pastuhova (Unlicensed)

Introduction

The 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 ECOS:

  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 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 are some points you should know about the Activiti:

  • workflow and process are synonyms;
  • definition and instance are different things. Definition is a process definition (type), instance is a running process instance (object);
  • The process consists of tasks and transitions;
  • The processes have their own variables;
  • The tasks have their own variables, too (defined in the model);
  • You can transfer parameters to the processes, but these are just the initial values of the variables;
  • You can attach the forms to the tasks;
  • The forms are attached to the processes as well.

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 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].

Example of a confirmation process start: http://localhost:8080/share/page/start-specified-workflow?packageItems=workspace://SpacesStore/...&workflowId=activiti$confirm.

 

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 processes additionally support the following parameters:

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

Confirmation processes

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

 

Confirmers are selected on the start form. The confirmation can be divided into several stages. Inside the stage, there is a certain list of the confirmers. The stages are consistent while the confirmation inside the stage is parallel.

The confirmation process parameters:

  • wfcf:skipCorrectTask – if true, the Correct Task is skipped (on default – false);
  • wfcf:canConfirmWithComments – if true, the Confirm Task has the third variant – Confirmed with comments (on default – false);
  • wfcf:confirmersPermission – permission issued to confirmers (on default – Consumer – read permission).

In this system version, the confirmation process is not designed to be run automatically.

Sometimes an additional confirmation process is used. A confirmer runs it directly from the confirmation task. It has the following chart:

Process identifier - activiti$additional-confirm. The confirmation task is assigned to an additional confirmer while Confirmation notification – to the main confirmer.

Additional confirmation process parameters:

  • 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:

Identifier –  activity$sign. Several variants of the result: Signed, Rejected, Return to confirm, Return to correct.

The signing process parameters:

  • wfsgn:signer – signer-user
  • wfsgn:signerGroup – signer Group;
  • wfsgn:canReturnToConfirm – if true, Return to confirm and confirmers selection end option is available (on default – false);
  • wfsgn:canReturnToCorrect – if true, Return to correct end option is available (on default – false).

Here are more examples of standard processes consisting of a single task. They are convenient to be used from the life cycle.

  • Correction – correction;
  • Signing – sign;
  • Scanning – scan;
  • Printing – print;
  • Registration – registration;
  • Normative control – normative-control;
  • Prolongation – prolongation;
  • Affirmation – simple-affirm;
  • Payment – simple-payment;
  • Moving to archive – move-to-archive.

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

Performance process

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

The performance process parameters:

  • 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).

Resolution process parameters:

  • wfres:resolver – resolver – user or group (role);
  • wfres:resolutionText – resolution text (draft);
  • wfres:resolutionDueDate – resolution due date (draft);
  • wfres:resolutionPriority – resolution priority (draft);
  • wfres:resolutionPerformers – resolution performers (draft).

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 system one transition table can be attached to the document type. The table consists of the following columns:

fromState (text) – mandatory column. It shows what the document state should be (lc:state) in order a transition could be applied to it. The value “*” means that the transition is possible from any state of the document.

event (JSON) – mandatory column. It contains the JSON object with basic information about the transition. The object has the following fields:

  • eventType - mandatory. It specifies the type of the event that allows the transition. It contains one of several predefined values:
    -userTransition – the transition performed if the user clicks a specific action in the document card;
    -automaticTransition – automatic transition. If the document is in the state with this type of transition, it tries to be performed immediately (if transitionCondition allows);
    -onEndProcess – the transition performed at the end of the business process of a certain type;
    -onStartProcess – the transition performed at the start of the business process of a certain type; If a transition is possible, the "Start business process" action is available in the document  card (case);
    -timerTransition - the transition performed after a certain time;
    -onSignal - The transition performed on the signal from the business process.
  • actionName – defines the action name which is shown to the user in the card for a transition. It is used for automaticTransition and onStartProcess.
  • workflowId - defines process type identifier. It is used for onStartProcess and onEndProcess.
  • dateTimeExpression - contains server JS calculating the date. It is used in timerTransition to calculate transition time.
  • signalId - contains signal identifier allowing to perform a transition. It is used in onSignal.

toState (text) –  The final state of the document at the time of transition.

transitionCondition (JS) –  Contains a logical expression in javascript. All features of the server JS Alfresco as well as the following objects are available: document (current document), person (current person) and, if the transition includes the process end or start, process containing the process variables. You can also add your JS functions defining them in lifecycle.lib.js. If the JS returns true the transition is possible, otherwise – impossible.

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.

  1. The CSV file with the table is downloaded to Alfresco;
  2. Invoke the webscript /api/lifecycle/create-transition-table?nodeRef={nodeRef}&type={type}

where:
nodeRef is a nodeRef csv with the table;
type is the type of the document the table should be attached to (for example, idocs:inbox).

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:

The table is as follows:

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