Archivage de Données SAP

CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL ASSOCIE DE LYON Centre denseignement du pays de GEX ___________________
MEMOIRE
prsent en vue d'obtenir le DIPLOME D'INGENIEUR CNAM
SPECIALITE : INFORMATIQUE dumas-00530235, version 1 - 28 Oct 2010 OPTION : INFORMATIQUE, SYSTEMES DINFORMATION
par
Michel BOLOGNESI
___________________
Archivage de donnes SAP

Soutenu le 17 septembre 2010 _________________ JURY PRESIDENT : MEMBRES : Christophe Picouleau Bertrand David Claude Genier Jacques Savioz Jean-Luc Philippona
dumas-00530235, version 1 - 28 Oct 2010
Remerciements
Difficile dtre exhaustif aprs ces annes de recherches, mais je tiens remercier toutes les personnes suivantes qui mont aid mener bien ce travail de mmoire : Monsieur Claude Genier, professeur CNAM, pour son soutien, sa disponibilit et son encouragement pour ce cette formation dingnieur. Monsieur Jacques SAVIOZ, coordinateur SAP, Romande Energie SA, pour la coordination et lorganisation des sances avec les diffrents intervenants chez Romande Energie. dumas-00530235, version 1 - 28 Oct 2010 Madame Laure BOULIANNE, juriste, Romande Energie SA, pour tous les renseignements concernant le code des obligations suisse. Monsieur Pascal MARMY, responsable systme, Romande Energie SA, pour les conseils techniques concernant le systme darchivage. Monsieur George CORONADO, responsable de lapplication JetForm, socit Cisel SA, pour la collaboration dans la cration des fichiers pdf. Monsieur Jean-Luc PHILIPPONA, responsable tude et dveloppement, neo technologies SA. Madame Rgine PRALONG, socit Affaires classes, pour la relecture et la correction du prsent rapport. Monsieur Jean-Pierre WERMEILLE, consultant logistique SAP, neo technologies SA, pour la relecture et la traduction en anglais. Monsieur Martial GUERRY, analyste programmeur, neo technologies SA, pour les diffrentes conseils concernant larchivage. Monsieur Laurent MARGELISCH, consultant SAP, neo technologies SA, pour ses explications concernant les modules de finance. Madame Carmelina BOLOGNESI, mon pouse, pour son soutien et sa patience.
REMERCIEMENTS .............................................................................................................................. 3 INTRODUCTION................................................................................................................................... 9 I 1 2 2.1 2.2 2.3 2.4 3 PREMIERE PARTIE : PERIMETRE DU PROJET............................................................... 11 NAISSANCE DU PROJET ........................................................................................................ 11 ENVIRONNEMENT .................................................................................................................. 11 PRESENTATION DES SOCIETES ................................................................................................... 11 GENERALITE SUR LE PGI (PROGICIEL DE GESTION INTEGRE) ..................................................... 12 PGI SAP EN GENERAL ............................................................................................................... 13 IMPLEMENTATION DE SAP A ROMANDE ENERGIE ..................................................................... 16 OBJECTIFS DU PROJET ......................................................................................................... 18 LES CONCEPTS DE LARCHIVAGE ELECTRONIQUE ................................................... 21 DEFINITION............................................................................................................................... 21 1.1 2 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4 4.5 4.6 III 1 2 3 4 4.1 TERMINOLOGIE ......................................................................................................................... 22 BESOIN DE CONSERVATION ................................................................................................ 22 ENVIRONNEMENT JURIDIQUE ........................................................................................... 23 DROIT SUISSE DES SOCIETES ...................................................................................................... 23 SPECIFICITE CONCERNANT LES FACTURES ET PIECES JUSTIFICATIVES AU REGARD DE LA TVA . 26 PROCEDURE CIVILE ................................................................................................................... 27 TEMPS DE CONSERVATION......................................................................................................... 27 CONTRAINTES TECHNIQUES DU SYSTEME DARCHIVAGE. .................................... 28 FORMAT DES DOCUMENTS ELECTRONIQUES .............................................................................. 28 CONTRAINTES SECURITAIRE ...................................................................................................... 31 LA SIGNATURE ELECTRONIQUE ................................................................................................. 34 CYCLE DE VIE DE LINFORMATION ARCHIVEE ............................................................................ 36 SUPPORT PHYSIQUE. .................................................................................................................. 38 SYSTEME DARCHIVAGE ELECTRONIQUE (SAE) ........................................................................ 44 PRINCIPE DE LARCHIVAGE SAP ....................................................................................... 51 DEFINITION............................................................................................................................... 51 MOTIVATIONS ......................................................................................................................... 51 PRINCIPE ................................................................................................................................... 52 OBJET DARCHIVAGE ............................................................................................................ 53 PROGRAMMES ASSOCIES AU PROCESSUS ARCHIVE .................................................................... 54
II 1
Bolognesi Michel
25.08.2010
5/145
4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 6
STRUCTURE DUN OBJET DARCHIVAGE .................................................................................... 56 TUPLES DE TABLES NON ARCHIVES............................................................................................ 57 DEPENDANCE ENTRE OBJETS ARCHIVE ...................................................................................... 57 PROGRAMME DE LECTURES DES FICHIERS ARCHIVES ................................................................. 58 TEMPS DE RESIDENCE DANS LA BASE DE DONNEES .................................................................... 58 TABLES INFORMATION .............................................................................................................. 59 FONCTIONS SPECIFIQUES (USER-EXIT) ....................................................................................... 60 REMARQUES .............................................................................................................................. 60 PROCESSUS ............................................................................................................................... 60 PARAMETRAGE PROCESSUS DARCHIVAGE (CUSTOMIZING) ...................................................... 61 PROCESSUS PRINCIPAL .............................................................................................................. 65 PROCESSUS ANNEXES ................................................................................................................ 67 ARCHIVELINK .......................................................................................................................... 68
6.1 6.2 6.3 6.4 7 IV 1 1.1 1.2 1.3 1.4 1.5 1.6 2 2.1 2.2 2.3 3 3.1 3.2 4 4.1 4.2
Bolognesi Michel
PRINCIPE ................................................................................................................................... 69 OBJET METIER ........................................................................................................................... 69 TABLES DE LIENS....................................................................................................................... 70 PROTOCOLE HTTP. ..................................................................................................................... 74 BILAN DE CONFORMITE ....................................................................................................... 75 REALISATION DU PROJET ................................................................................................... 79 PREPARATION DU PROJET .................................................................................................. 80 ANALYSE DE LA CROISSANCE DU VOLUME DE LA BASE DE DONNEES ........................................ 80 ANALYSE SELON LA LOI PARETO ............................................................................................... 81 CIBLER LES OBJETS DARCHIVAGE ............................................................................................ 83 TEMPS DE RETENTION DES DONNEES ......................................................................................... 93 VISUALISATION DES ARCHIVES ................................................................................................. 95 EQUIPE PROJET .......................................................................................................................... 95 BUSINESS BLUEPRINT (CONCEPTION GENERALE) ...................................................... 96 ARCHITECTURE TECHNIQUE ...................................................................................................... 97 VISUALISATION DES ARCHIVES ................................................................................................. 98 AUTORISATIONS ...................................................................................................................... 104 REALISATION ......................................................................................................................... 104 ARCHIVAGE DES DONNEES ...................................................................................................... 104 ARCHIVAGE DES DOCUMENTS ................................................................................................. 107 PREPARATION FINALE........................................................................................................ 111 TEST ARCHIVAGE DES DONNEES .............................................................................................. 111 TESTS ARCHIVAGE DES DOCUMENTS ....................................................................................... 112
25.08.2010 6/145
5 5.1 5.2 V 1 2 3 3.1 3.2 3.3 3.4
GO LIVE ET SUPPORT ........................................................................................................... 113 RESULTAT APRES LE PREMIER CYCLE DARCHIVAGE DES DONNEES ........................................ 113 RESULTAT APRES LARCHIVAGE DES DOCUMENTS .................................................................. 114 CONCLUSION .......................................................................................................................... 117 BILAN DU PROJET ................................................................................................................. 117 CONSIDERATIONS PERSONNELLES ................................................................................ 119 AUTRES PROJETS.................................................................................................................. 120 PAYNET .................................................................................................................................. 120 ARCHIVAGE DE DONNEES SAP CHEZ ALCAN ALUMINIUM VALAIS SA ................................... 121 ARCHIVAGE DES DOCUMENTS ESB BIENNE ............................................................................ 122 GESTION DES DOCUMENTS AUX SERVICES INDUSTRIELS DE LAUSANNE .................................. 122 ANNEXES.................................................................................................................................. 125 ILM OU GESTION DU CYCLE DE VIE DE LINFORMATION. .................................... 125 1.1 1.2 1.3 1.4 DEFINITION ............................................................................................................................. 125 OBJECTIF ................................................................................................................................. 125 DEMARCHE ............................................................................................................................. 125 CYCLE DE VIE DE LINFORMATION .......................................................................................... 126 NOM DU FICHIER LOGIQUE .............................................................................................. 127 2.1 2.2 2.3 CREATION DUN CHEMIN LOGIQUE .......................................................................................... 127 DEFINITION DU NOM DE FICHIER LOGIQUE ............................................................................... 127 MOTS RESERVES...................................................................................................................... 128 HTTP CONTENT SERVER DE SAP ..................................................................................... 129 CODE SOURCE ZP_ISU_LOAD_FACTURE_PDF............................................................. 131 EXEMPLE DE PROGRAMME DE LECTURE DES ARCHIVES ..................................... 136 BIBLIOGRAPHIE ............................................................................................................... 139 LIENS INTERNET ................................................................................................................... 139 SUPPORT DE COURS SAP .................................................................................................... 141 LISTE DES FIGURES ......................................................................................................... 143 LISTE DES TABLEAUX ......................................................................................................... 145
VI 1
3 4 5 VII 1 2 VIII IX
Bolognesi Michel
25.08.2010
7/145
Introduction
SAP (SAP Systems Analysis and Program Development) est un progiciel intgr de gestion dentreprise, compos de plusieurs modules lis troitement entre eux. Il permet de satisfaire les exigences, mme les plus pointues, dun vaste ventail de socits, de nature, de milieu et de mtier trs diffrents. Ce progiciel sappuie solidement sur une base de donnes, qui, au fil du temps, augmente considrablement de volume. Cet accroissement implique une perte de performances progressive et exponentielle, une augmentation des cots lis la gestion du volume de donnes et un temps inacceptable dindisponibilit en cas de problme. Lobjectif premier de ce projet d Archivage de donnes SAP dfini il y a cinq ans tait dtudier et de mettre en uvre une solution visant matriser les problmes lis la croissance du volume de la base de donnes mentionns prcdemment. Cela signifiait amliorer les temps de rponse des transactions, rduire les cots dexploitation et diminuer le temps dindisponibilit du systme en cas de problme. Cependant, au cours de ces annes, le client, pour lequel ce projet tait prvu, a renvoy la date de mise en uvre maintes reprises. Nanmoins, lapprentissage de larchivage lectronique, ltude de la mise en uvre du projet et une ralisation partielle a t ralise. De manire subjacente lobjectif premier du projet, dautres aspects indissociables larchivage ont d tre tudis tels que la gestion de contenu, le systme de stockage et les bases juridiques concernant la conservation des documents. Ces derniers, en particulier la gestion de contenu, ont fait lobjet de plusieurs ralisations non prvues dans les besoins initiaux. La rdaction de ce mmoire va sarticuler entre plusieurs parties. La premire se concentre sur le primtre du projet : ses acteurs, l'environnement SAP install et les perspectives. La deuxime vise dmystifier le concept darchivage lectronique. Ensuite, la troisime se focalise sur le fonctionnement des outils darchivage SAP. La quatrime dcrit la partie ralis du projet. Enfin, la dernire partie sera ddie une brve projection des projets annexes et des considrations personnelles.
Bolognesi Michel
25.08.2010
9/145
I Premire partie : primtre du projet

Cette premire partie vise exprimer brivement la raison de la naissance de ce projet darchivage, le postulat de base et les volutions de ce dernier, influenc par lenvironnement et par lvolution des besoins exprims par les acteurs. Tout cela aboutira la dfinition du primtre du projet.
Naissance du projet
Le projet est n de manire atypique, cest--dire que le besoin na pas t exprim par
le client, mais par lditeur du progiciel SAP. Ce dernier prconise quaprs un certain temps dumas-00530235, version 1 - 28 Oct 2010 dutilisation du progiciel, il faut prvoir et mettre en uvre de larchivage. Neo technologies SA, mon employeur, a propos Romande Energie SA, son client, dtudier et mettre en place un systme et des processus darchivage. Le projet na pas encore abouti car ce besoin nest pas vital pour le client et ce dernier a repouss sa ralisation maintes reprises car il avait dautres priorits.
2
2.1
Environnement
Prsentation des socits
neo technologies SA
neo technologies SA est une socit de services informatiques et de consulting qui
2.1.1
offre des prestations de conception et ralisation, dexploitation et support de systmes dinformation. Reconnue sur le march comme centre de comptences Utilities , elle ralise des projets de dveloppement et dintgration de nouvelles technologies dans ce secteur. Outre le march de lnergie quelle matrise depuis de nombreuses annes, neo technologies uvre dans le secteur public et offre aux collectivits un service et des solutions de gestion sappuyant sur la plateforme SAP.
2.1.2
Romande Energie SA
Romande Energie SA est la socit oprationnelle du Groupe Romande Energie cot
en bourse. Ce dernier est le cinquime fournisseur en Suisse de production, distribution et vente dlectricit.
Bolognesi Michel
25.08.2010
11/145
L'Etat de Vaud et plus de deux cents communes vaudoises (dont 130 lies par une convention) sont, ensemble, ses plus gros actionnaires. Romande Energie dtient des participations importantes dans Alpiq et les Forces Motrices Hongrin-Lman.
2.1.3
SAP
SAP est une socit allemande fonde en 1972. Grce ses nombreuses annes
dexprience et son incessante innovation, SAP est devenu un vritable leader mondial dans le logiciel de gestion dentreprise1 et inter-entreprise.
2.2
Gnralit sur le PGI (progiciel de gestion intgr)

Le progiciel de gestion intgr se caractrise par une conception unique pouvant
couvrir lensemble des besoins du systme dinformation2 de lentreprise. Dans ce dessein, il dumas-00530235, version 1 - 28 Oct 2010 est subdivis en modules qui couvrent chacun un des domaines ou primtres de gestion de lorganisation. En cas dimpact dun module, linformation est mise jour en temps rel dans lensemble des autres modules associs. Par exemple, la saisie d'une vente gnre automatiquement une criture comptable en partie double dans le journal des ventes, avec calcul automatique de la TVA collecte. Le grand livre et le compte de rsultat sont automatiquement impacts. Grce ce lien troit entre modules, le PGI facilite la recherche et lanalyse dinformations lors daudits. Chaque entreprise a ses propres flux et modes de fonctionnement. Dans ce but, un PGI est paramtrable souhait et peut tre adapt pour le dveloppement de programmes spcifiques. Cependant, les dveloppements sont, en gnral, rduits au minimum, car ils sont trs coteux la ralisation et surtout la maintenance, sans compter les risques de dysfonctionnements mal matriss sur les autres modules.
Soit nomm par lacronyme anglais ERP Enterprise Ressource Planning , soit, dans le monde
francophone, par la dnomination PGI (Progiciel de gestion intgr). Cependant, la terminologie anglo-saxonne prime.
2
Un systme d'information (not SI) reprsente l'ensemble des lments participant la gestion, au
stockage, au traitement, au transport et la diffusion de l'information au sein d'une organisation. (Wikipdia)
Bolognesi Michel
25.08.2010
12/145
2.3
PGI SAP en gnral

Comme dj voqu, SAP, depuis sa fondation, a progress et innov aussi bien
fonctionnellement que techniquement, pour satisfaire une clientle trs diverse, de milieux et domaines trs diffrents. On pourrait presque affirmer que SAP a cr son propre monde trs riche et vari, dont je vais me limiter mentionner les principales solutions en mappuyant sur la Figure 1 : intgration des solutions mySAP 3.
Figure 1 : intgration des solutions mySAP
2.3.1
SAP ERP (Entreprise Ressource Planning)

SAP ERP est une suite de modules de gestion relative la finance, aux services
d'entreprise, aux applications analytiques, aux fonctions de self service et la gestion des ressources humaines et des oprations. En quelques mots, cest le vrai PGI de loffre SAP. Le projet Archivage de donnes SAP se droule dans cet environnement.
2.3.2
SAP PLM (Product Lifecycle Management)

SAP PLM est une application spcifique pour la gestion des cycles de vie des produits.
PLM est un environnement qui assure un accs rapide et fiable aux informations les plus rcentes pour tous les acteurs du processus de dveloppement du produit, de fabrication et de maintenance.
Rgulirement, lditeur allemand change et modifie la dnomination de ses produits. Cependant, le
contenu et les fonctionnalits deviennent beaucoup plus stables.
Bolognesi Michel
25.08.2010
13/145
2.3.3
SAP CRM (Customer Relationship Management)

SAP CRM est une application centrale sur laquelle les diffrents canaux de
distribution traditionnels viennent se greffer pour la gestion de la clientle. Elle fournit les outils ncessaires pour le support et le service de la clientle, ainsi que pour le marketing et la vente.
2.3.4
SAP SRM (Supplier Relationship Management)

SAP SRM est une application pour la gestion des relations fournisseur. Elle met
disposition un systme de collaboration pour toutes les fonctions qui touchent la gestion des achats et la relation fournisseur.
2.3.5
SAP SCM (Supply Chain Management)

SAP SCM est une application pour la gestion globale de la chane logistique allant du
fournisseur du fournisseur au client du client.
2.3.6
Bus dintgration SAP NetWeaver

Depuis 2004, SAP a mis disposition une plate-forme applicative et dintgration
nomme NetWeaver. Elle permet la communication entre la suite logicielle mySAP Business Suite, reprsentes par la figure 1, et toutes autres tierces applications. Ce socle technologique est compatible avec les normes internet telles que le protocole HTTP ou le langage XML, ainsi que les services Web. NetWeaver se caractrise galement par son ouverture et son interoprabilit avec Microsoft .NET et les environnements J2EE (Java 2 Platform Enterprise Edition) tels que IBM WebSphere.
2.3.7
Architecture SAP
SAP ERP est un progiciel client/serveur n-tiers subdivis en trois couches :
prsentation, application et base de donnes selon la figure 2.
Bolognesi Michel
25.08.2010
14/145
Figure 2 : modle en trois couches.
2.3.7.1
Couche reprsentation (Presentation layer) SAPgui (graphical user interface) est la couche reprsentation install sur le poste des
utilisateurs pour visualiser ou modifier les textes, les champs de la base de donnes, les tapes dun flux de travaux, etc.. 2.3.7.2 Couche applicative (Application Layer) La couche applicative, comme son nom lindique, est un ensemble de programmes, dapplications excutes par un ou plusieurs serveurs. Le lien entre ces serveurs est fait par un dispatcher. Ce dernier reoit les requtes de la couche prsentation et lachemine vers le serveur disponible. Le serveur interagit avec la couche prsentation, le gestionnaire de base de donnes et avec toutes autres connections externes tel que NetWeaver mentionn prcdemment. 2.3.7.3 Couche base de donnes (DataBase Layer). La couche base de donnes est un systme central contenant toutes les donnes. Dans ce dessein, un gestionnaire de base de donnes (Database Management System) est trait dunion entre la couche applicative et une base de donnes. Dans le cadre de ce projet, ORACLE version 10 est la base de donnes utilise. 2.3.7.4 Paysage systme Chaque solution SAP est installe dans un paysage systme distinct dfini par trois environnements reprsents par la figure 3: dveloppement, qualit et production. Un
Bolognesi Michel
25.08.2010
15/145
environnement est une instance de la couche applicative et de base de donnes installe sur un ou plusieurs serveurs appartenant au mme domaine rseau.
Figure 3 : paysage systme
Lenvironnement de dveloppement est utilis pour le codage des programmes spcifiques, pour le paramtrage et pour les tests sommaires. La vrification de la pertinence de ces derniers est accomplie par des tests approfondis dans lenvironnement de qualit. Aprs approbation, les nouvelles fonctionnalits sont utilises dans lenvironnement de production. Le passage du code des programmes spcifiques et du paramtrage se fait par lappel de fonctions distantes entre les environnements appels transport.
2.4
Implmentation de SAP Romande Energie

Depuis 2002, Romande Energie a implment SAP pour couvrir la quasi-totalit des
besoins de son systme dinformation, principalement par les modules suivants : IS-U (Industrie system utilities) : cest un module spcialis pour toutes les entreprises du domaine de la vente et de la distribution dlectricit, gaz, eau, multimdia et chauffage distance. Ce dernier comprend plusieurs parties : o La gestion des donnes de base : commerciales (les clients, les contrats, etc.) et techniques (les appareils, les installations, etc.). o La gestion du processus de facturation et de comptabilisation o La gestion de la maintenance par des contrles priodiques des appareils du rseau, la dlivrance de certificats de conformits des installations, etc. o La gestion des changes des courbes de charges de consommation.
Bolognesi Michel 25.08.2010 16/145
MM (Material Management) : cest le module logistique de SAP. Il gre les achats darticles et les stocks darticles (les mouvements de stocks : entres et sorties, transferts de stocks). MM permet en particulier le calcul des besoins, la gestion des achats et des rapprovisionnements, mais aussi les demandes dachat et les contrats. MM gre aussi les emplacements magasin (WM Warehouse Management) et contrle les factures dachat.
SD (Sales and Distribution) : cest le module dadministration des ventes. Il gre les appels d'offres, les offres, les contrats, les commandes clients, les expditions et livraisons, les remises, la facturation et le systme d'information commercial.
PM (Plant Maintenance) : cest le module de maintenance des appareils installs sur le rseau de distribution lectrique. PM permet de dcrire le rfrentiel technologique des postes techniques et des quipements. Il traite galement les ordres de maintenance jusqu lachvement de lensemble des oprations dentretien des quipements et des appareils.
FI (Financial) : cest le module comptable contenant toutes les critures comptables de ventes, dachats et dimmobilisations, qui se centralisent dans la comptabilit gnrale. FI se subdivise en plusieurs sous modules : o FI-AR (Accounts Receivable) : comptabilit client o FI-AP (Accounts Payable) : comptabilit fournisseur o FI-AM (Assets Management) : comptabilise les immobilisations o FI-GL (General Ledger) : comptabilit gnrale
CO (Costing) : cest le module de contrle de gestion de lentreprise. Il permet lanalyse des cots par centre de profits, par catgorie de produits/services/projets. Il permet galement ldition du compte de rsultat, de reportage dactivits et danalyses financires.
HR (Human Resources) : cest le module de la gestion du personnel. HR permet de grer les recrutements, les paies des employs, les comptences des employs, de suivre les temps de travail et les volutions de carrire, de grer les demandes et les frais de dplacement.
Bolognesi Michel
25.08.2010
17/145
Objectifs du projet
Aprs la prsentation des acteurs et de lenvironnement, ce travail se consacre aux objectifs de ce projet darchivage de donnes SAP tels quils mont t attribus : 1. Dcouvrir le milieu de larchivage lectronique, son langage, ses pratiques et son application de manire gnrale. 2. Dcrire les outils propres au systme SAP dans le domaine de larchivage de donnes, ainsi quun systme darchivage pour le stockage des fichiers darchive. 3. Cibler les objets darchivage potentiels par une analyse des besoins techniques et fonctionnels tels que la volumtrie des donnes, les problmes de performances, la suppression dentits organisationnelles obsoltes. 4. Dfinir les besoins en termes de rtention de donnes et les contraintes lgales de dumas-00530235, version 1 - 28 Oct 2010 donnes. 5. Prsenter une structure de projet complte avec les intervenants ainsi que les responsabilits dans un projet darchivage SAP. 6. Raliser, dans un premier temps, une maquette dans le systme de qualit pour valider les concepts thoriques tudis. Puis, dans un deuxime temps, raliser la mise en uvre de larchivage dans le systme productif en orchestrant tous les intervenants de la structure du projet prsent. 7. Planifier lexcution priodique des lots de programmes darchivage et larchivage long terme.
Bolognesi Michel
25.08.2010
18/145
II Les concepts de larchivage lectronique

Cette partie vise donner un aperu thorique et gnrique de larchivage lectronique, sans prendre en considration les spcificits de lditeur allemand. Il sagit en quelque sorte de labcdaire de larchivage lectronique, largement inspir par louvrage Dmatrialisation et archivage lectronique (voir VII Bibliographie rfrence 1) et la compilation de plusieurs ressources trouves sur la toile (voir VII1Liens internet). Pour apprhender le sujet, le premier chapitre va dfinir larchivage lectronique. Il sera suivi par les besoins de conservations qui convergent principalement aux contraintes lgales. Par consquence le troisime chapitre est consacr aux lois et aux codes des obligations qui dfinissent dans une certaine mesure les caractristiques dun systme dumas-00530235, version 1 - 28 Oct 2010 darchivage. Le dernier chapitre relve le dfi de dcrire comment ces caractristiques peuvent tre mises en uvre par les outils et technologies actuelles.
Dfinition
L'archivage lectronique consiste archiver des donnes sous forme lectronique sur
un support lectronique ddi cet effet. Les informations sont donc dmatrialises, cest-dire converties en donnes numriques (pour des informations issues de supports analogiques tels que papier, film, microfilm, etc.) ou simplement transposes (pour des informations issues de formats lectroniques). A noter que par abus de langage, les termes de sauvegarde et darchivage sont parfois confondus. Cependant, ces notions sont bien diffrentes : La sauvegarde : elle a comme finalit de permettre une copie des donnes dorigine dite copie de scurit afin dviter de les perdre en cas de dysfonctionnement du dispositif sur lequel elles sont enregistres. La dure de conservation est dconnecte de la valeur du contenu et relative la priodicit de la sauvegarde. Larchivage 4: il est dfini comme lensemble des actions visant identifier, recueillir, classer et conserver des informations, en vue de consultation ultrieure, sur un support adapt et scuris, pour la dure ncessaire la satisfaction des obligations lgales ou des besoins dinformation. Contrairement la sauvegarde, les donnes archives sont considres comme figes (non modifiables) et aisment consultables.
Selon norme NF Z42 013
Bolognesi Michel
25.08.2010
21/145
1.1
Terminologie
Avant de continuer, il est opportun de dfinir certains termes utiliss dans le contexte document numrique et
de larchivage lectronique: donne, information, connaissance, dossier.
Donne : est la reprsentation dune ide ou dun fait sous une forme conventionnelle, code et structure pour que son traitement puisse tre automatis, gnralement laide doutils informatiques. Information : est un ensemble de donnes lies entre elles et porteuses de sens. Connaissance : est une information que son utilisateur, dans un contexte donn, entend explorer pour une action particulire. Document numrique : est un ensemble de donnes organises selon une dumas-00530235, version 1 - 28 Oct 2010 structure stable associe des rgles de mise en forme permettant une lisibilit partage entre son concepteur et ses lecteurs. Dossier : est constitu par lensemble de document ou /et dinformations qui tracent et documentent une action.
Besoin de conservation
Larchivage lectronique est une rponse au besoin dune entit de conserver des
documents. La conservation est lie principalement trois facteurs majeurs : lobligation lgale et daudit, le contentieux et le besoin oprationnel de lentit. Nanmoins, ce sont principalement les exigences lgales et daudit qui ont influenc les bonnes pratiques de mise en uvre dun systme darchivage. Lobligation lgale et daudit : est encadre par la rglementation et les codes dobligations cantonales, fdrales ou internationales. Ces derniers sont requis en cas daudit fiscal ou financier, ou daudit interne. Le contentieux : est la capacit de fournir, lors dun litige, des documents probants, authentiques et dans le temps imparti. Cet ensemble est le plus difficile cerner car la matire contentieuse est, par nature, imprvisible. Lindentification de ces archives relve dune valuation des risques de non disponibilit de linformation en cas de recherche. La valeur de preuve tant dcide par le juge, il sagit danticiper au mieux la survenance et lvolution des litiges.
Bolognesi Michel
25.08.2010
22/145
Le besoin oprationnel de lentit : constitue lensemble des informations qui sont utiles lentit pour son fonctionnement soit par le pass, soit pour le futur. Parmi ces informations, il y a les comptes rendus de sances stratgiques, les procds, les projets de brevets abandonns, les tudes, etc.
Environnement juridique
Les socits suisses ont lobligation de conserver les documents au regard du droit des
socits et du droit fiscal. Les entits soumises surveillance, tels les intermdiaires financiers ou les banques, ont des exigences supplmentaires relatives cette obligation de conservation. Ce chapitre vise donner un bref aperu de la lgislation fdrale concernant larchivage lectronique. Le but est de mettre en vidence cette problmatique. Il va de soi dumas-00530235, version 1 - 28 Oct 2010 que des particularits demeurent selon les domaines (notamment les professions mdicales) et que des prescriptions cantonales entrent galement en ligne de compte. De manire gnrale, les lois et rglements servent de base la dtermination des rgles de conservation, qui spcifient aussi bien la dure que le support des documents. Malheureusement, en Suisse, peu de textes fixent des dlais relatifs la conservation des documents pour les entreprises prives. Le Code des Obligations (CO) et lOrdonnance concernant la tenue et la conservation des livres de comptes (Olico) donnent des indications uniquement pour les documents comptables. Les lois sur les archives publiques ou dautres textes lgaux, comme la LPD (Loi Fdrale sur la protection des donnes), apportent quelques complments. Il est galement souvent admis de prendre modle sur certaines pratiques trangres.
3.1
Droit suisse des socits

En droit suisse, toute entit inscrite au Registre du commerce a lobligation de
conserver les documents commerciaux pendant une priode de 10 ans ou plus selon les cas. Cette obligation sapplique en particulier aux socits anonymes et aux socits responsabilit limite. Les documents qui entrent dans le champ dapplication de cette obligation gnrale de conservation et darchivage sont : - les documents comptables de la socit, savoir les divers tats financiers que la socit est tenue de conserver en vertu des dispositions de droit comptable (comme le bilan, les comptes de rsultats, etc.), - les justificatifs y affrents (factures, reus, relevs de comptes, etc.),
- les procs-verbaux (assembles gnrales, runions du conseil dadministration) , - les contrats et - la correspondance commerciale (entrante et sortante).
3.1.1
Correspondance
Concernant la correspondance en particulier, les entreprises devraient au moins
conserver celle qui prsente un intrt du point de vue comptable. Dune manire gnrale, les documents purement internes, tels notes, projets, correspondance interne et documents similaires, nont pas tre conservs et archivs. Il nest nanmoins pas toujours vident de tracer une limite claire entre documents internes et externes. A titre dexemple, un contrat de travail sera qualifi de document externe dumas-00530235, version 1 - 28 Oct 2010 dans ce contexte.
3.1.2
Forme darchivage
Le droit suisse des socits contient des dispositions concernant la forme de
larchivage : seuls les comptes de rsultats et de bilans doivent tre conservs sous forme crite et dment signs. Par contre, les documents sociaux, les documents comptables, la correspondance et les autres documents peuvent tre conservs sous forme crite ou sur un support lectronique ou comparable, condition que lauthenticit soit garantie. Les donnes sur supports lectroniques doivent toutefois tre accessibles tout moment.
3.1.3
Disposition sur la conservation lectronique

Lordonnance fdrale sur la tenue et la conservation des livres de comptes (Olico art.
957) donne certaines directives. Ces dernires sont considres de la bonne pratique pour la conservation des documents de manire gnrale. Voici le contenu des principaux testes : Intgrit (authenticit et infalsifiabilit) (art.3) Le mode de tenue, de saisie et de conservation doit garantir que les livres, les pices comptables et la correspondance ne puissent tre modifis sans que la modification soit apparente .(art. 3) Disponibilit (art. 6) Jusqu la fin du dlai de conservation, toute personne autorise doit pouvoir, en tout temps et dans un dlai raisonnable, consulter et vrifier les livres, les pices comptables et la correspondance. Organisation (art.7)
Bolognesi Michel
25.08.2010
24/145
Les
informations archives sont spares des informations actuelles, ou sont
signales de telle manire que la distinction soit possible. La responsabilit des donnes archives doit tre clairement rgle et consigne dans un document. Laccs aux donnes archives doit tre possible dans un dlai raisonnable. Archives (art.8) Les informations sont inventories systmatiquement et protges contre les accs non autoriss. Les consultations et les accs sont enregistrs. Ces enregistrements sont soumis la mme obligation de conservation que les supports de donnes. Supports dinformation autoriss (art.9) 1. Sont autoriss pour la conservation de documents: a. les supports dinformation non modifiables, notamment le papier, les supports dumas-00530235, version 1 - 28 Oct 2010 dimages et les supports de donnes non modifiables. 2. Les supports dinformation modifiables si: a. des procds techniques (p. ex. signature lectronique) sont utiliss, qui garantissent lintgrit des informations enregistres; b. le moment o les informations ont t enregistres peut tre prouv sans possibilit de falsification (p. ex. grce un systme dhorodatage); c. les autres prescriptions relatives lutilisation du procd en question qui existent au moment de lenregistrement sont respectes, et les procdures et les modes dutilisation de ces supports sont consigns et les informations ncessaires (protocoles, journal de bord des connexions [log files]) sont galement conserves. Les supports dinformation sont rputs modifiables lorsquils peuvent tre modifis ou effacs sans que lopration soit dtectable sur le support de donnes lui-mme (p. ex. bandes magntiques, disquettes magntiques ou optico-magntiques, disques durs ou disques amovibles, disques ltat solide [solid-state]). Contrle et migration des donnes (art. 10) Les supports informatiques doivent faire lobjet dun contrle de leur intgrit et de leur lisibilit. Les donnes peuvent tre modifies et transfres sur un autre support et/ou format dans le cas dune migration, mais les lments suivants doivent tre garantis : Les informations restent compltes et exactes. La disponibilit et la lisibilit continuent de satisfaire aux exigences lgales. La migration doit faire lobjet dun procs-verbal.
Bolognesi Michel
25.08.2010
25/145
3.1.4
Lieu de conservation
Concernant le lieu darchivage des documents, il ny a aucune disposition en droit
suisse qui impose que ces documents doivent tre conservs en Suisse (mise part certaines obligations concernant la lgislation en matire de blanchissement dargent5). Il ny a donc, aucun obstacle ce que des documents soient archivs ltranger, pour autant que les personnes habilites puissent y accder dans un dlai raisonnable.
3.2
Spcificit concernant les factures et pices justificatives au regard de la TVA

La conservation des factures et des autres pices justificatives est une des obligations
fondamentales des assujettis. Elle permet ladministration de procder aux vrifications de dumas-00530235, version 1 - 28 Oct 2010 la comptabilit et des dcomptes au regard de la TVA (art. 43 OLTVA). Les donnes et les informations qui sont transmises ou conserves lectroniquement ou de faon analogue et qui sont pertinentes pour la dduction de limpt pralable, pour la perception ou pour le recouvrement de limpt ont la mme force probante que celles qui sont lisibles sans moyen auxiliaire, pour autant que les conditions suivantes soient remplies: Preuve de lorigine Preuve de lintgrit Incontestabilit de lenvoi et de la rception Les assujettis, doivent garantir que ces donnes et ces informations puissent tre lisibles en tout temps pendant la dure du dlai lgal de conservation. A cet effet, lassujetti doit mettre disposition les moyens ncessaires. Il doit, sur demande, permettre lAdministration fdrale des contributions daccder directement aux donnes conserves lectroniquement. En ce qui concerne la tenue et la conservation par un moyen lectronique ou de faon analogue des livres comptables, des pices comptables et de la correspondance commerciale, les prescriptions de lart. 957 du code des obligations (CO) sont applicables par analogie.
Des exigences spcifiques rsultant de la lgislation et de la rglementation bancaire et de la loi
fdrale sur le blanchiment dargent, prvoit que les intermdiaires financiers, auxquels appartiennent les banques, doivent tablir et conserver les documents concernant les transactions et les clarifications obtenues en vertu de la lgislation anti-blanchiment. A ce sujet le serveur sur lequel ces documents conservs sous une forme lectronique doit tre situ en Suisse. Si tel nest pas le cas, il faut que lintermdiaire financier dispose en Suisse soit dune copie papier des documents pertinents, soit dune copie lectronique.
Bolognesi Michel
25.08.2010
26/145
3.3
Procdure civile6
Lorsquune procdure civile advient entre deux parties adversaires, des titres sont
prsents pour prouver les faits. La partie qui invoque un titre doit en prouver lauthenticit si la partie adverse la conteste sur la base de motifs suffisants (art. 175). Ces titres sont des documents, tels que des crits, des dessins, des plans, etc. (art. 174). Cela nimporte pas quils soient sur un support traditionnel ou digital, ou quils soient issus dun support lectronique ds lorigine ou dun document traditionnel scann. Cela rsulte galement du droit la preuve (art. 150). On peut mme faire valoir une copie classique ou de produits de llectronique valeur probante lorsque larchivage de cette dernire est conforme aux rgles du doit commercial (Olico).
3.4
Temps de conservation
Le temps de conservation lgal des documents commerciaux est fix en gnral dix
ans. Cependant, il convient dviter de confondre dlai de conservation et dlai de prescription. En effet, si certaines actions judiciaires dans lesquelles un document est requis sont toujours en cours avant le terme de la dure de prescription, ce dernier ne doit en aucun cas tre dtruit. Cest la raison pour laquelle plusieurs experts en archives7 prconisent un dlai de rtention bien suprieur. Le tableau ci-dessous en donne un aperu :
La procdure civile est un ensemble de moyens mis la disposition des particuliera par lEtat pour leur
permettre dobtenir la conscration de leurs droits privs, quils soient contests ou subordonnes au prononc dune dcision.
7
Voir http://www.archives.ch/
Bolognesi Michel
25.08.2010
27/145
Type de document
DOCUMENTS COMPTABLES
Journal Livre dinventaire, Grand livre, Bilan annexe, Comptes de rsultat, Journaux auxiliaires, Balances, etc.
Dlai lgal
Dlai suggr
10 ans aprs la clture de lexercice
11 ans aprs la clture de lexercice
FACTURES ET PRTS
Factures, Contrats dassurance, Contrats de prts, etc.
10 ans aprs la clture de lexercice. 10 ans aprs la clture de lexercice. 10 ans aprs la clture de lexercice. Aucun dlai nest fix par la loi Aucun dlai nest fix par la loi 10 ans Aucun dlai nest fix par la loi
Tableau i: Temps de conservation
11 ans aprs la clture de lexercice 11 ans aprs la clture de lexercice 11 ans aprs la clture de lexercice 30 ans
DOCUMENTS FISCAUX
Impts, TVA, etc.
DOCUMENTS BANCAIRES
Relevs de comptes, Bordereaux de remises, etc.
CONTRATS COMMERCIAUX
Marchs, Plans, Cahiers des charges, etc.
INVESTISSEMENTS
Contrats dacquisition, Contrats de cessions, Contrats de participations, etc.
30 ans
SALAIRES
Livre de paie, Bulletin de paie, etc.
80 ans 10 ans
SAUVEGARDES INFORMATIQUES
Contraintes techniques du systme darchivage.

Ce chapitre relve le dfi de dcrire comment les lois et les obligations vues
prcdemment peuvent tre mises en uvre par les outils et technologies actuelles, en abordant notamment les notions suivantes : le format de fichier, la scurit, la signature lectronique, le cycle de vie de linformation, le support physique et le systme darchivage.
4.1
Format des documents lectroniques

Come dfini prcdemment, un document numrique est un ensemble de donnes
organises selon une structure stable associe des rgles de mise en forme permettant une
Bolognesi Michel
25.08.2010
28/145
lisibilit partage entre son concepteur et ses lecteurs. Ces rgles sont rgies par des formats de fichiers. La lisibilit des formats de fichiers est lie au matriel physique, au systme dexploitation et au logiciel. Il est possible de distinguer les types de format que lon peut rencontrer du plus ouvert au plus ferm : Standard : lorsquils sont produits par un organisme de normalisation et que leur utilisation est libre. Ouvert : quand les spcifications sont libres. Propritaire : lorsquils sont dfinis par une entreprise prive et que leur utilisation est soumise des droits. Ferm : quand les spcifications sont tenues secrtes par leur propritaire. dumas-00530235, version 1 - 28 Oct 2010 Les formats fichier peuvent, pour diffrentes raisons, disparatre au cours du cycle darchivage du document. Pour cette raison, il est ncessaire de pouvoir accder aux spcifications dudit format et ainsi pouvoir crire au besoin un programme destin linterprter. Ce sont les raisons pour lesquelles, dans le cadre darchivage, il est fortement recommand dutiliser des formats standards ou ouverts tel que XML ou PDD/A.
4.1.1
XML (eXtensible Makup Language)

XML est un langage informatique de balisage gnrique. Il sert essentiellement
stocker/transfrer des donnes au format texte Unicode8 structures en champs arborescents. Ces principaux atouts sont : Format standard ouvert, gratuit et libre de droits. Il est dfini sous la responsabilit du World Wide Web Consortium (W3C). Facilement lisibles et comprhensibles car il est au format texte unicode. XML est un mtalangage extensible souhait et permet de crer ses propres balises9.
Unicode est une norme informatique, dveloppe par le Consortium Unicode, qui vise donner tout
caractre de nimporte quel systme dcriture un nom et un identifiant numrique, et ce de manire unifie, quelle que soit la plate-forme informatique ou le logiciel (voir http://fr.wikipedia.org/wiki/Unicode )
9
Marque qui permet d'identifier un lment d'un fichier, sa fonction, son emplacement
(http://www.linternaute.com/dictionnaire/fr/definition/balise/ )
Bolognesi Michel
25.08.2010
29/145
Sa structure arborescente permet de modliser la majorit des problmes informatiques. Il est universel et portable : le format texte tient compte des diffrents jeux de caractres est comprhensible par tous les systmes d'exploitation. Il est dployable : il peut tre facilement distribu par n'importe quels protocoles mme de transporter du texte, comme HTTP10. Il a un niveau lev d'intgrabilit: un document XML est utilisable par toute application pourvue d'un parser11. Grce tous ses atouts, XML facilite la migration des documents qui peuvent ou doivent tre migr lors du cycle de vie de conservation.
4.1.2
PDF/A
Avant de parler de PDF/A ( A comme archive), il convient de prciser ce qu'est le
format PDF. Le PDF (Portable Document Format) a t initialement cr par Adobe Systems, pour grer ses changes de documents en interne. Son usage sest ensuite largement rpandu principalement grce au fait quil permettait de reproduire fidlement des textes et images complexes lcran comme sur limprimante, quelle que soit l'application ou la plate-forme utilise pour le crer. Le PDF est un langage de reprsentation de documents, riche en fonctionnalits qui na cess de stoffer au travers de ses versions successives. Les documents PDFs peuvent tre simples ou complexes, structurs ou non structurs. Ils peuvent contenir du texte, des images, des graphiques et mme des contenus multimdia (documents sonores ou images animes). Les annotations, les mtadonnes, les liens hypertextes, les signets ainsi que la signature lectronique sont galement supports par ce format de fichier. Depuis juillet 2008, les spcifications et publications sont sous la tutelle de lorganisme international de normalisation ISO sous la rfrence ISO 32000-1. PDF/A est une famille de normes ISO (ISO 19005) qui dfinit des sous-ensembles du format PDF des fins d'archivage long terme de documents lectroniques. Cette norme dfinit les exigences pour la cration de documents adapts larchivage, en se basant sur le
10
hypertext markup language : langage informatique permettant de dsigner la structure d'un document
l'aide de balises et d'tablir des liens hypertextuels entre ses diffrents constituants et d'autres textes. (http://fr.encarta.msn.com/dictionary_2016011710/HTML.html )
11
Logiciel permettant d'analyser un code XML et d'en dterminer sa structure syntaxique afin
d'effectuer divers traitements, comme par exemple la visualisation.
Bolognesi Michel
25.08.2010
30/145
format de fichier PDF. Elle spcifie en dtails quels sont les types de contenu autoriss et ceux qui ne le sont pas. Ces spcifications sont destines assurer la lisibilit dans le temps des fichiers, indpendamment des applications et des systmes dexploitation dans lesquels ils ont t produits. PDF/A repose sur la version 1.4 de PDF. Pour assurer la portabilit dans le temps, certaines fonctionnalits contenues dans le PDF 1.4 sont exclues de la norme, comme le mode transparent, l'inclusion de squences sonores, d'images animes, d'images fixes comprimes avec JPEG 2000, etc. En revanche, le PDF/A impose certaines fonctionnalits comme lincorporation des polices de caractres ncessaires l'affichage des textes, lajout des mtadonnes au format XMP12, etc. Les principaux avantages de ce format PDF/A sont : Spcifications disponibles : La publication de la norme garantit la possibilit dumas-00530235, version 1 - 28 Oct 2010 pour toute entreprise ou toute administration de pouvoir accder librement aux spcifications du format et donc de pouvoir crer librement des logiciels de lectures ou de production de fichiers conformes PDF/A. Metadonnes : Des mtadonnes, comme le titre, lauteur, la date de cration du document, sa date de modification, le sujet, les mots-clefs, etc. peuvent tre enregistres directement dans le fichier PDF/A. Ainsi, les documents peuvent dune part tre classs automatiquement sans intervention manuelle et, dautre part, ces dernires peuvent garantir lauthenticit du document. Recherche texte avance : PDF/A peut enregistrer les documents en mode "texte", ce qui permet une recherche avance sur un mot, des expressions, des chiffres. Cela nest pas le cas pour des fichiers de type image tels que JPEG ou TIFF (utiliss galement pour larchivage) sans laide dun ROC13.
4.2
Contraintes scuritaire
Les documents lectroniques dfinis par le format de fichiers dcrits doivent tre
scuriss en respectant les contraintes dcoulant de lordonnance fdrale sur la tenue et la conservation des livres de comptes (Olico art. 957) voque prcdemment.
12
Extensible Metadata Platform ou XMP est un format de mtadonnes bas sur XML. XMP permet
d'enregistrer sous forme d'un document XML des informations relatives un fichier : titre, auteur, historique des modifications, etc. Bien qu'ouvert tout type de donnes pouvant intgrer un document XML, XMP prdfinit la faon de stocker un certain nombre d'informations les plus courantes.
13
La reconnaissance optique de caractres (ROC) : dsigne les procds informatiques pour la
traduction d'images de textes imprims ou dactylographis en fichiers de texte.
Bolognesi Michel
25.08.2010
31/145
Ci-aprs seront mentionnes les contraintes dintgrit, de traabilit, de confidentialit, daccessibilit, dindentification et de traitement des virus.
4.2.1
Intgrit
Techniquement, lintgrit se concrtise par la cration dune empreinte lectronique
du document. Lempreinte est le rsultat dun calcul effectu laide dun algorithme appropri appel fonction de hachage14. Cette fonction permet de garantir les proprits suivantes : Si lon change ne serait-ce quune virgule dans le document, son empreinte change. La probabilit que deux documents aient la mme empreinte est quasi nulle. dumas-00530235, version 1 - 28 Oct 2010 Il est impossible de reconstituer le document partir de sa seule empreinte. Il est intressant de noter quil y a une diffrence entre intgrit technique et intgrit au sens juridique. La premire, comme vu prcdemment, est mise en cause ds linstant o un seul bit constituant le document est modifi. La seconde consiste conserver le sens de linformation du document sans sattacher ncessairement la forme. Par exemple le fait de changer un accent dans un texte ne va pas changer fondamentalement le sens, alors que cela suffira lui faire perdre son intgrit technique. Nanmoins, mme si le contrle dintgrit ne repose pas uniquement sur lintgrit technique, il en est largement tributaire car il est vident que ce type de contrle peut tre facilement automatis, contrairement un contrle sur le sens dun contenu. A ce sujet, il est possible de distinguer trois types de contrles : contrle ponctuel, contrle rgulier par sondage et contrle continu. Contrle ponctuel : ce contrle est fait uniquement au moment o lobjet est interrog. Le calcul dempreinte est effectu pour comparer le rsultat de lempreinte faite au moment o lobjet est entr dans le systme darchivage. Le principal inconvnient rside dans le risque de se trouver dans une situation paradoxale o le systme darchivage sera juste capable davertir lutilisateur que lobjet rclam a t chang pendant sa conservation, sans pouvoir lui restituer lobjet sans modification.
14
Voir chapitre La signature lectronique pour plus de dtails
Bolognesi Michel
25.08.2010
32/145
Contrle rgulier par sondage : afin dviter la situation dcrite prcdemment, ce type de contrle est opr de faon systmatique, rgulire et automatique sur des objets choisis. Le choix est fait de manire alatoire ou sur la base de catgorie dobjets, par exemple en fonction de leurs criticits. Contrle continu : ce type de contrle est une extension du prcdent, cest-dire que les vrifications sont faites sur lensemble des objets et non pas uniquement sur un chantillon.
4.2.2
Traabilit
La traabilit doit tre prsente tous les niveaux du systme darchivage afin
denregistrer les traces de lensemble des oprations effectues tant par les utilisateurs du dumas-00530235, version 1 - 28 Oct 2010 systme que par ses administrateurs. Elle doit galement garantir lintgrit des objets quant au sens de leur contenu, en conservant la trace et les modalits des diffrentes migrations ventuellement effectues.
4.2.3
Confidentialit
Le systme darchivage doit permettre de vrifier les accs aux objets uniquement par
les personnes autorises en assurant un complment la confidentialit. Cela se traduit par la mise en place dautorisations, comptes utilisateur, mots de passe et parfois de systmes de chiffrement.
4.2.4
Accessibilit
Laccessibilit du document est un lment crucial dans tout systme darchivage car
elle est dterminante pour retrouver linformation. Cette notion revt en fait deux composantes : lorganisation des donnes et les performances techniques. Lorganisation des donnes : est compose dune structure cohrente et efficace permettant de trouver rapidement et facilement les documents. Cette structure repose sur un plan de classement et la constitution dindex. Les performances : sont directement lies au type dinfrastructure physique (serveurs, disques, etc.) et rseau.
4.2.5
Identification, authentification
Afin de respecter la confidentialit, il est ncessaire quun utilisateur voulant se
connecter possde les droits affrents, cest--dire quil est bien habilit accder
Bolognesi Michel
25.08.2010
33/145
linformation. Le principe est en gnral didentifier la personne grce un systme didentifiant (login) assorti dun mot de passe. Malheureusement, rien nindique de faon certaine quil sagit bien de lutilisateur autoris. En effet, mme si lidentifiant et le mot de passe sont corrects, il se peut trs bien que lutilisateur ait drob ces derniers son propritaire. Afin de pallier cet inconvnient, il est possible de faire recours un systme d authentification forte . Un tel systme fait usage de cartes puces ou dauthentifications biomtriques comme les empreintes digitales.
4.2.6
Traitement des virus

Dire que les virus informatiques, pris au sens large, sont en constante volution et quil
faut sen protger serait une vritable lapalissade. Toutefois, il est important de rappeler que dumas-00530235, version 1 - 28 Oct 2010 tout document doit tre conserv sain. Malgr tout, pour pallier toute ventualit quun virus ait tout mme pu chapper aux contrles, il se doit de conserver la dfinition virale.
4.3
La signature lectronique
Certains documents lectroniques concernent les contrats. A ce sujet, il est important
de relever quen droit suisse, la forme des contrats est rgie sur le principe de libert de la forme15. Ds lors, le contrat conclu oralement ou encore par voie lectronique est tout fait valable et protg par la loi, partir du moment o laccord ncessaire sa formation est effectivement donn16. Cependant, dans la perspective dun litige, lenjeu sera de convaincre le juge. De ce fait, lexigence dune certaine forme devient importante pour lever toutes ambigits du contrat oral . En pratique, ces derniers sont sous forme crite et signs la main par celui qui soblige17. Le code des obligations, sous certaines conditions exposes ci-aprs, prvoit que mme la signature lectronique est assimile la signature manuscrite18.
15
La validit des contrats nest subordonne lobservation dune forme particulire quen vertu Le contrat est parfait lorsque les parties ont, rciproquement et de manire concordante, manifest Art. 14 al. 1 CO La signature lectronique qualifie, base sur un certificat qualifi manant dun fournisseur de
dune prescription spciale de la loi (art. 11 CO)

16
leur volont. Cette volont peut tre expresse ou tacite (art. 1 CO)
17 18
service de certification reconnu au sens de la loi du 19 dcembre 2003 sur la signature lectronique est assimile
Bolognesi Michel
25.08.2010
34/145
Sans entrer dans le dtail de la cryptographie, le principe de signature lectronique ncessite la dlivrance dun bi-cl constitu d'une cl publique et d'une cl prive. Cette dernire doit absolument rester secrte et la seule connaissance de son dtenteur. A 1inverse, la cl publique peut tre divulgue, en gnral assortie dautres renseignements, le tout tant contenu dans un certificat lectronique.
4.3.1
Certificat lectronique
Il s'agit d'un document sous forme lectronique attestant du lien entre les donnes de
vrification de signature lectronique telles que les cls publiques et un signataire. Il joue vritablement le rle de pice d'identit lectronique tel quun passeport dans le monde physique . Ce dernier contient par exemple : dumas-00530235, version 1 - 28 Oct 2010 le nom du propritaire, la cl publique, la date dexpiration du certificat, le numro didentification (unique) du certificat, le nom de lautorit de certification qui a dlivr le certificat (ou PSCE), etc. 4.3.1.1 Lautorit de certification
Comme pour un passeport, le certificat lectronique doit tre mis et valid par une autorit comptente et autorise dlivrer ce dernier19. Il existe trois grandes classes de certificats qui se diffrencient au niveau du contrle de linformation contenue dans le certificat : Certificat de classe I : ne garantit pas lidentit du titulaire du certificat mais seulement lexistence du courriel de celui-ci. Certificat de classe II : les informations concernant le titulaire et son entreprise sont contrles par lautorit de certification sur la base de pices justificatives qui sont transmises en gnral par voie postale. On parle de contrle sur pices.
la signature manuscrite. Les dispositions lgales ou conventionnelles contraires sont rserves (art. 14 al. 2bis CO). Pour plus de dtails voir http://www.bakom.admin.ch/themen/internet/00467/index.html?lang=fr .
19
http://www.seco.admin.ch/sas/00229/00251/index.html?lang=fr : Dans ce lien, il y un rpertoire dans
lequel figurent les entreprises suisses qui dlivrent et grent des certificats lectroniques qualifis et qui sont reconnues.
Bolognesi Michel
25.08.2010
35/145
Certificat de classe III : par rapport la classe II, un contrle supplmentaire de lidentit du titulaire est effectu physiquement par un agent de lautorit de certification. On parle de contrle de face face.
4.3.2
Principe de fonctionnement du certificat lectronique.

Le principe de fonctionnement du certificat lectronique se base principalement sur
deux lments : la signature du document et la vrification de la signature. 4.3.2.1 Signature du document. La signature du document commence par lempreinte numrique de ce dernier et le chiffrement de cette empreinte au moyen de la cl priv. Le rsultat de ce chiffrement correspond la signature numrique du document. Ensuite, le document est transmis au(x) dumas-00530235, version 1 - 28 Oct 2010 destinataire(s) accompagn de sa signature et du certificat lectronique correspondant. 4.3.2.2 Vrification de signature La cl publique transmise dans le certificat permet de dchiffrer la signature numrique et donc de retrouver l'empreinte originale du document. Cette dernire est compare une empreinte que l'on prend du document reu. Si les deux sont identiques, le document transmis est authentique et mane bien du possesseur de la cl publique, comme dfini dans le certificat lectronique. En effet, seule la cl publique contenue dans le certificat est capable de dchiffrer la signature obtenue avec la cl prive correspondante du bi-cl, attestant du mme coup de son origine. Reste cependant vrifier la validit dudit certificat auprs de l'autorit comptente.
4.4
Cycle de vie de linformation archive

Le temps de conservation lgal des documents commerciaux, comme vu
prcdemment, est fix dix ans. Implicitement, cette obligation impose un cycle de vie de linformation archiv. Ce cycle est linaire qui suit les phases de vie de linformation 20: capture dans le systme, maintenance pendant la dure requise et destruction ou transfert.
20
Voir annexe : ILM ou gestion du cycle de vie de linformation
Bolognesi Michel
25.08.2010
36/145
4.4.1
Identification et capture dans le systme

Toute information archivable doit tre identifie et capture dans le systme
darchivage selon un processus. Ce dernier peut tre par exemple : 1. Enregistrement dans le systme darchivage avec un identifiant unique. 2. Rattachement au rfrentiel de conservation et au plan de classement. 3. Vrification de la qualit du format et du support avec refus du fichier ou dclenchement dune procdure de conversion. 4. Capture des mtadonnes existantes relatives aux donnes et au contexte de production : date, nom des documents, auteurs, destinataires, etc. 5. Vrification de lunicit des donnes, cest--dire vrification quelles ne sont pas dj t archives. dumas-00530235, version 1 - 28 Oct 2010 6. Ajout, si besoin, de mtadonnes complmentaires. 7. Allocation dune adresse de stockage.
4.4.2
Maintenance
La maintenance, cest--dire la conservation des informations dans le systme
darchivage pendant toute la dure requise, comporte trois volets : la maintenance des formats, la maintenance des mtadonnes et la maintenance des droits daccs. 4.4.2.1 Maintenance des formats La prennisation des donnes suppose une matrise des formats et des supports avec, en cas dobsolescence, des migrations systmatiques. Pour ce faire, des contrles rguliers de la qualit des donnes et de leur lisibilit doivent tre entrepris tout au long de la conservation. En cas de dficience, des actions correctives doivent tre appliques sans omettre de tracer toute modification pour respecter les exigences lgales. 4.4.2.2 Maintenance des mtadonnes Au fil du temps, les mtadonnes relatives aux plans de classement ainsi quau rfrentiel peuvent changer. Il est donc ncessaire de les modifier et de les faire voluer pour garantir la recherche, et par consquence laccs ais, aux utilisateurs. Comme pour la maintenance des formats, les changements des mtadonnes doivent tre tracs.
Bolognesi Michel
25.08.2010
37/145
4.4.2.3
Maintenance des droits daccs Enfin, la maintenance du systme inclut une gestion rigoureuse des habilitations ou
droits daccs, afin que les dparts et changements de poste des collaborateurs soient mis jour dans le systme darchivage. On vite ainsi que des fichiers archivs soient inaccessibles du fait que la ou les personnes autorises ont quitt lentreprise alors que les donnes doivent toujours tre conserves.
4.4.3
Destruction
Les documents et donnes prims doivent tre dtruits chance de leur dure de
conservation. Si ces derniers prsentent un intrt pour la mmoire historique, ils peuvent soit changer de statut tout en restant dans le systme darchivage, soit tre transfrs vers un dumas-00530235, version 1 - 28 Oct 2010 centre darchives historiques. 4.4.3.1 Mise en application Toute action de destruction devrait ncessiter lintervention de trois acteurs : le responsable de larchivage qui tablit la liste des donnes dtruire, le responsable des contenus qui valide la destruction en vrifiant quil ny a pas daffaire en cours ncessitant un prolongement de la conservation, et le responsable du stockage qui effectue la destruction.
4.5
Support physique.
Aujourd'hui, un grand nombre de supports physiques sont disponibles pour
l'archivage. Cependant, il est gnralement admis quil y a deux familles : les supports magntiques (bande et disque magntiques) et les supports optiques (CD, DVD et disques magnto-optique). La grande diffrence des supports optiques par rapport aux ceux magntiques rside dans leur fiabilit, et surtout dans leur prennit. Elle est bien plus leve et n'est pas soumise aux phnomnes physiques naturels dus, par exemple, au caractre magntique de la bande pouvant long terme provoquer un phnomne de collage. Mme si certains constructeurs de disques optiques n'hsitent pas annoncer des dures de garantie trs longues pour leurs supports, il faut modrer une telle information. En effet, au bout de nombreuses annes, il y a de fortes chances que les lecteurs n'existent plus dans ce format et qu'en consquence, on se trouve avec un disque illisible. Par ailleurs, tant pour les CD que pour les DVD, l'information est stocke d'une faon permanente par modification du substrat, l'origine de la notion de WORM (Write Once Read Many). C'est pourquoi, les supports optiques avaient encore
Bolognesi Michel
25.08.2010
38/145
rcemment une large tendance tre privilgis pour rgler les problmes d'archivage. Nanmoins, l'inconvnient majeur vient de son prix de revient, nettement plus lev que celui de la bande magntique. La solution qui aujourdhui semble se rpandre de plus en plus est lie de nouvelles technologies bases sur le disque magntique.
4.5.1
Le WORM
Avant dexpliciter les diffrentes technologies bases sur le disque magntique, il est
important de dvelopper la notion de WORM (Write Once Read Many). Cette dernire, comme mentionn prcdemment, tait originalement attribue essentiellement aux disques optiques. La norme ISO 18509 largit la notion de WORM une mthode denregistrement dont la proprit intrinsque est dtre non effaable, non rinscriptible et non modifiable. Elle distingue trois types de WORM : dumas-00530235, version 1 - 28 Oct 2010 Type A: transformation permanente du support, principe des disques optiques avec modification du substrat ; Type B: utilisation dun microcode WORM inclue dans le support au moment de sa fabrication, reconnu par le lecteur ou le contrleur et protg de leffacement et de la rcriture dans des conditions normales dutilisation, principe des disques magnto-optiques ou des bandes quivalentes ; Type C: gnration dun micro-code enregistr avec linformation et destin traiter cet enregistrement comme un enregistrement de type WORM par le logiciel de gestion du support, le protgeant du mme coup de leffacement et de la rcriture dans des conditions normales dutilisation, principe des disques magntiques. Dans certains cas, la protection de type WORM peut tre limite une dure de conservation associe aux donnes protger. Le type C permet ainsi aux technologies base essentiellement de disques magntiques de pouvoir se positionner naturellement pour rsoudre des problmatiques d'archivage. 4.5.1.1 Le disque dur magntique. Pourquoi cet acharnement de la part des constructeurs utiliser le disque dur magntique ? Il y a au moins quatre raisons : la rapidit d'accs et de transfert des donnes, la fiabilit du support, la migration technologique et la possibilit de supprimer un fichier.
Bolognesi Michel
25.08.2010
39/145
Rapidit d'accs et de transfert des donnes : les supports optiques sont en effet gnralement peu performants. Toutefois, concernant l'archivage, c'est--dire des documents qui ne seront probablement consults que de manire exceptionnelle, le critre de rapidit n'est pas forcment prdominant. Fiabilit du support : la dure de vie des supports optiques tant relativement courte (5 20 ans), il faut prvoir un cycle de duplication rgulire, permettant d'assurer la prennit voulue. Les disques magntiques intgrs des baies de type RAID21, peuvent tre remplacs chaud, les donnes se trouvant dupliques et automatiquement rgnres. Migration technologique : les normes et technologies inhrentes aux disques, lecteurs, armoires... voluent rapidement. En cas de migration, il est plus dumas-00530235, version 1 - 28 Oct 2010 simple de vider le contenu d'une armoire ancienne dans une nouvelle, plutt que relire tous les supports optiques ou toutes les bandes magntiques. Possibilit de supprimer un fichier : cela peut paratre paradoxal de vouloir supprimer une archive, mais la loi impose dsormais que les donnes ne soient pas conserves au-del d'une dure normale d'utilisation. Or, sur un support optique, les possibilits de suppression sont pour le moins limites.
4.5.2
Le Worm Logique
Il existe en fait trois approches diffrentes destines assurer cette conservation
scurise : le worm logiciel, les CAS et le stockage en grille. 4.5.2.1 Worm logiciel La premire de ces approches, sans doute la plus simple , consiste utiliser des baies de stockage traditionnelles sur disque et y ajouter une couche logiciel en amont destine grer cette notion de WORM logique et ainsi bloquer toute tentative de rcriture, de modification ou de suppression. En rsum, le principe repose sur une horloge logicielle indpendante de la baie qui crit sa mesure systmatiquement sur les disques WORM toutes les 10 secondes. Toutes les fonctions lies la manipulation des fichiers worm sont valides par l'horloge. Si jamais l'on
21
RAID (Redundant Array of Independent Disks) : est une technologie permettant de stocker des
donnes sur de multiples disques durs afin d'amliorer, en fonction du type de RAID choisi, la tolrance aux pannes et/ou les performances de l'ensemble. (voir http://fr.wikipedia.org/wiki/RAID_(informatique) )
Bolognesi Michel
25.08.2010
40/145
remplace le contrleur par un contrleur dune nouvelle armoire avec une nouvelle horloge et avec une autre mesure de temps, le logiciel s'en aperoit et se recale. Les disques sont de type RAID. Lors des manipulations, le contrleur effectue un calcul de contrle et, en cas derreur, le segment est rcrit. Avec le RAID, les donnes sont cryptes et rparties, ce qui rend impossible la lecture ou la modification directe. L'avantage de ce dispositif rside dans sa simplicit : n'importe quel volume peut devenir un WORM, l'application n'a pas besoin d'une API22 pour accder aux archives, il suffit d'y accder comme un NAS23. 4.5.2.2 dumas-00530235, version 1 - 28 Oct 2010 Le CAS (Content Addressed Storage) Une autre approche, est l'adressage de fichiers fixes appel CAS (Content Addressed Storage). Ce dernier cre une empreinte numrique pour chaque objet entrant. Cette empreinte devient ensuite le seul moyen pour consulter lobjet ainsi stock Il sagit en fait dune logique apparente celle des consignes. En effet, vous dposez un objet et en retour vous obtenez un ticket (adresse de contenu). Ultrieurement, seul ce ticket vous permettra de retrouver lobjet dpos. La faon dont est conserv ce dernier est totalement prise en charge par le systme. Par exemple, habituellement, pour stocker le fichier "resultats.xls", le systme va inscrire les donnes sur le disque et enregistrer sur une table d'allocation, le nom du fichier, l'adresse physique correspondante (ou les adresses si le fichier est rparti sur plusieurs segments), ainsi que quelques donnes supplmentaires comme la taille ou la date d'criture. Ce systme comporte deux inconvnients dans une utilisation d'archivage : Il peut arriver quun fichier strictement identique puisse tre enregistr plusieurs fois ou dans un autre rpertoire. Il est impossible de distinguer deux exemplaires dun fichier avec le mme nom, la mme taille, mais avec un chiffre modifi, par exemple.
22
API (Interface pour la programmation d'applications) : Ensemble de bibliothques permettant une
programmation plus aise car les fonctions deviennent indpendantes du matriel. (voir http://www.futurasciences.com/fr/definition/t/informatique-3/d/api_465/ )
23
NAS (Network Attached Storage) : est une unit autonome, relie un rseau dont la principale
fonction est le stockage de donnes en un gros volume centralis pour des clients-rseau htrognes. (voir http://fr.wikipedia.org/wiki/Stockage_en_r%C3%A9seau_NAS )
Bolognesi Michel
25.08.2010
41/145
Dans le cas de l'archivage, il est important de ne pas multiplier les versions identiques d'un mme fichier. Au contraire, il est intressant de distinguer une version mise jour. Pour pallier ce problme, toute modification du contenu dclenche automatiquement la cration dune nouvelle adresse de contenu. A linverse, si un mme objet se prsente, ladresse de contenu tant dj existante, il ny aura pas de doublement en matire de stockage. Les accs aux ressources sont rapides. La gestion et ladministration dune telle solution sont considrablement simplifies, mme pour de gros volumes. Par ailleurs, le systme est en mesure de garantir lintgrit du contenu long terme et la confidentialit des informations peut tre obtenue par un chiffrement systmatique des donnes ainsi conserves. 4.5.2.3 dumas-00530235, version 1 - 28 Oct 2010 Le stockage en grille La troisime approche rpond une logique dorganisation en cellules, faisant appel au concept de stockage en grilles ou grid . De telles solutions intgres darchivage sont plutt indpendantes des applications, mais elles utilisent nanmoins une mthode daccs aux enregistrements normalise. Cette approche est constitue de plusieurs cellules interconnectes via un rseau Ethernet24. Chacune dentre elle participe la solution et une demande darchivage est ainsi rpartie sur lensemble des cellules. Une cellule possde un processeur, un espace de stockage pour lindexation des contenus et les mta donnes ainsi quun espace de stockage pour les donnes des contenus. Lun des principaux avantages de cette approche est de permettre la ralisation facile de systmes de stockage complexes partir dlments standards. Une telle technologie permet en effet la ralisation de solutions trs performantes, indpendantes du nombre denregistrements grs, vitant du mme coup tous les phnomnes lis aux baisses de performances que lon peut observer au cours des montes en charge. Un autre avantage et non des moindres rside dans sa capacit effectuer des migrations trs progressives, cellule par cellule. Enfin, lexploitation de tels systmes est simplifie et surtout allge lextrme. Ainsi, mme si en apparence le cot dacquisition peut sembler plus onreux quun systme traditionnel, une comparaison plus complte tenant compte des cots dexploitation sur trois ans ne laisse plus aucun doute. Lintrt est encore plus vident si lon prend en considration la notion de migration, voque prcdemment.
24
Ethernet est un protocole de rseau local commutation de paquets.
Bolognesi Michel
25.08.2010
42/145
4.5.2.4
Principaux acteurs du march Ce sous-chapitre vise donner quelques exemples de grands acteurs du march
utilisant les approches dcrites prcdemment : IBM : Ce constructeur bien connu, disposant toujours de juke-boxes de disques optiques son catalogue pour l'environnement iServer (AS/400), propose galement depuis quelques annes une solution d'archivage WORM base de disques magntiques, le Totalstorage DR (pour Data Retention). Ce systme repose sur le module SSAM (System Storage Archive Manager), une extension du logiciel TSM (Tivoli Storage Manager), connu pour la gestion du stockage. Outre la garantie de protection WORM des donnes sur disque et leur cryptage, le Totalstorage DR offre des fonctions sophistiques et auditables de dumas-00530235, version 1 - 28 Oct 2010 conservation des informations rpondant aux exigences multiples et volutives des lgislations et des outils de gestion de contenu. Pour les conservations de longue dure, et dans le but d'assurer un vritable ILM (Information Lifecycle Management)25, le Totalstorage DR prend son compte les volutions technologiques et assure, au moment opportun, la migration des donnes vers une unit de conservation WORM plus rcente. Network Appliance : De son ct, NetApp dvelopp un solution sogiciel dfend nomme SnapLock permettant de faire du Worm logique. EMC : propose au travers des systmes Centera une solution avec une technologie base sur lapproche du CAS (Content Aeeess System) vue prcdemment. Hitachi: En tant que fournisseur de baies de stockage, Hitachi a dvelopp un gestionnaire d'archivage avec son logiciel Data Retention Utility. Ce logiciel utilitaire offre ainsi la fonction Worm sur les systmes de stockage sur disque Hitachi dans les environnements de type systmes ouverts ou de type mainframe. Hitachi offre galement une vritable solution ddie l'archivage: Archive Content Platform. Cette solution est bas sur lapproche de stockage grille. Hewlett Packard (HP) : HP propose une solution intgre d'archivage RISS (Reference Information Storage System) indpendante des applications avec
25
Voir annexe ILM ou la gestion du cycle de vie de linformation (voir VI1).
Bolognesi Michel
25.08.2010
43/145
une mthode d'accs aux informations normalises. Cette solution utilise une approche du stockage en grille. SUN/Storagetek: Fournisseur de solutions d'archivage, ce constructeur a une approche de la gestion du stockage sous la forme de classes de service indpendante des technologies utilises. Cette approche permet la mise en uvre dune vritable politique ILM (Information Lifecycle Management) intgre au processus mtier et garantit une gestion trs efficace des fonctions d'intgrit et de traabilit indispensables dans des contextes d'archivage valeur probante.
4.6
Systme darchivage lectronique (SAE)

En conclusion de ce chapitre consacr aux concepts de larchivage lectronique, je
vais brivement exposer le modle de rfrence OAIS26 (Open Archival Information System) concernant le systme darchivage lectronique (nomm par la suite SAE), puis terminer par larchitecture technique du SAE.
4.6.1
Fonctionnalit du modle OAIS

Sans entrer dans les dtails du modle OAIS, il est intressant de relever quil sagit
dun modle abstrait. Il dfinit une terminologie et des concepts. Il identifie les acteurs, dcrit les fonctions et les flux dinformations, et propose un modle dinformation adapt la problmatique de larchivage numrique sur le long terme27. Cependant ce modle nest pas un recueil de spcifications techniques destines tre directement implmentes. Parmi tous les concepts exprims par OAIS, il y a cinq fonctions relevantes (voir la Figure 4): la fonction de versement, la fonction de stockage, la fonction de gestion des
26
OAIS (Open Archival Information System) : est le rsultat dun travail du CCSDS (Consultative
Committee for Space Data Systems), organisme international de normalisation des agences spatiales, ralis la demande dISO. Ce travail, auquel ont t associs des reprsentants de bibliothques et darchives institutionnelles, a abouti en 2002 la rdaction dun document qui spcifie de manire trs gnrale larchitecture logique et les fonctionnalits dun systme darchivage. OAIS ne prjuge pas de la nature des objets archiver, mais le modle est particulirement bien adapt aux objets numriques. Le modle de rfrence OAIS est aujourdhui une norme internationale ISO (ISO 14721).
27
Le long terme est dfini comme suffisamment long pour tre soumis limpact des volutions
technologique, cest--dire, en ce qui concerne le document numrique, entre 3 10 ans (mme si cela est trs tributaire du format).
Bolognesi Michel
25.08.2010
44/145
donnes descriptive, la fonction de consultation et de communication et la fonction dadministration.
Figure 4 : fonctions du systme darchivage lectronique
4.6.1.1
Fonction versement: La fonction de versement permet le traitement des paquets d'informations en
provenance des services versants dans leur ensemble. Cette fonction inclut ainsi tous les mcanismes de prparation, transmission, contrle, rejet, complment d'information ainsi que tous les traitements de ces informations pour une intgration dans le dispositif de stockage des contenus et celui de gestion des donnes descriptives. 4.6.1.2 Fonction stockage La fonction stockage gre l'ensemble des services lis la conservation des paquets d'informations archivs partir du moment o ils sont mis sa disposition par la fonction de versement jusqu' leur destruction/limination s'il y a lieu, tout en garantissant leur intgrit. Cette fonction prend entre autres en compte les aspects de choix de supports et de gestion de l'ensemble des migrations. 4.6.1.3 Fonction gestion des donnes descriptives La fonction gestion des donnes descriptives assure la conservation, la mise disposition et la mise jour des informations descriptives associes aux contenus d'informations, conservs par la fonction stockage. Ces informations doivent servir aux utilisateurs comme point d'entre au SAE et permettre de retrouver les donnes qu'ils recherchent en assurant le lien avec leur identification de localisation dans le systme de stockage.
Bolognesi Michel
25.08.2010
45/145
4.6.1.4
Fonction de consultation et de communication La fonction de consultation et de communication prvoit l'ensemble des mcanismes
permettant d'accder, de consulter et de livrer les informations disponibles dans le SAE, qu'il s'agisse des donnes descriptives ou du contenu lui-mme. Elle comprend la mise disposition d'une interface de consultation, d'un systme de recherche effectue partir des donnes descriptives, dun principe de visualisation du rsultat, la slection de contenus communiquer et la livraison effective de ces contenus sous forme de paquets d'informations diffuss. 4.6.1.5 Fonction d'administration La fonction d'administration permet d'assurer l'exploitation de l'ensemble du systme dumas-00530235, version 1 - 28 Oct 2010 d'archivage lectronique et sa prennisation, ainsi que la gestion des utilisateurs du SAE au sens de leurs droits d'accs. En fonction de ses propres besoins, l'administration pourra galement laborer diffrentes statistiques sur les fonctions de versement, la consultation, ou encore sur celles directement lies l'exploitation. Ces statistiques permettront par exemple d'anticiper toute augmentation des capacits de stockage ou de planifier les migrations de supports et de format.
4.6.2
Architecture technique du SAE

Larchitecture technique reprsente par la Figure 5 doit tre considr comme un
exemple de cas dcole .
Figure 5 : Exemple darchitecture technique du SAE
Bolognesi Michel
25.08.2010
46/145
Cette architecture se compose de trois sites idalement loigns gographiquement, pour des raisons de scurit. En fait, grce cette distance, les paquets dinformations sont stocks au moins trois fois.
4.6.3
Site 1
Le premier site prsente le dtail des diffrents composants ncessaires la bonne
marche du SAE dun point de vue essentiellement fonctionnel. Dans le prsent cas dcole , chaque composante est spare par un serveur physique diffrent. Lintrt davoir plusieurs serveurs est double : Premirement, lensemble sera plus performant car dune part chaque serveur possde son propre processeur et, dautre part, tous les serveurs peuvent tre dimensionns et optimiss en fonction du service quils doivent fournir. dumas-00530235, version 1 - 28 Oct 2010 Deuximement, en cas de dysfonctionnement, seuls les services du serveur concern seront hors service. Cependant, dans la pratique, il est tout fait envisageable de regrouper compltement ou partiellement lensemble de ces derniers. 4.6.3.1 Gestion du stockage La gestion du stockage a deux fonctionnalits distinctes: le serveur de stockage et lunit de stockage. Le serveur de stockage : gre les donnes de gestion et il doit voluer et tre mis jour au cours du temps, en fonction des diffrentes modifications qui peuvent intervenir sur les donnes correspondantes. Lunit de stockage : conserve le contenu de linformation archive. De ce point de vue, cette fonctionnalit est plus statique et lvolution se rsume un changement ventuel du support, voire du format au cours du temps. 4.6.3.2 Serveur frontal ou serveur Web Le serveur frontal est une interface des communications entre les applications ainsi quun point dentre uniformis pour les services du SAE. Par exemple, dans les architectures web, on peut utiliser un serveur frontal HTTP (comme Apache) pour traiter les requtes gnrales et renvoyer certaines demandes de service vers un serveur d'application (comme Tomcat).
Bolognesi Michel
25.08.2010
47/145
4.6.3.3
Serveur applicatif Le serveur applicatif est ddi fournir tous les services applicatifs comme le
classement, les fonctions de recherche, etc. du SAE. 4.6.3.4 Serveur de secours Le serveur de secours ne constitue pas une obligation, mais simplement un moyen de gagner en efficacit dans le cas d'un dysfonctionnement de l'un des serveurs. En effet, si l'on dispose d'un serveur prparamtr, le temps d'indisponibilit des services sera videmment moins important.
4.6.4
Site 2
Le deuxime site permet dune part de rpartir la charge, et, d'autre part, de faire
fonction de site de secours. Contrairement au premier site, toutes les fonctions de stockage peuvent tre regroupes dans un mme ensemble, ce qui reprsente un mode de fonctionnement minimaliste dans la mesure o il suppose que l'on travaille sur un seul et mme type de support.
4.6.5
Site 3
Le troisime site garantit une troisime copie des donnes. Il est mis jour de manire
asynchrone de manire pouvoir corriger des paquets de donne en erreur lors dun dysfonctionnement des deux autres sites.
Bolognesi Michel
25.08.2010
48/145
III Principe de larchivage SAP

Cette partie vise exposer les outils fournis par SAP pour la ralisation du projet darchivage des donnes SAP. Dans un premier temps, elle va donner une dfinition, expliciter les motivations et le principe dun tel archivage. Elle sera ensuite suivie par la prsentation de lobjet darchivage, le processus associ et lArchiveLink. Pour terminer, un comparatif entre les directives du code des obligations en terme de conservation et les outils seront prsents.
1
Dfinition
Larchivage consiste dplacer des donnes dun systme SAP vers un serveur de
fichiers ou systme de gestion de contenu, et en assurer la relecture totale ou partielle avec SAP (voir Figure 6 : dfinition).
Figure 6 : dfinition
Motivations
Temps de rponses du systme : au fil du temps, la taille de la base de donnes augmente et, en particulier, toutes les tables reprsentant le coeur de lactivit de lentreprise. Cela implique une perte progressive et souvent exponentielle des temps de traitement et de rponse du systme, causant du dsagrment aux utilisateurs.
Les motivations qui justifient un archivage des donnes sont multiples :
Bolognesi Michel
25.08.2010
51/145
Technique : l'archivage permet de rduire le temps de sauvegarde, de restauration et de la dure des traitements, ainsi que la difficult voire impossibilit rorganiser une base de donnes dune taille importante.
Economique : cela diminue les cots de stockage car les donnes archives peuvent tre stockes sur un support moins onreux.
Principe
Le principe de larchivage se base sur trois tapes principales : extraction, criture et
suppression. Le but de lextraction est de lire les tables qui modlisent un objet dans la base de donnes normalise28, pour reconstituer ce dernier. Par exemple, la facture dumas-00530235, version 1 - 28 Oct 2010 (voir Figure 7) est modlise par les tables telles que VBAK et VBAP. Les donnes extraites lors de ltape prcdente sont crites dans des fichiers archives. Ils sont ensuite entreposs dans un systme de fichiers ou un gestionnaire de contenu. Enfin, les donnes extraites sont supprimes des tables.
Figure 7 : Principe darchivage
La consultation des fichiers archives se fait gnralement par les mmes crans de transaction que pour les donnes dans la base. Le but est de faciliter et de rendre la consultation la plus aise possible. Par contre, le temps daffichage des fichiers archives est
28
La normalisation vise liminer les inconvnients dus la prsence de redondances dans les schmas
relationnels de donnes.
Bolognesi Michel
25.08.2010
52/145
gnralement plus long, aucune donne nest modifiable et certains champs peuvent tre non renseigns29.
Objet darchivage
Le chef dorchestre darchivage des donnes est lobjet darchivage30. Ce dernier est
une sorte de couteau suisse fournissant tous les outils ncessaires pour la cration de fichiers archive, de tout ou d'une partie dun document, de faon cohrente et dans un tat stable. Par exemple (voir Figure 8) une facture de dcompte (objet mtier) est compose d'une en-tte et des postes. Ces deux parties sont modlises par plusieurs tables sur lesquelles les objets darchivage ISU_PRDOCH et ISU_PRDOCL se basent31.
29
Les causes de non affichage sont en gnral dues une diffrence de version, cest--dire que si un
nouveau champ est ajout aprs que larchivage ait t fait, il ne pourra en aucun cas tre complt dans les archives.
30
Attention : lobjet darchive na pas les mmes caractristiques quun objet en programmation OO Note : la reprsentation de la facture par deux objets archives vite la redondance dans les fichiers et
(Orient Objet), il ne simplmente pas, ne se drive pas, etc.

31
permet donc une certaine forme de normalisation. En plus, vu que la lecture des fichiers archives est assez lente, il pourrait tre envisageable darchiver uniquement les postes (en gnral cest le plus volumineux) tout en gardant les en-ttes dans la base de donnes, ce qui amliorerait les temps de consultation.
Bolognesi Michel
25.08.2010
53/145
Objet mtier
Tables de base de donnes.

Table : ERDK Donnes den-tte Table : EITERDK Index document dimpression Table : ERDTS Frais et taxes Etc
Objet archivage
FACTURE DE DECOMPTE. En-tte de dcompte de facture
Objet : ISU_PRDOCH En-tte de dcompte de facture Programmes : lecture, suppression, criture. Paramtres : temps de rsidence.
Ligne de dcompte facture.
Table : DBERDL Lignes document impr. Table : DBERDLB Rf. Ligne calcul facture Table : DBERDZ Ligne individuelle doc. Impr. Figure 8 : Exemple facture de dcompte
Objet : ISU_PRDOCL Ligne document imprim Programmes : lecture, suppression, criture. Paramtres : temps de rsidence.
La suite de ce chapitre vise dcrire toutes le lames des ce couteau permettant de mener bien larchivage des donnes.
4.1
Programmes associs au processus archive

Le processus darchivage est une suite dtapes matrialises par des programmes et
des paramtres associs (voir Figure 9).
Bolognesi Michel
25.08.2010
54/145
Figure 9 : Copie dcran dun objet darchivage (transaction AOBJ)
Programme dcriture lit les tables et cre des fichiers darchive. Programme de suppression permet de supprimer les donnes de la base de donnes, mais, dans certains cas, seul un tmoin de suppression32 est plac dans les donnes. Programme de rechargement comme son nom lindique, il permet de recharger les donnes partir dun fichier darchive dans la base de donnes. Cependant, lutilisation est rserve quasiment uniquement dans le cas o des donnes ont t archives par mgarde. Prprocesseur : certains objets exigent un programme de prtraitement qui prpare les donnes pour larchivage. Ce programme marque les donnes archiver, mais il ne supprime aucune information de la base de donnes. Postprocesseur est effectu aprs que le programme de suppression ait eu lieu. En gnral, il est utilis pour supprimer de la base de donnes les donnes marques dun tmoin par le programme de suppression.
32
Le tmoin de suppression est un statut indiquant que lobjet nest plus fonctionnellement utilis mais
rsident dans la base de donnes. C'est le cas des articles qui ne sont plus fabriqus par le fournisseur, et sont donc supprims, mais qui ont dj t facturs. LERP dans ce cas empche la suppression physique pour garantir la cohrence de ces pices.
Bolognesi Michel
25.08.2010
55/145
Programme de cration dindex permet denregistrer des index dans des tables de la base de donnes SAP pour indexer les fichiers archives. Par cet astuce, laccs aux archive est plus rapide et ais. Programme de suppression des index permet de supprimer les index crs par le programme de cration dindex. 4.1.1.1 Paramtres associs aux programmes Il y a un certain nombre de paramtres lis aux programmes prcdents : Lancer les jobs de suppression la fin de la phase d'criture : cela impose que tous les jobs de suppression ne soient lancs qu'aprs la gnration de tous les fichiers du processus d'archivage. dumas-00530235, version 1 - 28 Oct 2010 Cration de fichiers lors du rechargement : lors du rechargement de fichiers archives, de nouveaux fichiers archives sont crs si les objets de donnes ne sont pas tous rechargs dans la base de donnes. Tmoin d'archivage inter-mandants indique que les donnes archiver doivent tre archives pour tous les mandants.33 Objet d'archivage XML : quelques rares programmes darchivages utilisent un connecteur au format XML au lieu de celui standard SAP (l'Archive Development Kit : ADK).
4.2
Structure dun objet darchivage

Un objet darchivage, comme dj mentionn, doit garantir la cohrence des donnes
archives. Dans ce dessein, il possde une structure issue de la dfinition des tables utilises par lobjet mtier reprsent par la Figure 10. Dfinition table 1 Dfinition table 2 Dfinition table 3 Etc.
Figure 10 : structure objet archivage
Les programmes darchivage utilisent cette structure pour crire et lire les fichiers archives.
33
Le mandant est une unit indpendante d'un point de vue commercial, organisationnel et technique
dans un systme SAP. Les mandants possdent leurs propres fiches, ensembles de tables, droits daccs et un certain nombre de paramtrage spcifique.
Bolognesi Michel
25.08.2010
56/145
4.2.1
Classes darchivage
Pour rendre plus facile la dfinition de la structure, il est possible de lui associer des
classes darchivage. Ces dernires sont une dfinition de structure qui peut tre rutilise par plusieurs objets darchivage.
4.3
Tuples de tables non archivs

Certains objets darchivage peuvent supprimer des donnes dune liste de table dfinie
sans archiver pour autant ces donnes (voir Figure 11).
Figure 11 : Liste des tables supprimes uniquement
Ces tables contiennent gnralement des donnes qui peuvent tre reconstruites tout moment laide des donnes du systme comme par exemple des tables dindex. En clair, ce sont gnralement des donnes qui ne doivent pas ncessairement tre conserves.
4.4
Dpendance entre objets archive

Dans certains cas, un objet darchivage ne peut pas lui seul garantir la consistance de
la base de donnes mentionne prcdemment. SAP a prvu une dpendance entre objets, cest--dire des contrles garantissant une cohrence. Par exemple pour archiver un document de vente (voir Figure 12) il faut qu au pralable les documents dachats, les factures, les demandes dachats, etc. soient archivs.
Bolognesi Michel
25.08.2010
57/145
Figure 12 : exemple de dpendance entre objets
4.5
Programme de lectures des fichiers archives

A chaque objet darchivage, il est possible de lui associer plusieurs programmes (voir
Figure 13) conus pour la lecture de fichiers archives. Ces programmes sont utiliss par les
transactions de visualisation des donnes ou pour des fins statistiques.
Figure 13 : liste des programmes pour la lecture des fichiers archives
4.6
Temps de rsidence dans la base de donnes

Chaque objet archivage a des besoins de rsidence dans la base de donnes diffrents
en fonction des contraintes mtiers. Pour ce faire, il est possible de lui associer un ou plusieurs codes transactions (voir Figure 14 ) qui permettent de dfinir ce temps de rsidence par plusieurs critres.
Bolognesi Michel
25.08.2010
58/145
Figure 14 : liste des transactions permettant de dfinir le temps de rsidence
Par exemple, pour une pice comptable, il est possible de dfinir le temps de rsidence en fonction de la socit et du type de pice (voir Figure 15). dumas-00530235, version 1 - 28 Oct 2010
Figure 15 : exemple de dfinition temps de rsidence
4.7
Tables information
La lecture des fichiers archives est faite de manire squentielle, bloc par bloc. Pour
optimiser la lecture de ces derniers, il est possible dassocier lobjet darchivage des tables dindex et dinformations (voir Figure 16).
Figure 16 : Liste des tables index
Bolognesi Michel
25.08.2010
59/145
4.8
Fonctions spcifiques (user-exit)

La plupart des programmes des objets darchivage sont dj fournis par SAP, mais
lentreprise a parfois des particularits non prvues par lditeur. Les fonctions spcifiques ou user-exit , pour utiliser le jargon SAP, sont appeles pendant lexcution du programme standard pour modifier le comportement sans que le code de lditeur ne soit modifi.
4.9
Remarques
A la fin de ce chapitre consacr lobjet darchivage, il est important de faire
remarquer que tous ces points de paramtrage sont interdpendants. Autrement dit, chaque lment doit interagir ave les autres afin de pouvoir obtenir les rsultats escompts. Par exemple si une table dinformation est cre et associe lobjet darchivage sans dumas-00530235, version 1 - 28 Oct 2010 que le programme de cration et suppression dindex ainsi que de lecture des archives soit cr ou conu pour pendre en compte cette dernire, il ny aura pas leffet escompt.
Processus
Le processus darchivage est une suite dactions squentielles matrialises par des
programmes exposs prcdemment. La gestion de ce dernier, ainsi que dautres fonctionnalits associes larchivage, sont orchestres par la transaction SARA (voir Figure
17).
Figure 17 : Copie dcran de la transaction SARA
Bolognesi Michel
25.08.2010
60/145
La transaction SARA affiche uniquement les actions paramtres (voir chapitre 4.1) et elles doivent tre excutes dans lordre du haut vers le bas (numrotes de 1 3 dans la figure 21). Certaines actions (notes par la lettre de A C dans la figure 21) sont optionnelles ou informatives. En rsum, des paramtres influencent le processus et ce dernier peut tre subdivis en deux parties : processus principal et optionnel.
5.1
Paramtrage processus darchivage (Customizing)

Par la transaction SARA, il est possible daccder aux points de paramtrage qui
permettent dinfluencer le processus darchivage (voir Figure 18 ).
Figure 18 : paramtres processus archivage
La suite de ce sous-chapitre vise donner une brve description de ces principaux paramtres.
5.1.1
Paramtrage valable pour tous objets darchivage

Il y a deux ensembles de paramtrage (customizing) concernant lensemble des objets :
options techniques et contrle et suppression. 5.1.1.1 Options techniques Les principales options techniques (voir Figure 19) indpendantes dun objet darchivage sont :
Bolognesi Michel
25.08.2010
61/145
Figure 19 : Options techniques pour tous les objets archivage
Contrle daccs pour slection darchivage : il permet de dfinir le contrle daccs soit dlgu au systme darchivage soit par un contrle sur le fichier lui-mme ou les deux. Interruption implicite de la phase dcriture : si une valeur diffrente de 0 est saisie le processus dcriture est interrompu aprs le temps saisi. Groupe de serveurs pour traitement en arrire-plan : pour une instance de SAP il est possible de lui associer plusieurs serveurs. Un choisissant un serveur (ou groupe) lensemble du processus sera excut sur ce dernier. Ce paramtre est particulirement utile dans le cas o un serveur est ddi larchivage sinon il vaut mieux laisser grer le choix par le systme. 5.1.1.2 Contrle et suppression Certains objets darchivage peuvent partager un ensemble de paramtres. Il est fort probable que cette fonctionnalit sera dveloppe davantage par SAP car, lheure actuelle, seul un objet peut utiliser ce point de paramtrage.
5.1.2
Paramtrage spcifique lobjet archivage

Il y a deux ensembles de paramtres spcifiques chaque objet darchivage : options
techniques et routage des archives.
Bolognesi Michel
25.08.2010
62/145
5.1.2.1
Options techniques Voici un descriptif des diffrentes options techniques :
Figure 20 : Options techniques spcifiques objets archivage
Nom fichier logique : le nom du fichier logique est une dfinition qui permet au systme de dfinir le nom du fichier archive (pour plus dinformations, se rfrer lAnnexe 2). Taille dun fichier archive : elle permet de dfinir la taille maximum dun fichier archivage, soit en limitant le kilo octet, soit en limitant le nombre maximal dobjets. Options pour programme de suppression : chaque objet darchivage a son propre programme de suppression avec des paramtres spcifiques. Cependant, tous les objets ont au moins un paramtre test et un paramtre productif.
Bolognesi Michel
25.08.2010
63/145
o Variante34 mode test : la variante de test est utilise par le processus pour lancer le programme de suppression en mode test, cest--dire que le programme simula la suppression. o Variante mode productif : la variante productive est utilise par le processus lors de la suppression des donnes. Jobs de suppression : pendant le processus darchivage, il est possible dinfluencer le lancement du programme de suppression, soit manuellement (aucune planification), soit automatiquement (aprs le programme dcriture), soit aprs un vnement.35 Archivage sous forme dans le systme archivage : les fichiers archives peuvent tres stocks dans un systme darchivage (voir III6 Archivelink) au dumas-00530235, version 1 - 28 Oct 2010 lieu dtre placs dans un rpertoire (voir Annexe 2). Si le code de lancement automatique est choisi, les fichiers archives seront transfrs dans un systme d'archivage aprs leur traitement. En plus de ce choix, on pourra opter pour trois comportements diffrents : o Suppression avant archivage : le programme de suppression est excut avant que le fichier archive soit stock dans le systme d'archivage. N.B. : cette option permet de gagner en performance, mais elle comporte des risques en cas de problmes. o Archivage avant suppression : contrairement au prcdent paramtre, les fichiers archives sont en premier entreposs dans le systme darchives et ensuite seulement les donnes sont supprimes de la base de donnes. NB : Cette option apporte un bon compromis de scurit/performance. o Programme de suppression lit depuis le systme d'archivage : cette option indique que la donne est supprime aprs la lecture de cette dernire dans le fichier archive.
34
Une variante est le moyen mis disposition par SAP pour mmoriser les valeurs des paramtres de
lcran de slection. Grce aux variantes, les utilisateurs peuvent lancer les programmes sans devoir ressaisir toujours les mmes paramtres.
35
SAP encapsule un moteur de Workflow, il est donc possible de crer ou dutiliser des dclencheurs
tels que la fin dun programme, une action de lutilisateur, etc. pour lancer le programme de suppression.
Bolognesi Michel
25.08.2010
64/145
NB : cette option est de loin la plus scurisante, mais elle ncessite un traitement bien plus long. 5.1.2.2 Routage des archives En raison des problmes de conformit lgale, les entreprises, en particulier les multinationales, sont de plus en plus contraintes de stocker les donnes archives sparment afin de rpondre aux exigences de conservation des diffrents pays. Par cette fonction, il est donc possible de crer des rgles et des conditions (voir Figure 21) permettant de router les fichiers archives vers des systmes darchivages et/ou des noms de fichiers logiques diffrents. Grce ce routage, ces entreprises peuvent jouir dune plus grande souplesse. dumas-00530235, version 1 - 28 Oct 2010
Figure 21 Options de routage
5.2
Processus principal
Le processus principal est compos de trois tapes obligatoires et de deux tapes
facultatives (dans le sens quelles ne doivent pas tre systmatiquement prsentes dans tous les objets). Les tapes obligatoires sont : criture, stockage et suppression. Les tapes facultatives sont : prtraitement et post traitement.
5.2.1
Prtraitement (ou prprocesseur)

Certains objets darchivage requirent un prtraitement pour vrifier et prparer les
donnes avant ltape de lcriture. Lutilisateur choisit un certain nombre de filtres par rapport aux critres sa disposition. Un certain nombre de contrles sont effectus pour garantir la cohrence des donnes filtres. Enfin, les donnes juges cohrentes selon les filtres sont marques avec le statut archiver .
Bolognesi Michel
25.08.2010
65/145
Il faut noter que normalement cette tape est englobe dans ltape criture , mais pour des raisons de performances, elle a t scinde en deux.
5.2.2
Ecriture et stockage
Le programme dcriture est, gnralement, le point de dpart de larchivage. Le but
principal de ce dernier est de crer des fichiers darchive selon la structure de lobjet et les stock. Le programme sarticule autour trois parties : filtre, contrle et criture. dumas-00530235, version 1 - 28 Oct 2010 Filtre : par une interface graphique, lutilisateur peut choisir un certain nombre de paramtres et de filtres. Contrle : les donnes sont slectionnes selon les filtres et contrles pour garantir la cohrence. Dans le cas dobjets avec prtraitement, cette partie se limite slectionner uniquement les donnes avec statut archiver . Ecriture : toutes les donnes cohrentes sont crites dans un fichier darchive36 stock.
5.2.3
Suppression
Cette tape, comme son nom lindique, supprime physiquement de la base de donnes
les tuples qui ont t enregistrs dans un fichier. Cependant, pour certains objets, la suppression physique est remplace par un tmoin de suppression. Il existe diffrentes sortes de suppressions avec des caractristiques diffrentes : Uniquement suppression : les donnes sont supprimes sans aucun contrle. Cette option est assez risque, mais plus rapide et adapte pour des objets de type techniques ou des objets avec post traitement. Vrification avant suppression : cette option fait un contrle de lecture du fichier archive et supprime ensuite les donnes, la condition que le test soit probant. Vrification aprs suppression : le contrle de lecture du fichier archive est fait uniquement aprs la suppression.
36
Le fichier archive est un fichier compress environ 3 fois avec une structure propritaire. Ce dernier
est lisible uniquement par SAP. Pour faciliter la manipulation et gagner en rapidit de lecture, un paramtre permet de dfinir une taille maximale. Cela implique que pendant ltape dcriture plusieurs fichiers peuvent tre crs.
Bolognesi Michel
25.08.2010
66/145
5.2.4
Post traitement (ou postprocesseur)

Comme pour le prtraitement, cette tape a t cre pour scinder en deux la
suppression pour des raisons de performances. Dans ce cas, ltape de suppression met un tmoin de suppression sur les donnes qui seront physiquement effaces pendant le post traitement.
5.3
Processus annexes
En annexes aux tapes darchivage, il est possible de lancer des routines de
rechargement, de lecture et de gestion des archives (voir Figure 22).
Figure 22: tapes processus annexes
5.3.1
Rechargement (bouton Syst. Archiv.)

Le rechargement permet de recharger les donnes supprimes par le processus
darchivage en partant des fichiers archives. Cette opration est utiliser avec beaucoup de prcautions car elle peut engendrer des incohrences fonctionnelles et/ou des conflits dunicit. Par exemple si une commande de vente est archive depuis plusieurs annes et pendant ce temps tous les codes du canal de distribution ont t modifis suite une rorganisation, aprs le rechargement, le canal de distribution risque de ntre plus pertinent selon la nouvelle organisation. Il pourrait galement arriver que le numro de commande, cl unique de la table VBAK, soit utilis par une nouvelle, ce qui causerait un conflit dunicit. Pour toutes ces raisons, le rechargement est trs rarement utilis, sauf pour corriger un archivage erron..
5.3.2
Visualisation (bouton lecture)

La visualisation, dans ce contexte, est une fonctionnalit fournie pour vrifier que
lcriture des fichiers archive sest droul correctement.
Bolognesi Michel
25.08.2010
67/145
5.3.3
Gestion des archives

Cette fonctionnalit ddie aux oprateurs darchives permet de visualiser les
processus darchives avec les fichiers associs (voir Figure 23)
Figure 23: gestion des archives
ArchiveLink
ArchiveLink est une interface et un service de communication pour lier tous
documents entrants ( Incoming Document ) ou sortants ( Outgoing Documents ) entre SAP et une autre application. Les flches de la Figure 24 reprsentent ce lien fourni par ArchiveLink et le serveur encercl au milieu, de la Figure 24, symbolise une application.
Bolognesi Michel
25.08.2010
68/145
Figure 24 : documents entrants et sortant entre SAP et dautres applications.
6.1
Principe
Archivelink peut tre compar, dans une certaine mesure, un lien hypertexte.
Comme tous les internautes le savent, ce lien reprsent par un texte bleu soulign permet douvrir une page html qui peut tre stocke dans un autre site internent. ArchiveLink est un module transversal permettant de faire un lien unique entre un objet mtier et des fichiers annexes. Pour ce faire, SAP met disposition un paramtrage spcifique qui sarticule autour de trois lments principaux : objet mtier, table de lien et protocole HTTP.
6.2
Objet mtier
Un objet mtier ou Business Objet sinspire de la thorie de la programmation
objet avec des attributs, des mthodes, des vnements, etc. Dans ce contexte, lobjet est une implmentation dune classe reprsentant un lment rel comme un article, une commande, un bon de livraison, une facture, etc. Il faut remarquer que le module SAP darchivage est, lui aussi, un objet mtier, ne pas confondre avec les objets archives. Les objets archive servent uniquement pour larchivage et sont, dans une certaine mesure, un sous-ensemble des objets mtier. Par exemple lobjet mtier facture dcompte est archiv avec les objets archive ISU_PRDOCH et ISU_PRDOCL (voir Figure 8). Pour illustrer le principe, un article (objet mtier) lui est associ plusieurs fichiers annexes (grce aux tables de liens) comme les spcifications, les caractristiques qualits, etc.
Bolognesi Michel
25.08.2010
69/145
6.3
Tables de liens
Comme son nom lindique, ces tables de liens de la base de donnes SAP permettent
de crer un lien unique entre lobjet mtier et le document stock sur le serveur de contenu. Ces tables sont utilises par les programmes de cration, lecture et suppression des fichiers annexes. Elles sont transparentes pour lutilisateur, sauf certaines reprsentes par des vues de paramtrage utilises pour la mise en uvre dArchiveLink. Le propos nest pas de faire une cartographie exhaustive de toutes ces dernires, mais simplement de comprendre comment ce lien est dfini par les vues Liens pour Content Repositories , Content Repositories et comment ces liens sont enregistrs par la table TOA01 .
6.3.1
Vue Liens pour Content Repositories

La vue de paramtrage Liens pour Content Repositories permet de dfinir
comment le lien doit soprer (voir Figure 25).
Figure 25 : copie dcran de la vue lien pour Content Repositories .
Les champs clef de cette table sont : Type objet : ce code dfinit le nom de la classe de lobjet mtier
Bolognesi Michel
25.08.2010
70/145
Type de document : ce code dfinit le format de fichier. Larchitecte de la base de donnes a ajout un niveau supplmentaire la dfinition des formats de fichier pour permettre de mieux le dcrire selon le contexte (voir Figure 26)
Figure 26 : exemple dentre de la table type de document.
S : cest un champ de type boolen. Si X est activ, cela signifie qu'une seule classe d'objet mtier et qu'un type de document peuvent tre actifs. ID Rf.Cont. : ce code est le nom du content serveur. Lien : le nom de la table de lien D. rsidence : il indique le nombre de jours au bout desquels un document archiv peut tre supprim dans les tables de liens.
Champ non clef :
En rsum, cette vue dfinit le serveur de contenu et la table de lien pour une classe dobjet mtier et un format de fichier .
6.3.2
Content Repositories
La vue de paramtrage Content Repositories de la Figure 27 dfinit le moyen de
communiquer avec le serveur de contenu qui est distant.
Bolognesi Michel
25.08.2010
71/145
Figure 27 : Vue de paramtrage du Content Repositories.
Le seul champ clef de cette table est le code Content Rep . Ce dernier est simplement un champ alphanumrique deux positions. Les autres champs significatifs sont : Intervalle document : il correspond la tranche de numro interne utilise pour la gnration de noms de fichiers et de numros d'ordres univoques pour les ordres asynchrones. Type de stockage : ce code permet de dfinir le type de communication : http, RFC, etc. Protocole : par ce champ, SAP permet dutiliser plusieurs protocoles, mais il reste souhaitable dutiliser uniquement le saphttp, qui se base sur un protocole standard. N de version : cest la version du protocole saphttp. Serveur http : c'est l'adresse IP du serveur de contenu. N de port : c'est le numro de port du serveur de contenu. Numro port SSL : c'est le numro de port SSL, si utilis (?), du serveur de contenu Script http : cette routine est fournie par le serveur de contenu pour tablir la communication. Chemin de base : ce champ dfinit lemplacement du disque o le fichier stocker est plac temporairement avant qu'il soit entrepos sur le serveur de contenu par une commande http.
Chemin darchivage : lors de la consultation dun fichier stock sur le serveur de contenu, il est copi temporairement dans cet emplacement du disque pendant le temps de lecture de SAP.
Unit de sortie : derrire ce code se cache limprimante utilise pour le stockage des listings sortants de SAP vers le serveur de contenu. Sans signature : si cette coche est valide, les changes http entre SAP et le serveur de contenu se font avec une signature de cryptage.
Ces boutons servent vrifier si la communication avec le serveur de contenu se fait correctement.
6.3.3
Table TOA01
Pour des raisons de performances lors dun trs grand nombre dentres, SAP a prvu,
dans son architecture, la possibilit de crer autant de tables de lien que le besoin se fait sentir. Cependant, la structure est et doit tre identique lexemple de la Figure 28.
Figure 28 : exemple dun tuple de la table dune table de lien.
Les cinq premiers champs de la table des liens permettent de rendre ce lien unique. Ces champs sont les suivants : Mandant : le mandant est une sparation logique des bases de donnes lintrieur dune installation du systme SAP. Type dobjet : ce code dfinit le nom de la classe de lobjet mtier. Dans lexemple de la copie dcran, il correspond un numro de facture. ID de lobjet : cest le numro unique de lobjet mtier. Dans cet exemple, c'est le numro de facture.
Bolognesi Michel
25.08.2010
73/145
ID Cont. Rep. : ce code est le nom du serveur de contenu. ID du document : ce code est cr par un algorithme permettant de le rendre unique du ct SAP et du ct serveur de contenu. Ce dernier est donn toujours en paramtre pour tous les changes entre ces deux systmes.
Les autres champs donnent quelques informations supplmentaires : Type doc. : ce code dfinit le format de fichier. Archiv le : cela indique la date laquelle le fichier a t stock sur le serveur de contenu. Supprim le : cela indique la date de suppression du fichier. Rserve : ce champ a t ajout pas SAP pour des besoins futurs.
6.4
Protocole http.
Archivelink utilise le protocole http version 1.1 dvelopp par le consortium World
Wide Web (www.w3c.org). Cependant, SAP utilise une certaine syntaxe pour communiquer avec les contents externes. Cette dernire est expose sommairement dans ce chapitre.
6.4.1
-
Syntaxe
http://servername:port/script?command&parameters servername : c'est le nom du serveur par lequel la requte est adresse. Port : c'est le numro de port du serveur (servername) par lequel la requte est adresse. Script : c'est le nom du programme pour accder au serveur interpell. Ce dernier peut tre une DLL,37 un script CGI38 ou ASP39. Command : c'est une commande pour dfinir laccs au serveur distant par des oprations de lecture, cration, changement et suppression.
37
DLL (Dynamic Link Library) est une fonction qui fait partie dune bibliothque dynamique. Cette
dernire est appele lors de lexcution dun programme, mais nen faisant pas partie. Lavantage principal dune bibliothque dynamique est la rduction de la taille d'un excutable, puisque certaines parties du logiciel se situent dans le systme, et l'introduction de validations identiques pour chaque programme, puisque tous sont lis une seule et mme bibliothque.
38
CGI (Common Gateway Interface) est une interface normalise utilise par les serveurs HTTP. Ce
dernier, au lieu d'envoyer le contenu d'un fichier (page HTML, image...), excute un programme puis retourne le contenu gnr, comme s'il s'agissait d'un contenu de fichier.
39
ASP (Active Server Pages) est un langage de programmation dvelopp par Microsoft permettant
l'excution de script sur le serveur.
Bolognesi Michel
25.08.2010
74/145
Parameters : pour chaque commande, il faut ou il peut y avoir des paramtres spcifiques.
6.4.2
Exemple de commande http

Lexemple suivant est une commande http qui demande au serveur de contenu de
renvoyer un document : http://192.168.110.143:1090/ContentServer/ContentServer.dll?get&pVersion=0046&c ontRep=Z0&docId=F31C5490BDF4E44B959AE10424CC96D0 dumas-00530235, version 1 - 28 Oct 2010 192.168.110.143 : adresse IP du serveur de contenu (voir 6.3.2). 1090 : numro du port de serveur de contenu (voir 6.3.2). ContentServer/ContentServer.dll : chemin et nom du programme pour laccs au serveur (voir 6.3.2), Get : est la commande de lecture Version=0046 : paramtre qui indique la version de protocole http utilise par ArchiveLink. Rep=Z0 : nom du Content Repositorie (voir 6.3.2) docId=F31C5490BDF4E44B959AE10424CC96D0 : numro unique du document dont la correspondance se trouve dans la table des liens (Figure 29) .
Figure 29: Table des liens
Bilan de conformit
Aprs ce survol des fonctionnalits fournies par lditeur allemand concernant
larchivage des donnes, ce chapitre effectue un bilan de conformit en fonction des exigences lgales vues dans la section prcdente, car, thoriquement, larchivage de donnes est un sous ensemble de larchivage lectronique.
Bolognesi Michel
25.08.2010
75/145
Disposition sur la conservation lectronique

(voir II3.1.3 Disposition sur la lectronique ) conservation
Degr de couverture
Conformit des outils darchivage des donnes SAP
Intgrit (authenticit et infalsifiabilit)
Disponibilit dumas-00530235, version 1 - 28 Oct 2010
Organisation
Sparation entre les informations archives et celles actuelles Contrle et migration des donnes
Temps de conservation
Les fichiers archives sont dans un format propritaire. Ils sont illisibles par aucun dautre moyen que par lenvironnement SAP et en plus aucun outil standard SAP permet de les modifier. Dans ce sens il serait presque possible de considrer que lintgrit est respecte. Les fichiers archives sont visualiss par les mmes crans que ceux de la transaction qui a gnr la donne. Laccs est donc rapide et assez facile. Cependant, il faut noter que si lenvironnement ayant gnr les fichiers archives nest plus disponible, il sera trs difficile, voire impossible, de les relire. Le systme dautorisation standard de lenvironnement SAP sapplique galement pour laccs aux fichiers archives. Des problmes dautorisation dans la lecture des fichiers archives ne peuvent donc pas surgir durant la conservation. Lors de la consultation, lutilisateur doit choisir une transaction spcifique pour consulter les archives et une mention Archive apparat sur lcran de visualisation. Lditeur garantit qu'avec son environnement, les donnes seront toujours lisibles mme aprs des changements successifs de versions. Cela peut tre acceptable pour la conservation des donnes court terme, cependant ce nest pas satisfaisant pour la conservation moyen et long terme. Le processus darchivage ne prend pas en compte la suppression automatique des archives la fin du dlai de conservation. Loprateur doit grer cela de manire manuelle et la suppression est faite directement dans le systme darchivage.
N.B. : il ne faut pas confondre temps de rsidence dans la base de donnes avec temps de conservation des archives. Le premier est un paramtre de contrle utilis par le processus darchivage pour limiter larchivage avant une certaine date, alors que le second est le temps de rsidence des fichiers archives dans le systme darchivage.
Bolognesi Michel
25.08.2010
76/145
Conclusion : Je pense que les outils pour larchivage des donnes SAP ne sont pas adapts pour larchivage lectronique pour deux raisons principales : Format propritaire : comme voqu dans le chapitre II4.1 si pour une raison quelconque les progiciels SAP devaient disparatre il sera trs difficile, voire impossible, de relire les archives. Une contrainte supplmentaire sajoute au format de fichier propritaire, c'est la quasi impossibilit de relire des fichiers sans le systme qui en a t lorigine. En clair, mme si thoriquement tout systme SAP est en mesure de lire des fichiers archives, il reste trs difficile de le faire sans les tables index stockes dans la base de donnes dorigine. dumas-00530235, version 1 - 28 Oct 2010 Pour ma part, je crois que de manire gnrale il est plus judicieux de gnrer les documents soumis des contraintes lgales dans un format tel que pdf/A et de les conserver dans un systme darchivage. En conclusion, larchivage des donnes SAP est un excellent moyen pour purger les tables et ainsi prserver les performances, faciliter ladministration et rduire le temps dindisponibilit en cas de problme de la base de donnes.
Bolognesi Michel
25.08.2010
77/145
IV Ralisation du projet
Le projet darchivage de donnes SAP est avant tout un projet dintrt technique. Si chaque administrateur de base de donnes connat les avantages de garder la base la moins volumineuse possible, les utilisateurs du progiciel souhaitent, au contraire, que toutes leurs donnes demeurent en ligne pour les consulter le plus aisment possible, la taille de stockage ntant gure leur problme. Cependant, ces deux visions divergentes doivent coexister et il faut trouver le meilleur compromis tout en respectant les exigences lgales, organisationnelles et techniques. SAP a mis au point une mthodologie appele ASAP (pour Accelerated SAP) pour aider les chefs de projet mener bien les projets dintgration du progiciel allemand. Le dumas-00530235, version 1 - 28 Oct 2010 prsent projet peut galement tre gr et suivi laide de cet outil. ASAP sappuie sur une feuille de route appele roadmaps, jalonne de cinq tapes (voir Figure 30) : prparation de projet, business blueprint40 (ou conception gnrale), ralisation, prparation finale et go live et support.
Figure 30: feuille de route ASAP
40
blueprint en rfrence au tirage de plans transparents originaux transformant dans des machines
tirage de papier lammoniaque des papiers jaunes dsazots en plans bleus.
Bolognesi Michel
25.08.2010
79/145
Prparation du projet
La prparation de ce projet a dbut par une brve formation effectue par SAP sur les
outils darchivage. Ces informations thoriques ont ensuite t compltes par un tmoignage expliquant la mise en uvre dun tel projet dans lentreprise Migros SA. Enfin, la participation plusieurs sminaires consacrs larchivage lectronique, ltude approfondie des ressources cites en annexe et de nombreux tests dans le systme ont permis de mieux comprendre son fonctionnement. Aprs ce travail prliminaire qui tait ncessaire, le vrai projet a commenc par une analyse de la croissance du volume de la base de donnes, le choix des objets darchivage par une analyse selon la loi Pareto des tables les plus volumineuses, la proposition du temps de rsidence en ligne et la dfinition de lquipe de projet. dumas-00530235, version 1 - 28 Oct 2010
1.1
Analyse de la croissance du volume de la base de donnes

Cette analyse de la croissance du volume de la base de donnes est un indicateur
permettant dvaluer grossirement le niveau durgence de la mise en uvre le projet darchivage de donnes. Grce la pente de la courbe de croissance, il est possible destimer quand il faut prvoir lachat despace disque supplmentaire ou le remplacement des serveurs pour garantir le mme niveau de temps de rponse. Lautre alternative, objectif de ce projet, est darchiver avant quil ne faille entreprendre des modifications physiques.
1.1.1
Courbe de croissance
Le tableau ci-dessous reprsente lvolution mensuelle du volume de la base de
donnes durant les 13 derniers mois (voir Tableau ii).
mars.10
602 10
aot.09
sept.09
janv.10
fvr.10
nov.09
dc.09
mai.09
juin.09
avr.09
Volume net Go 643 669 677 683 698 509 525 Croissance Go 26 8 6 15 -189 16 Croissance moyenne ( partir doctobre 2009) en Go
544 19
562 18
577 15
592 15
615 13
15
Tableau ii: croissance de la base de donnes
Bolognesi Michel
25.08.2010
80/145
avr.10
oct.09
juil.09
La Figure 31 illustre avec un graphique les valeurs du tableau prcdent. En septembre, il y a une baisse trs importante du volume suite des actions de purge (dcrites plus loin) et sa rorganisation.41
Figure 31 : croissance de la base de donnes
1.2
Analyse selon la loi Pareto

A lheure actuelle, la base de donnes SAP comporte 72419 tables diffrentes. Il est
utopique de toutes les archiver, cela engendrerait beaucoup defforts inutiles. Par contre, il serait plus judicieux de classer les plus volumineuses (voir Tableau iii) et daxer larchivage sur ces dernires pour que limpact sur le volume de la base de donnes soit significatif. Cette dmarche sinspire sur la loi de Pareto 42 : environ 80 % du volume est le produit de 20 % des tables.
41
La rorganisation de la base de donnes est une opration qui vise modifier la structure physique de
cette dernire. Cette dmarche permet de rcuprer les espaces libres entre les segments au sein dun data file, et donc de rduire la taille de ces fichiers.
42
La loi de Pareto, aussi appele loi des 80/20, est une loi empirique inspire des observations de
Vilfredo Pareto, conomiste et sociologue italien : environ 80 % des effets sont le produit de 20 % des causes. Cette loi , bien qu'empirique, a t formalise en mathmatiques par la distribution de Pareto (voir http://fr.wikipedia.org/wiki/Loi_de_Pareto).
Bolognesi Michel
25.08.2010
81/145
Table
DBERCHZ1 DFKKOPK DFKKMOP DFKKOP CDCLS DBERCHZ3 COEP DBERDL DBERDLB EDI40 DBERCHZ2 COSP CDHDR GLPCA KNVP DFKKOPBW KNVV DFKKKO CE41000_ACCT ERDK DFKKCIBW EABL REPOSRC PTDW_TIMES_DB D010TAB BALDAT SWELOG DFKKZP EDIDS WBCROSSGT DBTABLOG DFKKZR ERCH CE41000 MSEG ETTIFN DOKCLU GVD_SEGSTAT BSIS SRRELROLES SOFFCONT1 RFBLG BDCP PPOIX FKKMAZE ZISU_LOG_FACT D010INC COEJ DPAYP
Description de la table
Lignes individuelles de document Postes pour la pice compte courant Postes pour pice compte courant type Postes pour la pice compte courant Comptabilit : index secondaire pr comptes gnraux Lignes individuelles de docmt (des de montants et de prix) Objet CO: Postes individuels lis la priode Lignes document d'impression Rfrence d'une ligne doct imprim ligne doct CalcFacturat Document de relev Lignes individuelles de document (donnes d'appareil) Objet CO : totaux cots - critures externes En-tte de document de modification EC-PCA : postes individuels au rel Base de donnes clients : rles partenaire Extraction de postes non solds Fiche client : donnes ventes Donnes d'en-tte pour pice compte courant SIE Facture / donnes d'en-tte FICA : extraction postes compars Document de relev Codes source de programmes Extraction des donnes de temps (dures du travail) Table pour utilisation table <-> programme Protocole d'application : donnes d'un protocole Table pour entres de la trace des vnements Lot de paiements : donnes de paiement Enregistrement de statut (IDOC) Index pour types globaux - cas d'emploi Workbench Enr. de prot. pr modifications tables Formulaire de paiement Donnes de facture SIE Segment de document pour article Val. fixes installation (normales) Formulaire de paiement Oracle monitoring: Copy of GV$SEGSTAT Comptabilit : index secondaire pr comptes gnraux Service relation objet : rles SOFF : table pour contenus de documents (import/export) Codes source de programmes Pointeur de modification Index ligne rsultat du calcul de paie -> ligne d'criture Historique de relance, lignes pice Facture imprime Table des utilisations des includes ABAP Objet CO: Postes individuels sur l'anne Programme de paiement - donnes pour le poste pay Tableau iii: classement des 50 tables les plus volumineuses
Go
49,55 18,00 13,92 12,82 12,41 10,80 9,01 8,25 7,55 7,25 7,22 5,99 4,52 4,46 3,95 3,07 3,04 2,91 2,76 2,68 2,45 2,44 2,43 2,39 2,36 2,35 2,20 2,13 1,91 1,89 1,75 1,69 1,66 1,65 1,60 1,46 1,46 1,32 1,19 1,19 1,19 1,19 1,15 1,13 1,13 1,13 1,12 1,07 1,07
Bolognesi Michel
25.08.2010
82/145
1.3
Cibler les objets darchivage

A partir de ce classement, il est possible de dterminer les objets darchivage grce
la transaction DB15. Cette dernire renvoie la liste des objets darchivage par rapport une table et vice-versa (voir Figure 32).
Figure 32: Transaction DB15
Toutefois, pour les tables nayant pas dobjet, il faut valuer la possibilit den crer un sur mesure. A noter que le dveloppement est en gnral consquent et, surtout, quil doit tre maintenu tout au long de la conservation des donnes. Compte tenu de ce fait, les bonnes pratiques suggrent en gnral dviter un tel dveloppement. Pour revenir lexemple de la table COEP de la Figure 32, un grand nombre dobjets darchivage mis disposition par SAP permet darchiver cette dernire, mais il faut cibler quel est lobjet le plus pertinent, cest--dire celui qui va avoir un meilleur impact par rapport lenvironnement. Dans ce but, SAP a dit un guide43 rpertoriant les tables les plus courantes, avec des conseils sur le meilleur moyen de les purger et les archiver. Si toutefois des tables ne sont pas rpertories, la solution est de tester tous les objets darchivages pour dterminer le plus pertinent.
43
Data Management Guide for SAP Business Suite (https://websmp203.sap-ag.de/ilm)
Bolognesi Michel
25.08.2010
83/145
Aprs avoir trouv la meilleure mthode, il faut rechercher la dpendance (voir III4.4) grce la fonction graphique de rseau propose depuis la transaction SARA (voir Figure 33).
Figure 33: graphique de rseau
Pour terminer, cette analyse par lapproche ascendante,44 il est opportun de situer les objets dans leur contexte fonctionnel, cest--dire de dterminer quel est le domaine dutilisation des transactions qui produit les tuples des tables successibles larchivage. Cette recherche permet de dfinir les interlocuteurs susceptibles de participer au projet darchivage.
1.3.1
Correspondance tables / objets

Ci-dessous (voir Tableau iv) est rsume la liste des tables avec leur objet darchivage
correspondant. Pour certaines, dont plusieurs objets permettent de les archives, quelques explications complmentaires sont donnes.
Table
PPOIX MSEG *) DBERDL DBERDLB ERDK ETTIFN EABL DBERCHZ1 DBERCHZ2
Description de la table
Index ligne rsultat du calcul de paie -> ligne d'criture Segment de document pour article Lignes document d'impression Rfrence d'une ligne doct imprim ligne doct CalcFacturat Facture / donnes d'en-tte Val. fixes installation (normales) Document de relev Lignes individuelles de document Lignes individuelles de document (donnes d'appareil)
Objet
PA_PIDX MM_MATBEL ISU_PRDOCL ISU_PRDOCL ISU_PRDOCH ISU_FACTS ISU_EABL ISU_BILLZ ISU_BILLZ
Description objet
HR : fichiers index pour enregistrement dans FI/CO Gestion des articles : documents article IS-U archivage : ligne de document imprim IS-U archivage : ligne de document imprim Archivage IS-U : en-tte doc. impr. Valeurs fixes pour l'installation IS-U archivage : rsultats de relev IS-U archivage : poste du document de dcompte IS-U archivage : poste du document de dcompte
44
Approche ascendante (ou bottom up) cest--dire commencer lanalyse par le dtail pour aller vers le
gnral.
Bolognesi Michel
25.08.2010
84/145
DBERCHZ3 ERCH DFKKMOP *) EDI40 EDIDS DFKKZP FKKMAZE DFKKOP DFKKOPK DFKKKO BSIS RFBLG KNVP KNVV GLPCA *)
Lignes individuelles de docmt (des de montants et de prix) Donnes de facture Postes pour pice compte courant type Document de relev Enregistrement de statut (IDOC) Lot de paiements : donnes de paiement Historique de relance, lignes pice Postes pour la pice compte courant Postes pour la pice compte courant Donnes d'en-tte pour pice compte courant Comptabilit : index secondaire pr comptes gnraux Codes source de programmes Base de donnes clients : rles partenaire Fiche client : donnes ventes EC-PCA : postes individuels au rel SIE SIE Objet CO: Postes individuels sur l'anne Objet CO: Postes individuels lis la priode Objet CO : totaux cots - critures externes Comptabilit : index secondaire pr comptes gnraux En-tte de document de modification Protocole d'application : donnes d'un protocole Enr. de prot. pr modifications tables Pointeur de modification Table des utilisations des includes ABAP Table pour utilisation table <-> programme FICA : extraction postes compars Extraction de postes non solds Formulaire de paiement Formulaire de paiement Programme de paiement - donnes pour le poste pay Oracle monitoring: Copy of GV$SEGSTAT Codes source de programmes SOFF : table pour contenus de documents (import/export) Table pour entres de la trace des vnements Index pour types globaux - cas d'emploi Workbench Facture imprime Service relation objet : rles
ISU_BILLZ ISU_BILL ISU_BBP IDOC IDOC FI_MKKPAYL FI_MKKDUNN FI_MKKDOC FI_MKKDOC FI_MKKDOC FI_DOCUMNT FI_DOCUMNT FI_ACCRECV FI_ACCRECV EC_PCA_ITM COPAC_1000 COPAC_1000 COPA1_1000 COPA1_1000 COPA1_1000
IS-U archivage : poste du document de dcompte Archivage IS-U: E/T document calcul de facturation IS-U archivage : plan de paiement IDOC - Document intermdiaire IDOC - Document intermdiaire FI-CA : lot de paiement FI-CA : historique de relance FI-CA : pice FI-CA : pice FI-CA : pice FI : pices de la comptabilit FI : pices de la comptabilit Donnes de base clients Donnes de base clients Facture centre de profit : postes rels/de budget COPA analytique - objet rsultat, primtre rsult COPA analytique - objet rsultat, primtre rsult COPA analytique, prim. rsultat 1000 COPA analytique, prim. rsultat 1000 COPA analytique, prim. rsultat 1000
CE41000 CE41000_ACCT COEJ *) COEP *) COSP *) CDCLS *) CDHDR *) BALDAT DBTABLOG BDCP D010INC D010TAB DFKKCIBW DFKKOPBW DFKKZR DOKCLU DPAYP GVD_SEGSTAT REPOSRC SOFFCONT1 SWELOG WBCROSSGT ZISU_LOG_FACT SRRELROLES *)
CHANGEDOCU Documents de modification CHANGEDOCU Documents de modification Objet d'archivage pour journal des BC_SBAL applications Archivage des modif. de la table du BC_DBLOGS Customizing Cette table peut tre purge par la Aucun objet transaction BD22 Dictionnaire donnes: aucune action Aucun objet entreprendre Dictionnaire donnes: aucune action Aucun objet entreprendre Aucun objet Aucun objet Aucun objet Aucun objet Cette table peut tre purge par le Aucun objet programme RFKPYD00. Aucun objet Aucun objet Cette table peut tre purge par le Aucun objet programme RSSORE00 Aucun objet Aucun objet Aucun objet Aucun objet Cette table n'a pas t dveloppe par SAP Cette table peut tre purge par le programme RSRLDREL
Tableau iv: correspondance table / objet darchivage

*) Concerne les tables ayant plusieurs objets. 1.3.1.1 Tables CDHDR et CDCLS : changement de document Le document Data Management Guide for SAP Business Suite a t une prcieuse aide pour dterminer que lobjet pertinent pour ces tables est CHANGEDOCU. 1.3.1.2 Tables COEJ, COEP et COSP Ces tables du module SAP de comptabilit sont archives par plusieurs objets. SAP a mis disposition trois programmes RARCCOA1, RARCCOA2 et RARCCOA3 pour dterminer quel est le plus pertinent. Lanalyse seffectue en deux tapes : il faut dabord excuter le programme RARCCOA1 puis ensuite lancer RARCCOA2 ou/et RARCCOA3 dumas-00530235, version 1 - 28 Oct 2010 pour mettre en forme lanalyse du premier. Aprs lexcution des programmes RARCCOA1 et RARCCOA2 (voir Figure 34), lobjet COPA2_1000 influence plus de 50% du volume total.
Figure 34: rsultat d'analyse par le programme RARCCOA2
1.3.1.3
Table GLPCA Grce la variante ARCHIVE de la transaction TAANA, il est dtermin plus
simplement quel objet choisir (voir Figure 35).
Bolognesi Michel
25.08.2010
86/145
Figure 35: analyse de la table GLPCA par la transaction TAANA
1.3.1.4
Tables D010* Toutes les tables avec le prfixe D010, comme D010INC et D010TAB, contiennent
les informations du dictionnaire des donnes utilises par le fonctionnement des programmes SAP. La croissance de ces dernires demeure normale et rien ne doit tre entrepris pour les archiver ou les purger. 1.3.1.5 Table SOFFCONT1 Il est possible de joindre des fichiers lis aux objets tels que des factures, articles, commandes, etc. Ces derniers sont stocks principalement dans la table SOFFCONT1, mais SAP recommande fortement dutiliser un lien de stockage externe (cest le principe de larchivage des documents voir chapitre IV3.2). Cette table peut tre purge par le programme RSSORE00.
1.3.2
Domaine dutilisation et dpendance

Aprs avoir trouv les objets darchivage correspondant aux tables volumineuses, il est
important de sintresser aux dpendances de ces derniers (voir III4.4) et de situer lorigine fonctionnelle des donnes. Dans ce but, les objets sont regroups en 6 catgories : contrle de gestion, finance, industrie, logistique, ressources humaines et technique. 1.3.2.1 Contrle de gestion Par dfinition, le module de contrle de gestion apporte des informations des fins de planification, de rapport dactivit, danalyse financire, etc.
EC_PCA_ITM - Facture centre de profit : postes rels/de budget Lobjet EC_PCA_ITM est utilis pour archiver les lignes de calcul des centres de profit qui permettent de calculer un rsultat analytique. Ils sont aliments avec les produits ds leur comptabilisation dans la comptabilit gnrale, et indirectement avec les charges par l'intermdiaire des centres de cots, ordres internes45 ou lments dOTP46, qui leur sont rattachs. COPAC_1000 (COPA analytique - objet rsultat, primtre rsult) et COPA1_1000 (COPA analytique, prim. rsultat 1000) Les objets COPAC_1000 et COPA1_1000 sont utiliss pour archiver les donnes des rsultats du primtre de rsultat de la socit 1000 (Objets de rsultats CO-PA). Un dumas-00530235, version 1 - 28 Oct 2010 primtre analytique est une entit organisationnelle dans laquelle sont suivis les charges et les produits. Un primtre analytique peut rassembler une ou plusieurs socits et un primtre de rsultat est affect un primtre analytique. 1.3.2.2 Finance FI Toutes les pices comptables enregistres dans les modules de comptabilit gnrale, comptabilit dbiteurs, fournisseurs et immobilisations gnrent un enregistrement comptable dans le module FI. FI_DOCUMNT - FI : pices de la comptabilit Lobjet FI_DOCUMNT sert archiver lensemble de ces pices, aussi bien pour lentte (code de la socit, date comptable, etc.) que pour les postes (comptes gnraux, TVA, objet analytique, etc.) de cette dernire. 1.3.2.3 Finance module FI-CA Le module FI-CA (Contract Accounts Receivable and Payable) est un grand livre auxiliaire dbiteur. Ce dernier a t conu pour traiter et suivre un grand volume de documents dbiteurs tels que factures, relances, payements, plans dpurement, etc.
45
Un ordre interne est utilis pour assurer le suivi dune partie des cots et parfois des produits de Un lment dOTP (Organisation Technique Projet) permet dimputer des cots dans la gestion de
l'entreprise.
46
projet.
Bolognesi Michel
25.08.2010
88/145
Bien que FI-CA offre beaucoup de fonctionnalits pour amliorer le processus de gestion des dbiteurs, il ne remplace pas le module de comptabilit FI-GL47. En fait, les critures des dbiteurs collectes par FI-CA sont agrges et rapportes en comptabilit gnrale par traitement priodique. FI_MKKDOC - FI-CA : pice Lobjet FI_MKKDOC permet darchiver toutes les pices du module FI-CA de la mme manire que FI_DOCUMNT fait pour les pices de comptabilit gnrale. FI_MKKDUNN Lobjet FI_MKKDUNN permet darchiver les relances si au pralable les pices, par lobjet FI_MKKDOC, lont t (voir Figure 36). dumas-00530235, version 1 - 28 Oct 2010
Figure 36: Dpendance objet FI_MKKDUNN
FI_MKKPAYL - FI-CA : lot de paiement Les fichiers du trafic de payement provenant de la banque ou de la poste sont dans un premier temps stocks dans les tables telles que la DFKKZP. Ensuite, un complexe algorithme de rapprochement gnre les pices des dbiteurs FI-CA. Lobjet FI_MKKPAYL archive toutes les donnes intermdiaires des lots de payements. FI_ACCRECV - Donnes de base clients Lobjet FI_ACCRECV permet darchiver les donnes de base des clients. Il est cependant dpendant de beaucoup dautres objets (voir Figure 37).
47
FI-GL (General Ledger) : est le module de comptabilit gnrale de SAP
Bolognesi Michel
25.08.2010
89/145
Figure 37: dpendance objet FI_ACCRECV
Compte tenu de cette forte dpendance, leffort pour gagner quelques Ko est disproportionn par rapport au temps de ralisation. Pour cette raison et en restant cohrent au principe petite effort pour un grand rsultat , cet objet nest pas pris en compte dans la liste des objets archiver. dumas-00530235, version 1 - 28 Oct 2010 1.3.2.4 Industrie (IS-U) Le cur de lactivit de Romande Energie SA est la vente et la distribution dlectricit. Il nest pas surprenant de retrouver une forte croissance des tables concernant ces activits. ISU_PRDOCL - ligne de document imprim Lobjet ISU_PRDOCL permet darchiver les factures nergies appeles dans le jargon de ce module lignes de documents imprims . ISU_PRDOCH - En-tte document imprim Lobjet ISU_PRDOCH permet darchiver les en-ttes des factures si, au pralable, les postes lont t par lISU_PRDOCL (voir Figure 38).
Figure 38: dpendance objet ISU_PRDOCL
Bolognesi Michel
25.08.2010
90/145
ISU_BILLZ (lignes de document de calcul de facturation) et ISU_BILL (en-tte de document calcul de facturation) Avant de pouvoir tablir une facture, un dcompte ou un acompte,48 des calculs de facturation sont excuts dans le systme. Ces derniers sont stocks et peuvent tre archivs pour les lignes par lobjet ISU_BILLZ et ISU_BILL pour les en-ttes. Cependant, larchivage est possible en respectant la dpendance montre dans la Figure 39).
Figure 39: dpendances objet ISU_BILLZ et BILL
ISU_FACTS - Valeurs fixes pour l'installation dumas-00530235, version 1 - 28 Oct 2010 Lors du calcul de facturation, un algorithme trs sophistiqu dtermine le tarif de chaque installation.49 Les valeurs fixes influencent la dtermination de ce tarif et lobjet ISU_FACTS permet de les archiver si les dpendances sont respectes (Figure 40).
Figure 40: dpendances objet ISU_FACTS
ISU_EABL - Rsultats de relev Priodiquement, en gnral annuellement, les compteurs des installations sont relevs pour pouvoir tablir une facture base sur un dcompte exact. Les donnes concernant ces relevs peuvent tre archives par lobjet ISU_EABL si les dpendances sont respectes (voir Figure 41).
Figure 41: dpendances objet ISU_EABL
48
Pour chantillonner le payement de la vente dlectricit, les socits facturent, cadence rgulire
(mensuellement, bimensuellement, etc.), des acomptes. Ensuite, de manire moins rgulire (gnralement annuellement), les compteurs sont relevs, ce qui permet dtablir une facture base sur un dcompte exact.
49
Une installation est un ensemble homogne de produits et services facturer.
Bolognesi Michel
25.08.2010
91/145
ISU_BBP - Plan de paiement Lobjet ISU_BBP permet darchiver les donnes concernant les plans de payement si les dpendances sont respectes (voir Figure 42).
Figure 42: dpendances objet ISU_BBP
1.3.2.5
Logistique SAP journalise tous les mouvements des articles dans les diffrents magasins de
lentreprise. Ces journaux peuvent tre archivs grce lobjet MM_MATBEL (Gestion des articles : documents article). dumas-00530235, version 1 - 28 Oct 2010 1.3.2.6 Ressources humaines Aprs le calcul de paie, des index sont crs et enregistrs dans le module FI-CO. Ces index peuvent tre archivs par lobjet PA_PIDX HR (fichiers index pour enregistrement dans FI/CO) si les rsultats de calcul de paie lont pralablement t (objet PA_CALC : HR : rsultats du calcul de paie). 1.3.2.7 Objets techniques Dans son fonctionnement, SAP mmorise plusieurs journaux consults surtout en cas de dysfonctionnement. Ces derniers sont gnrs lattention des administrateurs SAP. Ils sont souvent inconnus par les utilisateurs, car ils nont pas dimpact direct sur les transactions mtiers. Normalement, ces objets sont plutt utiliss pour faire de la purge, cest--dire que le processus darchivage sest droul normalement et que les fichiers archives sont ensuite supprims. IDOC - Document intermdiaire Un document intermdiaire (Idoc - Intermediate document) est un conteneur destin lchange de donnes entre des systmes SAP et tout autre systme. A lheure actuelle, le protocole dchange le plus pertinent et le plus judicieux est XML. Malheureusement les IDOC sont tellement utiliss par les applications que pour le moment reste un grand standard de communication dans le milieu de lditeur allemand
Bolognesi Michel
25.08.2010
92/145
CHANGEDOCU - Documents de modification Beaucoup de documents tels que les commandes, partenaires, etc. peuvent subir des modifications. Ces dernires sont mmorises dans des journaux et lobjet CHANDEDOCU permet de les archiver. BC_SBAL - Objet d'archivage pour journal des applications Lorsquun programme sarrte brusquement de sexcuter pour des raisons anormales, un journal derreurs est sauvegard. Ces journaux peuvent tre archivs par lobjet BC_SBAL. BC_DBLOGS - Archivage des modifications des tables de paramtrage Pour sadapter aux spcificits de chaque implmentation, SAP met disposition un dumas-00530235, version 1 - 28 Oct 2010 immense ventail de paramtres. Les modifications de ces derniers sont journalises et lobjet BC_DBLOGS permet de les archiver. N.B. : parmi lensemble des objets techniques mentionns, il est le seul qui ne doit pas tre trait comme de la purge.
1.4
Temps de rtention des donnes

Ce chapitre propose un temps de rtention en ligne des donnes avant larchivage. Il
sintresse galement au temps de conservation des fichiers archives selon les directives du code des obligations voques au chapitre II3.4 qui se traduit par une conservation de 10 ans pour lensemble des objets sauf ceux qui ont une vocation technique (voir Tableau v).
Bolognesi Michel
25.08.2010
93/145
Objet
EC_PCA_ITM COPAC_1000 COPA1_1000 FI_MKKPAYL FI_MKKDUNN FI_MKKDOC FI_DOCUMNT
Description objet
Facture centre de profit : postes rels/de budget COPA analytique - objet rsultat, primtre rsult COPA analytique, prim. rsultat 1000 FI-CA : lot de paiement FI-CA : historique de relance FI-CA : pice FI : pices de la comptabilit IS-U archivage : ligne de document imprim Archivage IS-U : en-tte doc. impr. Valeurs fixes pour l'installation IS-U archivage : rsultats de relev IS-U archivage : poste du document de dcompte Archivage IS-U: E/T document calcul de facturation IS-U archivage : plan de paiement Gestion des articles : documents article
Temps Temps de rsidence rsidence systme en ligne archivage [jours] [jours]

1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 1095 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555 2555
Volume libr estim [Go]

2,82 1,04 0,68 1,35 0,71 21,34 1,50 10,00 1,69 0,93 1,55 42,77 1,05 8,81 1,02 0,72
ISU_PRDOCL ISU_PRDOCH ISU_FACTS ISU_EABL ISU_BILLZ ISU_BILL ISU_BBP MM_MATBEL
HR : fichiers index pour PA_PIDX enregistrement dans FI/CO IDOC IDOC - Document intermdiaire CHANGEDOCU Documents de modification Objet d'archivage pour journal des BC_SBAL applications Archivage des modifications des BC_DBLOGS tables de paramtrage
1095 2555 100 purge *) 100 purge *) 100 purge 1095 1) *)
0,80
TOTAL VOLUME
Tableau v: temps de rsidence
103,19
*) Objets dj archivs 1) Ces fichiers archives seront conservs tant que le progiciel SAP est utilis
1.4.1
Dure de rtention en ligne

La dure de rtention en ligne permet de savoir combien de temps les donnes sont
conserves dans la base de donnes avant quelles ne soient archives. Ce temps est donn de manire indicative car il doit tre dtermin par le responsable du domaine fonctionnel.
Bolognesi Michel
25.08.2010
94/145
Grce cette dure, il est possible destimer le volume thorique que larchivage va pouvoir librer de la base de donnes. 1.4.1.1 Calcul du volume libr Le calcul du volume libr peut tre estim par la formule suivante : Volume objet = Volume_table1 + Volume_table2 + Volume_table50 = Croissance_moyenne_journalire * Nombre_jours_rsidence
1.5
Visualisation des archives

Pour un meilleur confort des utilisateurs, ces derniers peuvent consulter les archives
gnralement avec les mmes transactions qui permettent de visualiser les donnes en ligne dumas-00530235, version 1 - 28 Oct 2010 (voir Tableau vi). Mme pour Code donnes en transaction ligne?
9KE9 KE24 Oui Oui Non Non Oui Oui Oui Oui Oui Oui Oui Oui Oui Oui Non
Objet
EC_PCA_ITM COPAC_1000 COPA1_1000 FI_MKKPAYL FI_MKKDUNN FI_MKKDOC FI_DOCUMNT ISU_PRDOCL ISU_PRDOCH ISU_FACTS ISU_EABL ISU_BILLZ ISU_BILL ISU_BBP MM_MATBEL PA_PIDX
Description objet
Facture centre de profit : postes rels/de budget COPA analytique - objet rsultat, primtre rsult
COPA analytique, prim. rsultat 1000 FI-CA : lot de paiement FP05 FI-CA : historique de relance FPM3 FI-CA : pice FPE3 FI : pices de la comptabilit fb03 IS-U archivage : ligne de document imprim EA40 Archivage IS-U : en-tte doc. impr. EA40 Valeurs fixes pour l'installation ES32 IS-U archivage : rsultats de relev EL31 IS-U archivage : poste du document de dcompte EA22 Archivage IS-U: E/T document calcul de facturation EA22 IS-U archivage : plan de paiement EA63 Gestion des articles : documents article MB51 HR : fichiers index pour enregistrement dans FI/CO PCP0 Tableau vi: consultation des archives
1.6
Equipe projet
En se basant sur lanalyse faite et en fonction des domaines fonctionnels concerns par
larchivage de donnes, il est dsormais possible de dfinir lquipe projet qui est compose
50
Les tables prises en considration pour ce calcul sont uniquement celles qui apparaissent dans le
classement.
Bolognesi Michel
25.08.2010
95/145
des personnes suivantes : chef de projet, administrateur SAP, techniciens dexploitation, utilisateur cls par domaine et juriste dentreprise. Le chef de projet a bien entendu la charge de planifier, diriger et coordonner le projet. Ce rle est celui qui ma t imparti. Ladministrateur SAP analyse la croissance de la base de donnes, tablit le classement des tables les plus volumineuses, paramtre lArchiveLink et rorganise la base de donnes. Le technicien dexploitation est en charge de la prparation et de la surveillance de lexcution des programmes du processus darchivage. Les utilisateurs cls des modules fonctionnels (finance, comptabilit, ressources humaines, logistique et vente dnergie) se limitent valider, grce dumas-00530235, version 1 - 28 Oct 2010 leur exprience professionnelle, le temps de rsidence dans la base de donnes, la formation de lensemble des usagers sur le moyen de consultation des fichiers archives et les autorisations pour les objets darchivage concernant leur domaine de comptence. Le juriste dentreprise valide le temps de rsidence des donnes darchivage dans la base de donnes et supervise de manire globale que les exigences lgales soient respectes.
Business blueprint (conception gnrale)

Le business blueprint est, dans une certaine mesure, le cahier des charges de
lapplication intgrer dans le progiciel. Ce dernier est tabli en gnral par lintgrateur en collaboration avec le client. Parfois, pour certains projets trs consquents et volumineux, la conception gnrale est accompagne par un autre document rdig uniquement par lintgrateur appel technical blueprint. Dans ce cas, le business blueprint dcrit les processus, les rgles de gestion des mtiers, etc. alors que le technical blueprint prcise les spcifications des programmes, les points de paramtrage, etc. En labsence de technical blueprint, ces informations sont englobes dans le business blueprint. Malheureusement, aucun de ces documents na t tabli de manire officielle dans le cadre de ce projet car le client na jamais valid loffre de mise en uvre. Cependant, sil fallait ltablir, voici sa structure :
Bolognesi Michel
25.08.2010
96/145
Dfinition de larchivage (voir chapitre III1) Motivations (voir chapitre III2) Principe de larchivage (voir chapitre III3) Liste des objets archives (voir chapitre IV1.3) Description de leur contexte fonctionnel Temps de rtention en ligne et dans le systme darchivage Dpendance entre objets
Architecture technique Visualisation des archives (voir chapitre IV1.5) Autorisations Planification dumas-00530235, version 1 - 28 Oct 2010 Ci-aprs seront davantage dvelopps certains points de cette structure de blueprint qui nont pas t encore dcrits.
2.1
Architecture technique
Larchitecture technique, c'est--dire linfrastructure physique qui va accueillir les
archives, sappuie principalement sur celle dj existante. Elle nest donc pas dtaille, sauf quelques spcifications concernant trois catgories: fichiers archives, purge et documents.
2.1.1
Fichiers archives
Les fichiers archives sont dans un format propritaire qui ne peut tre lu que par un
environnement SAP. De ce fait, ces documents sont gnralement stocks directement dans un emplacement du gestionnaire de fichiers. Pour ce projet, ils sont dposs dans le SAN51 dj existant dans linfrastructure de Romande Energie SA. Nota : lors de ltape de suppression des donnes (voir III5.2.3) du processus darchivage, il est fortement recommand de sauvegarder au pralablement les fichiers archives.
51
SAN (Storage Area Network) est un rseau spcialis permettant de mutualiser des ressources de
stockage. Les baies de stockage n'apparaissent pas comme des volumes partags sur le rseau. Elles sont directement accessibles en mode bloc par le systme de fichiers des serveurs. En clair, chaque serveur voit l'espace disque d'une baie SAN auquel il a accs comme son propre disque dur.
Bolognesi Michel
25.08.2010
97/145
2.1.2
Purge
Le processus darchivage pour les objets dfinis comme techniques (voir IV1.3.2.7)
est utilis pour faire de la purge. Dans ce but, lemplacement des fichiers est purement temporaire car ces derniers seront supprims aprs leur cration.
2.1.3
Documents
Les factures et les rappels au format pdf sont archivs dans un gestionnaire de
contenu, mais cette dmarche sera dveloppe plus loin. Originalement, cette gestion devait tre faite par le programme Documentum52 car il tait dj install et oprationnel chez Romande Energie SA. Cependant, pour pouvoir sintgrer dans ce projet, le module Documentum Content Services for SAP aurait d tre ajout. dumas-00530235, version 1 - 28 Oct 2010 Mais pour les raisons exposes dans le chapitre IV3.2, le gestionnaire HTTP Content Server de SAP a t utilis en lieu et place.
2.2
Visualisation des archives

Comme dcrit dans le chapitre IV1.5, la plupart des transactions permettent de
visualiser aussi bien les donnes en ligne que celles archives. Par contre, les informations archives ne peuvent pas tre imprimes, contrairement celles en ligne. Pour pallier ce problme, il a t propos darchiver au pralable une copie de limpression au format pdf dans Documentum et crer un lien avec SAP par lArchiveLink. Le client a manifest un vif intrt pour cette proposition car elle apportait galement une solution un autre problme quil rencontrait depuis plusieurs annes : reproduire lidentique les factures et les rappels : Les factures : leur mise en page est en perptuelle mutation et, bien souvent, lors de la rimpression, la mise en page diffre quelque peu de loriginal. En plus, lorsque le client a chang dadresse, il nest pas possible de rimprimer le document avec lancien domicile. En clair, dans tous les cas, le document est imprim avec la dernire adresse connue. Les relances : non seulement la mise en page et ladresse peuvent changer, mais surtout, dans la version prcdente de SAP (forte heureusement ce nest plus le cas), il tait impossible de la rimprimer dans un niveau prcdent. Par
52
Documentum est un logiciel dit par la socit ECM pour grer tous les types de contenu de
l'entreprise au sein d'une infrastructure d'informations communes.
Bolognesi Michel
25.08.2010
98/145
exemple, si une facture avait le statut interruption de fourniture (troisime niveau de relance), il tait impossible de rimprimer ltat invitation au paiement (deuxime niveau de relance). Ces problmes avaient de fcheuses consquences, particulirement lors de la mise en contentieux. Effectivement, les juges peuvent exiger lensemble des factures et rappels tels quils ont t envoys au client. Pour raliser larchivage des documents, il faut modifier le processus ddition. En fait, aprs le calcul de facturation et la cration des documents dimpression, un fichier dchange est envoy de SAP vers le logiciel JetForm de la socit Cisel SA. JetForm est un logiciel dditique qui permet de faire la mise en page de documents et de piloter des dumas-00530235, version 1 - 28 Oct 2010 imprimantes et des machines de mise sous pli (voir Figure 43).
Figure 43: processus d'impression avant modification
Ce processus a d tre modifi par la socit Cisel SA pour que lors de la gnration du fichier de spool, un fichier pdf soit cr pour chaque document et stock dans un rpertoire temporaire. Un automate dans le serveur de gestion de contenu Documentum lit les fichiers, les archive et les supprime du rpertoire temporaire. Ensuite, un autre programme cre une rfrence du fichier archiv dans SAP afin que ce dernier puisse tre lu comme pice jointe depuis les transactions standards du document (voir Figure 44).
Bolognesi Michel
25.08.2010
99/145
Figure 44: processus de facturation aprs modification
2.2.1
Spcification de nommage du fichier pdf

Le nom de fichier pdf cr par JetForm doit respecter la nomenclature suivante : mandant_systme_CodeTypeDocument_noDocument_TimeStamp.pdf Mandant : se rfre au code mandant SAP, par exemple 100 pour la socit Romande Energie du systme productif. Systme : se rfre au systme SAP, par exemple P01 pour le systme productif. Code type document : o F : pour les facture ISU o R : pour les relances Numro du document : numro de facture Time stamp : la date, lheure, les minutes et les secondes de la cration du document.
2.2.2
Protection des fichiers pdf

Les fichiers pdf doivent tre protgs de la modification, de la copie du contenu, etc.,
mais ils doivent pouvoir tre imprimables (voir Figure 45 ).
Bolognesi Michel
25.08.2010
100/145
Figure 45: protection des fichiers pdf
2.2.3
Spcification pour des mtadonnes des fichiers pdf

Les fichiers pdf doivent tre enrichis dun certain nombre de mtadonnes qui se
trouvent dans les documents de factures et relances : Systme source (pour rappel, cest le systme SAP dorigine du document) Mandant (pour rappel, cest une unit indpendante d'un point de vue commercial, organisationnel et technique dans un systme SAP) N du compte de contrat N du client N de la facture Date comptable de la facture Montant payer ou d Grce ces mtadonnes, un automate lintrieur de Documentum est en mesure de classer et indexer les fichiers de sorte que ces derniers puissent tre consults depuis une interface fournie par ce logiciel.
Bolognesi Michel
25.08.2010
101/145
2.2.4
Spcifications du programme dintgration des fichiers pdf dans Documentum

La socit Sword SA intgratrice de la solution Documentum chez Romande Energie
SA est en charge dadapter la structure et de dvelopper un programme dintgration des fichiers pdf dans ce gestionnaire de contenu. Cette recherche mentionne uniquement les grandes lignes et les proprits principales, car les spcifications exactes et dtailles doivent tre fournies par la socit Sword SA. 2.2.4.1 Structure physique La structure physique du plan de classement des factures et des relances doit tre la selon la Figure 46 ci-dessous : dumas-00530235, version 1 - 28 Oct 2010
Figure 46: structure du plan de classement
2.2.4.2
Programme dintgration Le programme dintgration devra prendre en considration les points suivants : Lire les fichiers stocks dans le rpertoire temporaire. Contrler les fichiers : o Contrle si le fichier pdf nest pas corrompu, o Contrle des doublons, o Contrle si le type de document est reconnu. Si une de ces erreurs est dtecte, cette dernire doit tre note dans un journal et le fichier doit tre dplac dans un rpertoire ddi aux erreurs. Classer le fichier selon son nommage et lire les mtadonnes. Enrichir les caractristiques par la lecture des mtadonnes du fichier. Ces dernires permettent dindexer le document dans Documentum afin quil puisse tre consult facilement par les utilisateurs. Dfinir la date de conservation en fonction de la date comptable qui se trouve dans les mtadonnes : date comptable + 10 ans. Supprimer les fichiers du rpertoire aprs intgration.
Bolognesi Michel
25.08.2010
102/145
2.2.5
Lien entre la facture SAP et Documentum

Une fois que les fichiers sont intgrs dans Documentum, il faut crer un lien pour que
les utilisateurs puissent les consulter depuis la transaction de visualisation des documents imprims. Pour ce faire, il faut crer une communication entre SAP et Documentum par le paramtrage de lArchiveLink explicit dans le chapitre III6 ArchiveLink. En plus, il faut dvelopper un service web53 afin quun automate cr par Sword puisse lutiliser pour lier le fichier avec le document imprim. 2.2.5.1 Service web pour la cration du lien fichier document imprim Paramtre dentre : dumas-00530235, version 1 - 28 Oct 2010 o Numro de facture o Type de document : F pour facture et R pour relance o Numro dindentification unique : ce numro alphanumrique est lidentifiant unique dans Documentum dun fichier Retour : o 0 : traitement termin avec succs o 4 : doublon o 8 : document inexistant o Dautres messages de retours sont supports directement par les couches dchange Contrles : o Contrle si le numro de facture existe et, si ce nest pas le cas, retourner 8. o Contrle des doublons par la combinaison du numro de facture et du numro didentifiant unique, si cest le cas renvoyer 4. Cration : o Cration du lien dans la table des liens TOA01 (voir chapitre III6.3.3 Table TOA01 pour plus de dtails).
53
Le service web est une technologie permettant des applications de dialoguer distance via Internet,
et ceci indpendamment des plates-formes et des langages sur lesquels elles reposent.
Bolognesi Michel
25.08.2010
103/145
2.3
Autorisations
Comme dj mentionn plusieurs reprises, la consultation des fichiers archives ainsi
que des documents lis se fait depuis la transaction standard de visualisation des donnes en ligne. Des droits daccs sont dj associs cette dernire, mais si des restrictions supplmentaires sont ncessaires la consultation des archives ou des documents lis, cela doit tre spcifi par le client. A noter par contre que la consultation des fichiers pdf depuis Documentum requiert la mise en place des autorisations.
3
Ralisation
Selon la mthode ASAP, la ralisation concerne le paramtrage, le dveloppement et
les tests unitaires dans le systme de dveloppement (voir chapitre I2.3.7.4). Comme le client a uniquement valid la mise en place de larchivage des documents pour les factures et les relances, la direction de neo technologies SA a dcid de mettre en place gracieusement larchivage des donnes pour les objets techniques. Il faut savoir que Romande Energies SA a sign, avec neo technologies SA, un contrat de niveau de service, plus connu sur la terminologie anglaise SLA54. Bien que ce dernier ne prvoie pas de prestation concernant larchivage des donnes, il a t admis que les objets techniques peuvent faire partie de ladministration courante.
3.1
Archivage des donnes

La ralisation de larchivage comprend le paramtrage global, le paramtrage
spcifique, des traitements particuliers et un test de droulement du processus pour chaque objet technique : document intermdiaire, document de modification, journal des applications et journal des protocoles des workflows55.
54
Le SLA (Service Level Agreement) est un document qui dfinit la qualit de service requise entre un Le workflow est une automatisation d'un processus (partiel ou complet), au cours duquel des
prestataire et un client.
55
documents, des informations et des tches passent d'un participant un autre, au sein d'un groupe de travail, en conformit avec un ensemble de rgles prdfinies. Un systme de workflow dfinit, cre et gre l'excution de tels processus (voir http://www.alaide.com/dico.php?q=Workflow).
Bolognesi Michel
25.08.2010
104/145
Certains ont pu remarquer que les protocoles des workflows nont pas t dfinis lors de lanalyse de Pareto (voir chapitre 1.2). Cependant, lors de lanalyse effectue en 2009, ces derniers faisaient partie des objets dont les tables taient parmi les plus volumineuses. Ensuite, aprs la purge de septembre 2009, la croissance de ces tables na pas t aussi importante.
3.1.1
Paramtrage global
Les paramtrages globaux sont lensemble des paramtres communs tous les objets
darchivages mentionns au chapitre III5.1.1.1. En ralit, aucun de ces paramtres na t modifi car les options standard conviennent. Par contre, un fichier logique commun tous les objets a t dfini (voir Annexe 2 pour plus de dtails) : dumas-00530235, version 1 - 28 Oct 2010 Chemin logique :
Dfinition du nom de fichier :
3.1.2
Paramtrage spcifique
Pour lensemble des objets techniques seront utiliss les mmes paramtres grs par
la transaction SM30 vue V_ARC_USR. Ces derniers sont (encadrs en rouge dans la copie dcran ci-dessous voir Figure 47) : le nom du fichier logique, la dfinition de la taille des
Bolognesi Michel
25.08.2010
105/145
fichiers archives, la variante dexcution en mode productif et le lancement automatique de la suppression.
Figure 47: paramtrage spcifique
3.1.3
Traitement particulier
Associs au processus darchivage, certains objets tels que lIDOC bnficient des
traitements particuliers. Ces derniers servent inhiber certains contrles de cohrences typiques du programme de cration des fichiers archives ou complter le processus. 3.1.3.1 Document intermdiaire (IDOC) Dans la gnration des documents intermdiaires, un certain nombre de liens sont crs et mmoriss dans la table SRRELROLES. Lorsque les IDOCs sont supprims, ces liens nont plus dutilit et le programme RSRLDREL les supprime. Dans le contexte de ce projet, ce programme doit tre excut pour le type de relation IDC8 (voir Figure 48) et IDCA.
Figure 48: suppression des relations IDC8
Bolognesi Michel
25.08.2010
106/145
3.1.4
Tests
Les tests dans lenvironnement de dveloppement ont t effectus par mes soins sur
un petit chantillon de donnes. Ces derniers, bien que sommaires, ont permis de vrifier que le processus est exact et les programmes sexcutent correctement. NB : des tests plus approfondis sont effectus dans le systme de qualit (voir I2.3.7.4).
3.2
Archivage des documents

Avant dentrer dans le vif du sujet concernant larchivage des documents (voir IV2.2),
il est important de relever une substantielle modification qui est survenue avant la ralisation. Le client, pour des raisons de rapidit de mise en uvre, a souhait que les documents soient dumas-00530235, version 1 - 28 Oct 2010 intgrs dans le gestionnaire de contenu HTTP Content Server de SAP (voir lAnnexe 3) au lieu de Documentum, et ce nest que dans un deuxime temps quils migreront du HTTP Content Server vers Documentum comme dfini dans le cahier des charges initial (voir IV2.2). Ce changement a entrain quelques modifications dans le processus de facturation prvu. Pour la premire partie, cest--dire la cration du fichier pdf, le stockage de ces derniers dans un rpertoire partag et le paramtrage de lArchiveLink, il ny a pas eu de changements. Par contre, toute la partie dintgration du pdf dans le Content Server et le lien avec SAP a d tre adapte par la cration dun programme spcifique pour grer les fichiers, les intgrer dans le serveur de contenu et faire le lien avec SAP (voir la reprsentation de la Figure 49).
Figure 49: intgration des pdf dans le HTTP Content Server
Bolognesi Michel
25.08.2010
107/145
3.2.1
Cration des fichiers pdf

La socit Cisel SA sest charge dajouter leur processus interne la mise en page
des documents, la cration des fichiers pdf et leur sauvegarde dans un rpertoire partag.
3.2.2
Ralisation du paramtrage de lArchiveLink

La premire partie de la ralisation concerne le paramtrage de lArchiveLink. La suite
de sous-chapitre explicite pas pas les tapes de ce paramtrage. 1. Cration du rfrentiel de contenu (transaction OAA3) : Cette transaction permet de dfinir les protocoles pour piloter, en fonction du type de document, la communication entre le systme SAP et les gestionnaires de contenu. La Figure 50 montre les paramtres saisis. dumas-00530235, version 1 - 28 Oct 2010
Figure 50: rfrentiel de contenu
2. Cration dun repository (transaction OAC0) Comme expliqu dans le chapitre III6.3.2, (voir Figure 51) dfinit le moyen de communiquer avec le serveur de contenu. Physiquement, ce dernier correspond un rpertoire (voir Figure 62).
Figure 51: paramtrage du content repositorie
Nota : lors de la mise en place de Documentum, il faudra changer uniquement les paramtres : Serveur HTTP, N de port et Script HTTP. 3. Cration des types de document (transaction SM30 vue TOAVE)
Le type de document permet de regrouper tous les documents du mme type par rapport un objet mtier. Pour ce projet, il a t cr le type ISU_BILL pour les factures et ISU_DUNN pour les relances (voir Figure 52).
Figure 52: type de document
4. Cration dune table des liens (transaction SE11) La table des liens est le pivot entre lcran de visualisation des documents dumas-00530235, version 1 - 28 Oct 2010 imprims et les fichiers pdf stocks dans le HTTP Content Server. La cration de cette dernire nest pas indispensable car il est possible dutiliser celle fournie en standard. Cependant, dans le cadre de ce projet, je prconise den crer une nouvelle tous les trois ans pour matriser le nombre denregistrements et prserver les temps daccs. La cration de cette nouvelle table est faite par copie de la TAO01 (voir Figure 53).
Figure 53: Cration de la table des liens
5. Enregistrement la table des liens (transaction SM30 vue V_TOACO) Aprs la cration de la table des liens, il faut lenregistrer pour quelle soit reconnue dans le traitement des liens. 6. Traitement des liens (transaction OAC3) Le paramtrage de traitement des liens met en relation (voir Figure 54) lobjet mtier (PRINTDOC : document dimpression), le type de document (voir point 3), le content repository (voir point 2) et la table des liens (voir points 4 et 5).
Bolognesi Michel
25.08.2010
109/145
Figure 54: traitement des liens
NOTA : Le X du 3me champ S signifie que le rfrentiel est actif, c'est-dire que cest dans ce dernier que les donnes vont tre stockes.
3.2.3
Ralisation du programme dintgration

Le programme ZIP_ISU_LOAD_FACTURE_PDF (le code source se trouve dans
lannexe 4) permet de lire les fichiers stocks dans le rpertoire partag, de contrler la dumas-00530235, version 1 - 28 Oct 2010 cohrence des ces derniers, de poster les fichiers dans le serveur de contenu et de crer les liens dans SAP. 3.2.3.1 Format du fichier attendu <NumroDeFacture><Date>.pdf a. b. <NumroDeFacture> : 12 positions numriques <Date > : format anglais -> AAAAMMJJ
Exemple fichier: 00100045667020060528.pdf 3.2.3.2 Paramtres
Figure 55: paramtres du programme ZP_ISU_LOAD_FACTURE_PDF
Rpertoire :
saisir le chemin complet du rpertoire contenant les fichiers intgrer.
Simulation : si la coche est active, les fichiers ne sont pas intgrs. Cependant, les contrles suivants sont effectus : a. b. c.
Bolognesi Michel
Erreur si le fichier na pas lextension pdf Erreur si le numro de facture nest pas au bon format Erreur si la date nest pas au bon format
25.08.2010 110/145
d. 3.2.3.3
Erreur si le fichier existe dj dans le Content Server Messages derreurs

Explication Le test est fait sur la base du nom du fichier : savoir les douze premires positions doivent tre numriques. Le test est fait sur la base du nom du fichier : savoir les huit dernires positions avant le .. Test si lextension du fichier est pdf Message derreur si le numro de facture et la date (20 digits du nom du fichier) existent dj dans la table des liens (ZAI08 ou ZAS08). Il y un problme dans le Content Server, car SAP nas pas pu dposer le fichier. Erreur de communication entre SAP et CS.
Message derreur Numro de facture incohrent !
Date incorrecte ! L'extension du fichier doit tre pdf ! Fichier dj existant dans le content serveur ! Erreur lorsque le fichier est entrepos dans CS ! Erreur cration lien Archivelink !
Prparation finale
Selon la mthode ASAP, la prparation finale comporte tout dabord le transport du
paramtrage et des programmes dans le systme de qualit. Des tests approfondis sont ensuite effectus pour sassurer que lorsque le processus sera install dans le systme productif, il ny aura pas de surprises majeures. Enfin, lquipe de support est forme pour assurer la future maintenance dans lenvironnement productif, alors que les utilisateurs le sont pour la consultation des documents archivs.
4.1
Test archivage des donnes

Le Tableau vii ci-dessous rsume les tests raliss dans cet environnement, qui se sont
drouls sans aucun problme. Cela tmoigne que cette configuration peut tre transporte et excute dans le systme productif.
Bolognesi Michel
25.08.2010
111/145
Nb objets supprim Objet

IDOC CHANGEDOCU BC_SBAL WORKITEM
Temps de t [h]
Espace [Mo]
traitemen disque total

6.20 6.66 0.25 0.42 2692,920 1997,262 457,679 355,524
Libell
Document intermdiaire Documents de modification Journal des applications Journal des protocoles des Workflows
s
1 093 219 365 051 185 118 64 545
TOTAL
Tableau vii: rsultat aprs larchivage de test
5503,38
4.2
Tests archivage des documents

Concernant larchivage des documents, des tests dintgration de plusieurs milliers de
fichiers pdf ont t intgrs pour tester dune part la stabilit du programme ZP_ISU_LOAD_FACTURE_PDF et, dautre part, le temps dexcution. Ces tests ont port entire satisfaction. Dautre part le client a galement fait des tests en ouvrant plusieurs de ces fichiers par les transactions standard SAP, comme le tmoigne la copie dcran ci-dessous (voir Figure 56).
Figure 56: exemple de visualisation dune facture pdf
Bolognesi Michel
25.08.2010
112/145
Go live et support
Selon la mthodologie ASAP, cette dernire tape marque la fin du projet, le dbut de
la vie de larchivage (do le terme anglais go live) et le dbut du support. Concrtement, les paramtrages et tous les programmes sont transports dans lenvironnement productif. Les processus darchivages sont excuts pour la premire fois en production et les premires factures pdf sont intgres dans le serveur de contenu.
5.1
Rsultat aprs le premier cycle darchivage des donnes

Le premier cycle darchivage a eu lieu en septembre 2009. Le Tableau ii du chapitre
IV1.1.1 montre que le gain despace a t de 189 Go, presque un tiers du volume total. Cet important gain est d en petite partie larchivage (voir Tableau viii), mais surtout grce une rorganisation complte de la base de donnes56.
Nb objets supprim Objet
IDOC CHANGEDOCU BC_SBAL WORKITEM
Temps de t [h]
Espace [Mo]
traitemen disque total

4.30 4.26 6.13 15.22 3452,094 2751,835 7423,300 3456,819
Libell
Document intermdiaire Documents de modification Journal des applications Journal des protocoles des Workflows
s
1 401 415 502 784 3 341 695 1 322 137
TOTAL
Tableau viii: rsultat aprs le premier archivage productif
17084.05
La priodicit de cycles est dfinie en fonction du volume et de la courbe de croissance. En clair, plus le volume est important et/ou la croissance est rapide, plus les cycles doivent tre rapprochs. Dans le cas de ce projet, il a t dcid de faire un cycle tous les ans. Le prochain aura donc lieu en septembre 2010.
56
Il faut savoir que cette opration (la rorganisation) navait jamais t entreprise depuis linstallation,
donc environ 7 ans.
Bolognesi Michel
25.08.2010
113/145
5.2
Rsultat aprs larchivage des documents

Larchivage des documents a dbut en octobre 2007. A lheure actuelle, il y a plus de
4 millions de documents, entre les factures et les relances, qui ont t intgrs dans le serveur de contenu. Le traitement qui permet dintgrer ces documents est fait de manire automatique tous les soirs et un technicien dexploitation contrle tous les matins le rsultat de cette excution. En clair chaque impression un fichier pdf est automatiquement gnr et le programme ZP_ISU_LOAD_FACTURE_PDF est planifi tous les soirs pour intgrer lensemble des documents crs dans la journe.
5.2.1
Reprise
Concernant les factures mises avant octobre 2007, Romande Energies a dcid de ne
pas entreprendre un projet de reprise pour plusieurs raisons : 1. Le temps de rimpression des factures est estim environ 3 mois de travail machine, sans compter le temps de prparation et dintgration. 2. Compte tenu de cet important temps de traitement il est utopique dexcuter la reprise dans le systme productif. Il a t tudi lventualit de crer un systme parallle issu dune copie de celui productif, mais cette alternative porte prjudice sur lintgrit des fichiers gnrs. 3. La mise en page des fichiers ne pourra pas tre identique loriginal En rsum leffort et les cots de reprise ne la justifie pas.
5.2.2
Gestion du cycle de vie

Le gestionnaire de contenu HTTP Content Server de SAP ne prvoit pas la gestion du
cycle de vie des documents. En clair, lorsque les factures et les rappels auront 10 ans, aucune fonction existante ne permettra de les dtruire. Dans ce but, il faudra soit migrer les fichiers pdf dans le gestionnaire de contenu Documentum comme cela a t prvu, soit dvelopper des programmes spcifiques pour ajouter cette fonctionnalit. Le client a environ 7 ans pour se dcider.
Bolognesi Michel
25.08.2010
114/145
V Conclusion
En conclusion de ce rapport, je souhaite faire un bilan de ce travail, partager quelques considrations personnelles concernant loutils SAP et enfin mentionner certains projets analogues qui mont permis dapprofondir et consolider les connaissances acquises.
Bilan du projet
Le Tableau ix ci-dessous tablit un bilan en fonction des objectifs et des attentes de ce
travail de diplme dingnieur (voir chapitre I3).
Objectif
Bilan
Dcouvrir le milieu de larchivage Ralis : la dcouverte sest concrtise par lectronique, son langage, ses pratiques et ltude de plusieurs ressources mises en son application de manire gnrale. annexe et par la participation plusieurs sminaires. Dcrire les outils propres au systme SAP Ralis partiellement : du point de vue du dans le domaine de larchivage de donnes, projet, aucun document na t remis au ainsi quun systme darchivage pour le client ; cependant, la partie III Principe de stockage des fichiers darchive. larchivage SAP de ce rapport de mmoire peut tre utilise pour faire cette description. Cibler les objets darchivage potentiels par Ralis : plusieurs analyses ont t faites une analyse des besoins techniques et pour cibler les objets darchivage au cours de fonctionnels tels que la volumtrie des ces annes. La dernire en date est celle donnes et les problmes de performances. dcrite dans le prsent rapport. Dfinir les besoins en termes de rtention de Ralis partiellement : en ce qui concerne la donnes et les contraintes lgales darchivage dfinition de la rtention des fichiers archives de donnes. selon les exigences lgales, cela peut se rsumer, dans le contexte, dix ans. Cependant, la dfinition du temps de rtention en ligne des donnes non techniques devra tre dfinie ultrieurement au cours du projet. Prsenter une structure de projet complte Ralis partiellement : la dfinition des avec les intervenants ainsi que les profils a t dcrite dans le chapitre IV1.6. responsabilits dans un projet darchivage Cependant, lattribution devra tre faite lors SAP. du lancement du projet.
Bolognesi Michel
25.08.2010
117/145
Raliser dans un premier temps une maquette dans le systme de qualit pour valider les concepts thoriques tudis. Raliser ensuite la mise en uvre de larchivage dans le systme productif en orchestrant tous les intervenants de la structure du projet prsent.
Pour ce qui concerne la maquette elle a t ralise il y a 4 ans dans le systme de qualit. Cependant elle a d tre dtruite, car tous les ans ce systme est rinstall par une copie de celui productif. Concernant la mise en uvre dans le systme productif, seul larchivage des objets techniques a t implment et de ce fait il peut tre considr comme partiellement ralis. Planifier lexcution priodique des lots de Partiellement ralis : la planification de programmes darchivage et larchivage lexcution priodique des objets techniques long terme. a t dfinie par une excution par an. Par contre, pour les autres objets, cette planification devra tre dfinie. dumas-00530235, version 1 - 28 Oct 2010
Tableau ix: bilan du projet
En rsum, lensemble des objectifs concernant la ralisation du projet a t partiellement atteint car le client, pour des raisons que lui sont propres, na toujours pas valid la mise en place de larchivage des donnes pour tous les objets non techniques. Dans une certaine mesure, je comprends sa position : alors que SAP prconise larchivage pour amliorer le temps de rponse des transactions, la rduction des cots dexploitation et une diminution dindisponibilit en cas de problme, certains de ces points ne se sont pas vrifis : La dgradation du temps de rponse des transactions est un levier trs significatif pour que les utilisateurs acceptent un projet darchivage. Malheureusement ou heureusement, cela dpend du point de vue, au cours de ces dernires annes, le temps de rponse moyen est rest pratiquement constant se situant entre 300 et 600 ms. Bien quil soit assez difficile mesurer, il ny a pas eu une consquente augmentation de temps dexploitation d la croissance de la base de donnes. Cependant, il a t relev que le temps de sauvegarde, il y a 5 ans, tait denviron 5 heures pour une base de donnes de 350 Go. A lheure actuelle, pour une base de donnes de 600 Go, cela prend thoriquement 7 heures. Ce temps est divis par deux car le processus dcriture sur bande magntique a t paralllis, cest--dire que lcriture de la copie de sauvegarde est faite sur deux bandes simultanment. Le temps dindisponibilit en cas de problmes est tributaire, dune certaine mesure, du systme de sauvegarde. En effet, le temps de restaurer la base de
Bolognesi Michel
25.08.2010
118/145
donnes est pratiquement identique celui de sauvegarde. Comme vu dans le point prcdent, grce la paralllisation sur deux bandes, le temps sest amlior. Cet ensemble de constatations tend prouver que dans le contexte de ce projet, les prconisations de lditeur allemand confortent la position du client. Cependant, il faudra tout mme archiver les donnes pour purger lensemble des objets dont les contraintes lgales nobligent plus la conservation, cest--dire partir de la onzime anne. Cela nest pas une contrainte clairement exprime dans le code des obligations, mais selon les dires de Matre Kronbichler,57 lors dun procs, le juge va exiger des justificatifs lentit si elle conserve des documents au-del du temps lgal.
2
Considrations personnelles
En conclusion, dans lensemble des environnements que jai pu analyser, larchivage
des donnes reste utile surtout pour la purge. Par contre, larchivage des documents du point de vue de SAP reste un atout trs intressant pour lier des fichiers des transactions. Toutefois, jestime que lHTTP Content Server de SAP nest pas adapt pour cette fonctionnalit car il nest pas utilisable dans un autre environnement que celui de SAP, il ne gre pas le cycle de vie du document et surtout il nintgre pas des fonctionnalits darchivage lgal. Un bon remplaant de ce gestionnaire de contenu pourrait tre Alfresco. Ce dernier, bien que Open Source, a toutes les fonctionnalits essentielles dun progiciel commercial tel que Documentum (dailleurs il a t conu par une quipe de ce dernier) ou OpenText. Dans ce but, je souhaite proposer lensemble de la direction de neo technologies SA, dont je fais dsormais partie, une solution cl en main. Cette dernire serait cible pour des petites et moyennes entreprises du secteur public et de la distribution et la vente dnergie qui souhaitent grer des documents autour de SAP. La solution devrait contenir un ensemble de fonctionnalits de base telles que le connecteur ArchiveLink, des paramtres et programmes spcifiques pour SAP ainsi que des programmes, un plan de classement, etc. pour Alfresco. Dsormais ce projet-ci est de la douce musique davenir et seul le futur en connat le refrain
57
Monsieur Stephan Kronbichler, avocat du cabinet Kronbichler & Tourette, spcialiste dans les
questions du droit commercial et de la tenue et la conservation des documents.
Bolognesi Michel
25.08.2010
119/145
Autres projets
Ltude et la formation de lenvironnement de larchivage et de la gestion des
documents ont donn le jour dautres projets. Certains sont en extension directe comme celui de PayNet, alors que dautres sont tout simplement de nouvelles implmentations comme larchivage de donnes chez Alcan, larchivage des documents chez ESB et la gestion des documents aux services industriels de Lausanne.
3.1
PayNet
Romande Energies SA a souhait ajouter les services offert par la socit PayNet58 la
solution darchivage des factures. Cela permet ses clients de payer leur consommation dlectricit via le portail de la banque virtuelle. dumas-00530235, version 1 - 28 Oct 2010 Dans une certaine mesure, PayNet est une bote aux lettres lectronique annexe aux services du portail de la banque virtuelle. Dans cette dernire est gr lensemble des factures dmatrialises que le fournisseur a envoy son client. Le client peut en quelques clicks de souris payer et grer les factures reues par ce biais (voir Figure 57). A lheure actuelle, en Suisse, ce service est propos par environ 90 banques et prs de 200 metteurs de factures et tous semblent tmoigner que cette tendance va augmenter.
Figure 57: exemple dun systme de payement par internet
58
PayNet (Schweiz) AG est une socit du Telekurs Group.
Bolognesi Michel
25.08.2010
120/145
Sans entrer trop dans les dtails de la solution PayNet, le processus de facturation tel que dcrit dans le chapitre IV3.2 reste identique (voir Figure 58). En effet, aprs le calcul de facturation, un fichier dchange est envoy de SAP vers le logiciel JetForm de la socit Cisel SA (1). Par ce logiciel, les factures sont mises en page (2) et un fichier pdf est gnr et stock dans un rpertoire partag (3). Un programme SAP contrle priodiquement ce rpertoire et intgre les fichiers dans le serveur de contenu (4) et (5). Un programme spcifique a ensuite t ajout pour envoyer la facture au format pdf et un ensemble de mtadonnes sur le portail de PayNet (6). PayNet publie cette facture pour que les clients puissent faire le payement directement par leur accs bancaire sur internet (7). Une fois que le payement est effectu, la banque envoie un acquittement SAP par le biais dun fichier (8).
Figure 58: intgration PayNet
3.2
Archivage de donnes SAP chez Alcan Aluminium Valais SA

Alcan Aluminium Valais SA est une socit appartenant au groupe Rio Tinto Alcan,
spcialis dans la transformation de laluminium. Leur site de production bas Sierre utilise le progiciel de gestion dentreprise SAP. Aprs plus de 10 ans dutilisation, ils ont constat dimportantes pertes de performances. Pour pallier ce problme, on ma mandat pour dfinir les primtres dun projet darchivage de data. Aprs analyse, jai pu constater que la base de donnes navait pas atteint une taille critique par rapport leur systme. Il sest avr que le problme tait caus par des dysfonctionnements dun relais rseau entre le site de production et lhbergeur des systmes.
Bolognesi Michel
25.08.2010
121/145
Malgr le rsultat de lanalyse, le client a souhait raliser un projet darchivage en trois phases : purge, ractivation des processus dj raliss dans le pass et dveloppement de nouveaux processus. Comme pour Romande Energie SA, jai mis en place plusieurs processus darchivage pour purger les donnes techniques. Lors de lanalyse, la surprise gnrale, jai remarqu que certains processus darchivages avaient dj t mis en place par une ancienne quipe du service informatique. Ma mission a t de documenter ces derniers, former et planifier le lancement de ces processus. En ce qui concerne la troisime phase, cest--dire paramtrer des nouveaux objets, le client a annul cette partie. dumas-00530235, version 1 - 28 Oct 2010
3.3
Archivage des documents ESB Bienne

Le service ESB (Energie Service Bienne) de la ville de Bienne distribue et vend de
llectricit, du gaz et de leau. Dans leur utilisation de SAP, ils ont souhait mettre en place la gestion par le gestionnaire de contenu HTTP Content Server de SAP des documents comme les factures, les relances et les courriers reus des clients. Ma mission a t de paramtrer et crer des programmes spcifiques pour lintgration de ces derniers.
3.4
Gestion des documents aux services industriels de Lausanne

Les services industriels de la ville de Lausanne commercialisent et vendent
llectricit, le gaz, le chauffage distance et leau. Dans leur utilisation de SAP, ils ont souhait mettre en place la gestion par le gestionnaire de contenu Alfresco des documents comme les factures, les relances et les photos de leurs articles en stock.59 Ma mission a t de paramtrer lArchiveLink, de dfinir le cahier des charges pour la cration dun connecteur ArchiveLink ainsi que celui pour les programmes dintgration.
59
Alfresco offre une vraie alternative Open Source pour la Gestion de Contenu d'Entreprise (ECM) -
Gestion de Documents, Collaboration, Gestion des Archives/Enregistrements lgaux, Gestion de Contenu Web et Gestion des Documents Numriss (voir http://www.alfresco.com/fr/).
Bolognesi Michel
25.08.2010
122/145
VI Annexes
1 ILM ou gestion du cycle de vie de linformation.
LILM (Information Lifecycle Management) est un concept lanc en 2003 par Legato dans une optique marketing et qui recle une porte bien plus grande et bien plus profonde quune appellation commerciale.
1.1
Dfinition
La SNIA (Storage network industry association) dfinit lILM comme lensemble de
rgles, processus, pratiques et outils que l'on dploie pour aligner au mieux la valeur mtier dumas-00530235, version 1 - 28 Oct 2010 des informations et l'infrastructure qui les hberge, et ce depuis leur cration jusqu' leur destruction !
1.2
Objectif
Lobjectif fondamental de lILM est de diffrencier les rgles de stockage selon la
valeur de linformation et dajuster au mieux les cots de stockage aux exigences de scurit, de conservation et de disponibilit des donnes. En plus, il cherche la convergence entre une gestion plus performante des infrastructures et des moyens de stockage, laide de la virtualisation et par lorganisation logique de linformation avec une structuration et une hirarchisation des donnes.
1.3
Dmarche
La dmarche consiste prendre en compte chaque information avec ses
caractristiques afin de dfinir des rgles communes et des classes de service pour lensemble des informations prsentant les mmes caractristiques. Ces caractristiques sont par exemple : Consultation : quand ? Par qui ? A quelle frquence ? Avec quelle urgence ? Confidentialit : droits daccs. Etat du document : fig, valid, sign etc. Dure de conservation : quelle est la dure de conservation ? Est-elle rvisable ? Unicit de linformation : quelle originalit de linformation ? Existe-t-elle ailleurs ? Pourrait-on la reconstituer ?
Il est important de remarquer que ces caractristiques voluent dans le temps et lILM doit en tenir compte pour proposer la meilleure formule chaque tape du cycle de vie de linformation.
1.4
Cycle de vie de linformation

Linformation numrique est mallable, cest--dire plus facile produire, plus facile
modifier et plus facile diffuser. Cependant, elle est aussi plus difficile protger et conserver. Malgr tout, elle a un cycle de vie avec les mmes tapes que le document traditionnel : Etape 1 : cest la phase de llaboration, donc modifiable jusqu' son approbation. dumas-00530235, version 1 - 28 Oct 2010 Etape 2 : cest la validation et elle devient fige. Etape 3 : ce stade elle est dite en maintenance dans le sens quelle est conserve ou/et archive pendant la dure de validit. Etape 4 : cest la fin de lutilit qui se traduit par une destruction ou par un transfert vers des collections patrimoniales.
Bolognesi Michel
25.08.2010
126/145
Nom du fichier logique

Le nom du fichier logique permet de crer des fichiers indpendants de la plate-forme
(Windows, Mac OS, etc..) et dans un emplacement du systme des fichiers. Ce dernier est dfini par la transaction FILE.
2.1
Cration dun chemin logique

Avant de pouvoir dterminer le nom du fichier logique, il faut au pralable dterminer
un chemin logique. Ce dernier dfinit un chemin (ou emplacement) indpendant de la plateforme o les fichiers logiques sont enregistrs. Les principaux paramtres sont (voir Figure 59) : dumas-00530235, version 1 - 28 Oct 2010
Figure 59 : Dfinition dun chemin logique
Chem. log. : cest le nom du chemin logique. Groupe synt. : il permet de choisir dans une liste droulante les systmes dexploitation supports par SAP. Chem. phys. : cest le chemin physique spcifique la plate-forme dans laquelle des fichiers sont enregistrs. Il doit contenir le mot rserv <FILENAME> comme caractre gnrique pour le nom de fichier. Par ailleurs, il peut contenir d'autres mots rservs pour indiquer dynamiquement des sousrpertoires.
2.2
Dfinition du nom de fichier logique

La dfinition du nom de fichier logique est faite par la dfinition des paramtres
suivants (voir Figure 60) :
Bolognesi Michel
25.08.2010
127/145
Figure 60 : Dfinition dun fichier logique
Fich. log. : nom du fichier logique. Fich. phys. : dfinition de la structure pour la cration du nom du fichier lors de lexcution. Comme pour le chemin logique, il est possible de lui associer un certain nombre de mots rservs. dumas-00530235, version 1 - 28 Oct 2010 Format donnes : il est possible de forcer le format du fichier gnr. Domaine fonct. : le domaine fonctionnel indique dans quelle application un nom de fichier logique est utilis. Au niveau fonctionnel, il ne joue aucun rle pour la cration des noms de fichiers spcifiques de la plate-forme. Chem. Log. : cest le nom du chemin logique prcdemment cr. Par la concatnation de ce dernier avec la dfinition du fichier logique, le systme peut crer un fichier dans un placement dfini.
2.3
Mots rservs
Voici une liste non exhaustive de mots rservs pour dfinir dynamiquement une
partie du chemin ou le nom du fichier: Mot rserv <SYSID>

<CLIENT> <PARAM_1> <PARAM_3> <DATE> <TIME> <SECOND>
Description Est le nom de linstance SAP. Est le nom du mandant Domaine fonctionnel (par exemple FI pour finance) Est le nom de lobjet darchivage Date lors de lexcution Heure minute lors de lexcution Seconde lors de lexcution
Bolognesi Michel
25.08.2010
128/145
HTTP Content Server de SAP

Le HTTP Content Server fourni par SAP est un gestionnaire de contenu bas sur un
serveur http60 (voir Figure 61).
Figure 61: exemple d'implmentation server HTTP content Server
Ce gestionnaire gre uniquement le flux des fichiers entrants et sortants en les classant dans une arborescence de rpertoires pour un accs rapide (voir Figure 62).
Figure 62: exemple d'arborescence du HTTP Content Server

60
Est un logiciel implmentant le protocole HTTP et ouvert aux connections provenant de l'extrieur
Bolognesi Michel
25.08.2010
129/145
Les fichiers peuvent tre comprims, crypts et un fichier data accompagne ces derniers avec un certain nombre dinformations (voir Figure 63).
Figure 63: exemple de fichier data
En conclusion, lHTTP Content Server de SAP reste un outil trs rudimentaire et conomique pour lier de fichiers annexes SAP. Ses principaux atouts sont : conomique (car il est fourni gratuitement avec les licences SAP), facile installer et administrer et parfaitement intgr avec lenvironnement SAP par le protocole ArchiveLink. Dailleurs, il est compltement inutilisable en dehors de cet environnement car, dune part, il est impossible de lui associer des mtadonnes et, dautre part, il est compltement dpourvu doutils indispensables comme la gestion du cycle de vie du document, le classement, les outils de recherche et de gestion des versions. Compte tenu de ces carences, lHTTP Content Server nest pas adapt la gestion lectronique des documents.
Bolognesi Michel
25.08.2010
130/145
Code source ZP_ISU_LOAD_FACTURE_PDF

Ce programme crit en ABAP61 (Advanced Business Application Programming)
permet de lire les fichiers stocks dans le rpertoire partag, de contrler la cohrence des ces derniers, de poster les fichiers dans le serveur de contenu et de crer les liens dans SAP.
*&---------------------------------------------------------------------* *& Report ZP_ISU_LOAD_FACTURE_PDF *& *&---------------------------------------------------------------------* *& Auteur: Michel BOLOGNESI *& Socit: neo technologies SA *&---------------------------------------------------------------------* *& Description: *& Intgration dans le Content Serveur des factures au format pdf. *& - Format des fichiers : <NumroDefacture><Date >.pdf *& <NumroDeFacture> : 12 positions numriques *& <Date > : format anglais -> AAAAMMJJ *& - Exemple fichier: 00100045667020060528.pdf *&---------------------------------------------------------------------*
report zp_isu_load_facture_pdf no standard page heading line-size 150 line-count 65(0) message-id e9.
*----------------------------------------------------------------------* * Dfinition des variables *----------------------------------------------------------------------* types: begin of ty_table, "Pour rcuprer les fichiers stocke dans le rpertoire
line(200) type c, end of ty_table.
data: data: data: data: data: data: data: data: data: data: data: data: data:
t_file type epsfili occurs 0 with header line. w_file type epsfili. w_path like epsf-epsdirnam. "rpertoire w_count like epsf-epsfilsiz. "Nombre de fichier lu dans le rpertoire w_date_ref like toav0-ar_date. Date w_no_facture like sapb-sapobjid. Numro de la facture w_err(1). "Retour de la form f_test_nom_file w_err_cs(1). "Retoutd e la form f_ctrl_doublon_tb_lien w_no_err type i. t_toaom like toaom occurs 0 with header line. w_file_arch(128) type c. "path + file pour archivage w_doc_id type toav0-arc_doc_id. Numro du document du content server w_cont type i.
61
L'ABAP est l'un des successeurs du COBOL et est apparu dans les annes 1980 dans la vague des
langages de quatrime gnration (4GLs). Il s'agit d'un driv du langage permettant de raliser des sorties de donnes (appeles rapports) de l'application SAP R/2, sur lequel de nombreuses multinationales avaient bti leur architecture d'application professionnelle. L'ABAP a par la suite t maintenu comme langage de rfrence pour les applications SAP R/3 qui sont apparues en 1992. Le langage a t par la suite tendu pour englober un modle de donnes orient objet (ABAP Objects) partir de sa version 4.5, pour tre finalement intgr comme langage d'un produit plus gnral appel NetWeaver. Ce dernier utilise aussi bien l'ABAP que le java. C'est un langage interprt. (voir wikipedia : http://fr.wikipedia.org/wiki/ABAP)
Bolognesi Michel
25.08.2010
131/145
*----------------------------------------------------------------------* * Variables de slection *----------------------------------------------------------------------*

parameter parameter parameter parameter p_path like epsf-epsdirnam obligatory default '\\ECM1\WORK\'. p_text as checkbox default 'X'. p_sapobj like toaom-sap_object no-display default 'PRINTDOC'. p_arobj like toaom-ar_object no-display default 'ISU_BILL'.
*----------------------------------------------------------------------* * Start *----------------------------------------------------------------------*

start-of-selection.
* Lecture du rpertoire et rcupration des fichiers
w_path = p_path. translate w_path to upper case. call function 'EPS_GET_DIRECTORY_LISTING' exporting dir_name = w_path importing file_counter = w_count tables dir_list = t_file exceptions invalid_eps_subdir = 1 sapgparam_failed = 2 build_directory_failed = 3 no_authorization = 4 read_directory_failed = 5 too_many_read_errors = 6 empty_directory_list = 7 others = 8. if sy-subrc <> 0. message i899 with 'Erreur lecture du rpertoire'. stop. endif. call function 'ARCHIV_METAINFO_GET' exporting ar_object = p_arobj sap_object = p_sapobj tables toaom_fkt = t_toaom exceptions error_connectiontable = 1 error_parameter = 2 others = 3. if sy-subrc <> 0. message e052 with 'TOAOM'. endif. loop at t_file into w_file where rc = '0000'.
* Recherche des tables de liens: voir transaction AOC3.
* * Traitement de tous les fichiers lu
Test si le fichier est correct
perform f_test_nom_file using w_file-name changing w_err. if w_err = 'N'.
Test si le fichier nest pas un doublon

perform f_ctrl_doublon_tb_lien using w_file-name changing w_err_cs.
if w_err_cs = 'N' and p_text <> 'X'. clear w_doc_id. concatenate p_path '\' w_file-name into w_file_arch.
Stocker le fichier dans le Content Server

call function 'SCMS_AO_FILE_CREATE_PATH' exporting
Bolognesi Michel
25.08.2010
132/145
mandt = arc_id = path = doc_type = no_delete = importing doc_id = exceptions error_http = error_archiv = error_kernel = error_config = others = if sy-subrc <> 0.
sy-mandt t_toaom-archiv_id w_file_arch 'PDF' 'X' w_doc_id 1 2 3 4 5.
write: / w_file-name(24), text-005, sy-subrc. add 1 to w_no_err. else. w_no_facture = w_file-name(12). w_date_ref = w_file-name+12(8).
text-005 : Erreur lors dpose fichier dans CS:
Cration lien Archivelink
call function 'ARCHIV_CONNECTION_INSERT' exporting archiv_id = t_toaom-archiv_id arc_doc_id = w_doc_id ar_date = w_date_ref ar_object = p_arobj mandant = sy-mandt object_id = w_no_facture sap_object = p_sapobj doc_type = 'PDF' exceptions error_connectiontable = 1 others = 2. if sy-subrc <> 0. add 1 to w_no_err.
write:/ w_file-name(24), text-006, sy-subrc. else. add 1 to w_cont. endif. endif. else. if w_err_cs <> 'N'. add 1 to w_no_err. endif. endif. else. add 1 to w_no_err. endif. endloop. new-line. uline. new-line. write: / text-008,' ', w_count. "Text-008: Nombre de fichier lu: write: / text-009,' ', w_no_err. "Text-009: Nombre d''erreur: write: / text-010,' ',w_cont. "Text-010: Nombre de factures intgrs:
text-006: Erreur cration lien Archivelink !
* Ecriture des rsultats
end-of-selection.
*----------------------------------------------------------------------* * FORMS : sous-programmes *----------------------------------------------------------------------* *&---------------------------------------------------------------------* *& Form f_test_nom_file *&---------------------------------------------------------------------* * Premier test de vrification de pertinence si le nom du fichier * est pertinent. *----------------------------------------------------------------------*
Bolognesi Michel
25.08.2010
133/145
form f_test_nom_file using w_nom changing w_err.
* Variables locales
data: data: data: data:
w_long type i. w_no_fact(12) type c. w_date type d. w_ext(4) type c.
w_long = strlen( w_nom ). w_no_fact = w_nom(12). w_date = w_nom+12(8). w_ext = w_nom+20(4). translate w_ext to upper case.
* Si le num facture est alphanumrique -> erreur *

if w_no_fact co '0123456789'.
Vrification si la date est valide
call function 'DATE_CHECK_PLAUSIBILITY' exporting date = w_date exceptions plausibility_check_failed = 1 others = 2. if sy-subrc <> 0. w_err = 'O'. write: / w_nom(24), text-002. else. if w_ext = '.PDF'. w_err = 'N'. else. w_err = 'O'.
Text-002: Date incorrecte !
Vrification si le fichier est un pdf
write: / w_nom(24), text-003. endif. endif. else. w_err = 'O'.
Text-003 : Ce n''est pas un fichier pdf !
write: / w_nom(24), text-001. endif. endform. "f_test_nom_file
Text-001 : Numro de facture incohrent !
*&---------------------------------------------------------------------* *& Form f_ctrl_doublon_tb_lien *&---------------------------------------------------------------------* * Vrification si le fichier est dj prsent dans le content * serveur. *----------------------------------------------------------------------*
form f_ctrl_doublon_tb_lien using w_nom changing w_err.
* Variables locales
data: data: data: data: data:
w_no_fact like toa01-object_id. w_date type d. w_date_ref type d. w_toa01 like toa01. w_tb_err like toaom-connection.
w_no_fact = w_nom(12). w_date = w_nom+12(8). clear w_tb_err.
* Vrif si le fichier existe dans les tables de liens
loop at t_toaom. select single * from (t_toaom-connection) into w_toa01 where sap_object = p_sapobj and object_id = w_no_fact. if sy-subrc = 0. clear w_toa01. select single * from (t_toaom-connection) into w_toa01 where sap_object = p_sapobj and object_id = w_no_fact and ar_date = w_date.
Bolognesi Michel
25.08.2010
134/145
if sy-subrc = 0. w_tb_err = t_toaom-connection. endif. endif. endloop. if w_tb_err is initial. w_err = 'N'. else. w_err = 'O'.
write: / w_nom(24),' ' , text-004, ' ', ' (',w_tb_err,')'. endif.
Text-004 : Fichier dj existant dans le content serveur !
endform.
"f_ctrl_doublon_tb_lien
Bolognesi Michel
25.08.2010
135/145
Exemple de programme de lecture des archives

Le code source ci-dessous est un exemple de lecture des fichiers archives issus de
lobjet BC_SBAL. A noter que dans le cadre de ce projet, ce programme na quun intrt pdagogique.
*----------------------------------------------------------------------* neo technologies SA * Michel Bolognesi *----------------------------------------------------------------------* Date: 28.10.2005 *----------------------------------------------------------------------* Description : Ce programme affiche les donnes archives des protocoles * dapplications (objet BC_SBAL). *----------------------------------------------------------------------REPORT z_archive_bcsbal . DATA: w_handle LIKE sy-tabix, w_record_type LIKE arc_buffer-rname, w_buffer LIKE arc_buffer-segment, w_balhdr_wa LIKE balhdr, w_number_of_records_read TYPE i.
* Tables internes ......................................................

TYPES: BEGIN OF w_donnee_type, lognumber LIKE balhdr-lognumber, "N de protocole object LIKE balhdr-object, "Nom de l'objet subobject LIKE balhdr-subobject, "Sous-objet extnumber LIKE balhdr-extnumber, "Identification externe aldate LIKE balhdr-aldate, "Date "Utilisateur aluser LIKE balhdr-aluser, altcode LIKE balhdr-altcode, "Code transaction END OF w_donnee_type. DATA: t_donnee TYPE w_donnee_type OCCURS 0 WITH HEADER LINE.
************************************************************************ * PROGRAMME PRINCIPALE ************************************************************************

START-OF-SELECTION.
* Lecture des archives
PERFORM f_lecture_archives. LOOP AT t_donnee. WRITE: / t_donnee. END LOOP.
* Affichage des valeurs lues
END-OF-SELECTION.
************************************************************************ * FORMS ************************************************************************ *&---------------------------------------------------------------------* FORM f_lecture_archives *&---------------------------------------------------------------------* Lecture des donnes archives *----------------------------------------------------------------------* Ouverture du fichier archive
FORM f_lecture_archives. CALL FUNCTION 'ARCHIVE_OPEN_FOR_READ' EXPORTING object = 'BC_SBAL' IMPORTING archive_handle = w_handle EXCEPTIONS
Bolognesi Michel
25.08.2010
136/145
OTHERS
= 1.
* Boucle pour trouver le prochain objet du fichier archive

DO. CALL FUNCTION 'ARCHIVE_GET_NEXT_OBJECT' EXPORTING archive_handle = w_handle EXCEPTIONS end_of_file = 1 OTHERS = 2. IF sy-subrc <> 0. EXIT. ENDIF.
IF sy-subrc <> 0. WRITE: / 'Aucun file archive trouv'(001). EXIT. ENDIF. CLEAR w_number_of_records_read.
Retour des valeurs lues
DO. CALL FUNCTION 'ARCHIVE_GET_NEXT_RECORD' EXPORTING archive_handle = w_handle IMPORTING record_structure = w_record_type record = w_buffer EXCEPTIONS end_of_object = 1 OTHERS = 2. IF w_record_type = 'BALHDR'. w_balhdr_wa = w_buffer. MOVE-CORRESPONDING w_balhdr_wa TO t_donnee. APPEND t_donnee. CLEAR: t_donnee. ENDIF.
IF sy-subrc <> 0. EXIT. ENDIF. ADD 1 TO w_number_of_records_read. ENDDO. ENDDO.
* Clture du fichier archive
CALL FUNCTION 'ARCHIVE_CLOSE_FILE' EXPORTING archive_handle = w_handle.
ENDFORM.
Bolognesi Michel
25.08.2010
137/145
VII Bibliographie
1. RIETSCH Jean-Marc, CHABIN Marie-Anne et CAPRIOLI Eric, Dmatrialisation et archivage lectronique, Dunod, 2006, 207 pp. 2. STEFANI Helmut, Archiving Your SAP Data, SAP Press, 2003, 334 pp.
Liens internet
Lensemble des liens internet ont t consults au cours des mois davril juin 2010. http://www.archives.ch/ : cest le site de la socit Archive & Plus SA. Cette socit est spcialise dans larchivage. Elle propose un certain nombre de documents concernant la lgislation et des recommandations sur larchivage du point de vue de larchiviste. www.adobe.com/fr/products/acrobat/pdfs/pdfarchiving.pdf Adobe PDF, norme darchivage . http://www.guideinformatique.com/dossier-archivage_et_sauvegarde-25.htm : Il y a plusieurs articles concernant larchivage surtout du point de vue Hardware. http://www.fedisa.eu/fedisa2007/ : ce site de la FedISA (Fdration de lILM, du Stockage et de lArchivage) propose plusieurs livres blancs intressants concernant : o Identification et authentification l're numrique - Enjeux et approches mthodologiques o Conserver les courriers lectroniques, ou comment rsoudre la problmatique de l'archivage des e-mails o Guide Pratique "Comprendre et utiliser les normes dans le domaine de l'archivage numrique" o Guide pratique du PDF/A http://www.ssi.gouv.fr : ce site de lANSSI (Agence nationale de la scurit des systmes dinformation) propose plusieurs documents concernant larchivage lectronique scuris (excellent rfrentiel des bonnes pratiques). o Archivage lectronique scuris Etat de lart o Cahier des charges pour un systme darchivage lectronique (sphre publique) trs : Livre blanc
Bolognesi Michel
25.08.2010
139/145
o Etc. http://www.bakom.admin.ch/themen/internet/00467/index.html?lang=fr signature lectronique. http://www.digitech-sa.ch/presse.php: dans ce site de Digitech SA on peut trouver plusieurs articles trs intressants consacrs diffrentes problmatiques de larchivage : o Conservation lectronique des documents dans les entreprises o La loi et la conservation lectronique des documents en Suisse o Conservation des factures et pices justificatives au regard de la TVA o Etc. dumas-00530235, version 1 - 28 Oct 2010 http://www.cines.fr/spip.php?article131 : brve description du modle OAIS (Open Archival Information System). http://www.figoblog.org/document1089.php : brve description du modle OAIS. http://www.aristote.asso.fr/PIN/presentations/2006/ILM.pdf prsentation concernant la notion de ILM. http://www.aproged.org/index.php/Voir-details/Publications/8-Memo-Lamaitrise-du-cycle-de-vie-du-document-numerique.html : Memo - La matrise du cycle de vie du document numrique http://help.sap.com/saphelp_erp2005/helpdata/fr/7c/aea63a9c69612fe10000000 a114084/frameset.htm : aide en ligne de SAP concernant les objets darchivage SAP. http://help.sap.com/saphelp_erp2005/helpdata/fr/d7/ad7c38ec757932e1000000 9b38f8cf/frameset.htm : aide en ligne SAP concernant le processus darchivage http://www.sdn.sap.com/irj/sdn/inf?rid=/webcontent/uuid/ef1b00f7-0a01-001074ab-e9260e80a441 : plusieurs documents mis disposition par SAP concernant larchivage de data. http://www.developpez.net/forums/d507979/logiciels/solutionsdentreprise/erp/sap/methode-asap-questionnaire/ : mthodologie ASAP. forum autour de la : brve Ceci est un lien vers le site de ladministration fdrale (suisse) sur le thme de la
Bolognesi Michel
25.08.2010
140/145
Support de cours SAP

BC 660, Data Archiving, 2001, 347 pp : notion de base concernant larchivage de donnes SAP. BC 615, SAP ArchiveLink, 2001, 358 pp: bases techniques concernant lArchiveLink de SAP et un survol des applications possibles. BC 670, Programming Display Fonctions, 2002, 225 pp : donne les bases ncessaires pour la cration de programmes personnaliss darchivage de donnes.
Bolognesi Michel
25.08.2010
141/145
VIII Liste des figures

Figure 1 : intgration des solutions mySAP ................................................................. 13 Figure 2 : modle en trois couches. .............................................................................. 15 Figure 3 : paysage systme ........................................................................................... 16 Figure 4 : fonctions du systme darchivage lectronique ........................................... 45 Figure 5 : Exemple darchitecture technique du SAE .................................................. 46 Figure 6 : dfinition ...................................................................................................... 51 Figure 7 : Principe darchivage .................................................................................... 52 Figure 8 : Exemple facture de dcompte ...................................................................... 54 dumas-00530235, version 1 - 28 Oct 2010 Figure 9 : Copie dcran dun objet darchivage (transaction AOBJ).......................... 55 Figure 10 : structure objet archivage ............................................................................ 56 Figure 11 : Liste des tables supprimes uniquement .................................................... 57 Figure 12 : exemple de dpendance entre objets .......................................................... 58 Figure 13 : liste des programmes pour la lecture des fichiers archives ........................ 58 Figure 14 : liste des transactions permettant de dfinir le temps de rsidence............. 59 Figure 15 : exemple de dfinition temps de rsidence ................................................. 59 Figure 16 : Liste des tables index ................................................................................. 59 Figure 17 : Copie dcran de la transaction SARA ...................................................... 60 Figure 18 : paramtres processus archivage ................................................................. 61 Figure 19 : Options techniques pour tous les objets archivage .................................... 62 Figure 20 : Options techniques spcifiques objets archivage ....................................... 63 Figure 21 Options de routage ....................................................................................... 65 Figure 22: tapes processus annexes ............................................................................ 67 Figure 23: gestion des archives .................................................................................... 68 Figure 24 : documents entrants et sortant entre SAP et dautres applications. ............ 69 Figure 25 : copie dcran de la vue lien pour Content Repositories . ..................... 70 Figure 26 : exemple dentre de la table type de document. ........................................ 71 Figure 27 : Vue de paramtrage du Content Repositories. ........................................... 72 Figure 28 : exemple dun tuple de la table dune table de lien..................................... 73 Figure 29: Table des liens............................................................................................. 75 Figure 30: feuille de route ASAP ................................................................................. 79
Bolognesi Michel
25.08.2010
143/145
Figure 31 : croissance de la base de donnes ............................................................... 81 Figure 32: Transaction DB15 ....................................................................................... 83 Figure 33: graphique de rseau..................................................................................... 84 Figure 34: rsultat d'analyse par le programme RARCCOA2 ..................................... 86 Figure 35: analyse de la table GLPCA par la transaction TAANA ............................. 87 Figure 36: Dpendance objet FI_MKKDUNN ............................................................ 89 Figure 37: dpendance objet FI_ACCRECV ............................................................... 90 Figure 38: dpendance objet ISU_PRDOCL ............................................................... 90 Figure 39: dpendances objet ISU_BILLZ et BILL..................................................... 91 Figure 40: dpendances objet ISU_FACTS ................................................................. 91 Figure 41: dpendances objet ISU_EABL ................................................................... 91 dumas-00530235, version 1 - 28 Oct 2010 Figure 42: dpendances objet ISU_BBP ...................................................................... 92 Figure 43: processus d'impression avant modification................................................. 99 Figure 44: processus de facturation aprs modification ............................................. 100 Figure 45: protection des fichiers pdf......................................................................... 101 Figure 46: structure du plan de classement ................................................................ 102 Figure 47: paramtrage spcifique ............................................................................. 106 Figure 48: suppression des relations IDC8................................................................. 106 Figure 49: intgration des pdf dans le HTTP Content Server .................................... 107 Figure 50: rfrentiel de contenu ................................................................................ 108 Figure 51: paramtrage du content repositorie ........................................................... 108 Figure 52: type de document ...................................................................................... 109 Figure 53: Cration de la table des liens .................................................................... 109 Figure 54: traitement des liens ................................................................................... 110 Figure 55: paramtres du programme ZP_ISU_LOAD_FACTURE_PDF ................ 110 Figure 56: exemple de visualisation dune facture pdf .............................................. 112 Figure 57: exemple dun systme de payement par internet ...................................... 120 Figure 58: intgration PayNet .................................................................................... 121 Figure 59 : Dfinition dun chemin logique ............................................................... 127 Figure 60 : Dfinition dun fichier logique ................................................................ 128 Figure 61: exemple d'implmentation server HTTP content Server .......................... 129 Figure 62: exemple d'arborescence du HTTP Content Server ................................... 129 Figure 63: exemple de fichier data ............................................................................. 130
Bolognesi Michel
25.08.2010
144/145
IX Liste des tableaux

Tableau i: Temps de conservation ................................................................................ 28 Tableau ii: croissance de la base de donnes................................................................ 80 Tableau iii: classement des 50 tables les plus volumineuses ....................................... 82 Tableau iv: correspondance table / objet darchivage .................................................. 85 Tableau v: temps de rsidence ...................................................................................... 94 Tableau vi: consultation des archives ........................................................................... 95 Tableau vii: rsultat aprs larchivage de test ............................................................ 112 Tableau viii: rsultat aprs le premier archivage productif ........................................ 113 dumas-00530235, version 1 - 28 Oct 2010 Tableau ix: bilan du projet .......................................................................................... 118
Bolognesi Michel
25.08.2010
145/145

Archivage de Données SAP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Archivage de Données SAP

Uploaded by

Copyright:

Available Formats

CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL ASSOCIE DE LYON Centre denseignement du pays de GEX ___________________

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

5 5.1 5.2 V 1 2 3 3.1 3.2 3.3 3.4

dumas-00530235, version 1 - 28 Oct 2010

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

I Premire partie : primtre du projet

Archivage de donnes SAP

Gnralit sur le PGI (progiciel de gestion intgr)

stockage, au traitement, au transport et la diffusion de l'information au sein d'une organisation. (Wikipdia)

Archivage de donnes SAP

PGI SAP en gnral

dumas-00530235, version 1 - 28 Oct 2010

Figure 1 : intgration des solutions mySAP

SAP ERP (Entreprise Ressource Planning)

SAP PLM (Product Lifecycle Management)

Rgulirement, lditeur allemand change et modifie la dnomination de ses produits. Cependant, le

contenu et les fonctionnalits deviennent beaucoup plus stables.

Archivage de donnes SAP

SAP CRM (Customer Relationship Management)

SAP SRM (Supplier Relationship Management)

SAP SCM (Supply Chain Management)

fournisseur du fournisseur au client du client.

Bus dintgration SAP NetWeaver

prsentation, application et base de donnes selon la figure 2.

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

Figure 2 : modle en trois couches.

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

Figure 3 : paysage systme

Implmentation de SAP Romande Energie

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010

dumas-00530235, version 1 - 28 Oct 2010

Archivage de donnes SAP

II Les concepts de larchivage lectronique

Selon norme NF Z42 013

Archivage de donnes SAP

de larchivage lectronique: donne, information, connaissance, dossier.

Archivage de donnes SAP

Droit suisse des socits

Archivage de donnes SAP

Disposition sur la conservation lectronique

Archivage de donnes SAP

informations archives sont spares des informations actuelles, ou sont

Archivage de donnes SAP

Spcificit concernant les factures et pices justificatives au regard de la TVA

Des exigences spcifiques rsultant de la lgislation et de la rglementation bancaire et de la loi

Archivage de donnes SAP

dumas-00530235, version 1 - 28 Oct 2010