Description du scénario
L'utilisateur final ou l'administrateur a édité un formulaire qui a déclenché un flux de travaux. L'instance sur laquelle le flux de travaux s'exécute est en général la même que celle sur laquelle la session de l'utilisateur se trouve sauf dans le cas de certaines tâches programmées où ces instances peuvent différer. Ces instances tombent en panne alors que le flux de travaux est en cours.
Sans persistance des sessions
Expérience utilisateur : basculement non transparent. L'envoi du formulaire ramène l'utilisateur à la page de connexion. L'instance de la tâche de flux de travaux en cours d'exécution devrait figurer dans le référentiel mais comme le nœud d'exécution est en panne, le statut du flux de travaux sera « arrêté ».
Étapes de reprise : le flux de travaux doit être envoyé de nouveau. Cela doit se faire en revenant au même formulaire et en entrant de nouveau les informations déjà utilisées pour déclencher le flux de travaux avant la défaillance du nœud.
L'envoi des mêmes données de demande peut fonctionner dans certains cas mais pas dans tous. Si le flux de travaux provisionne pour plusieurs ressources pendant son exécution et que certaines de ces ressources étaient provisionnées avant la défaillance, le nouvel envoi du flux de travaux par l'utilisateur devra tenir compte des ressources « déjà provisionnées ». Vous remarquerez que le flux de travaux arrêté reste dans le référentiel jusqu'à ce que resultLimit expire sur l'objet TaskInstance.
Avec persistance des sessions
Expérience utilisateur : basculement non transparent. L'utilisateur n'est pas déconnecté car sa session est continuée et rétablie dans la nouvelle instance. L'envoi du formulaire, toutefois, se traduira probablement par une erreur car le flux de travaux sera arrêté. Ce basculement n'est pas transparent car des actions de reprise sont nécessaires.
Étapes de reprise : identiques à celles du mode Sans persistance des sessions. L'utilisateur doit envoyer de nouveau la demande qui a déclenché le flux de travaux précédent avec des paramètres identiques ou modifiés.
Autres exemples de scénarios
Un utilisateur final vient d'envoyer une demande d'auto-enregistrement pour créer un compte Identity Manager quand l'instance tombe en panne.
Un administrateur vient d'envoyer une demande « Réinitialiser le mot de passe » qui est en cours quand l'instance tombe en panne.