Les différences entre les modes d’assignation

Cela ne vous a sûrement pas échappé, mais il y a différents mode de planification des assignations K2 que l’on peut configurer lorsqu’on se positionne en mode de configuration avancé d’une destination rule :

Nous allons donc voir aujourd’hui les différences subtiles entre chacun des modes et voir les impacts que cela peut avoir sur l’exécution de votre workflow. Pour cela, rien de tel qu’une démonstration par l’exemple, nous allons donc nous créer un processus qui contient 3 activités humaines, chacune utilisant un mode de planification différent. Voici la liste des éléments communs pour chacune des activités :

  • Concernant les slots, on demande la création d’un slot pour chaque destination :
  • L’activité est assignée à 3 personnes (configuration en dur pour plus de clarté) :
  • Chaque activité contient 1 événement de création d’un élément dans une liste SharePoint, l’événement client, puis un 2nd événement de création d’élément dans SharePoint. Les événements de création dans SharePoint sont configurés pour adresser la même liste et de la façon suivante :
    • Colonne Date : date et heure d’exécution de l’événement.
    • Colonne NomActivite : le nom de l’activité en cours d’exécution.
    • Colonne NomEvenement : le nom de l’événement en cours d’exécution.
    • Colonne Commentaire : le nombre de slots originellement disponibles, puis le nom de l’utilisateur à qui le slot en cours est attribué. Ce champ est laissé vide dans le cas du mode plan just once, car les paramètres utilisés ne sont pas disponibles dans ce mode là.
  • Et comme on a plus d’un slot disponible, on a modifié la succeeding rule pour indiquer qu’on attendait que 2 slots aient choisit l’action « fait » pour sortir de l’activité :

Voici donc la modélisation dont nous allons étudier le comportement à l’exécution :

Dans chacun des cas, la tâche est donc envoyée à 3 utilisateurs, on attend que 2 utilisateurs la traite pour passer à l’activité suivante. Au sein de chacune des activités, avant l’événement client on ajoute une ligne dans une liste SharePoint, puis on réitère cela après l’événement client.

Voyons donc à présent le résultat de chacun des modes. A chaque exécution, nous allons faire une copie d’écran de la liste SharePoint lorsque l’événement client est à disposition, puis nous allons faire une copie d’écran après chaque terminaison de tâche par un utilisateur.

Plan just once :

Création de l’activité :

Plan just once - Création de l'activité
Plan just once – Création de l’activité

Après la terminaison du 1er utilisateur (ici rien ne change) :

Plan just once - Après la terminaison du 1er utilisateur
Plan just once – Après la terminaison du 1er utilisateur

Après la terminaison du 2nd utilisateur :

Plan just once - Après la terminaison du 2nd utilisateur
Plan just once – Après la terminaison du 2nd utilisateur

Conclusion :

Le plan just once permet (contrairement aux modes suivants) de ne pas avoir d’impact sur l’exécution des événements systèmes. Peu importe la configuration des slots et de la succeeding rule, ils ne s’exécuteront qu’une seule fois. Il s’agit du mode par défaut et tous les utilisateurs reçoivent leur tâche en même temps. Cependant ce mode ne permet pas d’utiliser les paramètres relatifs à l’activity Destination Instance qui peuvent de temps en temps être nécessaires (comme pour le champ commentaire dans les modes suivants ou par exemple afin de pouvoir cocher la case destination user lors de la configuration d’un mail event).

Plan per destination – all at once

Création de l’activité :

Plan per destination - all at once - Création de l'activité
Plan per destination – all at once – Création de l’activité

Après la terminaison du 1er utilisateur :

Plan per destination - all at once - Après la terminaison du 1er utilisateur
Plan per destination – all at once – Après la terminaison du 1er utilisateur

Après la terminaison du 2nd utilisateur :

Plan per destination - all at once - Après la terminaison du 2nd utilisateur
Plan per destination – all at once – Après la terminaison du 2nd utilisateur

Conclusion :

Le plan par destination - all at once va permettre d’exécuter les événements positionnés avant l’événement client autant de fois qu’il y a de destinations, puis les événements positionnés à la suite de l’événement client vont s’exécuter à chaque terminaison de l’événement client jusqu’à ce que la succeeding rule soit évaluée à vrai. Ici tous les utilisateurs reçoivent leur tâche en même temps.

Plan per destination – one at a time

Création de l’activité :

Plan per destination - one at a time - Création de l'activité
Plan per destination – one at a time – Création de l’activité

Après la terminaison du 1er utilisateur :

Plan per destination - one at a time - Après la terminaison du 1er utilisateur
Plan per destination – one at a time – Après la terminaison du 1er utilisateur

Après la terminaison du 2nd utilisateur :

Plan per destination - one at a time - Après la terminaison du 2nd utilisateur
Plan per destination – one at a time – Après la terminaison du 2nd utilisateur

Conclusion :

Le plan par destination - one at a time va permettre d’exécuter chacun des événements les uns à la suite des autres jusqu’à ce que la succeeding rule soit évaluée à vrai. Les destinataires reçoivent leur tâche chacun leur tour dans l’ordre défini dans la modélisation dès que l’utilisateur précédent a terminé sa tâche (l’ordre des destinations a donc son importance dans ce cas).

Quelques remarques :

Les modes de planification sont souvent utilisés pour activer l’utilisation de certains champs (et le plus souvent afin de dégriser l’option destination user dans un mail event), et malheureusement la majorité des gens ignore que cela va avoir un impact sur les événements systèmes de l’activité. De plus, la plupart du temps, les événements systèmes sont utilisés à des fins de mises à jour (dans SharePoint ou dans des outils tiers), donc le comportement est différent sans que cela puisse se remarquer facilement (en effet, K2 exécutera x fois la même mise à jour donc le résultat pour l’utilisateur final semblera le même que si cela ne s’était exécuté qu’une seule fois), et de nombreuses ressources serveur auront été utilisées inutilement.

Il est donc nécessaire d’avoir conscience de l’impact de la planification par destination afin de toujours construire des applications optimales en terme de performance.

Vous aurez remarqué également qu’il existe une 3ème option : le plan per slot (no destinations). Cette option est utilisée dans le cas de configuration d’activité au sein de laquelle il y a uniquement des événements systèmes et cela permet de gérer dynamiquement leur instanciation. Nous avons abordé l’utilité de ce mode dans le billet expliquant comment boucler sur un événement multivalué.

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.

9 réponses à “Les différences entre les modes d’assignation

  1. je viens de relire et je pense que la réponse à ma question est dans la 2ème capture (Destination Rule options)
    dans ton exemple le comportement est un slot par role ou groupe.

    1. Salut Marwen,

      Effectivement, dans mon exemple, si on remplace les 3 utilisateurs par 3 groupes. Le résultat d’exécution présenté dans ce billet sera toujours le même. Donc, ici, utiliser des groupes ou des utilisateurs n’a pas d’impact sur la planification de mon étape.

      Cependant, ce qui va changer c’est la façon dont la tâche va être dispo pour les différents utilisateurs de chaque groupes. En laissant la case « create a slot for each role and group » cochée alors il y aura un slot de disponible PAR GROUPE, dès qu’un utilisateur d’un groupe termine la tâche, alors elle disparaît de la liste des tâches des autres utilisateurs de ce groupe uniquement.

      Si au contraire on décoche cette case pour cocher la case « resolve all roles and groups to users » alors K2 va générer autant de slot qu’il y a d’utilisateurs tous groupes confondus et la tâche pourra être traitée par les utilisateurs sans notion d’appartenance à un groupe (dans ce cas 2 personnes du même groupe pourront traiter la tâche).

      J’espère que c’est plus clair et je me rends compte que cette option pourrait peut être faire l’objet d’un billet 🙂

  2. Salult Jean,

    Merci pour ta réponse détaillée. Mais donc pourquoi les informations de l’activity destination ne sont pas disponibles lors d’un plan just once. Pourtant plusieurs utilisateurs peuvent recevoir une tâche en utilisant ce mode.

    1. Ceci tient à la structure des données sous jacente. Dans le cas d’un plan just once, les informations sur la « tâche » sont enregistrées dans une ligne de la BD K2. Dans le cas d’une planification par destination, il y a autant de lignes créées que d’utilisateurs à recevoir la « tâche ».
      Il est donc possible dans le 2ème cas de stocker des informations détaillées sur chaque utilisateur.

  3. Bon à savoir :

    (en utilisant le Custom Worklist Service Broker)

    Lorsque le plan all at once est utilisé et plusieurs utilisateurs sont en destination
    Il se trouve que la liste provenant du SmO (la worklist custom) retourne toutes les lignes (même les taches affectés aux autres utilisateurs) ce qui génère une erreur de type autorisation d’accès.

    Il faut dans ce cas filtrer non pas sur le User Name mais sur le Allocated user

  4. Bonjour Jean,
    Nous avons configuré une activité pour qu’elle reçoive ses destinations depuis un groupe AD + un login utilisateur en dur.
    le problème qu’on rencontre est que K2 n’arrive pas à résoudre les utilisateurs et confond le groupe avec un utilisateur et plante lors de l’exécution de l’envoi d’un mail event

    comment faites vous lorsque vous avez plusieurs types de destinataires ?
    Merci d’avance

    1. Bonjour Marwen,

      Si les données en entrées sont de types différents, afin que K2 puisse faire correctement l’évaluation, il est nécessaire d’utiliser la colonne type (cf 3ème copie d’écran de ce billet), afin de préciser que l’information ou la donnée saisie correpond à un login d’utilisateur, un groupe ou un rôle. Il faut donc bien mettre un destination set par type d’entrée.

Laisser un commentaire

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