6.8. Suivi des Workflows

La solution logicielle VITAM intègre une solution de suivi et de gestion des Workflows. Elle permet entre autres de :

  • Relancer un Workflow arrêté
  • Mettre en pause un Workflow démarré
  • Rejouer une étape d’un Workflow
  • Annuler un workflow

6.8.1. Suivi

Le suivi peut être réalisé via IHM, par des appels REST ou par un playbook ansible.

6.8.1.1. IHM

Il existe une page dans l”IHM de démonstration, permettant d’influer sur les processus en cours. Tous les processus mis en pause, automatiquement (lors d’un FATAL) ou bien manuellement (Mode pas à pas) apparaissent sur cette IHM. Il est également possible, à partir de cette IHM, de relancer le processus ou bien de rejouer une étape, après action d’exploitation.

6.8.1.2. Appels REST

Il est possible d’exécuter ces différentes actions sur l”API en direct, via des appels curl par exemple sur le composant access-external :

  • PUT sur le endpoint /operations/GUID avec comme header X-Action:RESUME par exemple.

Pour plus d’information, consulter la documentation des API externes.

6.8.1.3. Playbook ansible

Lancer le script suivant

   ansible-playbook ansible-vitam-exploitation/check_workflow_status.yml -i environments/hosts.<environnement> --ask-vault-pass -e '{"vitam_tenant_ids":[0,1,2], "states":[PAUSE,RUNNING,COMPLETED], "statuses":[UNKNOWN, STARTED, OK, WARNING, KO, FATAL]}'

Paramètres optionnels:
  • vitam_tenant_ids: Pour spécifier la liste des tenants à interroger (default values = variable vitam_tenant_ids defined in environments/ files)
  • states: Pour filter sur l’état des process (valid values = [RUNNING, PAUSE, COMPLETED])
  • statuses: Pour filtrer sur le status des process (valid values = [UNKNOWN, STARTED, OK, WARNING, KO, FATAL])

Avertissement

Le playbook ansible ne peut être exécuté que dans le cas où une installation a déjà été effectuée, et que la PKI n’a pas été rejouée (les certificats présents dans environments/certs doivent être ceux mis en place dans VITAM).

6.8.2. Cas des worklows en FATAL

Un workflow se met en pause dès qu’il se retrouve en statut FATAL. Plusieurs causes peuvent expliquer un tel état.

6.8.2.1. Plugins et Handlers

Plusieurs problèmes peuvent expliquer qu’un Handler ou un plugin retourne une erreur « FATAL » et donc provoque la mise en pause du Worfklow.

Si le composant workspace est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour tous les Handlers et plugins.

Si le composant logbook est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour les handlers suivants :

  • CommitLifeCycleActionHandler
  • CommitLifeCycleObjectGroupActionHandler
  • CommitLifeCycleUnitActionHandler
  • ListLifecycleTraceabilityActionHandler
  • FinalizeLifecycleTraceabilityActionHandler
  • RollBackActionHandler

Si le composant functional-administration est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour les Handlers suivants :

  • CheckArchiveProfileRelationActionHandler
  • CheckArchiveProfileActionHandler
  • GenerateAuditReportActionHandler
  • PrepareAuditActionHandler

Si le composant metadata est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour les Handlers suivants :

  • AccessionRegisterActionHandler
  • ListArchiveUnitsActionHandler
  • PrepareAuditActionHandler
  • ArchiveUnitRulesUpdateActionPlugin
  • AuditCheckObjectPlugin
  • IndexObjectGroupActionPlugin
  • IndexUnitActionPlugin
  • RunningIngestsUpdateActionPlugin

Si le composant storage est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour les Handlers suivants :

  • CheckStorageAvailabilityActionHandler
  • FinalizeLifecycleTraceabilityActionHandler
  • GenerateAuditReportActionHandler
  • PrepareTraceabilityCheckProcessActionHandler
  • PutBinaryOnWorkspace
  • CheckIntegrityObjectPlugin
  • CheckExistenceObjectPlugin
  • StoreMetaDataObjectGroupActionPlugin
  • StoreMetaDataUnitActionPlugin
  • StoreObjectActionHandler
  • StoreObjectGroupActionPlugin

Si le composant processing est défectueux ou ne répond plus, alors un FATAL pourra être obtenu pour les Handlers suivants :

  • ListRunningIngestsActionHandler

Si le composant FormatIdentifier est défectueux et ne répond plus, alors un FATAL pourra être obtenu pour le Handler suivant :

  • FormatIdentificationActionPlugin

6.8.2.2. Distributor

Plusieurs cas peuvent provoquer un FATAL au niveau du processing :

  • si metadata ou workspace est injoignable
  • si un handler (ou plugin) inexistant est appelé.
  • si le distributeur tente d’appeler une famille de worker inexistante

6.8.2.3. Processing - State Machine

Dans le cas ou le Processing ne parvient pas à enregistrer l’état du workflow sur le workspace, un FATAL est provoqué. Il en va de même si le composant logbook est défectueux.

6.8.3. Redémarrer un processus en cas de pause

6.8.3.1. Trouver la cause

De manière générale, il convient d’identifier le composant (ou les composants) posant problème. Il s’agira majoritairement de metadata, de logbook, du storage ou encore du workspace.

A partir du Guid de l’opération mise en pause, il est facilement possible de voir, dans les logs du processing ou des workers quels sont les composants incriminés.

6.8.3.2. Relancer le Workflow

A partir du Guid de l’opération mise en pause et une fois le composant redémarré, il est possible de relancer le workflow.

6.8.3.2.1. Vérifier les inputs

S’assurer à partir du GUID de l’opération que l’on nommera X la présence :
  • d’un fichier X.json dans /vitam/data/workspace/process/distributorIndex/
  • d’un répertoire X dans /vitam/data/workspace/ contenant à minima une liste de sous-répertoires (et notamment le SIP décompressé dans le sous répertoire SIP).

6.8.3.2.2. Rejouer une étape

Depuis l”IHM, relancer l’étape précédente en cliquant sur l’icône « Replay ». Via les API, il suffit de lancer un appel curl sur le composant access external : PUT sur le endpoint /operations/GUID avec comme header X-Action:REPLAY.

Cette action aura pour résultat d’exécuter une deuxième fois l’étape qui a échoué. En sortie de ce replay, le statut du workflow doit passer à OK et l’état à PAUSE.

6.8.3.2.3. Prochaine étape

Depuis l”IHM, exécuter l’étape suivante en cliquant sur l’icône « Next ». Via les API, il suffit de lancer un appel curl sur le composant « access-external » : PUT sur le endpoint /operations/GUID avec comme header X-Action:NEXT.

Cette action aura pour résultat d’exécuter l’étape suivante. En sortie de ce replay, le statut du workflow doit passer à OK et l’état à PAUSE.

6.8.3.2.4. Finaliser le workflow

Il est possible de poursuivre le workflow jusqu’à son terme.

Depuis l”IHM, finaliser le workflow en cliquant sur l’icône « Fast Forward ».

Via les API, il suffit de lancer un appel curl sur le composant access-external : PUT sur le endpoint /operations/GUID avec comme header X-Action:RESUME.