Organisation – Échanges entre sites

En fonction de l’organisation mise en place sur z/OS, il peut être nécessaire d’installer plusieurs Rule Engines pour préciser notamment plusieurs sites correspondant à des stades d’exécution différents (développement, test, recette, pré-production et production par exemple).

Le Guide d’installation z/OS du Rule Engine présente une manière de définir ces différents sites d’exécution à partir d’un environnement de distribution unique.

En suivant la procédure d’installation du Rule Engine, deux environnements sont créés.

  • L’environnement RDJHOME représente l’environnement de distribution à partir duquel on peut créer autant d’environnements d’exécution que l’on veut. Cet environnement contient les objets de référence (fichiers de référence, exécutables produits…).
  • L’environnement RDJEXEC représente l’environnement d’exécution créé.

Nous vous suggérons de suivre la procédure d’installation pour créer plusieurs Rule Engines répartis sur différents sites d’exécution. L’environnement de distribution RDJHOME, généralement installé dans un environnement système, constitue alors l’environnement de référence qui contient les objets communs à tous les Rule Engines installés (de manière à ne pas multiplier les références). Par contre, les environnements d’exécution RDJEXEC contiennent les objets spécifiques à un ou plusieurs projets client (paramétrage particulier, exits client, exécutables spécifiques…) à un stade de développement donné des projets.

Échanges entre sites

Une fois les données définies et validées, il faut extraire le paramétrage de l'AI Enabler et le transférer jusqu'à un Rule Engine installé sur un site d'exécution de manière à pouvoir procéder au test des règles. Il est nécessaire ensuite d’exporter ce paramétrage vers les différents sites d’exécution pour procéder aux différents tests jusqu’à l'AI Enabler de production pour la mise en production du paramétrage. Pour ce faire, vous pouvez choisir l’une des deux méthodes suivantes :

  • Délivrer le paramétrage systématiquement depuis l'AI Enabler.
    La maintenance du paramétrage étant réalisée dans l'AI Enabler et les objets étant stockés dans une base Oracle (base de référence), il semble légitime de pouvoir exporter le paramétrage vers n’importe quel site d’exécution.
  • La gestion des statuts dans l'AI Enabler permet de réaliser un suivi des phases de développement des objets du Rule Engine utilisés dans les projets jusqu’à leur mise en production.
  • Faire évoluer le paramétrage d’un Rule Engine d’un site d’exécution vers un autre Rule Engine d’un autre site d’exécution, en utilisant les procédures batch livrées pour l’export et l’import/mise à jour du paramétrage du Rule Engine.
  • Le risque de cette méthode est de perdre le lien avec l’AI Enabler en termes de suivi du stade de développement du projet dans l’AI Enabler. En revanche, cela permet d’avoir une vision plus claire sur la plateforme z/OS pour le suivi du projet.

Outre ces échanges de paramétrage du Rule Engine, on présente également dans cette section l’acheminement des informations de suivi depuis Rule Engine vers Axway Sentinel.

Transfert de paramétrage entre l'AI Enabler et Rule Engine

La mise à jour du paramétrage du Rule Engine se déroule en trois étapes :

  1. Constitution, dans un répertoire réservé à cet usage, de fichiers de mise à jour du paramétrage contenant les objets à transférer sur le serveur de l'AI Enabler.
  2. Transfert de ces fichiers sur la plateforme hébergeant le Rule Engine destinataire.
  3. Mise à jour des fichiers permanents du paramétrage du Rule Engine.

Les fichiers déposés et transférés par l'AI Enabler sont les suivants :

  • Le fichier bordereau mvt.mvt contient la description du référentiel de traduction : règles de traduction, tables internes, formats et variables.
  • Ce fichier est à renommer en "mvt" avant le transfert.
    Vous devez l’envoyer dans la bibliothèque MVTRDJ pour remplacer le précédent fichier du même nom. La procédure batch RDJMAJ (à adapter pour prendre en compte le nom du fichier) permet de mettre à jour la base de règles de l’environnement destinataire à partir des informations contenues dans ce fichier.
  • Le fichier ctx.mvt contient le paramétrage du contexte fonctionnel du référentiel.
    Vous devez le renommer et l’envoyer dans la bibliothèque MVTCTX sur z/OS pour remplacer le précédent fichier.
  • Pour un Rule Engine en mode UTF-16, ces fichiers (mvt et ctx) doivent être transférés en BINAIRE.

Échanges de paramétrage AI Enabler / Rule Engine

Échanges de paramétrage AI Enabler/ Rule Engine

Échanges de paramétrage entre environnements Rule Engine

Vous pouvez également avoir besoin de transférer des informations d'un environnement Rule Engine à un autre ; c’est-à-dire sans que ces informations ne soient obligatoirement issues de la station AI Enabler. Cela peut se produire, par exemple, dans le cas où il existe plusieurs environnements de tests où les échanges d’information nécessitent une certaine souplesse sans que celle-ci remette en cause la gestion du référentiel au niveau de la base d'AI Enabler.

Cette procédure ne peut pas être appliquée entre 2 Rule Engines installés dans des modes fichier différents (EBCDIC et UTF-16), parce que les 2 environnements d’exécution sont issus de délivrables différents, chacun possédant son propre format Mvttrf.

Étape 1 : Extraction

Pour cela, vous utilisez le fichier de demande de travaux DEMTRV et la procédure RDJTRF pour extraire tout ou partie du référentiel de traduction (règles de traduction, formats, tables internes et variables) de l’environnement Rule Engine source dans le fichier Mvttrf.

Étape 2 : Transfert

Transfert du fichier Mvttrf de l’environnement source sur l’environnement Rule Engine destinataire. Les trois fichiers de paramétrage Sysexp, Usrexp et Trcexp peuvent également être transférés si nécessaire.

Étape 3 : Mise à jour/import

Utilisez la procédure RDJMAJ pour mettre à jour les fichiers permanents du paramétrage du référentiel de traduction du Rule Engine avec le fichier d’entrée Mvttrf. Selon la constitution du fichier DEMTRV, l’extraction peut être complète ou partielle.

Pour plus d'information sur ce fichier sur la façon de configurer le fichier DEMTRV, reportez-vous à la section Structure et exploitation du fichier DEMTRV.

Échanges de paramétrage AI Enabler / Rule Engine

Échanges de paramétrage AI Enabler/Rule Engine

Suivi de vacation par Axway Sentinel

Sentinel est le module de suivi détaillé de :

  • La ré-initialisation du référentiel (suivi RAZ)
  • La mise à jour du référentiel (suivi MAJ)
  • La traduction, les rejets (suivi VACATION).

L’agent permet de procéder à l’alimentation des serveurs de suivi depuis la machine qui héberge le Rule Engine. Les différentes informations collectées peuvent être consultées en temps réel via l’interface utilisateur d'Axway Sentinel.

Suivi de vacation par Axway Sentinel

Suivi de vacation par Axway Sentinel

Related Links