Les 12 modes d'affectation des tâches de flux de travail avec K2 Blackpearl
- par Hamza Cheref
- •
- 02 janv., 2018
- •
Comment configurer l'attribution des tâches aux participants d'un flux de travail K2 Blackpearl
Comment configurer l'attribution des tâches aux participants d'un flux de travail K2 Blackpearl
Il est très important lors de la modélisation d'un flux de travail de prendre en considération la façon de configurer l'affectation des tâches aux utilisateurs participants, car une mauvaise configuration, même si elle peut répondre aux besoins fonctionnels, pourrait avoir un impact négatif sur les performances de votre plateforme. Et c'est pour quoi, il est primordiale de bien comprendre le fonctionnement des règles de destination dans un workflow K2.
- Plan just once : Si vous sélectionnez cette règle alors 1 seule instance de l'activité sera créée. C'est à dire plus simplement que le processus générera une seule tâche qui sera commune à tous les utilisateurs.
- Plan per destination : Si vous sélectionnez cette règle alors autant d'instances d'activité que de destinataires seront créées. C'est à dire plus simplement que le processus générera pour chaque destinataire une tâche avec un numéro de série (SN) différent, chaque tâche sera donc destinée à un destinataire (un destinataire peut être un utilisateur, un groupe ou un rôle). l'affectation de ces tâches peut se faire de façon parallèle (All at once) ou séquentielle (One at a time).
- Create a slot for each destination : Pour simplifier, on va définir le nombre de slots comme le nombre d'accès simultanés à une tâche, donc si vous cochez cette règle alors autant d'accès simultanés à la tâche seront créés que de destinataires.
- Specify the number of slots to be created : Avec cette règle vous pouvez fixer le nombre de slots à créer. Si vous saisissez 2 ça signifie que seuls 2 utilisateurs peuvent accéder simultanément à votre tâche, les autres doivent attendre qu'un accès (slot) soit libéré.
- Resolve all roles and groups to users : Si vous cochez cette règle alors ce sont les comptes utilisateurs dans les groupes et les rôles qui seront considérés comme destinataires.
- Create a slot for each role and group : Si vous cochez cette règle alors ce sont les groupes et les rôles qui seront considérés comme destinataires et non pas les comptes utilisateurs qui sont dedans.
La combinaison de ces 6 règles donne une matrice de 12 configurations possibles illustrées dans le tableau suivant :
| 9 participants : ·
1 utilisateur A
|
Create 2 slots |
Create a slot for each destination |
|||
| Create a slot for each role and group |
Resolve all roles and groups to users |
Create a slot for each role and group |
Resolve all roles and groups to users |
||
| Plan just once |
1 seule tâche commune est créée (avec un numéro de série SN unique) avec 2 accès simultanés (2 slots) partagés par les 9 utilisateurs |
1 seule tâche commune est créée (SN unique) avec : · 1 slot destiné à l’utilisateur A · 1 slot destiné à l’utilisateur B · 1 slot destiné au groupe G (partagé par ses 3 utilisateurs) · 1 slot destiné au rôle R (partagé par ses 4 utilisateurs) |
1 seule tâche commune est créée (SN unique) avec 9 accès simultanés (9 slots). Chacun des 9 utilisateurs aura son propre slot |
||
| Plan per destination |
All at once |
4 tâches sont créées simultanément (4 SN différents) : · 1 tâche pour l’utilisateur A avec 1 slot · 1 tâche pour l’utilisateur B avec 1 slot · 1 tâche pour le groupe G avec 2 slots partagés par ses 3 utilisateurs · 1 tâche pour le rôle R avec 2 slots partagés par ses 4 utilisateurs |
9 tâches sont créées simultanément (9 SN différents) pour les 9 utilisateurs avec 1 accès simultané (1 slot) pour chaque tâche (chacun des 9 utilisateurs aura sa propre tâche avec son propre slot) |
4 tâches sont créées simultanément (4 SN différents) : · 1 tâche pour l’utilisateur A avec 1 slot · 1 tâche pour l’utilisateur B avec 1 slot · 1 tâche pour le groupe G avec 1 slot partagé par ses 3 utilisateurs · 1 tâche pour le rôle R avec 1 slot partagé par ses 4 utilisateurs |
9 tâches sont créées simultanément (9 SN différents) pour les 9 utilisateurs avec 1 accès simultané (1 slot) pour chaque tâche (chacun des 9 utilisateurs aura sa propre tâche avec son propre slot) |
| One at a time |
4 tâches sont créées une à une (4 SN différents, dès qu'une tâche est traitée le workflow crée la suivante et ainsi de suite) : · 1 tâche pour l’utilisateur A avec 1 slot · 1 tâche pour l’utilisateur B avec 1 slot · 1 tâche pour le groupe G avec 2 slots partagés par ses 3 utilisateurs · 1 tâche pour le rôle R avec 2 slots partagés par ses 4 utilisateurs |
9 tâches sont créées une à une (9 SN différents, dès qu'une tâche est traitée le workflow crée la suivante et ainsi de suite) destinées aux 9 utilisateurs avec 1 accès simultané (1 slot) pour chaque tâche (chacun des 9 utilisateurs aura sa propre tâche avec son propre slot) |
4 tâches sont créées une à une (4 SN différents, dès qu'une tâche est traitée le workflow crée la suivante et ainsi de suite) : · 1 tâche pour l’utilisateur A avec 1 slot · 1 tâche pour l’utilisateur B avec 1 slot · 1 tâche pour le groupe G avec 1 slot partagé par ses 3 utilisateurs · 1 tâche pour le rôle R avec 1 slot partagé par ses 4 utilisateurs |
9 tâches sont créées une à une (9 SN différents, dès qu'une tâche est traitée le workflow crée la suivante et ainsi de suite) destinées aux 9 utilisateurs avec 1 accès simultané (1 slot) pour chaque tâche (chacun des 9 utilisateurs aura sa propre tâche avec son propre slot) |
|
Prenons par exemple la règle [Plan per destination], le nombre de tâche que créera le workflow est proportionnel au nombre de participants. Pour donc 2 groupes de 100 utilisateurs, le workflow va générer jusqu’à 200 tâches correspondant à 200 instances d'activité, et si en plus votre activité contient des événements généraux (lecture et écriture de données d'une base par exemple), alors l'exécution de ces événements sera répétée 200 fois inutilement.
Quant à la règle [Plan just once], dans certain cas, elle peut aussi poser un petit problème d'usage. Prenons l'exemple d'une demande d'approbation par formulaire à 3 utilisateurs (pas de groupes et pas de rôles). Selon notre matrice, 2 cas de figure se dessinent :
- Cas 1 (Plan just once / Create a slot for each destination) : dans ce cas, les 3 utilisateurs reçoivent une notification de tâche. Les 3 utilisateurs accèdent simultanément au formulaire de la tâche, mais c'est le premier utilisateur (le plus rapide) qui approuve (ou rejette) la demande qui gagne. Les 2 autres auront un message d'erreur (qui n'ai pas très très convivial) s'ils essayent de l'approuver (ou la rejeter) car la tâche n'existe plus. Ces deux utilisateurs peuvent ne pas comprendre comment ils ont pu accéder au formulaire pour le traiter et commencer même à introduire leur approbation sans qu'ils ne puissent le terminer.
- Cas 2 ( Plan just once / Create 1 slot ) : dans ce cas, les 3 utilisateurs reçoivent une notification de tâche, mais c'est le premier utilisateur (le plus rapide) qui accède au formulaire de la tâche qui gagne. Les 2 autres auront un messaged'erreur (qui n'ai pas très très convivial) s'ils essayent d'y accéder car la tâche est verrouillée (slot occupé par le premier utilisateur). Ces deux utilisateurs peuvent ne pas comprendre qu'ils ne peuvent pas y accéder à cause du slot occupé et que seul le premier utilisateur peut la traiter ou la libérer. La demande risque donc de rester bloquée si aucune intervention ni de la part du premier utilisateur ni de la part de l'administrateur K2 n'est faite.
A fin de remédier à cette situation, une solution est possible consiste à mettre en place un mécanisme de verrouillage et de déverrouillage personnalisé, dont les étapes sont les suivantes :
L'intelligence artificielle dans les processus métiers d'entreprise
Et l'IA par-ci, et l'IA par-là ! On ne jure que de l'IA depuis quelques temps, des prévisions et des annonces à la pelle ne cessent de voir le jour, promettant la quatrième révolution industrielle qui changera radicalement la surface de la terre, cette terre que nous, espèce humaine allons apparemment bientôt devoir la partager avec une autre espèce qu'est les Robots ! Mmm.. j'ai comme l'impression de regarder une publicité commerciale qui essaye de me vendre les merveilles d'un produit qui, au final, ne me servirait peut-être pas a grand-chose, car même si les investissements sur les technologies de l'IA dans le monde sont estimés à être dix fois plus élevés d'ici quelques années, une grande incertitude plane sur le retour de ses investissements.
Comment afficher une liste de données SharePoint sous format graphique en utilisant HighCharts
Highcharts est une librairie graphique multi-plateforme basée sur JavaScript. Optimisées pour appareils mobiles, elle permet l'intégration de graphiques réactifs rendant les données beaucoup plus interactives et facile à comprendre. Afin d'intégrer cette librairie dans SharePoint Online et utiliser ses graphes pour visualiser les informations de vos listes, vous devez récupérer d'abord les données de ces listes à l'aide d'un modèle de programmation client (comme CSOM Client-side Server Object Model ou JSOM JavaScript Object Model ou REST ) comme ci-dessous avec JSOM :
Comprendre le fonctionnement des pop-ups de confirmation dans K2 Smartforms
Les pop-ups de confirmation dans K2 Smartforms sont sous la forme de "OK-Cancel Confirmation" et non pas sous la forme "Yes-No Confirmation", la différence réside dans la logique du traitement des règles qui suivent la réponse de l'utilisateur. Cet article explique comment utiliser les OK-Cancel Confirmation de K2 Smartforms et comment les transformer en Yes-No Confirmation.Comme le montre l'exemple ci-dessous, les OK-Cancel confirmation ne permettent pas d'exécuter un traitement si l'utilisateur clique sur Cancel, par contre si l'utilisateur clique sur OK toute les règles qui suivent vont être exécutées.