Aller à : navigation, rechercher

Maarch RM/Ajouter une série à un fonds

L'une des premières et principales étapes de la mise en oeuvre de l'archivage de vos documents électroniques est l'analyse des flux documentaires et la constitution du plan de classement. Le plan de classement peut être vu comme une arborescence qui reflète l'activité de l'organisation: Ses racines sont les organismes producteurs (sociétés, collectivités), les branches sont les services et les activités et ses feuilles sont les typologies de documents archivés.

A chaque type de document correspond un ensemble d'informations de description des documents du point de vue du domaine d'activité. Ce jeu de données constitue le moyen d'indexer les documents pour la recherche et la consultation, mais permet aussi d'exploiter l'information dans des processus métier annexes à l'archivage (GED-Workflow par exemple).

Maarch RM est livré de base avec deux jeux de données standards utilisés respectivement pour la description des données d'archives de la sphère publique et des documents administratifs et financiers des entreprises, mais permet la définition du modèle pour l'adapter aux besoins spécifiques à votre organisation, pour l'archivage de documents produits par une activité ou un métier spécifique.

Cette adaptation peut se faire à deux niveaux :

  • l'ajout de données à un jeu existant permet d'adapter le dictionnaire de données à des spécificités portant sur des typologies documentaire déjà prévues
  • l'ajout d'un jeu de données complet permet d'ajouter des dictionnaires pour des typologies documentaires spécifiques

Modèle fonctionnel

Modèle de données

Dans Maarch RM, la description d'une archive est principalement constituée de deux entités:

  • une structure standard commune à toutes les archives quelle que soit leur typologie documentaire, qui contient les données d'identification et de gestion,
  • une structure spécifique au domaine d'activité qui contient la description métier pour une ou plusieurs typologies documentaires basée sur le dictionnaire de données


Ces deux parties ont une relation de cardinalité 1 pour 1 et sont agrégées lors des opérations d'enregistrement et d'accès. Les données descriptives doivent comporter un identifiant unique qui est référencé dans les données de gestion.

Lorsque le module de gestion archivistique traite les données pour les opérations de versement, communication ou élimination, la description est agrégée sous la structure de gestion:

Archive
 |_ Description

Le module de gestion spécifique aux données métier peut générer une vue qui jointe les deux entités en une seule, pour permettre la recherche multi-critères à la fois sur les données de gestion et sur les données de description:

Archive -- Description

Cette seconde représentation n'est qu'une vue et ne permet que l'accès en lecture aux descriptions d'archives.

Composants de gestion

A l'image du modèle de données, l'exploitation des archives est réalisée pour partie grâce à des composants standards fournis par le module de gestion archivistique, et pour partie par des composants spécifiques à l'implémentation du métier, selon la répartition suivante :

Usage

Fonctions des composants standard

Fonctions des composants spécifiques

Structure

Versement

Enregistrement des contenus de données et métadonnées de gestion

Enregistrement des métadonnées descriptives spécifiques

Composition

Recherche

Recherche multi-critères sur la vue qui jointe les métadonnées de gestion et les métadonnées descriptives spécifiques

Association

Accès*

Accès aux contenus de données et métadonnées de gestion

Accès aux métadonnées descriptives spécifiques

Composition

Destuction**

Destruction des contenus de données et métadonnées de gestion

Destruction des métadonnées descriptives spécifiques

Composition

* Accès lors des opérations de consultation, communication, modification, restitution et élimination

** Destuction lors des opérations de restitution et élimination


Ce fonctionnement nécessite donc un composant de gestion spécifique du modèle de description du métier pour 4 opérations :

  • la création de l'objet de description lors du versement de l'archive
  • la recherche des archives sur la vue associant les données de gestion et de description
  • la lecture des données de description via leur identifiant
  • la suppression des données de description via leur identifiant


On peut ajouter une cinquième opération de modification des métadonnées, qui ne constitue pas une opération archivistique mais pourra s'avérer nécessaire si le jeu d'informations de description est partiel lors du versement et doit être complété ultérieurement.

Implémentation

Les composants qui doivent être adaptés sont répartis dans trois couches :

  • le modèle physique de stockage des données (base de données)
  • le modèle logique (couche de logique métier)
  • la présentation (interface homme-machine)

Modèle physique

Cette partie n'est pas à proprement parler du domaine de l'application. Il s'agit de modifier le modèle utiliser par la couche de persistance, c'est-à-dire la base de données relationnelle.

La structure des données doit répondre à trois impératifs :

  1. il doit exister une table principale pour les données descriptives. Elle peut être associée à des tables secondaires par référence (clé étrangère) mais les entités principales de description (les agrégats) seront stockées dans cette table principale.
  2. elle doit comporter une clé primaire pour identifier les entités
  3. elle doit pouvoir être jointée à la table des données de gestion des archives (recordsManagement.archive) et doit donc être localisée sur le même serveur de base de données et l'utilisateur de la base de données doit posséder les droits d'insertion, mise à jour et suppression sur ces deux tables

Modèle logique

La structure des données descriptives doit être prise en compte par le modèle logique dans 3 composants:

  • la description du modèle de données
  • les méthodes du contrôleur de logique métier
  • les services exposés

Tous ces composants sont déployés dans un seul paquet, dont le nom doit correspondre au nom du schéma de base de données utilisé pour la table des données de description.

Par exemple, pour un modèle de description dans le schéma "acme", il faudra utiliser un paquet du même nom dans un répertoire laabs/src/bundle/acme

Modèle de données

Le modèle est défini dans une classe du paquet, dont le code source est localisé dans un fichier source portant le même nom que la classe (et que la table de la base de données) dans le répertoire Model du paquet.

Il doit y avoir une classe pour déclarer la structure de données de description seule et une classe pour déclarer la vue qui jointe la description et les données de base de l'archive par un mécanisme d'extension qui assure l'héritage de classe.

Par exemple, pour un modèle de description dans la table "acme"."asset", il faudra avoir déclaré la classe du même nom dans l'espace de nom "acme", dont le code source sera placé dans le fichier laabs/src/bundle/acme/Model/asset.php :

<?php
// Déclaration de l'espace de nom, indiquant que 
// la classe appartient au modèle du paquet "acme"
namespace bundle\acme\Model

//Déclaration de la classe "asset"
class asset 
{
    // Déclaration des propriétés de la classe
    // ...
}

Une seconde classe étend la première en y ajoutant les propriétés correspondant aux données de gestion de l'archive que l'on a intégré à la vue et que l'on souhaite utiliser.


<?php
// Déclaration de l'espace de nom, indiquant que 
// la classe appartient au modèle du paquet "acme"
namespace bundle\acme\Model

//Déclaration de la classe "assetRecord"
class assetRecord
    extends asset
{
    // Déclaration des propriétés de la classe recordsManagement/archive à utiliser
    /**
     * @var id
     */
    public $archiveId;

    /**
     * @var string
     */
    public $archivalProfileReference;

    /**
     * @var date
     */
    public $disposalDate;

    // ...
}

Contrôleur

Les entités correspondant au modèle logique déclaré vont être manipulées par un contrôleur de modèle, un composant spécialisé responsable de l'établissement des règles de la logique du métier et de la réalisation des actions sur les données.

Le contrôleur est défini dans une classe du paquet, dont le code source est localisé dans un fichier source portant le même nom que la classe dans le répertoire Controller du paquet.

Il doit y avoir une seule classe pour contrôler les données de description, et elle doit porter le même nom que la classe du modèle pour permettre un branchement dynamique au SAE.

Il doit comporter à minima des méthodes publiques pour les opérations suivantes :

  • create() : enregistrement des données descriptives dans la persistance. Elle accepte en argument l'objet de description et retourne l'identifiant de l'objet créé.
  • read() : lecture des données descriptives dans la persistance. Elle accepte en argument l'identifiant unique de l'entité et retourne l'objet correspondant.
  • delete() : suppression des données descriptives dans la persistance. Elle accepte en argument l'identifiant unique de l'entité et retourne un booléen.

Pour les fonctions de recherche, ni le nom de la classe ni celui des méthodes n'est imposé car il s'agit d'une mécanique spécifique, mais les bonnes pratiques veulent que la méthode de recherche soit intégrée à la classe de contrôle :

  • search() : recherche multi-critères. Elle prend en argument les valeurs de critères de recherche et retourne le tableau des résultats.

Par exemple, pour un modèle de description "asset", il faudra avoir déclaré la classe de contrôle du même nom dans l'espace de nom "acme", dont le code source sera placé dans le fichier laabs/src/bundle/acme/Controller/asset.php :

<?php
// Déclaration de l'espace de nom, indiquant que 
// la classe appartient aux contrôleurs du paquet "acme"
namespace bundle\acme\Controller

//Déclaration de la classe "asset"
class asset 
{
    // Déclaration des propriétés et méthodes de la classe
    // ...
}

Services

Les actions de contrôleur déclarées pour la manipulation des données doivent être exposées sous la forme de services dans une API, un composant responsable de la déclaration des services et contrats de données (messages).

L'API est définie dans une interface du paquet, dont le code source est localisé dans un fichier source placé dans le répertoire racine du paquet.

Le nombre et le contenu des APIs est fonction des services que l'on souhaite exposer. Par défaut, seul le service de recherche est indispensable car il sera utilisé par l'interface homme-machine.

Les services de manipulation des données peuvent être ajoutés, mais ils peuvent constituer des risques pour la sécurité et le respect des exigences normatives. En effet, exposer un service de création ou de suppression des informations de description permet de manipuler les données sans passer par la couche de gestion archivistique, donc en outrepassant la gestion des droits d'accès, la journalisation ou encore la prise en compte de la relation d'association forte entre l'archive et sa description.

Par exemple, pour un modèle de description "asset", on pourra avoir déclaré l'interface de service du même nom dans l'espace de nom "acme", dont le code source sera placé dans le fichier laabs/src/bundle/acme/assetInterface.php :

<?php
// Déclaration de l'espace de nom, indiquant que 
// l'interface appartient à l'API du paquet "acme"
namespace bundle\acme

//Déclaration de l'interface "asset"
interface assetInterface 
{
    // Déclaration du service de recherche
    /**
     * @param string $docnum
     * @param date   $docdate
     *
     * @return array
     */
    public function search($docnum, $docdate);

}

Présentation

La logique du métier implémentée peut maintenant être présentée à l'utilisateur grâce à la couche de présentation via 3 composants:

  • le modèle de vue Html
  • les méthodes du contrôleur de présentation
  • les routes de contrôle utilisateur (commandes)

La couche de présentation est organisée dans un seul et unique paquet pour l'ensemble du système, dans le répertoire laabs/src/presentation/maarchRM

Étant donnée cette architecture de déploiement, il est important de bien définir quels composants vont être impactés.

S'il s'agit de composants livrables de base, il est conseille d'utiliser le mécanisme de personnalisation de Maarch RM pour ne pas modifier le livrable mais l'étendre ou le remplacer par les composants développés spécifiquement. Dans ce cas, il faut placer les fichiers dans le répertoire correspondant à l'extension et déclarer cette dernière dans la configuration de l'instance présentée à l'utilisateur, par exemple laabs/src/extension/<nom_extension>/presentation/maarchRM (voir la documentation consacrée à la personnalisation.)

Modèle de vue Html

L'interface homme-machine utilise des modèles de vue en langage HTML qui incorporent des scripts en langage Javascript (JQuery et plugins) et CSS (Bootstrap et indépendants).

Les fichiers source Html sont placés dans le répertoire laabs/src/presentation/maarchRM/Resources/view, éventuellement organisés dans des sous-répertoires par domaine.

Par exemple, les fichiers des vues pour la recherche de documents "acme" seront placés dans laabs/src/presentation/maarchRM/Resources/view/acme pour conserver l'organisation de la logique du métier.

Trois vues sont strictement nécessaires:

  • l'écran de recherche, avec
    • le formulaire pour la saisie des critères
    • le fragment pour l'affichage des résultats
  • l'écran (le fragment) d'affichage des données de description pour la consultation des métadonnées de l'archive

La liste de résultat de recherche doit fournir à l'utilisateur les contrôles pour les différentes opérations auxquelles il peut avoir accès :

  • l'affichage du contenu de document
  • l'affichage des métadonnées descriptives de l'archive
  • la demande de modification des données de gestion: règle de conservation, règle de communicabilité/d'accès, gel et dégel de l'application du cycle de vie
  • la demande d'élimination
  • la demande de restitution
  • le contrôle de conformité

Toutes ces fonctions sont remplies en standard par le module de gestion archivistique, les deux premières pour une archive seulement, les quatre autres pour une ou plusieurs archives sélectionnées. Elles sont accessibles à l'utilisateur en branchant sur les contrôles des appels à la couche de présentation standard:

Fonction

URL

Arguments

Afficher le contenu

/recordsManagement/contents/<archiveId>

Afficher la description

/recordsManagement/description/<archiveId>

Demander le gel d'un ensemble d'archives

/recordsManagement/archive/freeze

archiveIds[]

Contrôleur de présentation

Ce composant présente les données reçues de la couche de logique du métier (via les appels aux services exposés) et présente la réponse à l'utilisateur, soit dans une représentation HTML inclue à l'interface, soit dans un flux JSON utilisé par le script côté client pour présenter un message simple, en retour d'un appel asynchrone par exemple.

Commandes utilisateur

Les actions de l'utilisateur sont transmises au serveur de présentation sous la forme de requêtes HTTP, comportant une URL et un corps. Un composant, nommé "UserStory" expose les commandes nécessaires à la réalisation des cas d'usage et permet de router la requête de l'utilisateur vers les composants de service et de présentation associés.

La User Story est définie dans une interface de la couche de présentation, dont le code source est localisé dans un fichier source placé dans le répertoire laabs/src/presentation/maarchRM/UserStory du paquet, éventuellement organisés dans des sous-répertoires par domaine.

Le nombre et le contenu des User Stories est fonction des commandes que l'on souhaite brancher dans l'IHM. Par défaut, seul les commandes de recherche sont indispensable car elles seront utilisées par l'interface homme-machine. Elles devraient au minimum être au nombre de deux:

  1. l'affichage du formulaire de recherche
  2. l'appel au service de recherche et l'affichage des résultats


Par exemple, pour un modèle de description "asset", on pourra avoir déclaré l'interface de commandes du même nom dans le domaine "acme", dont le code source sera placé dans le fichier laabs/src/presentation/maarchRM/UserStory/acme/assetInterface.php :

<?php
// Déclaration de l'espace de nom, indiquant que 
// l'interface appartient au cas d'usage "acme/asset" de l'application Maarch RM
namespace presentation\maarchRM\UserStory\acme

//Déclaration de l'interface "asset"
interface assetInterface 
{
    
    /**
     * Affichage du formulaire de recherche
     * @return acme/asset/search
     */
    public function readAcmeAssetSearch();

    /**
     * Appel à la fonction de recherche
     * avec les critères
     * @param string $critere1
     * @param string $critere2
     * ...
     *
     * @return acme/asset/find 
     * @uses acme/asset/readFind
     */
    public function readAcmeAssetFind($critere1= null, $critere2= null, ...);

}