Aller à : navigation, rechercher

Maarch RM/Traitements par lot

Les procédures d'exploitation font appel à des fonctionnalités qui sont pour la plus grande partie disponibles au travers de l'interface graphique utilisateur. Pour autant, l'application Maarch RM prévoit des traitements planifiés pour un certain nombre de processus qui peuvent se révéler longs ou consommateurs de ressources serveur, selon la quantité de données traitées et la nature des opérations demandées. Une exécution via l'interface utilisateur ou en cours de journée d'exploitation pourrait alors poser des problèmes de temps de réponse ou de dépassement de l'espace mémoire alloué pour les services interactifs.

La règle globale est la suivante : une planification est préférable si la procédure réalise des opérations sur les données d'archives, car elle doit pouvoir être réalisée pour un volume important de données.

C'est le cas pour

  • les entrées, avec la réception, la validation et le dépôt,
  • les sorties dans les procédures de communication, restitution et de transfert sortant,
  • les destructions en fin de procédure de restitution et d'élimination,
  • l'archivage des journaux du cycle de vie et de l'application (qui extraient les traces du jour et produisent des fichiers potentiellement volumineux),
  • la conservation sécurisée avec le contrôle périodique de l'intégrité des archives, les conversions de format et migrations de support.

Généralités

Les tâches planifiées consistent en des appels aux services via une ligne de commande du système (shell Linux, commande Windows, PowerShell...).

Il consiste à exécuter l'interpréteur PHP avec un script principal (équivalent du frontal http) auquel on fournit une représentation ligne de commande de la requête d'appel au service (équivalent à la requête http). La requête contient donc un verbe, un chemin, des arguments, des en-têtes.

  • Les verbes sont CREATE, READ, UPDATE, DELETE...
  • Le chemin de ressource est l'URI interne d'un service d'API, sous la forme minimale {bundle}/{API}, pouvant être complétée par d'autres étapes.
  • Les en-têtes sont déclarés sous la forme de paires -clé:valeur séparées par un espacement.
  • Les arguments sont passés sous la forme de paires clé=valeur séparées par un espacement.
php cli.php CREATE medona/Archivetransfer messageFile="ArchiveTransfer_001/ArchiveTransfer_0014.xml" attachments="ArchiveTransfer_001/*" -tokenfile:"token.txt"

Sécurité

Dans Maarch RM, tous les appels à des services doivent être réalisés par un compte déclaré dans l'application, c'est-à-dire un utilisateur ou un compte de service. Il en va de même pour les traitements planifiés. Il faut donc générer à partir de l'interface graphique utilisateur un jeton de sécurité pour un compte de service qui sera précisé à chaque lancement de deux manières possibles:

  • avec un argument -token qui fournit la chaîne du jeton chiffré
  • avec un argument -tokenfile qui fournit un chemin de fichier contenant le jeton chiffé

Exemples

Des exemples de script shell linux sont fourni avec l'application dans le répertoire data/maarchRM/batch/.

Les entrées

La procédure de versement est découpé en trois étapes réalisables de manière planifiée: la réception des messages, la validation et le dépôt.

Réception des messages

Cette fonction reçoit un message de transfert d'archive entrant, le place dans le tampon d'entrée, valide qu'il est bien formé et exploitable et l'enregistre dans le référentiel des messages.

Le service CREATE medona/archiveTransfer reçoit deux paramètres:

  • messageFile : contenu ou nom d'un fichier correspondant au bordereau à recevoir
  • attachments : liste de chaînes binaires de contenus de pièces jointes au message, liste de noms de fichiers de pièces jointes ou nom de répertoire contenant les pièces jointes

Le fonction retourne l'identifiant interne du message de transfert d'archive reçu.

Validation des messages

Cette fonction valide la conformité du message de transfert entrant par rapport à l'accord de versement. La validation des messages est réalisée en faisant appel au service de validation unitaire ou par lot.

Le service UPDATE medona/archiveTransfer/validate/{messageId}, où {messageId} représente l'identifiant du message à valider (reçu de la fonction de réception), valide un message. Il retourne un indicateur de succès OU l'identifiant du message de réponse indiquant le rejet du dépôt.

Le service UPDATE medona/archiveTransfer/validate/batch traite tous les messages de versement qui ont été reçus mais pas encore validés. Il retourne une liste associant les identifiants de message de versement validés, avec pour chacun l'indicateur de succès OU l'identifiant du message de réponse indiquant le rejet du dépôt.

Dépôt

Cette fonction finalise le versement avec le dépôt des archives contenues dans les messages de transfert entrant acceptés. L'acceptation est réalisée potentiellement par l'archiviste via l'interface homme-machine, ou automatique si l'accord de versement indique que tout message de versement valide est automatiquement accepté.

Comme la validation, le dépôt est réalisé en faisant appel au service de traitement unitaire ou par lot.

Le service UPDATE medona/archiveTransfer/process/{messageId}, où {messageId} représente l'identifiant du message à traiter (reçu de la fonction de réception et de validation), traite un seul transfert. Il retourne l'identifiant du message de réponse attestant du dépôt OU un indicateur d'une éventuelle erreur de traitement.

Le service UPDATE medona/archiveTransfer/process/batch traite tous les messages de versement qui ont été accepté mais pas encore traités. Il retourne une liste associant les identifiants de message de versement traités, avec pour chacun l'identifiant du message de réponse attestant du dépôt OU un indicateur d'une éventuelle erreur de traitement.

Les sorties

Communication

Cette procédure prend en compte toutes les demandes de communication acceptées et génère le message de réponse à la demande contenant les métadonnées, journaux et les pièces jointes, dans le tampon de sortie.

Le service UPDATE medona/ArchiveDelivery/process/Batch traite tous les message de demande de communication acceptés. Il retourne l'identifiant du message de réponse généré dans le tampon de sortie.

Restitution

Cette procédure prend en compte toutes les demandes de restitution acceptées et génère le message de restitution contenant les métadonnées, journaux et les pièces jointes, dans le tampon de sortie.

Le service UPDATE medona/archiveRestitution/process/Batch traite tous les message de demande de restitution acceptés. Il retourne l'identifiant du message de restitution généré dans le tampon de sortie.

Transfert sortant

Non implémenté.

Les destructions

La destruction intervient en fin de transaction d'élimination ou de restitution. La fonction prend en compte tous les messages de restitution acquittés et tous les messages de demande d'élimination acceptés.

Le service UPDATE medona/archiveDestruction/processAll traite tous les message. Il retourne l'identifiant du message de notification de destruction éventuellement générés.

Les journaux

Les journaux du système d'archivage sont doubles: celui du cycle de vie de l'archive et celui de l'application. Il existe donc deux fonctions pour produire et archiver les traces de ces deux journaux.

Journal du cycle de vie

Le service CREATE lifeCycle/journal/chainjournal génère un fichier de journal à partir des événements du journal du cycle de vie non encore inclus dans un fichier de journal, soit depuis la fin du journal précédent (ou depuis le début de l'exploitation lors de la première exécution). L'empreinte numérique du journal précédent est ajoutée en début de journal avec un jeton d'horodatage récupéré auprès d'un tiers horodateur, puis les traces à sécuriser. Le contenu d'information ainsi créé est archivé.

Journal de l'application

Le service CREATE audit/event/chainJournal génère un fichier de journal à partir des événements de l'application non encore inclus dans un fichier de journal, soit depuis la fin du journal précédent (ou depuis le début de l'exploitation lors de la première exécution). L'empreinte numérique du journal précédent est ajoutée en début de journal, puis les traces à sécuriser. Le contenu d'information ainsi créé est archivé.

La conservation

Contrôle d'intégrité

Le service READ recordsManagement/archiveCompliance/periodic reçoit deux paramètres :

  • limit fixe le nombre maximal d'archives à contrôler (entier)
  • delay fixe le délai maximal entre la première entrée de journal traitée et la dernière, sous la forme d'une durée PxYxMxD

Conversion de format

Le service READ medona/documentConvertion/process/all traite toutes les demandes de conversion de document en attente.