Procédure Migration de Genio 5.1 vers genio 6.0

Hypothèses :

- Génio 5.1 (Frontal : Module Designer, Administrateur) est installé sur un pc que nous appellerons « PC1 »

- Génio 6.0 (Frontal) sera installé sur un nouveau pc que nous appellerons « PC2 »

Phase 1 : Migration du référentiel

1.      Installer la version 6.0 sur le PC2

2.      Créer une nouvelle base de données ou respectivement un nouveau schéma oracle pour le nouveau référentiel 6.0

3.      Depuis la console d’administration de Genio 6, créer et configurer une nouvelle entrée qui pointe vers l’ancien référentiel 

4.      Connectez-vous à l’ancien référentiel et exporter les données (projets, modules, ...) au format XML.

5.      Depuis la console d’administration de Genio 6, suprimer l’entrée qui correspond à l’ancien référentiel

6.      Depuis la console d’administration de Genio 6, créer et configurer une nouvelle entrée qui pointe vers le nouveau référentiel

7.      Initialiser le nouveau référentiel

8.      Positionner le nouveau référentiel comme référentiel par défaut

9.      Fermer et puis rouvrir la console d’administration

10.  Sélectionner le nouveau référentiel, sélectionner le menu d’import de données. Et sélectionner le fichier XML généré dans l’étape 4

11.  De préférence, sélectionner l’importation des logs (à condition qu’ils aient été exportés)

Phase 2 : Migration du moteur genio

1.      Installer le nouveau moteur Genio 6.0 (Engine, poller, Scheduler) dans un nouveau serveur. Du moins pas dans le même serveur que l’ancien moteur !!!

        2.       Configuer le nouveau moteur (Nom NetBios, N° de Serie, Port, …)

Phase 3 : Adaptation du nouveau référentiel  

Après import des données, le nouveau référentiel pointe vers l’ancien moteur. Cette phase consiste donc reconfigurer le nouveau référentiel afin de lui donner la possibilité de communiquer avec le nouveau moteur

Remarques :

1.      Migrer Genio consiste essentiellement à migrer les données du référentiel;  

2.     On aurait pu dans la phase 2, commencer par désinstaller l’ancien référentiel avant d’installer le nouveau. Mais par précaution, je ne conseille pas cette démarche. En effet, il faut toujours conserver l’ancien référentiel et l’ancien moteur au cas ou la migration ne se passerait pas correctement;

3.     On pourra alors désinstaller l’ancien moteur et l’ancien référentiel (après sauvegarde du dernier DUMP) lorsqu’on sera sûr que le nouveau référentiel fonctionne correctement avec le nouveau moteur.

                     Cliquer ici pour télécharger la procédure au format pdf

Tout ou Partie de cet article ne peut reproduit sans autorisation écrite de M. Benjamin EPEE

I          Modèles de communication  

I-1       Mode de connexion Synchrone - http, corba  

- Mode conversationnel : Une seule connexion - bidirectionnel - demande explicite de déconnexion

- Mode requête, réponse : Cas particulier - un seul aller-retour - RPC appel de fonction à distance - l’application émettrice reste bloquée le temps de la requête

I-2       Mode de connexion Asynchrone - middleware

- Mode message Passing : sans connexion - unidirectionnel - non bloquant pour l’émetteur  

- Mode message Queuing : Cas particulier du précédent - stockage du message entre l’émission et la réception

- Mode publish & Subscribe : sans connexion - échange de 1 à n

II         Les mécanismes d’échange

II-1      Par fichiers (FTP - CFT)

II-2      via les ETL

II-3      Par réplication de données  

               -  Fil de l’eau ou mode batch

               -  Non intrusif dans les applications

               -  Peu de capacité de reformatage et de routage

II-4      MOM (Message Middleware Oriented):

 -  Transport point à point

 -  Garantie de délivrance (consommation immédiate du message ou file d’attente)

 -  Notification (simulation de synchronisme)

 -  Priorité via des files d’attente particulière

 -  Sécurité (restriction d’accès à certains messages)

 -  Triggering (à l’arrivée de message, activation d’opération)

 III       Les topologies d’intégration

III-1     Topologie Point à Point

 - Codage de chaque interface en dur dans les applications concernées

- Nouvelles applications => Nouvelles connexions => Nouveaux développement

III-2     Topologie bus

- « publish & Subscribe décentralisé » - « Architecture Network centric »

-   bus logique

-  Abonnement d’une application à une liste de diffusion

-  pas de routage par le contenu

-  Installation d’un agent sur chaque application pour l ’interfaçage avec le bus - potentiellement intrusif

-   Référentiel de règles et gestionnaire de messages distribués sur l’ensemble des nœuds  [point de connexion à une application]

IV         Les types d’intégration

Politique des petits pas: de l’intégration niveau données à l’intégration par les processus

-  Intégration au niveau données

-  « intégration par les flux » ou « intégration au niveau information

-  Intégration par l’objet

-  « intégration par les composants »

-  Intégration par les processus : finalité des EAI

-  « intégration par les services » orientée Service Web

-  Intégration niveau utilisateur : « intégration par la présentation 

V         Les composants d’une plate-forme EAI

-  Les connecteurs

-  Le bus d’échange (message broker en architecture « hub & spoke », bus logique en architecture décentralisée)

-  Le gestionnaire de processus

-  L’administration et la sécurité