Comprendre les scénarios de panne

Cette section contient huit scénarios de panne et compare deux déploiements, l'un avec persistance des sessions, l'autre sans.

• Le déploiement avec persistance des sessions assure l'affinité de session au travers d'un équilibreur de charge. Ce déploiement a dans un cluster plusieurs instances ayant une forme de persistance des sessions activée de sorte que les changements de session sont écrits dans un nœud de référentiel physiquement distinct.

• Le déploiement sans persistance des sessions assure l'affinité de session au travers d'un équilibreur de charge et a plusieurs instances ne faisant pas partie d'un cluster.

Scénario 1 : Scénario Pas de flux de travaux

Description du scénario

L'utilisateur final ou l'administrateur édite un formulaire ne faisant pas partie d'un flux de travaux. L'instance sur laquelle l'utilisateur a une session établie tombe en panne.

Sans persistance des sessions

Expérience utilisateur : basculement non transparent. Lorsqu'il envoie le formulaire, l'utilisateur est ramené à la page de connexion.

Étapes de reprise : l'utilisateur entre de nouveau son nom d'utilisateur et son mot de passe. Identity Manager traite alors le formulaire et présente les résultats dans la page suivant immédiatement la connexion.

Avec persistance des sessions

Expérience utilisateur : le formulaire de l'utilisateur est envoyé et les résultats sont retournés sans que l'utilisateur ne soit déconnecté ni doive consécutivement se reconnecter.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Autres exemples de scénarios

• Un utilisateur final s'est connecté et a récupéré des résultats de recherche pour des utilisateurs ou d'autres objets du référentiel lorsque l'instance tombe en panne.

• Un administrateur est sur le point d'envoyer une demande « Réinitialiser le mot de passe » ou « Éditer l’utilisateur » en utilisant l'interface Administrateur lorsque l'instance tombe en panne.

Scénario 2 : Scénario Flux de travaux en cours

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.

Scénario 3 : Scénario Flux de travaux en suspens ou endormi

Description du scénario

Ce scénario couvre les cas de figure dans lesquels le flux de travaux a démarré mais attend une action manuelle de la part d'un approbateur.

Sans persistance des sessions

Expérience utilisateur : basculement transparent en ce qui concerne l'approbateur, du moment que ce dernier ne s'est pas encore connecté. Après la défaillance du nœud, l'approbateur se connectant verra quand même la demande d'approbation dans sa boîte de réception et ce, même si cette demande a été déclenchée depuis un nœud qui n'est plus activé.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise :identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

• Le flux de travaux est à l'état de sommeil, il s'agit par exemple d'une action manuelle qui reste endormie jusqu'à une date d'ouverture ou de clôture pour un employé.

• Un administrateur a envoyé une demande de création d'utilisateur qui attend qu'un approbateur se connecte et l'approuve. Le nœud depuis lequel la demande a été envoyée est tombé en panne avant que l'approbateur n'approuve la demande.

Scénario 4 : Scénario Édition d'un élément de travail

Description du scénario

Ce scénario inclut les cas de figure dans lesquels un utilisateur est en train d'éditer un élément de travail et où le nœud sur lequel l'utilisateur a une session tombe en panne avant qu'il puisse envoyer l'élément de travail en question.

Sans persistance des sessions

Expérience utilisateur : basculement non transparent. Lorsque le formulaire d'édition de l'élément de travail est envoyé, l'utilisateur est déconnecté et ramené à la page de connexion.

Étapes de reprise : lors du renvoi des données d'identification de connexion, l'élément de travail de l'utilisateur est marqué comme étant terminé et le flux de travaux peut reprendre à partir de ce point. Le flux de travaux doit être sélectionné par le nouveau mode pour l'exécution à partir du point où l'action manuelle de l'utilisateur est marquée comme étant terminée.

Avec persistance des sessions

Expérience utilisateur : lorsque le formulaire d'édition de l'élément de travail est envoyé, l'utilisateur voit l'effet de son envoi, par exemple le formulaire suivant dans le flux de travaux personnalisés s'il y en a un, ou un message de réussite.

Étapes de reprise : aucune action de l'utilisateur n'est nécessaire.

Autres exemples de scénarios

• Un utilisateur final remplit un formulaire associé à une action manuelle dans un flux de travaux personnalisé, par exemple pour demander l'accès à des ressources spécifiques. Le nœud sur lequel réside la session de l'utilisateur tombe en panne avant que ce dernier ne parvienne à envoyer sa demande.

• Un administrateur s'est connecté à Identity Manager et a ouvert une demande d'approbation d'édition. Le nœud sur lequel réside la session de l'administrateur tombe en panne avant que ce dernier ne parvienne à envoyer sa demande.

Scénario 5 : Scénario Tâches programmées en cours

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels une panne de nœud se produit alors qu'une réconciliation est en cours ou qu'un rapport est en cours d'exécution.

Sans persistance des sessions

Expérience utilisateur : la tâche programmée s'arrête en cours.

Étapes de reprise : la tâche programmée qui était en cours doit être redémarrée. La tâche recommencera au début (pas à partir du point de panne). Cela revient à créer et démarrer une nouvelle tâche.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

• Un adaptateur Active Sync est configuré pour s'exécuter sur le nœud en panne.

Scénario 6 : Scénario Tâche programmée en suspens

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels le flux de travaux personnalisé d'un utilisateur a programmé une tâche pour qu'elle s'exécute à une date ultérieure sur un nœud spécifique. Le nœud sur lequel la tâche a été programmée tombe en panne avant la date prévue.

Sans persistance des sessions

Expérience utilisateur : le basculement est transparent en ce qui concerne les actions de reprise requises pour assurer que la tâche en question s'exécute à l'heure programmée.

Étapes de reprise : la tâche programmée est reprise par un nœud actif lorsque l'heure d'exécution programmée arrive.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Autres exemples de scénarios

• Dans le processus de création d'un compte utilisateur, le scannage des tâches différées est utilisé pour implémenter l'activation du compte à une date d'ouverture ou sa désactivation à une date de clôture. Le nœud sur lequel la tâche a été programmée tombe en panne avant la date d'ouverture ou de clôture prévue.

• Un rapport est programmé pour s'exécuter à une heure ultérieure ou une réconciliation est programmée pour s'exécuter à une heure spécifique et, le nœud sur lequel la tâche a été programmée tombe en panne avant l'heure prévue.

Scénario 7 : Scénario Demande de services Web pas encore reçue par Identity Manager

Description du scénario

Ces scénarios couvrent les cas de figure dans lesquels l'IUG d'Identity Manager n'est pas utilisée pour lancer le provisioning. À la place, l'interface utilisateur est fournie par une application qui émet en interne un appel vers Identity Manager en utilisant SPML ou une autre interface de service Web personnalisée. Ici, la session utilisateur relative à l'utilisateur qui suit l'IG est gérée au moyen de l'application appelante. Pour Identity Manager, les demandes sont toutes lancées en tant qu'objet « soapadmin ».

Dans un tel cas d'utilisation, ce scénario de panne couvre le cas dans lequel la demande par l'intermédiaire du point d'extrémité Identity Manager n'a pas encore été reçue et où le nœud ciblé est tombé en panne.

Sans persistance des sessions

Expérience utilisateur : basculement transparent. Les données d'identification de l'administrateur SOAP sont transférées pour chaque demande SOAP, soit via câble soit au sein d'Identity Manager par le biais du paramètre Waveset.properties. Du moment que le nœud qui devait recevoir cette demande SOAP ne l'a pas reçue avant de tomber en panne, le basculement est transparent avec ou sans persistance des sessions.

Étapes de reprise : aucune action n'est nécessaire. La demande SOAP est envoyée à un nœud actif qui l'exécute.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.

Scénario 8 : Scénario Demande de services Web en cours par Identity Manager

Description du scénario

Ce scénario est similaire au scénario sept. La seule différence est que le flux de travaux est en cours quand le nœud tombe en panne, ou que le nœud a reçu la demande SOAP avant de tomber en panne.

Sans persistance des sessions

Expérience utilisateur : ce scénario est similaire au scénario deux (flux de travaux en cours). Le flux de travaux est marqué comme étant arrêté et l'utilisateur voit une erreur en tant que résultat de la demande SOAP.

Étapes de reprise : l'utilisateur doit renvoyer le formulaire avec des paramètres similaires ou modifiés (selon le point du flux de travaux auquel la panne s'est produite) en utilisant l'interface utilisateur dans l'application tiers.

Avec persistance des sessions

Expérience utilisateur : identique à celle du mode Sans persistance des sessions.

Étapes de reprise : identiques à celles du mode Sans persistance des sessions.