Flux de tâches avec le moteur InterSystems IRIS Workflow Engine - Introduction

Cela fait un certain temps que j'ai l'intention de faire une sorte de démonstration de concept avec la fonctionnalité Workflow (flux de travail), qui, comme beaucoup d'autres fonctionnalités disponibles dans IRIS, tend à passer inaperçue aux yeux de nos clients (et je fais ici mon mea culpa). C'est pourquoi j'ai décidé il y a quelques jours de développer un exemple de configuration et d'exploitation de cette fonctionnalité en la connectant à une interface utilisateur développée en Angular.

Pour ne pas faire un article trop long et le rendre plus accessible, je vais le diviser en 3 parties. Dans ce premier article, je présenterai la fonctionnalité de Workflow ainsi que l'exemple que nous allons résoudre. Le deuxième article détaillera la configuration et l'implémentation de la production qui sera responsable de la gestion du Workflow. Enfin, nous montrerons comment accéder aux informations disponibles dans notre Workflow via une application Web.

Moteur de Workflow dans InterSystems IRIS

Pour expliquer ce qu'est cette fonctionnalité de Workflow, rien de mieux que de copier la description qui en est faite dans la documentation d'IRIS.

Un système de gestion des flux de travail automatise la répartition des tâches entre les utilisateurs. L'automatisation de la distribution des tâches selon une stratégie prédéfinie rend l'attribution des tâches plus efficace et l'exécution des tâches plus responsable. Un exemple typique est celui d'une application de service d'assistance qui reçoit des rapports de problèmes de la part des clients, envoie ces rapports aux membres des organisations appropriées pour qu'ils prennent des mesures et, une fois le problème résolu, communique les résultats au client.

Le moteur de workflow dans InterSystems IRIS offre un niveau de fonctionnalité bien plus élevé que les systèmes de gestion de workflow traditionnels et autonomes.

Où trouvons - nous les fonctionnalités de Workflow dans notre IRIS? Très simple, depuis le Portail de Gestion:

Expliquons brièvement chacune des options disponibles avant d'entrer dans l'exemple de projet.

Les rôles de Workflow

Cette option fait référence aux rôles dans lesquels nous classerons les utilisateurs qui utiliseront la fonctionnalité. La définition du rôle est quelque peu confuse, je préfère la voir plutôt comme des types de tâches que nous pouvons créer à partir de notre production. Le nom attribué à ces rôles doit correspondre aux noms des Opérations Métier que nous déclarerons plus tard dans notre production pour créer les tâches associées à ces rôles.

Utilisateurs de Workflow

Les utilisateurs IRIS qui peuvent être assignés à différentes tâches seront associés à un ou plusieurs rôles. Les utilisateurs doivent être enregistrés auprès d'IRIS.

Les tâches de Workflow

Liste des tâches créées dans le système avec leurs informations associées. À partir de cette fenêtre, des tâches peuvent être attribuées aux différents utilisateurs correspondant au rôle de tâche.

Quelles sont ces tâches? C'est très simple, les tâches sont des instances de la classe EnsLib.Workflow.TaskRequest, l'objet de ce type sera envoyé depuis le Processus Métier dans lequel il a été généré vers une Opération Métier de la classe EnsLib.Workflow.Operation et avec le nom du rôle que nous avons précédemment créé. Cette action créera à son tour une instance de la classe EnsLib.Workflow.TaskResponse. L'Opération Métier ne renverra pas de réponse tant que la méthode CompleteTask de l'instance de classe TaskResponse n'aura pas été exécutée.

Liste de travail de Workflow

Semblable à la fonctionnalité précédente, il nous montre également une liste de tâches avec les informations qui leur sont associées.

Exemple de Workflow

Le projet que vous trouverez associé à cet article présente un exemple simplifié de solution à un problème typique des organisations de santé tel que le traitement des patients chroniques. Ces types de patients nécessitent un contrôle continu et une surveillance stricte pour lesquels, dans de nombreux cas, les professionnels impliqués dans les soins ne disposent pas des moyens les plus appropriés.

Dans l'exemple, nous allons voir comment nous pouvons surveiller les patients souffrant d'hypertension. Nous supposerons que les patients prennent leur tension artérielle quotidiennement avec un tensiomètre qui enverra la lecture au serveur où notre InterSystems IRIS est installé. Si la tension artérielle dépasse 140 pour la systolique et 90 pour la diastolique, le patient est informé qu'il faudra reprendre la tension artérielle après un certain temps et, si la tension dépasse à nouveau les limites, le patient et le médecin sont informés de la situation afin qu'ils puissent décider des mesures à prendre.

Pour ce faire, nous allons diviser ce flux de tâches en deux étapes:

Étape 1: Prise quotidienne de la tension artérielle.

1. Réception dans la production de messages HL7 avec des mesures de la pression artérielle.
2. Vérifier l'existence de l'utilisateur dans le système (et le créer s'il n'existe pas), puis enregistrer l'utilisateur dans les rôles impliqués dans le workflow.
3. Extraction des données de tension artérielle et comparaison avec le critère d'alerte.
4. Si les données dépassent les critères d'alerte:
   1. Création d'une tâche pour informer le patient de la situation et lui demander une nouvelle mesure de la tension artérielle.
   2. Création d'une tâche automatique pour gérer la deuxième lecture de la tension artérielle.
5. Si les données ne dépassent pas les critères d'alerte, le processus est clôturé jusqu'à la réception de la prochaine lecture le lendemain.

Étape 2: Réception de la deuxième lecture après que la première lecture dépasse les valeurs d'alerte.

1. Réception du message HL7 avec la deuxième lecture de données.
2. En attente d'une récupération automatique des tâches.
3. Si les niveaux de tension artérielle dépassent les critères d'alerte:
   1. La tâche automatique est clôturée en indiquant l'état d'alerte.
   2. Une tâche manuelle est créée pour le médecin qui signale la situation du patient.
   3. Une tâche manuelle est créée pour le patient, l'avertissant de la situation et du fait que son médecin a été informé.
4. Si les niveaux ne dépassent pas les critères d'alerte:
   1. La tâche automatique est clôturée indiquant qu'il n'y a pas de danger.

Dans le prochain article, nous entrerons dans les détails de la conception de notre organigramme afin de refléter ce qui a été dit plus haut.

Interface utilisateur

Comme vous l'avez vu dans les captures d'écran ci-jointes, l'interface utilisateur fournie par InterSystems IRIS pour la gestion des tâches est, pour le moins, assez spartiate, mais l'un des avantages que nous avons avec IRIS est que nous pouvons créer notre propre API REST pour gérer notre flux de tâches d'une manière très simple, nous discuterons de ce point dans notre dernier article.

Pour offrir une interface conviviale aux utilisateurs, nous avons développé une petite application web en Angular en utilisant Angular Material qui nous permettra de créer une interface qui simule une application mobile.

Cette application mobile se connectera à InterSystems IRIS à l'aide de JSON Web Tokens (jetons Web JSON) et effectuera des requêtes HTTP vers une application web spécifique publiée dans IRIS, de manière à ce que les actions entreprises par les différents acteurs sur les tâches soient reflétées dans le flux de tâches défini.

Dans le chapitre suivant...

Après cette introduction à la fonctionnalité Workflow, dans notre prochain article nous montrerons comment implémenter le flux de tâches nécessaire pour traiter l'exemple que nous avons présenté en utilisant une BPL, nous configurerons l'ensemble de la production et nous verrons quelles sont les principales classes impliquées dans le Workflow (EnsLib.Workflow.TaskRequest et EnsLib.Workflow.TaskResponse).

Merci à tous pour votre attention!