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.

Admin interface

• Configuring identification banners: Up to version 8.0 of Mapping, it was strongly recommended to modify the files Haut.html and index.html in order to add a banner to identify the current Mapping environment visually.
  

As of ONYX 9.0, these banners are set up directly in the mapping.conf via GUI_DISPLAY_ENVIRONMENT_LABEL and GUI_DISPLAY_ENVIRONMENT_COLOR.

Designer

• Name of the projects: SEQUENCE_FORMAT (example : INVOICESS_00010.mpp).
  

An additional comment can be added afterwards (example: INVOICES_00010_Customer-Invoices.mpp). But in any case, it is important that the first 20 characters of the project name be discriminating.

Best practice: It is recommended that you create one sub-folder per project, containing the Designer and Connect source files, components, variable elements and example txt or xml files.

• No calculations: Avoid making calculations directly in M-Designer. Prefer making prior calculations (ERP, M-Connect...)

• TEXT memory zones: If no calculations are required, "Memory" type zones must always have a "Text Memory" sub-type, never an "Entire Memory" nor "Floating Memory" (even if the fields handled are numerical)

• FRONT Spacing: when creating groups, manage line breaks with the FRONT spacing. AFTER spacing should only be used to add an empty space before the next line. Do not ever write in a space dedicated to an other line (i.e the previous or next line), each line has its own dedicated space defined by "FRONT Spacing + AFTER Spacing".

• Automatic page break: Do not ever use more than one group to generate a page break in a project (even with execution conditions).

Connect

• MAPPING_DATASTREAM=XML: To generate an XML file, you must create the DB.MAPPING_DATASTREAM variable and associate the "XML" value to it.

• Generating XML projects automatically: Using the feature to generate projects automatically while supporting XML input file is not recommended. The code which is generated is difficult to maintain. It can however be used to understand CONNECT operating principles on XML files reading.

Workflow

• Identical integration, validation and production environment: Implementing 100% identical workflows in the integration, validation and production environment is strongly recommended. The differences in processing must be based on environmental parameters defined in the mapping.conf file.

Spooler

• Dedicated queues: Whenever external communication is involved (documents sent by e-mail, ftp etc...), a dedicated queue can be created. The processing associated with this communication must not handle anything else, except for potential variables (SetParam) and conditions. Do not combine a file processing (Connect, mapping, XPS file management) with e-mail delivery or ftp deposit, in the same queue.

• Autonomous continuous processings: Queues which manage processings (workflow, Shell etc...) usually need to be configured to keep processing the following jobs in the event of an error. The default value (default) is "Stop", this stops processings in case of technical failure, the user then needs to intervene.

• Save jobs: Do not forget to "Save" the jobs sent to the queues for debugging purposes.

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