La Gestion Electronique des Documents est un des nerfs centraux d’une entreprise, le but étant d’accéder à la majeure partie des données internes et clientèles rapidement et, aussi de pouvoir les conserver de manière sécurisée et fiable.

Situation initiale :

Lorsque j’arrive chez Aviva en 2010, une solution FileNet Image Services est en place mais cette dernière nécessite une mise à jour.

– FileNet Image Services est une solution logicielle qui s’appuie sur une base de données, qui permet des stocker les documents et annotations de manière sûre. Les documents sont stockés sur disque dur, un disque optique ou un NAS/SAN. Chaque document stocké sous FileNet possède des « attributs » tels que les ‘date d’entrée’, ‘taille’, ‘nombre de pages’ etc.. Or, ceux-ci sont non modifiables ; le document conserve ainsi son intégrité originelle.

Lorsque je travaillais pour IBM FileNet, 90% des grandes entreprises mondiales utilisaient une des solutions proposées.

Aviva utilise des versions de FileNet image services et de Oracle qui ne sont plus maintenues (Oracle 9.2.0.8). Aussi Aviva souhaite changer son mode de stockage.

Jusqu’à présent Aviva utilisait des disques optiques à haute densité (Ultra Density Optical Storage) où les documents étaient écrits de manière non modifiable (WORM). Ces disques sont gérés par une machine HP Storage Works appelée « Jukebox » car on y insère des disques ! Cette technologie est pourtant en fin de vie et l’idée est d’extraire les documents existants depuis les disques optiques et de les écrire sur un NAS où le WORM serait activé.

La deuxième étape est de faire la montée de version de la base Oracle de 9.2.0.8 vers 11.2.0.2 avec l’aide des DBA d’Aviva. Ensuite mon travail sera de monter la version de FileNet de quatre paliers (3.6.3 > 4.1.2).

Mise en œuvre :

La première étape a consisté à créer sous FileNet un nouveau type de stockage et donc une nouvelle classe de document, classe liée à un type de stockage défini. L’existant pointait vers des disques optiques 2.6GB : j’ai donc positionné l’attribut système afin de ne plus écrire sur du stockage optique déporté mais sur du stockage magnétique, un filesystème monté sur un NAS.

– OSAR : Optical Storage And Retrieval (optical jukebox)

– MSAR : Magnetic Storage And Retrieval (filesystèmes)

J’ai créé une classe de documents afin de stocker les nouveaux entrants. Il faut comprendre que la sécurité des documents de FileNet vient du fait que le logiciel ne stocke pas document par document mais il les regroupe dans un gros fichier de taille variable (ici 32GB) et seul FileNet peut en décrypter le contenu et les lire.

Ainsi, à cet instant, tous les nouveaux documents scannés ou envoyés seront sur du stockage filesystème, dans des fichiers de 32GB et lisibles uniquement par FileNet.

FileNet offre une solution pour extraire et copier les documents : il suffit de sélectionner cette action, de saisir le numéro de disque optique (numéro unique) et de choisir la ‘famille de destination’, famille que j’ai créée précédemment dans laquelle j’ai choisi du stockage filesystème.

J’ai été obligé de répéter cette action sur plusieurs semaines car la lecture et l’extraction depuis des disques optiques sont lentes et la totalité représentait environ 60 millions de documents électroniques. Après plusieurs semaines de copies, je me trouvais dans la situation suivante:

– Les nouveaux documents étaient maintenant écrits sur du filesystème

– L’historique avait bien été migré vers du filesystème, chaque gros fichier de 32GB portant le nom de son ancien disque optique.

Tous les documents sont dorénavant tous sur du stockage filesystème.

Migration :

La migration s’est déroulée sur un week-end entier où le samedi était réservé aux DBAs qui ont upgradé la base de données de FileNet et 9.2 vers 11.2.0.2 en trois paliers. J’ai les ai assistés pour cette mise à jour car elle comportait deux parties distinctes :

– La mise à jour des binaires (noyau Oracle)

– Le DB upgrade, mise à jour des tables, des vues et des index.

J’ai effectué cette seconde partie car FileNet propose un outil permettant de le faire, tout en étant néanmoins sous la surveillance des DBAs.

Le dimanche j’ai commencé par un backup particulier. Bien que nous ayons des sauvegardes légales quotidiennes, j’ai préféré faire une sauvegarde hors planning afin de ne pas corrompre – potentiellement – une sauvegarde légale. Ceci finalisé, j’ai arrêté le logiciel et ai commencé la procédure de migration dont la première étape était de faire un  « check« . Là encore, « l’installer » FileNet propose de vérifier si tous les critères requis pour la mise à jour sont validés.

Une fois ces critères validés, j’ai lancé la mise à jour des binaires, cette opération n’est pas très longue car les binaires pèsent environ 1GB. Suite à cette mise à jour de version majeure, j’ai appliqué les derniers service pack disponibles.

Puis j’ai redémarré physiquement la machine AIX. Pour la suite de la configuration il a fallu indiquer à FileNet que Oracle avait changé de version et, pour ce faire, j’ai lancé un « setup » en ligne de commande :

fn_setup
Is this the NCH server (1=yes, 2=no) [1]:ENTER
Enter NCH server name [Junior:FileNet]: ENTER
Enter system serial number [1100210409]: ENTER
Enter the relational database type configured on this server
        (0=None, 1=Oracle, 2=DB2) [1]: ENTER
Enter the relational database home directory [/applics/ora9208]: /applics/ora11202/11.2.0  <<
Enter the relational database user ID [ora9208]: ora11202  <<
Enter the relational database group ID [dba]: ENTER
Enter the relational database ID [idbIT]: ENTER
          This is the setup configuration:
                    NCH server name: 
                    Relational database type:  oracle
                    Relational database home:  /applics/ora11202/11.2.0
                    Relational database user ID:  ora11202
                    Relational database group ID:  dba
                   Do you want to continue (y/n) [y]:
fn_setup: Creating file /fnsw/local/setup_config
fn_setup: Creating file /fnsw/local/sd/root_station
fn_setup: Creating file /fnsw/local/ssn
fn_setup: Creating file /fnsw/local/sd/nch_domain
fn_setup: Changing permission on FileNET IS software and databases
fn_setup: Installing Image Services license.
Successfully installed license data !
fn_setup: Changing permission on FileNET IS software and databases

Maintenant que FileNet sait que son $HOME Oracle a changé, il est temps de mettre à jour les tables, les vues, l’index Oracle, si besoin :

RDBMS type: Oracle
RDBMS location: local
RDBMS configured for IS: Site-controlled
Enter the relational database home directory [/applics/ora11202/11.2.0]:  <<
Enter the relational database version, please use numeric format combined with character « . »: 11.2.0.2 <<
f_maint password updated in rdbup.bin …
User f_maint has a good password.
f_sw password updated in rdbup.bin …
User f_sw has a good password.
f_sqi password updated in rdbup.bin …
User f_sqi has a good password.
f_open password updated in rdbup.bin …
f_open .fmaint file entry being cleared …
User f_open has a good password.
Running script to grant user permissions <<
User f_sw has a good password.
Procedure created. <<
Procedure created.
Procedure created.
Procedure created.
Grant succeeded.
Grant succeeded.
Grant succeeded.
Grant succeeded.
/fnsw/bin/oraupgrade_sp: Processing completed.
/fnsw/bin/fn_set_rdb_privileges: Processing completed.
Execution complete.

A ce stade, FileNet est prêt à être démarré. Cela s’est déroulé sans heurts et les versions ont bien été prises en compte :

#fn_util whichfn
AIX Base OS Release:

        6.1.0.0
Oracle RDBMS Release:

        Local Site-controlled, 11.2.0.2
FileNet Image Services Release:

        4.1.2 Fix Pack 18
#

A ce jour cette version est toujours en production, seule la version du service pack a changé. Nous devrons faire à nouveau ce type d’opération courant 2016.

Bilan :

Aviva a pris la décision de me recruter pour diverses raisons et, parmi elles, on retrouve ma maîtrise de la langue anglaise, mes compétences en matière de stockage ainsi que mes 30 certifications FileNet.

La GED est critique pour une entreprise et plus particulièrement pour une compagnie d’assurance : si celle-ci connaît un dysfonctionnement, la totalité des comptes clients devient indisponible et les salariés, dans leur immense majorité, ne peuvent travailler. Ce sont pour ces raisons que Aviva a fait le choix d’avoir, en interne, un collaborateur capable de prendre en charge ces plateformes sans aide extérieure.

Compétence : G.E.D

Compétence : système Unix

Compétence : gestion de projet

Réalisations techniques