Nous distinguons deux notions : les processus modèles et les processus opérationnels.
Le processus modèle décrit les règles de gestion qui permettent l'enchaînement et l'exécution de tâches (ex : envoyer un mail, créer un évènement, Remplir un formulaire, Accepter ou Refuser une demande, Valider une proposition, …). Il définit les données associées au processus et leur possibilité de mise à jour lors de de l'exécution des tâches. Il n'est pas lié à un dossier.
Les processus peuvent être automatiques (lancement à une fréquence à déterminée), ou manuel (lancement suite à une action dans l'ERP).
Les processus opérationnels sont des instances de processus modèle. Ils héritent des règles de gestion du processus modèle au moment de leur création. Ils sont toujours rattachés à un dossier. La liaison avec un établissement est optionnelle.
Les tâches opérationnelles des processus opérationnels sont exécutées automatiquement.
Les utilisateurs peuvent voir les tâches décisionnelles qui leur sont affectées depuis une entrée au menu Processus où depuis un Widget de l'Interface d'Accueil.
Les administrateurs peuvent suivent le bon déroulement des processus opérationnels.
Le Scrutateur Processus est un programme qui doit tourner en permanence, il lit les règles de gestion des processus, modifie le statut des tâches, et exécute les opérations qui ne demande pas d'intervention (envoi de mail, création d'un évènement).

Mise en production de processus

Scrutateur

Le scrutateur est mono environnement et multi DOSSIERS.

En production, prévoir le lancement du Scrutateur par service Diva
Exemple de chaîne à rajouter dans le fichier DhsServices.txt pour lancement du scrutateur par un Service Diva :
<nom>scrutproc<programme>spppwebscru.dhop<tache>17-999<utilisateur>DEMO
L'utilisateur associé au scrutateur doit avoir les droits en lecture et écriture sur le répertoire défini au niveau des paramètres généraux (ou par défaut par le chemin SP_REP_SCRU)

Scrutateur avec trace (version X.4 Pack 214b)

Pour lancer le scrutateur en mode "bavard" il faut rajouter <trace>1 à la définition du service Diva

...

Le chemin des répertoires à scruter est défini par un code chemin au niveau des paramétra généraux :

Si aucun chemin n'est spécifié au niveau du paramétrage, c'est le code chemin SP_REP_SCRU qui sera utilisé.

Sources et objets des masques associés aux processus

Le module processus, à un générateur automatique de masques écrans. Il permet de générer et de compiler les masques utilisés pour le traitement des tâche manuelles.
Tous les masques d'un processus sont regroupés dans un seul fichier source (1 page par tâche manuelle).
On retrouve donc un masque et un objet par processus. 
On va retrouver

...

Il est donc important de vérifier que le fichier source, et l'objet compilé du masque modèle soit bien dans des répertoires autorisés en lecture et écriture.

Répertoires de destinations des masques (sources et objets)

A partir de la version X.3 (Pack 213b), il est possible de définir des codes chemins pour les répertoires de destinations des masques.

...

Les chemins doivent êtres de type Harmony, et présents dans les implicites.
Les chemins pris en compte sont ceux définis au niveau du dossier courant, ou du dossier commun.
En mode SAAS la définition de ces chemins est obligatoire, il faut que les chemins définis correspondent à des répertoires créés par le client, l'accès aux répertoires standards « Sources » et « Objets » étant interdit en écriture.

Processus administratifs

Il existe deux processus administratifs, dont les masques doivent être compilés pour permette un fonctionnement complet du module :

• zperreur : qui permet d'envoyer un mail à l'administrateur d'un processus lorsqu'un processus opérationnel est en erreur
• zparret : qui permet d'arrêter le scrutateur

Envoi des mails

Les mails sont envoyés par le scrutateur à l'aide d'instruction MAPI. Il faut donc que ces instructions soient exécutables sur le serveur qui abrite le scrutateur.