Duplication d'une instance ONYX Server Linux

Introduction

Cet article décrit le processus permettant de mettre à niveau un environnement ONYX Server sur le même ou sur un autre serveur Linux.

Déroulement de la mise à jour

Tout d'abord, 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.

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.
  • Elle 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

• 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

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.

Prérequis client

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 leur 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

Important : Les polices utilisées doivent être au format TTF (toutes autres types de polices devront être remplacés par des polices TTF par le client)

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.

Prise en main de l'environnement de client

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

Installation

Récupérer le dernier Setup disponible

Récupérer le dernier setup mis à disposition par Mapping.

Installer le produit sur un nouveau serveur ou dans un autre dossier du serveur de production

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

ATTENTION : dans le cas d'une installation sur un serveur hébergeant déjà Mapping, les ports http, spooler et lpd devront être différents des ports déjà utilisés par la ou les autres environnements Mapping

Paramétrage de l'environnement (Selon choix de type de migration)

Qu'importe le type de migration choisi (listé ci-dessous), les tests doivent être réalisé sur le nouvel environnement nouvellement installé

En aucun cas l'environnement de production ne doit être modifié. Cet environnement de production devra resté intacte durant tout le long de la migration et au delà.

Type SIMPLE : Copie simple de maquettes

Ce type consiste à une simple copie de fichiers ressources afin de copier les formats Designer, Connect ainsi que les Workflows et les définitions de queues du spooler. Les maquettes ne sont pas re-générées. Cette méthode n'est possible que si toutes les maquettes sont déjà en XPS.

Etape 1 : Copie des formats Designer et Connect

Copier toute l'arborescence conf/map400

Etape 2 : Copie de la définition des file d'attentes (imprimantes et points d'entrée)

Copier toute l'arborescence conf/queues

Etape 3 : Copie des règles de workflow

Copier toute l'arborescence conf/rules :

Etape 4 : Copie des ressources spécifiques du Designer

Copier toute l'arborescence import/lgobitmap :

Ce dossier comprend notamment les images dynamiques (logos), les fichiers XPS pouvant être utilisés par les maquettes, les fichiers de traductions et de remplacement de données.

Gestion des bugs sur un document

Aucun bug détecté

Rien de particulier. Il faudra bien que le client range leurs fichiers sources Designer (mpi, mpp et mpw) de façon à les retrouver façilement.

Conseil : Créer un répertoire par maquette avec le fichier d'entrée en .txt ou .pag s'il s'agit de fichiers textes paginés (équivalent SPOOL sur AS400) ou .xml s'il s'agit de fichiers xml.

Gestion des bugs détectés

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.

Type AVANCÉ : 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

for %%X in ("[Dossier contenant les sources de Designer]\docpc\*.mpp") do ("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)

Gestion des bugs sur un document

Aucun bug détecté

Le client pourra continuer d'utiliser leur document tel quel.

Gestion des bugs détectés

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)
   3. A compléter

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

1. Les corrections de la maquette corrige bien les problèmes (Preview et sortie cohérents) : Rien d'autre n'est à faire.

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.

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

Attention : La correction se fera uniquement en UNICODE.

Gestion des cas particulier

Les 3 types définis ci-dessus sont de façon générale toujours vrai. Cependant il peut exister quelques cas particuliers :

Passage partiel en XPS

Pour plusieurs raison, un client peut passer en XPS uniquement sur quelques documents. Voici quelques besoins pouvant nécessité cela :

1. Simplifier la gestion des maquettes pour un document donné car celui-ci a trop de maquette (La maquette en XPS pouvant gérer tous les langages)
2. Besoin de post traitement plus important pour un document :
   1. Fusion du document avec d'autres documents Mapping ou autres
   2. Conversion d'un flux vers un autre (PDF vers XPS et ensuite concaténation avec un autre document par exemple)
   3. Autres

Utilisation de flux thermique (Zebra, TEC)

Il est fortement conseillé par Mapping de passer les maquettes thermiques en XPS. Les raisons principales sont :

1. Aperçu Designer et impression finale bien plus fiable en XPS qu'en natif
2. XPS to TEC ou ZPL plus fiable et intuitif en XPS

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.

Validation

La mise à niveau finale de l'environnement de production sera réalisée lorsque le client aura validé à l'écrit tous les documents.

Passage en production

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