Duplication d'une instance ONYX Server Linux

Introduction

Cette procédure s'applique dans les cas suivants

• Montée de version, même mineure (hors mise à jour corrective)
• Migration de l'instance Mapping vers un autre serveur
• Duplication pour mise en place d'un serveur de backup
• Mise en place d'une architecture Haute Disponibilité (HA)

Ce document présente la trame générale permettant de réaliser la duplication d'une instance Mapping source vers une instance Mapping cible installée sur un autre serveur. Cependant, les spécificités de certains environnements peuvent nécessiter une étude et une réflexion plus approfondie.

D'autre part, si l'environnement existant ne s'appuyait pas sur la technologie "XPS", la mise à jour doit être considérée comme un projet à part entière, même si la reprise des maquettes existantes peut se faire mécaniquement et permettre ainsi un gain de temps dans la mise en place de la nouvelle solution.

Remarque : Dans le cadre d'une mise à jour, nous attirons votre attention sur le fait qu'il ne faut en aucun cas modifier l'environnement de production, même en faisant une sauvegarde au préalable.

Pré-requis

L’ensemble du paramétrage de la solution doit être parfaitement connu et identifié.

Si des bases de données ou des applications externes sont utilisées avec Mapping, leurs chemins d’accès doivent être identiques (exemple : appel d’un script *.sh dans un Workflow ou une tâche planifiée du serveur).

Profil utilisateur

Les manipulations nécessitent d'avoir un accès root sur la machine cible pour l'installation du produit.

Eléments à rassembler avant de commencer

Le client doit avoir une bonne connaissance de son environnement. Pour cela, il devra être capable de :

• Définir les documents clés devant être testés par MAPPING ou un de leurs partenaires certifiés
• Connaitre et retrouver les fichiers de données (texte ou xml) bruts pour chacun des documents
• Retrouver les projets Designer(.mpi, mpp et mpw) pour chacun des documents ainsi que leurs composants éventuels
• Retrouver les projets Connect(.src) pour chacun des documents
• Faire un état des lieux des règles ou workflows utilisés
• Faire un état des lieux des files d'attentes du spooler (imprimantes, points d'entrée ou de traitement, sites...)
• Retrouver les éventuels scripts (cmd ou shell) spécifiques appelés en amont, en cours de traitement, ou en aval de Mapping
• Avoir des exemples PDF ou papier de chacun des documents
• Lister les différentes sources applicatives (ERP, Progiciels etc...) connectées à Mapping

Tous les fichiers sources devront être classés dans des répertoire de façon méthodique : un répertoire par document par exemple.

Remarque : Un chiffrage d'upgrade pourra alors être réalisé par MAPPING.

ATTENTION : Si ce prérequis n'est pas respecté, un audit pourra être réalisé par Mapping ou un partenaire certifié Mapping pour reprendre la main sur l'environnement et en identifier tous les éléments importants.

Mapping ou Partenaire Mapping certifié : prendre connaissance de l'environnement du client

1. Vérifier si MAPPING est configuré en UNICODE ou non UNICODE
2. Vérifier si le format pivot "XPS" est mis en oeuvre (partiellement, ou totalement)
3. Valider que la configuration (mapping.conf) soit la même sur l'environnement de production actuel que sur l'environnement cible

Vue d'ensemble de la procédure de duplication

Toute la configuration de Mapping ONYX Server est stockée sous forme de fichiers (aucune base de données n’est requise pour l’utilisation de Mapping). La procédure de migration d’un serveur à un autre est donc relativement simple, et consiste essentiellement à de la copie de ces fichiers. Il convient néanmoins de respecter les étapes suivantes.

Le déroulement de la mise à jour d'ONYX Server Linux se compose des points suivants :

1. Déterminer la meilleure stratégie de bascule de l'environnement de production actuel vers l'environnement cible.
   • Celle-ci dépend de la méthode d'injection des travaux dans mapping, à savoir
     • Injection des travaux directement dans le spooler (via le protocole LPR ou l'appel d'un WebService) pour réaliser un traitement asynchrone.
     • Utilisation des robots "scanfolder".
     • Invocation des binaires mapping directement par l'application métier.
     • Appel d'un WebService avec traitement synchrone.
     • Plusieurs méthodes différentes selon le type et l'origine des travaux à soumettre.
2. Installation d'un environnement cible avec version de destination ONYX Server.
3. Copie du paramétrage de l'environnement de production sur l'environnement cible
4. Déroulement des tests sur le nouvel environnement cible
5. Passage en production
6. Rollback en cas de problème
7. Troubleshooting

Installation de la nouvelle instance Mapping cible

Pour l'installation du serveur, se référer à la documentation suivante : Installation ONYX Server pour Linux

Idéalement, dans le cas où l'installation est réalisée sur un serveur différent, il est préférable de choisir le même chemin d’installation et de conserver la même arborescence, afin de faciliter les copies et reprises ultérieures. Bien entendu, les informations inhérentes au serveur devront être différentes (adresse IP...).
Cependant, dans le cas d'une installation sur le même serveur, les chemins et les ports spécifiés lors de l'installation (http, spooler et lpd ) devront être différents de la ou des instances déjà présentes sur le serveur (ex : /apps/mapping_bis et ports 8003, 2001, 516)

Ces informations peuvent être retrouvées, sur l'instance Mapping source, dans le fichier de configuration de Mapping "mapping.conf".

Activer le logiciel sur la nouvelle instance Mapping cible (clés logicielles).

Duplication de la configuration

Dupliquer toute la configuration et le paramétrage Mapping de l'instance Mapping source vers l'instance cible, par simple copie des fichiers et/ou dossiers suivants.

• Les chemins indiqués ci-après sont ceux par défaut pour une installation du logiciel dans le répertoire de base « /apps/mapping» (variable PATH_BASE_MAPPING dans le fichier de configuration mapping.conf). Il faut donc veiller à remplacer les chemins et noms de l'administrateur par ceux choisis lors de l'installation du serveur B.

• Les fichiers de configuration suivants, situés dans le répertoire de configuration de Mapping, ne doivent surtout pas être copiés du serveur source vers le serveur cible

• mapping.conf : fichier de configuration de Mapping. Les modifications effectuées dans ce fichier doivent être reprises une à une, par comparaison des 2 fichiers.
• mapkey.txtet ucinfo.txt : fichiers de clés logicielles, dépendants de chaque serveur.
• /apps/mapping/map400/key : ce sous-répertoire contient les fichiers des recharges de page, dépendants de chaque serveur.

Fichiers à copier tels quels

• "/apps/mapping/conf/queues/*" : déclaration des files d’attente dans le Spooler Mapping (chown -R mapadmin:mapadmin / chmod -R 775)

• "/apps/mapping/conf/XPSConfig.conf" : déclarations des profils de conversion des documents XPS, notamment pour l’impression (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/conf/maprawd.conf" : déclarations de robots "Serveurs d’écoute Raw" (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/conf/GROUPS.conf" : déclarations de groupes d’utilisateurs Mapping (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/conf/USERS.conf" : déclarations d’utilisateurs Mapping (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/MapHTTPServer/.htpasswd" : utilisateurs pouvant s'authentifier via Apache (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/MapHTTPServer/.htgroup" : groupes d'utilisateurs Apache (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/conf/viewSettings.conf" : déclarations des différentes méthodes de visualisation des spools dans le Spooler Mapping (chown mapadmin:mapadmin / chmod chmod 664)

Fichiers à copier avec éventuelle modification au préalable pour adapter les chemins

• "/apps/mapping/conf/robot.conf" : déclarations de robots "Scanfolder" (chown mapadmin:mapadmin / chmod chmod 664)
• "/apps/mapping/conf/exportSettings.conf" : méthodes de déploiement d’un serveur à un autre (chown mapadmin:mapadmin / chmod chmod 664)

Duplication des Formats Designer et Connect

• "/apps/mapping/map400/*" : objets Mapping décrivant tous les formats Connect et Designer en production (chown -R mapadmin:mapadmin / chmod -R 775)

• /apps/mapping/import/lgobitmap/* : ressources externes (images, XPS, traductions) utilisées dans les formats Designer (chown -R mapadmin:mapadmin / chmod -R 775)

Autres duplications éventuelles

• "/apps/mapping/conf/menu/*.auth" (sous-répertoires inclus) : habilitations d'accès aux menus (attention en cas de changement de version, la hiérarchie des menus peut différer) (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/spool/logs/*" : Répertoire des logs du Spooler Mapping (optionnel, car elles peuvent être considérées comme propre à chaque serveur) (chown mapadmin:mapadmin / chmod chmod 664)

• "/apps/mapping/spool/global/*" et "/apps/mapping/spool/queues/counter.splf" : Répertoires des travaux du Spooler Mapping et son compteur de numérotation (chown mapadmin:mapadmin / chmod chmod 664)

Suivant la mise en oeuvre du produit, d’autres éléments peuvent être dupliqués, notamment des scripts appelés dans les Workflows de traitements Mapping, des tâches planifiées d’épuration ou de déclenchement de processus Mapping, etc. Ces éléments étant spécifiques à chaque client, ils ne peuvent être listés ici, et doivent impérativement être identifiés par l’utilisateur.

La gestion des maquettes de Mapping Designer

Toute modification de maquette (lié à une modification souhaitée ou un delta suite à la mise à jour) sera alors réalisée avec un Designer ayant la même version que le server Mapping.
Une copie de tous les projets Designer et Connect devront être effectués avant toute modification par une version plus récente de Designer et Connect.

Migration SIMPLE : copie simple de maquettes

Cette méthode n'est possible que si toutes les maquettes sont déjà en XPS.
Il s'agit d'une simple copie de fichiers ressources afin de copier les formats Designer, tels que décrit ci-dessous (copie du répertoire map400 et lgobitmap). Les maquettes ne sont pas re-générées.

Résolution des incidents

Si des écarts sont détectés sur le composition des documents (Designer), le projet devra être re-généré avec la dernière version Designer adapté à la version du serveur.

A ce moment-là, nous avons deux choix possibles :

1. La re-génération permet de résoudre le bug (avec ou sans modification de la maquette) Aucune autre action n'est requise. Il faudra juste bien classer les fichiers sources du projet (mpi, mpp et mpw) dans un répertoire afin de savoir rapidement que celui-ci a été ouvert et généré avec la nouvelle version de Designer.
2. La regénération ne permet pas de résoudre le bug. Dans ce cas, il faut apporter les modifications nécessaires à la maquette afin de corriger les problèmes rencontrés.

Migration AVANCÉE : Re-génération de toutes les maquettes

Ce type de migration impose la re-génération de toutes les maquettes, avec passage en XPS si ce n'est pas déjà le cas.

Regénération des projets Designer

1. Installer le dernier setup de Designer (correspondant à la version de votre nouvelle installation du serveur)
2. Ouvrez chaque maquette et générer manuellement en code page 1200 et dans le langage XPS sur le nouveau serveur
   

Remarque : Si les maquettes sont déjà au format de génération XPS, il est possible de scripter leurs générations. Pour cela, il faut:

1. identifier pour chaque projet, leur type de fichier en entrée (XML et SPOOL texte) ) et les ranger dans des dossiers séparés par type de fichier en entrée
2. Exécuter le script suivant qui permettra de lancer automatiquement la génération

"C:\MAPPING\M-Designer\M-Designer.exe" "-Generate" "-ProjectFile:%%X" "-Hide"

A savoir : Les chemins devront être changés en fonction de votre contexte.

Résolution des incidents

Selon le problème :

1. Alignements de zones :
   • Modifier la maquette pour que l'alignement de zone soit OK en preview. Valider que le document final (imprimé, PDF, etc) soit cohérent par rapport à la preview
     
2. Codes à barres :
   • Problèmes d'alignements : Vérifier la preview sur la maquette et corriger la maquette si besoin
   • Problème de labélisation : Cocher ou décocher le label du code barre (propriétés de la zone Code barre)
     

Si les modifications de la maquette ne sont pas concluantes, un ticket devra être ouvert au support MAPPING. Il faudra juste bien classer les fichiers sources du projet (mpi,mpp et mpw) dans un répertoire afin de savoir rapidement que celui-ci a été ouvert et généré avec la nouvelle version de Designer.

Phase de tests

Cas des tests exécutés de façon interactive.

Le principe est d'exécuter chaque commande manuellement pour chacun des fichiers en entrée et chacune des maquettes à tester.

Passage en production

La bascule de la production sur le nouvelle environnement B sera réalisée lorsque le client aura validé à l'écrit tous les documents.

Une fois la validation client réalisée, il est temps de passer en production. Selon la technique d'injection des fichiers dans Mapping utilisée, il est possible de faire un passage en production progressif (par site, par applicatif...) en modifiant un à un soit les dépôts de fichiers dans les différents dossiers pris en charge par les robots scanfolder, soit en modifiant les scripts côté applicatif permettant d'envoyer les travaux dans les files d'attente du spooler Mapping...

Troubleshooting

Problème 1 : Vous constatez un écart sur un document entre celui produit à l'aide de l'ancienne version (avant upgrade) et la nouvelle (après upgrade)

• Solution : Consulter la marche à suivre ci-dessus selon le type d'upgrade choisi