Impacts¶

Ajout d'un connecteur dans dependency/repository/Adapter

Modification du code responsable du calcul de la localisation de stockage pour supprimer l'adhérence aux systèmes de fichiers.
Dans la version actuelle le fonctionnement est le suivant :

Au dépôt
- calcul d'un chemin de stockage selon le masque de configuration et les variables de contexte (archive, message, date...)
- ouverture d'un conteneur de stockage (création ou ré-ouverture existant) par appel à la chaîne digitalResource->cluster->repository
- dépôt effectif par appel à la chaîne digitalResource->cluster->repository
- inscription du conteneur de stockage dans les métadonnées de l'archive

On a donc un double problème
- de responsabilité / répartition de code (car c'est le bundle recordsManagement qui produit le chemin de stockage passé aux composants responsables du stockage effectif)
- de modèle de données car le chemin est unique alors que le stockage peut être multiple, et incompatible a priori avec deux systèmes utilisant un adressage différent

Evolution sans impact :

Le chemin de stockage interne conservé dans l'objet archive reste une information agnostique du système de stockage (info métier).

Chaque connecteur de stockage est responsable de son interprétation pour fournir une localisation dans son propre schéma d'adressage interne.
- Pour fileSystem, aucune modification
- pour S3, configuration de la profondeur du chemin (en nombre de noms) qui désignent le bucket, la suite étant la clé de l'objet

Exemple :
configuration : {instance}/{originatorOwnerOrgId}/{archivalProfileReference}/{date(Y)}/{date(M)}/{date(d)}

chemin résolu archive : maarchRM/123456789/FACTURE/2022/09/15/archiveId

chemin filesystem : maarchRM/123456789/FACTURE/2022/09/15/archiveId/resId

Localisation S3
- bucket : maarchRM.123456789
- key : /FACTURE/2022/09/15/archiveId/resId

Début de connecteur avec gestion des chemins de stockage reçus de recordsManagement.archive pour prise en compte de 2 parties
- bucket (conteneur)
- key (objet)

Le nombre de parties du chemin à prendre en compte est défini dans l'option de paramétrage du repository bucketPathSteps

Correction d'un bug mineur sur l'écran de définition des paramètres.
Correction d'un bug mineur dans le contrôleur digitalResource.repository dans la fonction qui traite les paramètres.

Modification du connecteur S3 pour prise en compte des spécificités du stockage OVH et gestion par le client.

Paramètres :

• version : version de l'API (latest, v3, v4...)
• sdk : chemin vers le SDK AWS (où se trouve le fichier autoloader.php)
• region : région (bhs pour tests OVH)
• key : clé d'identification de l'utilsiateur
• secret : secret pour identification
• bucket : soit le nom du bucket à utiliser pour le repo en dur, soit un entier définissant la profondeur du chemin de stockage à utiliser pour déterminer le nom dynamiquement

Tests réalisés :
* versement
* dépôt direct via gestion
* destruction directe via gestion
* lecture
* contrôle d'intégrité

A faire :
* profilage
* élimination
* voir si le bucket peut être intégré au endpoint comme uri du service

Erreur lors de l'ajout d'un support dans une grappe existante.
La fonction de lecture cherche les adresses pour tous les supports et lève une exception si non trouvée.

A faire : prévoir le cas d'un nouveau support pour migration.

Modifications apportées sur plusieurs fonctions :

DigitalResource

• contents()
• metadata()
• info()
• delete()

cluster:

• retrieveRessource()

Test d'existence de l'adresse sur le support, pour toute itération dans les supports d'une grappe

Modification de retrieveRessource() pour lever une exception lorsqu'on sort de la fonction sans avoir retourné de pointeur de données (donc aucun support ne contient les données).