Boucler sur un élément multivalué

Il y a quelques temps, nous avons parlé du SmartWizard For Each qui permet, depuis la version 4.6.11, dans une modélisation, de boucler sur un élément multivalué. Mais pour les purs et durs cela abstrait toute la puissance de la configuration d’une modélisation K2. Je vous propose donc de voir aujourd’hui comment on faisait avant le 4.6.11, ce qui va permettre d’aborder des concepts avancés de modélisation K2.

Comme on peut le constater sur ce billet, d’un point de vue performance, cette méthode est plus intéressante que l’utilisation du for each.

Le cas d’usage

Pour illustrer ce billet, nous allons utiliser la démonstration de gestion des incidents. Reprenons simplement le besoin : quelqu’un déclare un incident, un chargé de suivi établi un plan d’actions, chaque action est envoyée à son ou ses destinataires, une validation unitaire de chaque action est faîte lorsque l’action est réalisée puis lorsque toutes les actions sont terminées, alors le chargé de suivi va mesurer l’efficacité du traitement global des actions.

Avec K2, ceci peut se modéliser de la façon suivante :

Modélisation des processus de l'application Gestion des Incidents
Modélisation des processus de l’application Gestion des Incidents

Nous avons donc 2 processus : le processus père qui gère tout ce qui est global et le processus fils qui gère les actions à faire de manière unitaire. Dans certains cas, le chargé de suivi déclarera une seule action à faire, dans d’autres cas, il pourra y en avoir 3, 4, 6, 10… en fonction des besoins.

K2 permettant de gérer les processus dynamiques, la modélisation réalisée permet de traiter chacun des cas. Tout va donc se jouer au niveau de la configuration de l’activité Actions.

D’un point de vue interface utilisateur, il s’agit simplement de remplir un tableau d’informations, dans notre exemple, ceci est représenté sous forme d’onglets (bas du formulaire ci-dessous)

Formulaire de planification
Formulaire de planification et de définition des actions

 Le pas à pas de la configuration

  1. Tout d’abord, il nous faut une structure de données adéquate : nous allons donc avoir un smartobject demande, qui contient un ID et les informations générales sur la demande, puis un smartobject action qui est composé de son propre ID, d’une référence à l’ID de la demande et de ses propres données.

    Structure de données associée au besoin
    Structure de données associée au besoin
  2. Ensuite, nous allons configurer la règle d’assignation de l’activité qui déclenche le sous-processus. Nous allons utiliser l’option Plan per slot (no destinations) qui est faîte pour configurer une règle d’assignation pour les tâches système. Puis nous allons nous baser sur un champ qui est résultat de l’appel à la méthode Get List de notre smartobject Action. Nous allons donc ici utiliser le champ Action.ID (lors de l’exécution on retrouvera la valeur de ce champ dans la propriété instance data, cette propriété sera alors réutilisée dans les configurations suivantes de façon à identifier l’élément courant). A l’appel de la méthode Get List, il faut bien veiller à filtrer le résultat sur le DemandeID, afin de ne récupérer que les actions relatives à cette demande. Cette configuration va permettre d’exécuter le contenu de l’activité autant de fois qu’il y a d’actions attachées à la demande.

    Paramétrage des slots de l'activité
    Paramétrage des slots de l’activité
  3. Maintenant que le sous-processus est instancié autant de fois que souhaité, assurons-nous que chaque instance puisse s’exécuter avec le contexte de l’action qui la concerne. Pour cela, il suffit de s’assurer que la valeur du champ action.ID sera bien disponible dans le sous-processus. Ce champ est enregistré instance par instance dans le champ instance data disponible au niveau des données principales du slot de l’activité et que nous avons paramétré à l’étape 2, il est alors possible de l’envoyer dans le folio ou même dans un DataField du sous-processus. Ensuite, lors de l’exécution du sous-processus, il n’y aura plus qu’à utiliser ce champ dans un load du smartobject Action pour récupérer toutes les informations relatives à l’action à traiter.
  4. Enfin, il ne reste plus qu’à mettre en place une règle de synchronisation afin qu’un jeton ne sorte de l’activité Actions que lorsque l’ensemble des sous-processus seront terminés. Pour cela nous allons mettre à jour la succeeding rule en indiquant que tous les status (sous-entendu de chaque instance de sous-processus) aient pour valeur Completed (à écrire textuellement). Si on ne fait pas ce paramétrage, le jeton sortira dès qu’une des instances du sous-processus sera terminée.

    Paramétrage de la règle de terminaison de l'activité
    Paramétrage de la règle de terminaison de l’activité

Nous avons ici utilisé un cas où l’activité appelait un sous-processus, cela permettant d’exécuter le sous-processus un nombre de fois dynamique, mais cela s’applique à n’importe quel type d’événement système à l’intérieur d’une activité. Il est donc possible de procéder de la même façon si l’on souhaite appliquer le même traitement à une liste d’objets (création dans l’AD d’une liste d’utilisateurs, envoi d’un même mail à une liste d’utilisateurs sans utiliser la notion de CC ou BCC, insertion d’une liste de valeurs dans une table, mise à jour d’un ensemble d’éléments dans SharePoint).

Ce billet est inspiré d’un article de la base de connaissance K2 dans lequel la liste de valeurs n’est pas représentée dans un smartobject mais dans un fichier XML.

Happy K2ing!

jean

Directeur technique de K2 France depuis 2006 et passionné par les technologies, je travaille dans le monde du BPM et des applications métier depuis... que je travaille :). Vous pouvez également me suivre sur twitter, linkedin.

2 thoughts to “Boucler sur un élément multivalué”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.