Tutoriel DataPower

Matériel co-écrit par Wedmeed

En 2017, lorsque notre projet a commencé au Vietnam, nous avons rencontré la nouvelle bête IBM DataPower pour nous. IBM DataPower est un produit de passerelle entre les clients et les backends conçu pour le filtrage, le routage, l'enrichissement ou d'autres transformations des messages qui le traversent (ci-après dénommées requêtes). Il fallait apprendre rapidement, il n'y avait pas de temps pour l'accumulation, donc on nous a demandé de nous familiariser avec, après quoi il y a eu de nombreuses heures de conférence Skype avec notre collègue de Moscou, qui nous a transmis ses connaissances et son expérience avec ce produit.

L'autoformation était basée sur l'étude de la documentation et le visionnage de vidéos de formation sur Internet - et ici j'attendais une prise. Je n'ai pratiquement pas pu trouver d'informations en russe. Soit dit en passant, ma connaissance de la langue anglaise à cette époque n'était pas au plus haut niveau, d'ailleurs c'était mon premier projet et, probablement, ces facteurs ont compliqué ma vie. Cela m'a fait écrire un article de formation en russe et de la manière la plus simple possible pour les développeurs débutants qui sont tombés sur ce produit et essaient de comprendre rapidement ses bases. L'article ne vous libérera pas de la lecture de la documentation, mais il vous facilitera la vie dans les premiers stades de la compréhension de «comment cela fonctionne».

Il convient également de noter que la structure donnée dans la pratique sera proche du projet réel, ce qui vous permettra de l'utiliser comme base, d'élargir et de compléter vos besoins. En conclusion, quelques mots sur le projet déjà mis en œuvre, ainsi que certaines fonctionnalités qui méritent une attention particulière, seront donnés aux sections Théorie.

Partie 1. Installation de DataPower avec la boîte à outils Docker

Installez et exécutez l'application Docker Toolbox. Immédiatement après le démarrage, vous verrez l'adresse IP de la machine, à travers laquelle DataPower sera disponible plus tard:

Pour démarrer l'image, vous devez modifier certains paramètres de la machine virtuelle (pertinents pour la version IDG.2018.4.1.0) et la redémarrer:

1. Arrêtez la machine docker avec la commande:
   
   

   docker-machine stop 

2. Système -> Carte mère -> Mémoire principale: minimum 4096 Mo;
   
3. Système -> Processeur: minimum 2;
   
4. Affichage -> Écran -> Mémoire vidéo: au moins 128 Mo;
   
5. Nous lançons la machine docker avec la commande:
   
   

    docker-machine start 

   
   Remarque Si vous êtes invité à redémarrer docker-machine env, exécutez:
   
   

    docker-machine env 

6. Ensuite, vous devez dégonfler l'image IBM DataPower:
   
   

    docker pull ibmcom/datapower 

7. Lancez ensuite le conteneur Docker avec la commande suivante:
   
   

    docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower 

8. Après avoir terminé la commande, appuyez sur Entrée et entrez admin / admin comme nom d'utilisateur et mot de passe
   
9. Pour démarrer l'interface de gestion Web, utilisez les commandes:
   
   

    co 

   
   et
   
   

    web-mgmt 0 9090 

10. Après toutes ces étapes, exécutez dans le navigateur https://192.168.99.100:9090/
    

Partie 2. Domaines

2.1. Théorie

Les domaines dans DataPower vous permettent de séparer les outils d'administration et de développement, ainsi que d'assurer la sécurité.

Après l'installation, il n'y a qu'un domaine par défaut à partir duquel les domaines d'application peuvent être créés. Chaque domaine a sa propre configuration de paramètres.

Certaines ressources et certains paramètres communs ne peuvent être définis que dans le domaine par défaut, notamment les interfaces réseau, les utilisateurs et le contrôle d'accès, les domaines d'application et autres.

Un domaine d'application est une section de développement pour les services de traitement des demandes. Les services qui y sont définis ne peuvent pas être partagés avec un autre domaine d'application. Les domaines d'application peuvent être redémarrés séparément et indépendamment, sans avoir besoin d'un redémarrage complet de DataPower.

Vous pouvez créer, redémarrer, réinitialiser, suspendre, renouveler ou supprimer des domaines. Vous pouvez trouver des informations plus détaillées sur toutes les fonctionnalités d'administration dans la documentation officielle.

Un peu sur le projet terminé. Nous avons utilisé 3 domaines:

• default - le domaine par défaut contenant les ressources et les paramètres partagés;
• trunk - le domaine principal contenant tout le nécessaire pour le traitement des demandes;
• paramètres - paramètres et domaine de sécurité, les fichiers locaux contiennent des informations sur les règles de routage des services et les paramètres de sécurité.

La nécessité de transférer tous les paramètres vers un domaine distinct est apparue dans le cadre de la recherche d'un chemin de déploiement plus simple. Comme dans de nombreux projets, les environnements de développement, de test et de production ont été séparés, et le transfert vers un domaine de paramètres séparé nous a permis d'installer tous les domaines principaux de l'environnement de développement dans d'autres environnements via l'exportation / importation, sans risque de perdre les paramètres d'environnement.

2.2. Pratique

• Dans le champ de recherche, entrez «domaine», sélectionnez «Domaine d'application» et cliquez sur «Ajouter»
  
• Ici, vous devez spécifier le nom de domaine, commenter (si vous le souhaitez) et activer l'audit et la journalisation. Remplissez les champs et appliquez les modifications
  
• De même, ajoutez un autre domaine "tronc"
• Allez à Examiner les modifications
  
• et enregistrez la configuration du domaine
  
• Vous pouvez vérifier l'état des objets créés en accédant au domaine par défaut dans l'arborescence de navigation dans État -> Principal -> État de l'objet
  
• Choisissez Afficher par: types
  
• Recherchez le domaine d'application dans la liste et vérifiez l'état des objets: chacun d'eux doit être enregistré, allumé et à l'état haut. Si c'est le cas, passez au chapitre suivant.

Partie 3. Gestionnaires de files d'attente

Le gestionnaire de files d'attente n'est pas un composant obligatoire d'IBM DataPower, mais c'est à travers l'exemple de MQ que vous pouvez montrer toute la puissance de ce produit. Nous utiliserons MQ d'IBM. Lors des tests décrits au chapitre 6, nous devrons envoyer un message au gestionnaire de files d'attente local. Dans cet article, je vais le faire en utilisant l'utilitaire rfhutil, mais vous pouvez utiliser n'importe quelle méthode à votre disposition. Pour les tests, vous devrez créer une connexion de DP à votre gestionnaire de files d'attente local à l'aide du gestionnaire de files d'attente MQ.

3.1. Théorie

Le gestionnaire de files d'attente permet l'échange de données entre la passerelle et les gestionnaires de files d'attente distantes.

Vous pouvez également configurer le groupe MQ Queue Manager, ce qui augmentera la tolérance aux pannes du système. Cela peut être utile, par exemple, si vous souhaitez connecter le client à l'un des ensembles de gestionnaires de files d'attente de travail et, dans certains cas, que vous pouvez trouver dans la documentation officielle.

D'après l'expérience du projet, une seule caractéristique doit être notée: à un moment donné, nous voulions essayer d'implémenter l'équilibrage de charge en utilisant DataPower, en particulier en utilisant des groupes de gestionnaires de files d'attente, mais en pratique, nous n'avons pas trouvé une telle opportunité. Une autre solution consiste à créer un cluster de gestionnaires de files d'attente.

3.2. Pratique

3.2.1. La préparation

1. Installez WebSphere MQ;
2. Créez un gestionnaire de files d'attente LOCAL_DP_QM local, accessible sur le port 3630;
3. Configurer le canal DP.SVRCONN;
   
   

   Lors de la création d'une chaîne, les commandes suivantes peuvent vous être utiles:

   
   

    strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END 

   
   
4. Créez les files d'attente DP.IIB.REQIN et DP.IIB.RESIN
5. Exécutez rfhutil sous le nom de l'utilisateur pour lequel le canal a été créé. Dans la ligne Nom du gestionnaire de files d'attente (pour vous connecter), écrivez:
   
   

    DP.SVRCONN/TCT/127.0.0.1(3630) 

   
   
6. Essayez de charger la liste des noms de file d'attente; il ne devrait pas y avoir d'erreurs dans la fenêtre de message. La connexion au canal a été vérifiée.
   

3.2.2. Créer IBM MQ Queue Manager

1. Accédez au domaine de jonction.
2. Dans la recherche, saisissez MQ, sélectionnez IBM MQ Queue Manager, puis cliquez sur Ajouter.
3. Vous devez spécifier le nom (TEST_QM), le nom d'hôte du gestionnaire de files d'attente, le nom du gestionnaire de files d'attente et le nom du canal, ainsi que le délai d'expiration. Configurez et enregistrez les modifications.
   
   

Vérifiez l'état de l'objet gestionnaire de files d'attente de la même manière que la vérification de l'état des domaines. Pour ce faire, sélectionnez État de l'objet et le filtre Afficher par: types dans le domaine de jonction. Dans la section "IBM MQ Queue Manager", recherchez l'objet approprié et vérifiez son état.

Partie 4. Passerelles multiprotocoles

4.1. Théorie

La passerelle multiprotocole (MPG) est une passerelle multiprotocole qui vous permet de recevoir des demandes de clients à l'aide de divers protocoles, puis de les transférer vers différents serveurs à l'aide de divers protocoles. Le protocole utilisé par le client peut ne pas correspondre au protocole utilisé par le serveur d'accès distant.

Dans les principaux paramètres MPG, vous pouvez définir les composants suivants:

• XML Manager - contrôle la compilation et la mise en cache des feuilles de style (xsl, xslt), la mise en cache des documents.
• Stratégie - se compose de règles, chacune définissant un ensemble d'actions appliquées au message passant par la passerelle.
• Paramètres avant et arrière (réglage de l'URL, types de messages entrants et sortants, délais d'expiration et plus).

Quelques mots sur le projet:

Le projet utilise 4 passerelles multiprotocoles (routage, 2 transformationnelles pour différents systèmes d'extrémité et une autre conçue pour recevoir des fichiers du domaine des paramètres). Le diagramme ci-dessous montre le schéma d'interaction général:

La quantité de MPG peut varier en fonction de l'architecture de la solution dans son ensemble. Dans notre cas, DataPower fait face à un bus d'intégration (IIB) et à des microservices, qui présentent des différences d'interfaces importantes (json / http contre xml / mq), il a donc été décidé de créer des MPG transformationnels pour chaque backend spécifique et de le nommer en conséquence. Pour tous les clients, nous travaillons sur json / http, donc le routage MPG en est un. Les principaux MPG sont constitués de 3 règles de traitement des messages - demande, réponse et erreurs. Chaque règle comprend les actions nécessaires, telles que la transformation, la journalisation, le routage et autres.

À partir des fonctionnalités - si dans la politique, vous utilisez l'action ConvertQueryParamToXML, alors soyez attentif à InputConversion. Si vous définissez le codage par défaut sur JSON et essayez d'envoyer une demande GET, vous serez surpris de constater que le message n'a subi aucune transformation que vous avez spécifiée et vous n'en trouverez aucune trace. Cette fonctionnalité aidera à surmonter la création d'une règle distincte pour les demandes GET.

4.2. Pratique

4.2.1. La préparation

Vous pouvez trouver tous les fichiers nécessaires au travail sur le lien https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1. Tronc de domaine

1. Accédez au domaine de jonction.
2. Dans le panneau de configuration, sélectionnez Gestion des fichiers.
3. Dans le répertoire local, créez la structure de répertoires suivante et placez-y les fichiers correspondants (chaque fichier contient une brève description des fonctions qu'il exécute, ainsi qu'une discussion plus détaillée à ce sujet plus loin dans l'article).
   
   

4.2.1.2. Paramètres de domaine

1. Accédez au domaine des paramètres.
2. Dans le panneau de configuration, sélectionnez Gestion des fichiers.
3. Dans le répertoire local, créez la structure de répertoires suivante et placez-y les fichiers appropriés (les fichiers en contiennent également une brève description).
   
   

4.2.2. Créer GetFileMPG

Tout d'abord, créez un MPG d'assistance simple qui retournera les fichiers du domaine des paramètres.

1. Accédez au domaine des paramètres.
2. Dans le panneau de configuration, sélectionnez Passerelle multiprotocole et cliquez sur Créer.
3. Spécifiez le nom (GetFileMPG), la description (facultatif) et le type de backend (dynamique). En fait, puisqu'il n'y aura aucun appel au backend, et seul le fichier sera retourné depuis le système local, dans cet exemple, vous pouvez spécifier n'importe quel type de backend.
   
   
4. Spécifiez les types de demande et de réponse. La spécification explicite des types réduira le nombre de vérifications en ligne. La spécification du type Pass through vous permet de ne pas créer de règle (dans ce cas, pour transformer la réponse). Si nous spécifions que le type de demande est également transmis, nous ne pourrons en aucun cas traiter le message. Cette option ne nous convient pas, nous limitons donc le type de demande à l'aide de Non-XML.
   
   
   
5. Cliquez sur + et sélectionnez le gestionnaire HTTP pour créer un nouveau protocole frontal.
   
   
   
6. Ici, vous devez spécifier un nom, une adresse IP, un port et une liste des méthodes autorisées. Faites attention à l'adresse IP. Si vous spécifiez 0.0.0.0, tout le monde peut accéder à cette passerelle. Si 127.0.0.1 - uniquement d'autres passerelles à l'intérieur du même DataPower. Puisqu'il y a des paramètres de sécurité parmi les paramètres, nous utilisons la deuxième option. Remplissez les champs et cliquez sur "Appliquer", le protocole sera automatiquement ajouté à la passerelle.
   
   
   
7. Cliquez sur + pour ajouter une nouvelle politique.
   
   
   
8. Remplissez le nom de la politique «GetFilePolicy».
   
9. Créez une nouvelle règle, indiquez le nom et la direction de la règle. Puisqu'il n'y a vraiment pas de backend et que seul le fichier souhaité est retourné, il n'y aura qu'une seule règle (client vers serveur).
   
   
   
10. Double-cliquez sur l'action Correspondance pour la configurer, sélectionnez une règle existante et appliquez les modifications. Il serait idéologiquement correct de définir une restriction sur la capacité de recevoir uniquement des requêtes Get, mais dans le cadre de la tâche de formation, vous pouvez sélectionner celle existante.
    
11. Ajoutez une autre action - GatewayScript en la faisant glisser sur la règle et en la configurant. En tant que transformation, nous utiliserons le fichier préparé, qui dans le système de fichiers local: /// trouvera le fichier par son nom à partir de l'URI de la demande entrante et le placera dans le corps du message. Le résultat de l'opération sera transféré directement dans le tampon de sortie de la règle. Enregistrez les modifications.
    
    
    
12. Le résultat final de la politique devrait ressembler à ceci:
    
    
    
13. La création de MPG est terminée, enregistrez les modifications.
    
14. Vous pouvez vérifier le succès de sa création à l'aide de l'état de l'objet, comme pour vérifier l'état des domaines et le gestionnaire de files d'attente. Pour ce faire, sélectionnez État de l'objet et le filtre Afficher par: services dans le domaine des paramètres. Dans la section «Passerelle multiprotocole», recherchez l'objet correspondant et vérifiez son état.
    
15. Vous ne pouvez pas appeler ce MPG de l'extérieur, car vous l'avez protégé avec ip. Modifiez temporairement l'ip de 127.0.0.1 à 0.0.0.0 et le port de 7171 à 7170 et exécutez la requête suivante:
    
    

     curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml" 

    
    
16. Vous devriez obtenir la réponse suivante:
    
    
    
17. Encore une fois, changez l'ip et le port en 127.0.0.1:7171 d'origine.
    

4.2.3. Création de routageMPG

Créez maintenant RoutingMPG. En fonction de la demande d'entrée et des règles de routage, il déterminera où et avec quels paramètres la demande doit être envoyée.

1. Accédez au domaine de jonction.
2. Créez une nouvelle passerelle multiprotocole conformément aux clauses 2-10 de la section 4.2.2 en utilisant les valeurs suivantes:
   
   • 3 - nom: RoutingMPG, type de backend: Dynamique (pour la possibilité d'acheminer les demandes vers différents MPG si nécessaire).
   • 4 - Rq: non xml, Rs: non xml.
   • 6 - nom: RoutingHTTP_FSH, ip: 0.0.0.0, port: 7170, + méthode Get.
   • 8 - nom: RoutingPolicy.
   • 9 - nom: RoutingPolicy_rule_req, direction: Client to Server.
   
   
3. Ajoutez une action supplémentaire pour acheminer la demande. Pour ce faire, faites glisser l'action "Acheminer" sur la règle, double-cliquez dessus pour la configurer, remplissez les champs et appliquez les modifications. Le fichier route.xsl reçoit le fichier de paramètres de routage du domaine de paramètres via GetFileMPG créé précédemment. Après cela, en fonction de l'URI, les paramètres nécessaires à cette opération sont déjà sélectionnés dans le fichier. Certains d'entre eux sont utilisés pour le routage, et certains sont ajoutés aux en-têtes pour une utilisation dans d'autres MPG. Les paramètres d'entrée et de sortie déterminent la façon de travailler uniquement avec le corps du message et n'affectent en aucune façon les en-têtes et les variables. Par conséquent: entrée de null - puisque les informations du corps du message ne sont pas utilisées pour le routage. La sortie est nulle - car le résultat de la transformation n'est qu'un changement dans les informations de service.
   
   
   
4. De même, créez 2 règles supplémentaires et enregistrez toutes les modifications:
   
   • Direction: Server-Client, nom: RoutingPolicy_rule_resp;
     Transformation: entrée INPUT, sortie NULL, fichier de transformation local: ///RoutingMPG/transform/resp.xslt. Le fichier resp.xslt reçoit le statut http de la réponse MPG de transformation et le définit explicitement sur la réponse RoutingMPG. Si cela n'est pas fait, le code par défaut sera défini sur 200, même si une erreur s'est produite dans la transformation MPG.
     
   • Direction: Erreur, nom: RoutingPolicy_rule_error;
     Transformation: Input INPUT, Output PIPE (selon la documentation, l'utilisation de PIPE entre deux nœuds d'action adjacents comme INPUT et OUTPUT peut éliminer le traitement supplémentaire et réduire la quantité de mémoire utilisée), le fichier de transformation est local: ///RoutingMPG/transform/errors.xsl. Le fichier errors.xsl reçoit le code d'erreur et le texte de la réponse de la transformation MPG et génère un message d'erreur JSON au format attendu par le client.
     
   
   
5. Le résultat final de la politique devrait ressembler à ceci:
   
   
   
6. La création de MPG est terminée, enregistrez les modifications.
   
7. À l'aide, par exemple, de l'utilitaire curl, exécutez la requête suivante:
   
   

    curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" 

   
   
8. Si vous obtenez l'erreur suivante, alors tout est fait correctement. Cette erreur signifie que le message a été reçu et traité avec succès, mais la tentative d'appel du backend (dans ce cas IIBMPG) a échoué. Passez à l'étape suivante.
   
   
   

4.2.4. Création de IIBMPG

L'étape suivante consiste à créer un MPG transformationnel. Supposons que le système externe soit au format de requête JSON et que le interne soit XML. Nous devons transformer le message d'entrée afin que le système interne puisse le comprendre. Il convient de noter qu'il ne s'agit pas toujours d'une simple conversion de l'ensemble du message. Il est souvent nécessaire de transmettre un message tronqué ou augmenté, parfois avec une structure complètement repensée.

1. Accédez au domaine de jonction.
2. Créez une nouvelle passerelle multiprotocole conformément aux clauses 2-10 de la section 4.2.2 en utilisant les valeurs suivantes:
   
   • 3 - nom: IIBMPG, type de backend: dynamique
   • 4 - Rq: JSON, Rs: XML
   • 6 - nom: IIBHTTP_FSH, ip: 127.0.0.1 (uniquement les requêtes du même DataPower), port: 7172, + méthode Get
   • 8 - Nom: IIBPolicy
   • 9 - nom: IIBPolicy_rule_req, direction: Client to Server
   
   
3. Ajoutez une description. En fonction du nom X-DP-Transform-Name dans les en-têtes de demande, le fichier IIBRuleRoute.xsl reçoit du fichier local: ///IIB/route/IIBRouteRules.xml les noms des fichiers de transformation de demande, de réponse et d'erreur pour ce service et définit leurs valeurs dans les variables de contexte correspondantes var: // context / IIB / reqTransform, var: // context / IIB / ansTransform, var: // context / IIB / errTransform. D'autres valeurs des en-têtes (url, uri, expire, timeout) sont également placées dans des variables de contexte.
   
   
   
4. Ajoutez une autre action en faisant glisser Avancé vers votre règle et en sélectionnant Convertir les paramètres de requête en XML dans la liste, configurez. Vous devez ajouter une nouvelle mappe de conversion d'entrée, en lui donnant un nom (cmnJSONParseCNVM) et le type requis (JSON).
   
   
   
   
   
5. Ajoutez la transformation après la conversion standard et configurez-la. Dans ce cas, la variable définie dans la transformation précédente est utilisée pour indiquer le fichier de transformation. Cette opération est effectuée de manière à ce que la transformation soit universelle et que le fichier lui-même soit remplacé "à la volée" en fonction du message d'entrée. Le corps du message est prêt. L'étape suivante consiste à router le message, et le corps du message ne changera pas, nous créons donc la variable dpvar_1 et y enregistrons le résultat. C'est cette variable que nous désignons l'entrée de l'action Résultats. Enregistrez les modifications.
   
   
   
6. Ajoutez une action de routage et définissez les paramètres suivants. Le fichier IIBURLRoute.xsl reçoit les valeurs des variables de contexte, certaines d'entre elles sont définies comme variables de demande de service, et à partir du reste, il forme un URI pour la demande au système de destination, qui stocke également dans la variable de service.
   
   
   
7. De même, créez 2 règles supplémentaires et enregistrez toutes les modifications:
   
   • Direction: Server-Client, nom: IIBPolicy_rule_resp;
     Transformation: Entrée INPUT, Sortie PIPE, fichier de transformation var: // context / IIB / ansTransform (variable de contexte pour substituer la transformation de la réponse "à la volée").
   • Direction: Erreur, nom: IIBPolicy_rule_error;
     Transformation: entrée NULL, sortie PIPE, fichier de transformation var: // context / IIB / errTransform (variable de contexte pour remplacer la transformation d'erreur à la volée).
   
   
8. Le résultat final de la politique devrait ressembler à ceci:
   
   
9. La création de MPG est terminée, enregistrez les modifications.
   

Partie 5. Test

5.1. La préparation

1. Téléchargez, par exemple, l'utilitaire rfhutil pour lire et écrire des messages dans la file d'attente;
2. Les fichiers de test se trouvent dans le dossier tests du même répertoire que les fichiers de projet.

5.2. Bilan de santé

1. Envoyez la demande à l'aide de l'utilitaire curl (pour la demande ci-dessous, le répertoire en cours doit être le même que example.json).
   
   

    curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json 

   
   
2. Ouvrez 2 instances de l'utilitaire rfhutil et soustrayez le message de la file d'attente DP.IIB.REQIN avec la première instance;
   
3. Accédez à l'onglet MQMD et copiez le MessageID;
   
4. Dans la deuxième instance, ouvrez le fichier rs.xml, dans l'onglet MQMD, insérez l'identifiant de message dans CorrelID et placez le message dans la file d'attente DP.IIB.RESIN;
   
5. Vous devriez obtenir une réponse similaire:
   
   
   
6. Répétez les étapes 1 à 3;
   
7. rs_error.xml correllId;
   
8. 
   
   
   

6.

6.1. Théorie

Log Targets , .

Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .

6.2.

1. trunk;
2. Log Target ;
3. :
   
   • (IIB_LOG);
   • (File);
   • (Text);
   • timestamp(zulu);
   • (logtemp:///IIB.log — IIBMPG);
   • (1000).
     
     
   
   
4. . MPG IIBMPG.
   
   
   
5. , , ( , ).
   
   
   
6. ;
   
7. ;
   
8. .
   
9. Log Targets MPG.
   
10. :
    
    • , , .
      
      
      
    • .
      
      
      
    
    

7. -

1. – , . – , , - .
   
2. . View Logs. , « », « » .
   
3. . . MPG Show Probe -> Enable Probe. . , .
   
   
   
4. , .
   

– .