Si vous avez utilisé Nintex pour Microsoft 365, vous avez sûrement dû utiliser des component workflows (pour faire simple, ce sont des appels de « sous workflows »). Ce sont des bouts de workflows dont on déporte l’exécution dans d’autres workflows afin d’améliorer les performances ou de permettre la réutilisabilité de certaines actions.

Hors, lorsqu’on utilise un Component Workflow (CWF) dans un workflow(WF), il se peut que notre WF finisse par rester bloqué.
En effet, si le workflow appelant est en attente de la fin d’exécution du component workflow (« Wait for Component Workflow to complete before continue ») et que le CWF est en erreur, alors le WF appelant restera dans un état bloqué (il sera en cours, sans aucun message d’erreur).
Effectivement, il est en attente de la fin d’exécution de l’instance de CWF, qui elle, sera en erreur, l’instance du component workflow ne sera jamais terminée normalement et ne rendra jamais la main au workflow appelant.
La seule solution sera de, manuellement, forcer le workflow appelant à se terminer et de le relancer, ce qui soit dit en passant n’est pas une solution viable.

Pour éviter ce cas, un simple pattern de conception peut être mis en place lors de l’appel aux component workflows!

Le principe

Utiliser un parallel block pour exécuter en concurrence :

• L’appel au component workflow
• Une pause d’un certain délai. Passé ce délai, le workflow considérera que le component workflow a planté et continuera son exécution. On définira certaines valeurs de variable (des valeurs par défaut pour les variables devant être retournées par le component workflow afin que le workflow ne plante pas, si ces variables sont requises)

Le design du workflow est présenté dans l’image ci-contre.

La mise en place

  1. Set Worklow variable (« init Continues ») : Définir une variable « Continue » de type bool sur valeur « False »
  2. Parallel Block : Configurer le « completion conditon » sur la variable « Continue ». Tant qu’elle est à False, le parallel bloc attendra la complétion des deux branches. C’est une des deux branches qui décidera de continuer le workflow (soit lorsque le component aura fini son exécution, soit lorsque le délai estimé d’exécution du component workflow sera passé)
  3. A. Branche de gauche : Run Component : Faire l’appel à votre CWF
  4. A. Branche de gauche : Set variable (« Set Continue ») : Mettre la valeur de la variable « Continue » à True

3. B. Branche de droite : Pause (« Pause for 1h ») : Faire une pause d’un certain temps. Passé ce délai, on estime que le CWF est en erreur/n’a pas pu répondre. Dans l’exemple, c’est une pause d’une heure (ce qui laisse généralement le temps à un workflow de s’exécuter)

4B. Branche de droite : Consigner dans l’historique : Un simple log dans l’historique de notre workflow pour dire que le component workflow est en erreur
5B. Branche de droite : Set variable (« Set default value ») : Mettre la valeur de la variable « Continue » à True. Définition des valeurs par défaut des variables devant être retournées par le component workflow.

À la sortie du parallel block, on aura alors deux cas :
• L’exécution du component workflow s’est correctement déroulée, toutes les variables auront les valeurs retournées par celui-ci.
• L’exécution du component workflow est en erreur, alors toutes les variables auront les valeurs par défaut définies à l’étape 5.B.

Il ne vous reste plus qu’à gérer ce dernier cas dans la logique de votre workflow.