Workflow technical annex

Algorithm principal Workflow object

A Workflow of the type object breaks down in a series of steps as follows :

• Initialization of the environment variables
• For a workflow of the type header or of the type line without grouping, processing of the assignment rule if it exists, then process the workflow.
• For a workflow of the type line with grouping, with read on the lines with the break on the different values of the group. With a constant value, actions of the type line that exist are executed and the line text is formatted. Then process the assignment rule for the group if it exists and then process the workflow for the group before passing to the next group.

Initialization of the environment variables

This stage consists of assigning the global variables. In particular the variable USRWRK is available, which corresponds to the current user for the original workflow.

Processing of the assignment rule

In this stage, the formulas given in the rule are evaluated and they are stored in a dimensioned variable named VALEXP. This is used notably to have available aggregated values that are not strictly used as a criterion for the definition of the recipients, but simply used late in the Workflow (for example to decide the sending of a message as a function of the minimum, maximum and average values for an element).

The number of values calculated is identified by the variable NBCOL.

Then a search is carried out from the calculated values, the line of the rule that corresponds, to assign the grid of USER variables (indexed from 1 to 10 maximum).

Processing of the Workflow

This stage breaks down into several sub-stages. Firstly, determine a certain number of values :

• the variable CTX must be initialized, which contains the current context, according to the parameterized formulas. This context is stored in the Workflow history and will then be reconstructed if a later Workflow event is triggered following the first receipt.
• The variables S_USER, S_CLEOBJ, S_ABREV need to be assigned, which define the user at the origin of the Workflow, the key for the object or the group of lines and the object concerned.
• S_NBRUSER is them calculated, which gives the number of signatures actually defined in the rule.

Then, verify the execution conditions in the Workflow header. If these conditions are achieved, the following operations are then carried out :

• Constitution of the return context (icon).
• Assignment of a chrono number to each processing of the rule. In the case of the manual Workflow, an assignment is made each time the value of the key in the principal table (if there is no regrouping field) or a grouping value (if there is one) is changed.
• Assignment of a chrono number for each line (there will be several by group if there is regrouping).
• Execution of the Workflow start action (if it exists and the conditions are met).
• If a message must be sent, or a receipt made, search for delegated users.
• If a message must be sent, processing of the message.
• If a receipt must be made, process the receipt.
• Execution of the actions of the type Workflow end (if it exists and the execution conditions are verified).

Processing of the message

This stage is carried out on the following operations :

• Constitution of the text by assembling the principal text and the text for the lines detail (if there are any).
• Constitution of the object for the message.
• Display of the window for the modification of the message (if the message is modifiable and if interactive triggering).
• Posting transaction in the corresponding tables : AWRKHISMES contains the body of the message, AWRKHISJOI the attachments and AWRKHISDES the recipients.
• Sending the message if the grouped send option is not activated. If not the grouped send will be made at the end of the Workflow process.

Processing of the receipt

This stage carries out the update of the line for the receipt to be carried out in the table AWRKHISSUI. The corresponding transaction is separated from the previous ones (but it is only executed if the previous ones have been processed correctly).

Algorithm principal Workflow signature

A workflow of the signature type is triggered following a signature action (either manually from the workbench, or automatically via another Workflow event or a notification via a click on the link).

The corresponding stages are as follows :

• Initialization of the inherited variables
• Loading of the variable classes [F] (tables) defined by the original event.
• This is a Workflow of the type Header or of the type line without grouping, processing of the assignment rule, then processing of the Workflow.
• If this is a workflow with a grouping of the lines, reading of the grouping lines corresponding to the receipt, processing of the assignment rule, then processing of the Workflow.
• For each line, execution of the action of the type line and formatting of the text in the line.
• What follows the process is identical to a standard Workflow.

Initialization of the inherited variables

The inherited variables for the context of the signature are assigned in this phase. This includes the following variables

NUMORG	chrono number for the original.
USRORG	recipient for the original event.
NUMSIG	chrono in which a signature process has been triggered.
USRDES	recipient of the chrono in which a signature process has been triggered.
USRWRK	user that signs it.
MAIWRK	email address for the signatory, when the signature is made by an external http link.
LEVSIG	Level of the signature (the original event carries the number 0, the events that carry on from this carries the successive numbers from 1).
RETORG	Key for the object on which the original Workflow has been triggered.
CONTXT	Reference the return icon.
CLEOBJ	Signed chrono number.
CTX(1..15)	Variables for the context.
S_USER	Recipient having triggered the original Workflow.
S_CLEOBJ	Key for the triggering (object or regrouping).
S_ABREV	Abbreviation of the object for the original Workflow.
S_NBRUSR	Number of users defined in the original Workflow rule.

Algorithm for the signature process

he signature phase for an event is made by the following process :

• initialization of the signature context.
• Verification of the existence of the chrono and the locking
• Evaluation (in view of the conditions) of the list of the authorized responses.
• Entry of a response from amongst the possible responses.
• Locking of the record that has generated the first receipt.
• Loading of the variable classes [F].
• Update of the RESULT variable as a function of the response.
• Modification of this variable by entry (if the response is modifiable)

Then, the signature transaction in the proper sense is carried out :

• Execution of the signature actions it there are any.
• Update of the field corresponding to the response (if it exists)
• Process of the Workflow associated with the signature (if one exists)
• Update of the receipt line (signed flag, corresponding signatory).

Initialization of the signature context.

When a user signs a receipt, the available variables in the context are as follows :

CHRONO	chrono for the event in which a signature has been carried out.
USRDES	user code for the recipient.
USRSIG	User code for signatory.
USRMAIL	email address for the signatory, when the signature is made by an external http link.
NUMORG	Chrono for the original event in which the first signature is carried out.
USRORG	Recipient for this event.
LEVSIG	Level of the signature (the original event carries the number 0, the events that carry on from this carries the successive numbers from 1).
USRTOP	Principal recipient (the others are delegates).
NUMGRP	Group of the event to be signed.
CTX(1..15)	Variables for the context.
S_USER	Recipient having triggered the original Workflow.
S_CLEOBJ	Key for the triggering (object or regrouping).
S_ABREV	Abbreviation of the object for the original Workflow.
S_NBRUSR	Number of users defined in the original Workflow rule.

The variables grid REPCHR is used to identify if other recipients for the same event have already signed. The number of groups is counted (a group is equal to a line in the signatory grid, once a delegate has signed, the event is signed and cannot be signed a second tome by another member of the group).

The situation is then :

REPCHR(0) = number of responses that remain to be carried out : if for example if there are 4 lines of signatories in the event description and that only one has signed, this value is equal to 3.

REPCHR(NO), where NO can be a value between 1 and 10, gives the number of signatories that have responded with the response placed in the line number NO in the responses grid.

These variables are then notably used to condition the follow on stages by the fact that the last signature is waiting a response or to work on the majority logic for the signature.