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.