5.22. Procédure d’exploitation suite à la création ou la modification d’une ontologie

Au préalable à la création ou à la modification d’une ontologie, les index Elasticsearch correspondant aux ontologies doivent être créés ou mis à jour.

5.22.1. Création d’une ontologie

Suite à la création d’une nouvelle ontologie, les index Elasticsearch doivent être mis à jour selon la procédure suivante:

• Dans le cas d’une création, il suffit de créer un nouveau mapping dans les index concernés.

Ex : Ajout d’une propriété Licence dans tous les index unit (unit* signifiant tous les index unit unit_0, unit_1 etc …)

Commandes à lancer sur une des partitions hébergeant le cluster elasticsearch « data » :

curl -XPUT "http://localhost:9200/unit*/_mapping/typeunique?update_all_types" -d'
{
      "properties": {
    "Licence": {
      "type": "text"
    }
      }
}'

Pour verifier sur un ou tous les index unit :

curl -XGET "http://localhost:9200/unit_0/_mapping/?pretty=true"

curl -XGET "http://localhost:9200/unit*/_mapping/?pretty=true"

5.22.2. Changement de type d’une ontologie existante

Dans ce cas, le changement de type dans elasticsearch n’est pas possible. Il faut donc créer un nouvel index ElasticSearch avec un nouveau mapping, puis reindexer l’ancien index dans ce dernier.

On récupère d’abord l’ancien index

curl -XGET 'localhost:9200/unit_1/_mapping?pretty=true'

On créé un fichier json et on y copie les données obtenues ( ne conserver que la balise « mappings » : { …} et son contenu). On modifie le mapping en changeant le type des propriétés choisies. On créé un nouvel index on lui passant en paramètre le fichier du nouveau mapping .

curl -XPUT "http://localhost:9200/new_unit_1" -H 'Content-Type: application/json' -d @newmapping.json

Verifier l’index :

curl -XGET 'localhost:9200/new_unit_1/_mapping/'

On reindexe unit_1 vers le nouvel index new_unit_1

curl -XPOST 'localhost:9200/_reindex' -H 'Content-Type:application/json' -d '{
    "source" : {
        "index" : "unit_1"
    },
    "dest" : {
        "index" : "new_unit_1",
        "version_type": "external"
    }
}'

On efface l’alias de l’ancien index unit_1

curl -XDELETE 'localhost:9200/unit_1/_alias/unit_1'

et on l’affecte au nouvel index new_unit_1

curl -XPUT 'localhost:9200/new_unit_1/_alias/unit_1'

Avertissement

les index elasticsearch de VITAM sont créés par tenant. Il faudra refaire l’opération ci-dessus pour chaque tenant.

Note

En cas du changement des mappings elasticsearch, il faudra veiller à ce qu’ils soient en cohérence avec l’ontologie.

5.23. L’ontologie externe suite à la montée de version de VITAM

Lors de la montée de version, les ontologies externes en cours d’exploitation par VITAM ne sont pas touchées et seront mergées avec les ontologies internes de VITAM.

Le fichier du référentiel de l’ontologie se trouve désormais dans environments/ontology/VitamOntology.json

La procédure de merge manuelle du référentiel de l’ontologie avant chaque montée de version n’est plus nécessaire. Depuis la version 3.4.0 de VITAM, le vocabulaire externe de l’ontologie est géré automatiquement avec le vocabulaire interne. Cependant, il est nécessaire de s’assurer que le merge est effectivement possible sans conflits.

Lors du lancement du procédure de mise à jour de VITAM, une phase de vérification devra être effectuée pour détecter des éventuels conflits entre les vocabulaires internes et externes.

Cette vérification s’exécute avant de charger l’ontologie externe afin de préserver celle existante en cas de conflit de merge.

Ainsi, il est recommandé, avant de procéder à une montée de version, de jouer le script ansible : ansible-vitam-exploitation/check_ontologies.yml

Prudence

En cas d’échec lors de l’exécution de ce playbook, cela signifie qu’il y a des conflits entre les deux vocabulaires. L’exploitant devra alors adapter l’ontology externe afin de résoudre ces conflits.

Prudence

Dans le cadre d’une montée de version, se référer également au DMV.