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)

• Space BEFORE: when creating groups, manage line breaks with Space BEFORE. 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 "Space BEFORE + Space AFTER".

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

• Local folders only: Setting a Scan folder robot to point in a remote folder on a remote server is not recommended.

• Transfer integrity: Establishing a coherent deposit strategy is essential so that Mapping cannot retrieve truncated files being transferred (ftp, sftp, cft or other protocoles). For example, use a temporary name for the time of the deposit, use a "cookie" file or move the file (in the same FS) once the transfer is finished. Do not use the "CHECK_FTP_FILE_ACCESS" setting and its timeout as it does not insure the integrity of the file retrieved.

Sending e-mails

• Separate splitting and sending: Do not use tools to split, print files and send e-mails all in the same processing. Prefer splitting in PDF into a dedicated e-mailing queue first, then in turn let this queue manage e-mail delivery, one e-mail at a time.
  

Otherwise, no tracking is possible and if, for example, an email address is inaccurate (syntax error), the job can be interrupted during processing even though some of the e-mails have already been sent. Relaunching the job properly is then impossible without generating duplicate e-mails.