Événements et gestionnaire d'événement

Les événements sont des structures de donnée simples qui peuvent être créés via docuteam feeder Event API ou générés de manière interne par feeder. Avec les gestionnaires d'événement, il est possible de définir des règles qui démarrent automatiquement un ou plusieurs workflows si un événement avec des propriétés spécifique se produit.

Les événements sont listés dans l'onglet "Événements", Les propriétés d'un événement peuvent être affichée en cliquant sur afficher.

Les gestionnaires d'événement peuvent être configurés dans l'onglet administrateur sous "Gestionnaires d'événement"

Structure d'un événement

Un événement a toujours au moins deux propriétés:

• source: l'origine d'un événement. L'origine d'un événement créé par feeder est toujours internal.
• event_type: Le type d'événement. Lors de la création d'un événement via l'API, un type arbitraire peut être défini. Les types d'événement créés par feeder sont documenté plus bas.

Configuration d'un gestionnaire d'événement

Lors de la création d'un gestionnaire d'événement, il faut définir au moins un nom et le workflow qui doit être démarré par le gestionnaire d'événement. Un gestionnaire d'événement défini avec ce minimum démarrera le workflow choisi à chaque événement.

Dans le champ Attribut du payload à utiliser comme SIP lors de l’exécution du flux, il est possible de définir quel propriété de l'événement sera transférée au workflow. Si cette propriété n'existe pas dans l'événement, aucun workflow ne sera démarré. Si un SIP ou une déposition doivent être transférés au workflow, il faut utiliser la valeur resource

Le nombre de champs indiqués dans la section Attributs à transmettre dépend du workflow sélectionné. Pour chaque paramètre requis par le workflow sélectionné, une propriété de l'événement doit être définie, dont la valeur doit être transmise en tant que paramètre au workflow Veuillez noter que si cette propriété n'existe pas dans un événement, aucun workflow ne sera lancé.

Créateur du gestionnaire d'événement permet de définir le nom de celui qui doit avoir créé l'événement (ce n'est que pertinent pour les événements créer par l'Event API de docuteam feeder).

Flux auquel le gestionnaire d'événement réagit permet de choisir un workflow qui doit avoir créé l'événement. Cela peut être utile pour lancer un workflow de nettoyage une fois un workflow terminé.

En cliquant sur Ajouter une règle d'attribut, il est possible d'ajouter des vérifications supplémentaires des propriétés de l'événement.

Il faut noter que ces règles sont liées par des ET logique et sont toujours comparées exactement. Si un gestionnaire d'événement a une règle qui cherche pour des événement de type test type, mais que l'événement est créé avec le type test-type, aucun workflow ne sera exécuté par le gestionnaire d'événement.

Cas d'utilisation

Migration de Fedora 3 à Fedora 6

Pour migrer de Fedora 3 à Fedora 6, feeder a besoin de savoir quels PIDs sont présents dans Fedora 3 et quels PIDs sont déjà présents dans Fedora 6. En se basant sur cette information, un DIP est créé et migré pour chaque PID qui n'est pas présent dans Fedora 6.

Pour cela, actions.js communique avec les deux systèmes Fedora et utilise l'API de docuteam feeder pour créer un événement par PID qui doit être migré avec le PID comme attribut et le type MigratablePID. Dans feeder, un gestionnaire d'événement qui réagit aux événement de type MigratablePID peut être créé afin de démarrer un workflow qui reçoit le PID comme paramètre SIP. On peut ainsi s'assurer que le DIP est uniquement créer pour les paquet qui sont migrés sur le moment même au lieu de créer d'un coup un DIP pour chaque objet.

{
  "PID": "CH-002003-9:1553",
  "source": "actions.js",
  "event_type": "MigratablePID"
}

Déposition de paquet de différents format en utilisant docuteam feeder Deposition API

Jusqu'à maintenant, il n'était pas possible de déposer des paquet de formats différent avec Deposition API, car un seul workflow spécifique pouvait traiter les dépositions.

Avec les événements, la création d'un déposition génère un événement qui contient le format du paquet comme propriété. De cette manière, il est possible de définir un gestionnaire d'événement distinct par format de paquet qui réagit aux événements de type Deposition Creation. Ces gestionnaires d'événements peuvent ensuite démarrer des workflows spécifiques qui peuvent traiter le format de paquet en question.

Événements générés par feeder

Comme mentionné, feeder génère des événements interne qui peuvent être utilisé pour définir des gestionnaires d'événement.

Changement de statut d'un workflow

Si le statut d'un workflow change, un événement de type WorkflowExecution Status Change est créé par feeder.

Cet événement contient les propriétés suivantes:

{
  "source": "internal",
  "event_type": "WorkflowExecution Status Change",
  "new_status": "failed",
  "source": "internal",
  "workflow_execution_id": 7,
  "workflow_id": 1,
  "sip": 4,
  "sip_type": "deposition"
}

Explication des propriétés:

• source: Toujours internal, car l'événement est créé par feeder.
• new_status: Soit failed soit finished.
• workflow_execution_id: ID d'exécution du worflow qui a créé l'événement.
• workflow_id: ID du workflow utilisé dans l'exécution de workflow qui a créé l'événement.

Toutes les autres propriétés dépendent ensuite des paramètres du workflow utilisé. En général, pour chaque paramètre, feeder ajoutera une propriété à l'événement. Dans le cas où un paramètre est de type file or folder, feeder ajoutera une propriété supplémentaire nommée type qui est soit deposition soit other.

Déposition créée

Si une déposition est créer dans feeder (soit en utilisant l'interface web dans l'onglet dépositions, soit en utilisant la Depositions API un événement de type Deposition Creation est créé.

Cet événement contient les propriétés suivantes:

{
  "source": "internal",
  "event_type": "Deposition Creation",
  "resource_type": "deposition",
  "package_format": "MatterhornMETSv1.0",
  "resource_value": 12
}

Explication des propriétés:

• source: Toujours internal, car l'événement est créé par feeder.
• resource_type: Toujours deposition.
• resource_value: ID de la déposition.
• package_format: format de paquet de la déposition.