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:
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:
Here is how the process chart opened in the Activiti Designer looks like:
where:
The Citeck EcoS has a developed standard set of atomic processes, which perform a specific function and are conveniently combined with each other.
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.
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:
The Citeck EcoS processes additionally support the following parameters:
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:
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:
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:
Here are more examples of standard processes consisting of a single task. They are convenient to be used from the life cycle.
You can find the parameters for these processes in the corresponding data models.
Identifier - activiti$perform. Two tasks: Check and Correct.
The performance process parameters:
Identifier - activiti$resolve. Two tasks: Prepare resolution (for originator – assistant resolver) and Resolve document (for the resolver).
Resolution process parameters:
The resolution draft parameters allow to offer the resolver a completely or partially filled resolution.
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.
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:
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.
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.
To download the transition table a webscript is made. The table must be csv.
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.
Let us create a table for the life cycle shown on the picture, as an example:
The table is as follows:
|
|
|
|
| |||||
|
|
|
| ||||||
|
|
| |||||||
|
|
|
|
| |||||
|
|
|
| ||||||
|
|
| |||||||
|
|
| |||||||
| {"eventType":"automaticTransition"} | confirm2 |
|
| |||||
|
|
|
| ||||||
|
|
| |||||||
|
|
|
|
| |||||
|
|
|
| ||||||
|
|
| |||||||
|
|
|
|