3.3. Collection LogbookLifeCycleUnit

3.3.1. Utilisation de la collection LogbookLifeCycleUnit

Le journal du cycle de vie d’une unité archivistique (ArchiveUnit) trace tous les événements qui impactent celle-ci dès sa prise en charge dans le système. Il doit être conservé aussi longtemps que l’unité archivistique est gérée par le système.

  • dès la réception d’une unité archivistique, l’ensemble des opérations qui lui sont appliquées est tracé.
  • les journaux du cycle de vie sont « committés » une fois le stockage des objets et l’indexation des métadonnées effectués sans échec, avant l’envoi d’une notification au service versant.

Chaque unité archivistique possède une et une seule entrée dans la collection LogbookLifeCycleUnit.

3.3.2. Exemple de JSON stocké en base comprenant l’exhaustivité des champs de la collection LogbookLifeCycleUnit

Extrait d’un JSON correspondant à un journal de cycle du vie d’une unité archivistique.

{
  "_id": "aeaqaaaaaehbl62nabqkwak3k7qg5tiaaaaq",
  "evId": "aedqaaaaaghbl62nabqkwak3k7qg5tiaaabq",
  "evParentId": null,
  "evType": "LFC.LFC_CREATION",
  "evDateTime": "2017-04-10T12:39:37.933",
  "evIdProc": "aedqaaaaaghe45hwabliwak3k7qg7kaaaaaq",
  "evTypeProc": "INGEST",
  "outcome": "STARTED",
  "outDetail": "LFC.LFC_CREATION.STARTED",
  "outMessg": "!LFC.LFC_CREATION.STARTED!",
  "agId": "{\"Name\":\"vitam-iaas-app-02\",\"Role\":\"worker\",\"ServerId\":1041627981,\"SiteId\":1,\"GlobalPlatformId\":236321613}",
  "obId": "aeaqaaaaaehbl62nabqkwak3k7qg5tiaaaaq",
  "evDetData": null,
  "events": [
      {
          "evId": "aedqaaaaaghbl62nabqkwak3k7qg5tiaaabq",
          "evParentId": null,
          "evType": "LFC.CHECK_MANIFEST",
          "evDateTime": "2017-04-10T12:39:37.953",
          "evIdProc": "aedqaaaaaghe45hwabliwak3k7qg7kaaaaaq",
          "evTypeProc": "INGEST",
          "outcome": "OK",
          "outDetail": "LFC.CHECK_MANIFEST.OK",
          "outMessg": "Succès de la vérification de la cohérence du bordereau",
          "agId": "{\"Name\":\"vitam-iaas-app-02\",\"Role\":\"worker\",\"ServerId\":1041627981,\"SiteId\":1,\"GlobalPlatformId\":236321613}",
          "obId": "aeaqaaaaaehbl62nabqkwak3k7qg5tiaaaaq",
          "evDetData": null,
          "_lastPersistedDate": "2017-04-10T12:39:37.953"
      },
      {
          "evId": "aedqaaaaaghbl62n5g8ftak3k7qg5tiaaabq",
          "evParentId": "aedqaaaaaghbl62nabqkwak3k7qg5tiaaabq",
          "evType": "LFC.CHECK_MANIFEST.LFC_CREATION",
          "evDateTime": "2017-04-10T12:39:37.953",
          "evIdProc": "aedqaaaaaghe45hwabliwak3k7qg7kaaaaaq",
          "evTypeProc": "INGEST",
          "outcome": "OK",
          "outDetail": "LFC.CHECK_MANIFEST.LFC_CREATION.OK",
          "outMessg": "Succès de la création du journal du cycle de vie",
          "agId": "{\"Name\":\"vitam-iaas-app-02\",\"Role\":\"worker\",\"ServerId\":1041627981,\"SiteId\":1,\"GlobalPlatformId\":236321613}",
          "obId": "aeaqaaaaaehbl62nabqkwak3k7qg5tiaaaaq",
          "evDetData": null,
          "_lastPersistedDate": "2017-04-10T12:39:37.953"
      },{

      [...]

      }
  ],
  "_tenant": 1,
  "_v": 0,
  "_lastPersistedDate": "2017-04-10T12:39:37.953"
}

3.3.3. Détail des champs du JSON stocké en base

« _id »: identifiant donné par le système lors de l’initialisation du journal du cycle de vie.

  • Il est constitué d’une chaîne de 36 caractères correspondant à un GUID.
  • Cet identifiant constitue la clé primaire du journal du cycle de vie de l’unité archivistique. Il reprend la valeur du champ _id d’une unité archivistique enregistré dans la collection Unit.
  • Cardinalité : 1-1
  • Ce champ existe uniquement pour la structure incluante.

« evId » (event Identifier): identifiant de l’événement.

  • Il est constitué d’une chaîne de 36 caractères correspondant à un GUID.
  • Il identifie l’événement de manière unique dans la base.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« evParentId » (event Parent Identifier): identifiant de l’événement parent.

  • Il est constitué d’une chaîne de 36 caractères correspondant à un GUID.
  • Il identifie l’événement parent. Par exemple pour l’événement LFC.CHECK_MANIFEST.LFC_CREATION, ce champ fera référence au GUID de l’évènement LFC.CHECK_MANIFEST.
  • La valeur est toujours « null » pour la structure incluante et les tâches principales.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« evType » (event Type): code du type d’événement.

  • Il s’agit d’une chaîne de caractères.
  • La liste des valeurs possibles pour ce champ se trouve en annexe. Seul le code est stocké dans ce champ, la traduction se fait via un fichier properties (vitam-logbook-message-fr.properties).
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« evDateTime » (event DateTime): date de l’événement.

  • Il s’agit d’une date au format ISO8601 AAAA-MM-JJ+ »T »+hh:mm:ss:[3digits de millisecondes]

Exemple : "2016-08-17T08:26:04.227"

  • Ce champ est positionné par le client LogBook.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« evIdProc » (event Identifier Process): identifiant du processus.

  • Il s’agit d’une chaîne de 36 caractères.
  • Toutes les occurrences de ce champ pour un même document dans le journal du cycle de vie partagent la même valeur, qui est celle du champ « _id » d’une opération enregistrée dans la collection LogbookOperation
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« evTypeProc » (event Type Process): type de processus.

  • Il s’agit d’une chaîne de caractères.
  • Nom du processus parmi une liste de processus possibles fixée. Cette liste est disponible en annexe.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« outcome »: statut de l’événement.

  • Il s’agit d’une chaîne de caractères devant correspondre à une valeur de la liste suivante :

    • STARTED (Début de l’événement)
    • OK (Succès de l’événement)
    • KO (Echec de l’événement)
    • WARNING (Succès de l’événement comportant des alertes)
    • FATAL (Erreur technique)

  • Cardinalité : 1-1

  • Ce champ existe pour les structures incluantes et incluses.

« outDetail » (outcome Detail): code correspondant à l’erreur.

  • Il s’agit d’une chaîne de caractères.
  • Il contient le code fin de l’événement, incluant le statut. La liste des valeurs possibles pour ce champ se trouve en annexe. Seul le code est stocké dans ce champ, la traduction se fait via le fichier properties (vitam-logbook-message-fr.properties)
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« outMessg » (outcome Detail Message): détail du résultat de l’événement.

  • Il s’agit d’une chaîne de caractères.
  • C’est un message intelligible destiné à être lu par un être humain en tant que détail de l’événement.
  • Traduction du code présent dans outDetail issue du fichier vitam-logbook-message-fr.properties.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« agId » (agent Identifier): identifiant de l’agent réalisant l’évènement.

  • Il s’agit de plusieurs chaînes de caractères indiquant le nom, le rôle et le PID de l’agent. Ce champ est calculé par le journal à partir de ServerIdentifier.

Exemple : "agId": "{\"Name\":\"vitam-env-int-worker-01.vitam-env\",\"Role\":\"worker\",\"ServerId\":1044139788,\"SiteId\":1,\"GlobalPlatformId\":238833420}"

  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

« obId » (object Identifier): identifiant de la solution logicielle Vitam correspondant au GUID de l’unité archivistique sur laquelle s’applique l’opération.

  • Il s’agit d’une chaîne de 36 caractères correspondant à un GUID.
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses

« evDetData » (event Detail Data): détails des données de l’événement.

  • Donne plus de détails sur l’événement.

  • Par exemple, l’historisation de métadonnées lors d’une modification se fait dans ce champ. Dans la structure incluse correspondant à cet événement, il est, par exemple, composé du champ suivant :

    • diff: contient la différence entre les métadonnées d’origine et les métadonnées modifiées. Chaîne de caractères.

  • Cardinalité : 1-1

  • Ce champ existe pour les structures incluantes et incluses.

« events »: tableau de structure.

  • Pour la structure incluante, le tableau contient n structures incluses dans l’ordre des événements (date)
  • Cardinalité : 1-1
  • S’agissant d’un tableau, les structures incluses ont pour cardinalité 1-n.
  • Ce champ existe uniquement pour la structure incluante.

« _tenant »: identifiant du tenant

  • Il s’agit d’un entier.
  • Cardinalité : 1-1
  • Ce champ existe uniquement pour la structure incluante.

« _v »: version de l’enregistrement décrit

  • Il s’agit d’un entier.
  • Cardinalité : 1-1
  • Ce champ existe uniquement pour la structure incluante.
  • 0 correspond à l’enregistrement d’origine. Si le numéro est supérieur à 0, alors il s’agit du numéro de version de l’enregistrement.

« _lastPersistedDate »: date technique de sauvegarde en base.

  • Il s’agit d’une date au format ISO8601 AAAA-MM-JJ+ »T »+hh:mm:ss:[3digits de millisecondes]
  • Elle est renseignée par le serveur Logbook. Exemple : "2016-08-17T08:26:04.227"
  • Cardinalité : 1-1
  • Ce champ existe pour les structures incluantes et incluses.

3.3.4. Champs présents dans les events

  • evId
  • evParentId
  • evType
  • evDateTime
  • evIdProc
  • evTypeProc
  • outcome
  • outDetail
  • outMessg
  • agId
  • obId
  • evDetData
  • lastPersistedDate

3.3.5. Détail des champs du JSON stocké en base spécifiques à une mise à jour

Exemple de données stockées dans le champ evDetData :

"evDetData": "{\n  \"diff\" : \"-    Title : Gare du Nord\\n-    Description : Dite aussi gare de Paris-Nord, inscrite au titre des monuments historiques depuis le 15 janvier 1970.\\n+    Title : Gare du Nord (Paris-Nord)\\n+    Description : Inscrite au titre des monuments historiques depuis le 15 janvier 1975.\\n-    #operations : [ aeeaaaaaaghi422cab6saalew6tqhaaaaaaq, aeeaaaaaaghi422cabvlsalew7liymaaaaaq ]\\n+    #operations : [ aeeaaaaaaghi422cab6saalew6tqhaaaaaaq, aeeaaaaaaghi422cabvlsalew7liymaaaaaq, aeeaaaaaaghi422cabvlsalew7lokkaaaaaq ]\\n-    #version : 1\\n+    #version : 2\"\n}",

Dans le cas d’une mise à jour de métadonnées d’une unité archivistique (ArchiveUnit), le champ « evDetData » de l’événement final est composé du champ suivant :

« diff »: historisation des modifications de métadonnées.

  • Son contenu doit respecter la forme suivante : les anciennes valeurs sont précédées d’un « - » (-champ1: valeur1) et les nouvelles valeurs sont précédées d’un « + » (+champ1: valeur2). Le changement d’un champ entraîne forcément l’ajout d’une nouvelle opération (le champ _ops de l’unité est modifié) et d’une nouvelle version de l’unité (le champ _v est modifié). Ces changements aparaissent également dans le diff.