Ajouter une série à un fonds

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
Sommaire
• 1 Modèle fonctionnel
♦ 1.1 Modèle de données
♦ 1.2 Composants de gestion
• 2 Implémentation
♦ 2.1 Modèle physique
♦ 2.2 Modèle logique
◊ 2.2.1 Modèle de données
◊ 2.2.2 Contrôleur
◊ 2.2.3 Services
♦ 2.3 Présentation
◊ 2.3.1 Modèle de vue Html
◊ 2.3.2 Contrôleur de présentation
⋅ 2.3.2.1 Commandes utilisateur
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
Versement
Fonctions des composants standard
Enregistrement des contenus de données et
métadonnées de gestion
Recherche
Fonctions des composants spécifiques
Structure
Enregistrement des métadonnées descriptives spécifiques
Composition
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 aux contenus de données et
Accès aux métadonnées descriptives spécifiques
métadonnées de gestion
des contenus de données et
Destuction** Destruction
Destruction des métadonnées descriptives spécifiques
métadonnées de gestion
* Accès lors des opérations de consultation, communication, modification, restitution et élimination
Accès*
** 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
Composition
Composition
• 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
Afficher le contenu
Afficher la description
Demander le gel d'un ensemble d'archives
Contrôleur de présentation
URL
Arguments
/recordsManagement/contents/<archiveId>
/recordsManagement/description/<archiveId>
/recordsManagement/archive/freeze
archiveIds[]
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, ...);
}