ONYX:9.0:Utilisation:Les bonnes pratiques/en

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.

• Log level: For performance reasons, do not leave the LOG_LEVEL setting set to 4 in production. You could leave it the way it is if performance is not one of your major concerns. This setting has huge impacts on performance if many "small" jobs are processed. In this case the log level 3 can also be too high, level 2 can be enough (only for errors and warnings).

Scan Folder Robots

• Automatic queue assignment: Except in special cases, you should NEVER associate a scanfolder robot with a "complex" workflow. The only processing the workflow can execute is assigning a job to the spooler queue, and potentially initiate variables to add meta data to this job. The aim is to track jobs and benefit from proper exception management.

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