Best practices

Installing the server

• Using the local loop: With the exception of special cases, the IP address of the Mapping server defined during installation must always be 127.0.0.0.1 or localhost. These addresses are always true, even if the Mapping environment is migrated to another server, or if its IP address changes.

Configuring the server

• Cleaning and purging: Refer to the operating guide to set up a systematic cleaning and purging strategy for jobs, temporary files, and log files.

Interface d'administration

• Paramétrer des bannières d'identification : Jusqu'à la version 8.0 de Mapping, il était vivement recommandé de modifier le fichier Haut.html et index.html afin d'ajouter une bannière permettant d'identifier visuellement l'environnement Mapping courant.
  

Depuis ONYX 9.0, ces bannières se paramètrent directement dans le mapping.conf via GUI_DISPLAY_ENVIRONMENT_LABEL et GUI_DISPLAY_ENVIRONMENT_COLOR.

Designer

• Nom des projets : FORMAT_SEQUENCE (exemple : FACTURES_00010.mpp).
  

Un éventuel complément commentaire peut être ajouté à la suite (exemple : FACTURES_00010_Factures-Clients.mpp). Mais dans tous les cas, il est important que les 20 premiers caractères du nom du projet soient discriminants.

Une bonne pratique consiste à créer un sous-dossier par projet, contenant les fichiers sources du Designer et de Connect, les composants, les éléments variables et les fichiers txt ou xml d'exemple.

• Pas de calculs : Eviter de faire des calculs directement dans M-Designer. Privilégier les calculs en amont (ERP, M-Connect...)

• Zones mémoire TEXTE : Si aucun calcul n'est requis, les zones de type "Mémoire" doivent toujours être de sous-type "Mémoire Texte" et jamais "Mémoire Entier" ni "Mémoire Flottant" (même si les champs manipulés sont numériques)

• Espacement AVANT : Lors de la création de groupes, gérer les sauts de lignes avec les espacements AVANT. Les espacements APRES ne doivent être utilisés que pour ajouter un espace libre avant l'impression de la ligne suivante. Ne jamais écrire dans un espace réservé par une autre ligne (c-a-d par la ligne précédente ou par la ligne suivante), chaque ligne ayant son propre espace défini par "Espacement AVANT + Espacement APRES".

• Sauts de pages automatiques : Ne jamais utiliser plus d'un groupe pouvant générer un saut de page dans un projet (même avec des conditions de d'exécution).

Connect

• MAPPING_DATASTREAM=XML : Pour générer un fichier XML, il faut impérativement créer la variable DB.MAPPING_DATASTREAM et lui affecter la valeur "XML"

• Génération automatique de projets XML : Il est déconseillé d'utiliser la fonctionnalité de génération automatique de projets prenant en charge des fichiers XML en entrée. Le code généré est en effet complexe à maintenir. Il peut néanmoins être utilisé pour comprendre les principes de fonctionnement de CONNECT sur la lecture de fichiers XML.

Workflow

• Dev, recette et prod identique : Il est vivement conseillé de mettre en place des workflows 100% identiques entre les environnements de dev, de recette et de production. Les différences de traitements doivent être s'appuyer sur des paramètres d'environnement définis dans le fichier mapping.conf

Spooler

• Files d'attente dédiées : Créer des files d'attentes dédiées dès qu'il y a une communication avec l'extérieur (envoi par email, ftp etc...). Le traitement associé ne doit rien faire d'autre que cette communication, avec éventuellement quelques variables (SetParam) et des conditions. Mais ne jamais cumuler un traitement de fichiers (Connect, composition, manipulation de fichiers XPS...) et un envoi de mail ou dépôt ftp dans la même file d'attente.

• Traitements continus sans intervention : En général, les files d'attente qui exécutent des traitements (workflow, Shell etc...) devront être configurée afin de continuer le traitement des travaux suivants en cas d'erreur. La valeur par défaut (default) étant "Stop", ce qui provoque un arrêt des traitements en cas d'échec, nécessitant un acquittement de la part d'un utilisateur.

• Conserver les travaux : Ne pas oublier de "Conserver" les travaux envoyés dans les files d'attente à des fins de debug.

• Niveau de log : Pour des raisons de performances de traitements des travaux, ne jamais laisser le paramètre LOG_LEVEL à 4 en production. Sauf éventuellement si les performances ne sont pas un besoin majeur. Ce paramètre a énormément d'impacts sur les performances s'il y a beaucoup de "petits" travaux" à traiter. Dans ce cas, le niveau 3 peut également être trop élevé, et le niveau 2 peut s'avérer suffisant (uniquement erreurs et warnings).

Robots Scan Folder

• Injection systématique dans une file d'attente : Sauf cas particuliers, il ne faut JAMAIS associer un robot scanfolder à un workflow "complexe". Le seul traitement pouvant être exécuté par le workflow est l'injection du travail dans une file d'attente du spooler, et éventuellement des initialisions de variables permettant d'ajouter des méta données à ce travail. Ceci pour des raisons de suivi des travaux ainsi que pour bénéficier d'une gestion correcte des exceptions.

• Répertoires locaux seulement : Il est vivement déconseillé de faire pointer un robot Scan folder sur un répertoire distant situé sur un serveur distant.

• Intégrité de transfert : Il est primordial de mettre en place une stratégie de dépôt cohérente afin que Mapping ne puisse pas récupérer des fichiers tronqués car en cours de transfert (ftp, sftp, cft ou autres protocoles). Par exemple avec un nom temporaire pendant le dépôt, avec un fichier "témoin" ou en déplaçant le fichier (dans le même FS) une fois le transfert terminé. Ne pas utiliser le paramètre "CHECK_FTP_FILE_ACCESS" et son timeout qui ne permet en aucun cas de garantir l'intégrité du fichier récupéré.

Envoi d'emails

• Séparer éclatement et envoi : Ne pas utiliser les outils permettant de faire à la fois l'éclatement d'un fichier d'impression ET l'envoi des emails dans le même traitement. En effet, il est préférable de faire d'abord l'éclatement en PDF vers une file d'attente dédiée à l'envoi d'email, puis que cette file d'attente se charge à son tour d'envoyer les emails de façon unitaire.
  

Dans le cas contraire, aucun suivi d'envoi n'est possible et si par exemple une adresse email est fausse (erreur de syntaxe), le travail peut être interrompu en cours de traitement alors qu'une partie des emails a déjà été envoyée. Il est alors impossible de relancer proprement le travail sans générer de doublons d'emails.