Duplication d'une instance ONYX Server Linux

Procédure de duplication d'une instance ONYX Server Linux

Cette procédure s'applique dans les cas suivants

• Upgrade vers une nouvelle 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 permet de guider un utilisateur expérimenté du logiciel pour dupliquer une instance Mapping (A) vers une instance Mapping (B), que ce soit sur le même serveur ou non.
Il présente la trame générale permettant de réaliser la duplication d'un environnement Mapping. 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.

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

- Avoir des droits d'accès root pour l'installation du produit

Eléments à ressembler

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

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

Dans Mapping, toute la configuration est stockée sur 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 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 :

• 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 le protocole LPR ou via 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 à la fois selon le type et l'origine des travaux à soumettre.

• Installation d'un environnement cible avec version de destination ONYX Server.
• Copie du paramétrage de l'environnement de production sur l'environnement cible
• Déroulement des tests sur le nouvel environnement cible
• Passage en production
• Rollback en cas de problème
• Troubleshooting

Procédure détaillée

Installation de la nouvelle instance Mapping B

• Installer la nouvelle version d'ONYX Server: Installation ONYX Server

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 A, dans le fichier de configuration de Mapping "mapping.conf".

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

Puis récupérer toute la configuration et le paramétrage Mapping de l'instance A sur l'instance B, par simple copie des fichiers et/ou dossiers suivants.

Les chemins indiqués ici sont ceux par défaut pour une installation du logiciel dans le répertoire de base « /apps/mapping » (variable PATH_BASE_MAPPING du fichier de configuration). Dans le cas de modifications de droits, cette documentation considère que l'administrateur est "mapadmin" dans le groupe "mapadmin". Il faut donc veiller à remplacer les chemins et noms de l'administrateur par ceux choisis lors de l'installation du serveur B.

Duplication de la configuration

Attention

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

• 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.txt et 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

• "/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/robot.conf" : déclarations de robots "Scanfolder"

(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)

• "/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 l’utilisation globale de la solution, 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 projets 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 qu'ONYX Server.
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.
Ce type consiste à 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

Bugs détectés sur le composition des documents (Designer)

Le projet Designer 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)

Rien d'autre n'est nécessaire. 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 résoud pas 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.

Etape 1 : 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 Le type de fichier en entrée est paramétré grace au paramètre XXXXXXXXXXXXXX (A terminer) Le language de génération est paramétré grace au paramètre YYYYYYYYYYYY (A terminer)

Résolution des incidents

Bugs détectés sur le composition des documents (Designer) 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. Code barre :
   1. Problèmes d'alignements : Vérifier la preview sur la maquette et corriger la maquette si besoin
   2. Problème de labélisation : Cocher ou décocher le label du code barre (propriétés de la zone Code barre)

1. 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