5.9. 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

5.9.1. IHM

Il existe une page dans l’IHM de démo, 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 possible à partir de cette IHM de relancer le processus ou bien de rejouer une étape, après action d’exploitation.

5.9.2. Appels REST

Il est tout aussi possible d’exécuter ces différentes actions sur l’API en direct, via des appels curl par exemple.

Il suffit juste de lancer un appel curl sur l’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.

5.9.3. Worklow en FATAL

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

5.9.3.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 et ne répond plus, alors un FATAL pourra être obtenu pour tous les Handlers et plugins.

Si le composant Logbook est défectueux et ne répond plus, alors un FATAL pourra être obtenu pour tous les Handlers, mais pour des raisons plus précises, pour ces handlers :
  • CommitLifeCycleActionHandler
  • CommitLifeCycleObjectGroupActionHandler
  • CommitLifeCycleUnitActionHandler
  • ListLifecycleTraceabilityActionHandler
  • FinalizeLifecycleTraceabilityActionHandler
  • RollBackActionHandler
Si le composant FunctionalAdministration est défectueux et 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 et 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 et 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 ProcessingManagement est défectueux et 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

5.9.3.2. Distributor

Plusieurs cas peuvent provoquer un FATAL au niveau du processing :
  • si Metadata ou Workspace est down
  • si un Handler (ou plugin) inexistant est appelé.
  • si le distributeur tente d’appeler une famille de worker inexistante

5.9.3.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.

5.9.4. Redémarrer un processus en cas de pause

5.9.4.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.

5.9.4.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.

5.9.4.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ézippé dans le sous répertoire SIP).

5.9.4.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 juste de lancer un appel curl sur l’access external : PUT sur le endpoint /operations/GUID avec comme header X-Action:REPLAY.

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

5.9.4.2.3. Prochaine étape

Depuis l’IHM, exécuter l’étape suivante en cliquant sur l’icône “Next”. Via les API, il suffit juste de lancer un appel curl sur l’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, normalement, le statut du workflow doit passer à OK et l’état à PAUSE.

5.9.4.2.4. Finaliser le workflow

Une fois sûrs de notre coup, il est maintenant 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 juste de lancer un appel curl sur l’access external : PUT sur le endpoint /operations/GUID avec comme header X-Action:RESUME.