Geekly articles weekly

DataPower-Lernprogramm

Von wedmeed mitverfasstes Material


Als unser Projekt 2017 in Vietnam begann, stießen wir auf das neue Biest IBM DataPower für uns. IBM DataPower ist ein Gateway-Produkt zwischen Clients und Backends, das zum Filtern, Weiterleiten, Anreichern oder für andere Transformationen von Nachrichten entwickelt wird (im Folgenden als Anforderungen bezeichnet). Es war notwendig, schnell zu lernen, es gab keine Zeit für den Aufbau, daher wurden wir eingeladen, uns damit vertraut zu machen. Danach gab es viele Stunden Skype-Konferenz mit unserem Kollegen aus Moskau, der uns sein Wissen und seine Erfahrung mit diesem Produkt weitergab.


Das Selbststudium basierte darauf, die Dokumentation zu studieren und Schulungsvideos aus dem Internet anzusehen - und hier wartete ich auf einen Fang. Ich konnte praktisch keine Informationen auf Russisch finden. Übrigens waren meine Kenntnisse der englischen Sprache zu dieser Zeit nicht auf höchstem Niveau, außerdem war es mein erstes Projekt und wahrscheinlich haben diese Faktoren mein Leben kompliziert. Dies brachte mich dazu, einen Schulungsartikel auf Russisch und auf einfachste Weise für Anfänger zu schreiben, die auf dieses Produkt gestoßen sind und versuchen, seine Grundlagen schnell zu verstehen. Der Artikel befreit Sie nicht vom Lesen der Dokumentation, erleichtert jedoch das Leben in den frühen Phasen des Verständnisses "wie es funktioniert".


Es ist auch erwähnenswert, dass die in der Praxis angegebene Struktur dem tatsächlichen Projekt nahe kommt, sodass Sie es als Basis verwenden und Ihre Anforderungen erweitern und ergänzen können. Abschließend werden den Abschnitten zur Theorie einige Worte zum bereits umgesetzten Projekt sowie einige Funktionen gegeben, die es wert sind, beachtet zu werden.




Teil 1. Installieren von DataPower mit der Docker Toolbox


Installieren Sie die Docker Toolbox-App und führen Sie sie aus. Unmittelbar nach dem Start sehen Sie die IP-Adresse des Computers, über die DataPower später verfügbar sein wird:




Um das Image zu starten, müssen Sie einige Einstellungen der virtuellen Maschine (relevant für Version IDG.2018.4.1.0) ändern und neu starten:


  1. Stoppen Sie die Docker-Maschine mit dem folgenden Befehl:

    docker-machine stop
  2. System -> Motherboard -> Hauptspeicher: mindestens 4096 MB;
  3. System -> Prozessor: mindestens 2;
  4. Anzeige -> Bildschirm -> Videospeicher: mindestens 128 MB;
  5. Wir starten die Docker-Maschine mit dem Befehl:

     docker-machine start

    Hinweis Wenn Sie aufgefordert werden, die Docker-Maschine env neu zu starten, führen Sie Folgendes aus:

     docker-machine env
  6. Als Nächstes müssen Sie das IBM DataPower-Image entleeren:

     docker pull ibmcom/datapower
  7. Starten Sie dann den Docker-Container mit dem folgenden Befehl:

     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. Drücken Sie nach Abschluss des Befehls die Eingabetaste und geben Sie admin / admin als Benutzernamen und Passwort ein
  9. Verwenden Sie die folgenden Befehle, um die Webverwaltungsoberfläche zu starten:

     co

    und

     web-mgmt 0 9090
  10. Führen Sie nach all diesen Schritten im Browser https://192.168.99.100:9090/ aus.

Teil 2. Domänen


2.1. Theorie


Mit Domains in DataPower können Sie Administrations- und Entwicklungstools trennen und Sicherheit bieten.


Nach der Installation gibt es nur eine Standarddomäne, aus der Anwendungsdomänen erstellt werden können. Jede Domäne hat ihre eigene Konfiguration von Parametern.


Einige allgemeine Ressourcen und Parameter können nur in der Standarddomäne definiert werden. Dazu gehören Netzwerkschnittstellen, Benutzer- und Zugriffssteuerung, Anwendungsdomänen und andere.


Eine Anwendungsdomäne ist ein Entwicklungsabschnitt für Anforderungsverarbeitungsdienste. Darin definierte Dienste können nicht mit einer anderen Anwendungsdomäne geteilt werden. Anwendungsdomänen können separat und unabhängig neu gestartet werden, ohne dass ein vollständiger Neustart von DataPower erforderlich ist.


Sie können Domänen erstellen, neu starten, zurücksetzen, anhalten, erneuern oder löschen. Ausführlichere Informationen zu allen Verwaltungsfunktionen finden Sie in der offiziellen Dokumentation.


Ein wenig über das abgeschlossene Projekt. Wir haben 3 Domains verwendet:


  • Standard - Die Standarddomäne mit gemeinsam genutzten Ressourcen und Parametern.
  • Trunk - die Hauptdomäne, die alles enthält, was zur Verarbeitung von Anforderungen erforderlich ist;
  • Einstellungen - Einstellungen und Sicherheitsdomäne, lokale Dateien enthalten Informationen zu Service-Routing-Regeln und Sicherheitseinstellungen.

Die Notwendigkeit, alle Einstellungen auf eine separate Domäne zu übertragen, entstand im Zusammenhang mit der Suche nach einem einfacheren Bereitstellungspfad. Wie in vielen Projekten wurden die Entwicklungs-, Test- und Produktumgebungen getrennt, und die Übertragung in eine separate Einstellungsdomäne ermöglichte es uns, alle Hauptdomänen aus der Entwicklungsumgebung in anderen Umgebungen durch Export / Import zu installieren, ohne das Risiko, die Umgebungseinstellungen zu verlieren.


2.2. Übe


  • Geben Sie im Suchfeld "Domain" ein, wählen Sie "Application Domain" und klicken Sie auf "Add".
  • Hier müssen Sie den Domainnamen angeben, einen Kommentar abgeben (falls gewünscht) und die Überwachung und Protokollierung aktivieren. Füllen Sie die Felder aus und übernehmen Sie die Änderungen
  • Fügen Sie in ähnlicher Weise eine weitere Domain "Trunk" hinzu
  • Gehen Sie zu Änderungen überprüfen
  • und speichern Sie die Domänenkonfiguration
  • Sie können den Status der erstellten Objekte überprüfen, indem Sie in der Navigationsstruktur unter Status -> Haupt -> Objektstatus zur Standarddomäne wechseln
  • Wählen Sie Anzeigen nach: Typen
  • Suchen Sie die Anwendungsdomäne in der Liste und überprüfen Sie den Status der Objekte: Jedes Objekt muss gespeichert, aktiviert und aktiviert sein. Wenn ja, fahren Sie mit dem nächsten Kapitel fort.



Teil 3. Warteschlangenmanager


Der Warteschlangenmanager ist keine obligatorische Komponente von IBM DataPower. Am Beispiel von MQ können Sie jedoch die volle Leistung dieses Produkts zeigen. Wir werden MQ von IBM verwenden. Während der in Kapitel 6 beschriebenen Tests müssen wir eine Nachricht an den lokalen Warteschlangenmanager senden. In diesem Artikel werde ich dies mit dem Dienstprogramm rfhutil tun, aber Sie können jede Methode verwenden, die Ihnen zur Verfügung steht. Zum Testen müssen Sie mithilfe des MQ-Warteschlangenmanagers eine Verbindung von DP zu Ihrem lokalen Warteschlangenmanager herstellen.



3.1. Theorie


Der Warteschlangenmanager stellt den Datenaustausch zwischen dem Gateway und den Remote-Warteschlangenmanagern bereit.


Sie können auch die MQ Queue Manager-Gruppe konfigurieren, wodurch die Fehlertoleranz des Systems erhöht wird. Dies kann beispielsweise nützlich sein, wenn Sie den Client mit einem der funktionierenden Warteschlangenmanager verbinden möchten, und in einigen Fällen, die Sie in der offiziellen Dokumentation finden.


Aus der Erfahrung des Projekts sollte nur eine Funktion beachtet werden: Zu einer Zeit wollten wir versuchen, den Lastenausgleich mit DataPower zu implementieren, insbesondere mit Gruppen von Warteschlangenmanagern, aber in der Praxis fanden wir keine solche Möglichkeit. Eine alternative Lösung besteht darin, einen Cluster von Warteschlangenmanagern zu erstellen.



3.2. Übe


3.2.1. Vorbereitung


  1. Installieren Sie WebSphere MQ.
  2. Erstellen Sie einen lokalen Warteschlangenmanager LOCAL_DP_QM, auf den über Port 3630 zugegriffen werden kann.
  3. Konfigurieren Sie den DP.SVRCONN-Kanal.

    Beim Erstellen eines Kanals können die folgenden Befehle hilfreich sein:


     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. Erstellen Sie die Warteschlangen DP.IIB.REQIN und DP.IIB.RESIN
  5. Führen Sie rfhutil unter dem Namen des Benutzers aus, für den der Kanal erstellt wurde. Schreiben Sie in die Zeile Name des Warteschlangenmanagers (zum Herstellen einer Verbindung):

     DP.SVRCONN/TCT/127.0.0.1(3630)

  6. Versuchen Sie, die Liste der Warteschlangennamen zu laden. Das Nachrichtenfenster sollte keine Fehler enthalten. Die Verbindung zum Kanal wurde überprüft.

3.2.2. Erstellen Sie IBM MQ Queue Manager


  1. Gehen Sie zur Trunk-Domain.
  2. Geben Sie bei der Suche MQ ein, wählen Sie IBM MQ Queue Manager aus und klicken Sie auf Hinzufügen.
  3. Sie müssen den Namen (TEST_QM), den Hostnamen des Warteschlangenmanagers, den Namen des Warteschlangenmanagers und den Kanalnamen sowie das Zeitlimit angeben. Konfigurieren und speichern Sie die Änderungen.


Überprüfen Sie den Status des Warteschlangenmanagerobjekts auf dieselbe Weise wie den Status von Domänen. Wählen Sie dazu Objektstatus und den Filter Anzeigen nach: Typen aus der Trunk-Domäne aus. Suchen Sie im Abschnitt "IBM MQ Queue Manager" das entsprechende Objekt und überprüfen Sie dessen Status.


Teil 4. Multiprotokoll-Gateways


4.1. Theorie


Multi-Protocol Gateway (MPG) ist ein Multi-Protocol-Gateway, mit dem Sie Anforderungen von Clients mit verschiedenen Protokollen empfangen und dann mit verschiedenen Protokollen auf verschiedene Server übertragen können. Das vom Client verwendete Protokoll stimmt möglicherweise nicht mit dem vom RAS-Server verwendeten Protokoll überein.


In den wichtigsten MPG-Einstellungen können Sie die folgenden Komponenten definieren:

  • XML Manager - steuert das Kompilieren und Zwischenspeichern von Stylesheets (xsl, xslt) sowie das Zwischenspeichern von Dokumenten.
  • Richtlinie - besteht aus Regeln, von denen jede eine Reihe von Aktionen definiert, die auf die durch das Gateway übertragene Nachricht angewendet werden.
  • Einstellungen auf der Vorder- und Rückseite (Festlegen der URL, Arten eingehender und ausgehender Nachrichten, Zeitüberschreitungen und mehr).

Ein paar Worte zum Projekt:


Das Projekt verwendet 4 Multiprotokoll-Gateways (Routing, 2 Transformations-Gateways für verschiedene Endsysteme und ein zusätzliches für den Empfang von Dateien aus der Einstellungsdomäne). Das folgende Diagramm zeigt das allgemeine Interaktionsschema:



Die Menge an MPG kann abhängig von der Architektur der gesamten Lösung variieren. In unserem Fall ist DataPower mit einem Integrationsbus (IIB) und Mikrodiensten konfrontiert, die erhebliche Unterschiede in den Schnittstellen aufweisen (json / http gegenüber xml / mq). Daher wurde beschlossen, für jedes spezifische Backend transformative MPGs zu erstellen und diese entsprechend zu benennen. Für alle Clients arbeiten wir mit json / http, daher ist das Routing von MPG eines davon. Die Haupt-MPGs bestehen aus 3 Regeln für die Verarbeitung von Nachrichten - Anforderung, Antwort und Fehler. Jede Regel besteht aus den erforderlichen Aktionen wie Transformation, Protokollierung, Routing und anderen.


Von Features - Wenn Sie in der Richtlinie die Aktion ConvertQueryParamToXML verwenden, achten Sie auf InputConversion. Wenn Sie die Standardcodierung auf JSON setzen und versuchen, eine GET-Anforderung zu senden, werden Sie überrascht sein, dass die Nachricht keine von Ihnen angegebenen Transformationen durchlaufen hat und Sie keine Spuren davon finden. Diese Funktion hilft dabei, die Erstellung einer separaten Regel für GET-Anforderungen zu überwinden.


4.2. Übe


4.2.1. Vorbereitung


Sie finden alle für die Arbeit erforderlichen Dateien unter dem Link https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1. Domain-Trunk


  1. Gehen Sie zur Trunk-Domain.
  2. Wählen Sie in der Systemsteuerung Dateiverwaltung aus.
  3. Erstellen Sie im lokalen Verzeichnis die folgende Verzeichnisstruktur und platzieren Sie die entsprechenden Dateien darin (jede Datei enthält eine kurze Beschreibung der von ihr ausgeführten Funktionen sowie eine ausführlichere Beschreibung dieser Informationen weiter unten in diesem Artikel).


4.2.1.2. Domäneneinstellungen


  1. Gehen Sie zur Einstellungsdomäne.
  2. Wählen Sie in der Systemsteuerung Dateiverwaltung aus.
  3. Erstellen Sie im lokalen Verzeichnis die folgende Verzeichnisstruktur und platzieren Sie die entsprechenden Dateien darin (die Dateien enthalten auch eine kurze Beschreibung davon).


4.2.2. Erstellen Sie GetFileMPG


Erstellen Sie zunächst ein einfaches Hilfs-MPG, das Dateien aus der Einstellungsdomäne zurückgibt.


  1. Gehen Sie zur Einstellungsdomäne.
  2. Wählen Sie in der Systemsteuerung Multi-Protocol Gateway aus und klicken Sie auf Erstellen.
  3. Geben Sie den Namen (GetFileMPG), die Beschreibung (optional) und den Backend-Typ (dynamisch) an. Da das Backend nicht aufgerufen wird und nur die Datei vom lokalen System zurückgegeben wird, können Sie in diesem Beispiel einen beliebigen Backend-Typ angeben.

  4. Geben Sie Anforderungs- und Antworttypen an. Durch die explizite Angabe von Typen wird die Anzahl der Inline-Prüfungen verringert. Wenn Sie den Durchgangstyp angeben, können Sie keine Regel erstellen (in diesem Fall die Antwort transformieren). Wenn wir den Anforderungstyp angeben, der ebenfalls weitergeleitet wird, können wir die Nachricht in keiner Weise verarbeiten. Diese Option passt nicht zu uns, daher beschränken wir die Art der Anforderung mithilfe von Nicht-XML.


  5. Klicken Sie auf + und wählen Sie den HTTP-Handler aus, um ein neues Front-Side-Protokoll zu erstellen.


  6. Hier sollten Sie einen Namen, eine IP-Adresse, einen Port und eine Liste der zulässigen Methoden angeben. Achten Sie auf die IP-Adresse. Wenn Sie 0.0.0.0 angeben, kann jeder auf dieses Gateway zugreifen. Wenn 127.0.0.1 - nur andere Gateways innerhalb derselben DataPower. Da die Einstellungen Sicherheitsparameter enthalten, verwenden wir die zweite Option. Füllen Sie die Felder aus und klicken Sie auf "Übernehmen". Das Protokoll wird automatisch zum Gateway hinzugefügt.


  7. Klicken Sie auf +, um eine neue Richtlinie hinzuzufügen.


  8. Geben Sie den Richtliniennamen "GetFilePolicy" ein.
  9. Erstellen Sie eine neue Regel, geben Sie den Namen und die Richtung der Regel ein. Da es wirklich kein Backend gibt und nur die gewünschte Datei zurückgegeben wird, gibt es nur eine Regel (Client zu Server).


  10. Doppelklicken Sie auf die Aktion "Übereinstimmen", um sie zu konfigurieren, wählen Sie eine vorhandene Regel aus und übernehmen Sie die Änderungen. Es wäre ideologisch korrekt, eine Einschränkung für die Fähigkeit festzulegen, nur Get-Anfragen zu empfangen. Im Rahmen der Schulungsaufgabe können Sie jedoch die vorhandene auswählen.
  11. Fügen Sie eine weitere Aktion hinzu - GatewayScript, indem Sie es auf die Regel ziehen und konfigurieren. Als Transformation verwenden wir die vorbereitete Datei, die im lokalen Dateisystem: /// die Datei anhand des Namens aus dem URI der eingehenden Anforderung findet und in den Nachrichtentext einfügt. Das Ergebnis der Operation wird direkt in den Ausgabepuffer der Regel übertragen. Speichern Sie die Änderungen.


  12. Das endgültige politische Ergebnis sollte folgendermaßen aussehen:


  13. Die MPG-Erstellung ist abgeschlossen. Speichern Sie die Änderungen.
  14. Sie können den Erfolg der Erstellung mithilfe des Objektstatus überprüfen, ähnlich wie Sie den Status der Domänen und des Warteschlangenmanagers überprüfen. Wählen Sie dazu in der Einstellungsdomäne den Objektstatus und den Filter Anzeigen nach: Diensten aus. Suchen Sie im Abschnitt „Multi-Protocol Gateway“ nach dem entsprechenden Objekt und überprüfen Sie dessen Status.
  15. Sie können dieses MPG nicht von außen aufrufen, da Sie es mit IP geschützt haben. Ändern Sie die IP vorübergehend von 127.0.0.1 auf 0.0.0.0 und den Port von 7171 auf 7170 und führen Sie die folgende Abfrage aus:

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

  16. Sie sollten die folgende Antwort erhalten:


  17. Ändern Sie erneut die IP-Adresse und den Port auf das Original 127.0.0.1:7171.

4.2.3. RoutingMPG erstellen


Erstellen Sie nun RoutingMPG. Basierend auf den Eingabeanforderungs- und Routingregeln bestimmt er, wohin und mit welchen Parametern die Anforderung gesendet werden soll.


  1. Gehen Sie zur Trunk-Domain.
  2. Erstellen Sie ein neues Multiprotokoll-Gateway gemäß den Abschnitten 2-10 von Abschnitt 4.2.2 mit den folgenden Werten:
    • 3 - Name: RoutingMPG, Backend-Typ: Dynamisch (für die Möglichkeit, Anforderungen bei Bedarf an verschiedene MPGs weiterzuleiten).
    • 4 - Rq: Nicht-XML, Rs: Nicht-XML.
    • 6 - Name: RoutingHTTP_FSH, IP: 0.0.0.0, Port: 7170, + Get-Methode.
    • 8 - Name: RoutingPolicy.
    • 9 - Name: RoutingPolicy_rule_req, Richtung: Client zu Server.

  3. Fügen Sie eine weitere Aktion hinzu, um die Anforderung weiterzuleiten. Ziehen Sie dazu die Aktion "Weiterleiten" auf die Regel, doppelklicken Sie darauf, um sie zu konfigurieren, füllen Sie die Felder aus und übernehmen Sie die Änderungen. Die Datei route.xsl empfängt die Routing-Einstellungsdatei von der Einstellungsdomäne über GetFileMPG, das zuvor erstellt wurde. Danach werden basierend auf dem URI die Einstellungen, die für diesen Vorgang erforderlich sind, bereits aus der Datei ausgewählt. Einige von ihnen werden für das Routing verwendet, andere werden Headern zur Verwendung in anderen MPGs hinzugefügt. Die Eingabe- und Ausgabeparameter bestimmen die Arbeitsweise nur mit dem Nachrichtentext und wirken sich in keiner Weise auf Header und Variablen aus. Deshalb: Eingabe von null - da die Informationen aus dem Nachrichtentext nicht für das Routing verwendet werden. Die Ausgabe ist null - da das Ergebnis der Transformation nur eine Änderung der Serviceinformationen ist.


  4. Erstellen Sie auf ähnliche Weise zwei weitere Regeln und speichern Sie alle Änderungen:
    • Richtung: Server-Client, Name: RoutingPolicy_rule_resp;
      Transformation: Eingabe INPUT, Ausgabe NULL, lokale Transformationsdatei: ///RoutingMPG/transform/resp.xslt. Die Datei resp.xslt empfängt den http-Status der Transformations-MPG-Antwort und setzt ihn explizit auf die RoutingMPG-Antwort. Ist dies nicht der Fall, wird der Standardcode auf 200 gesetzt, auch wenn im Transformations-MPG ein Fehler aufgetreten ist.
    • Richtung: Fehler, Name: RoutingPolicy_rule_error;
      Transformation: Input INPUT, Output PIPE (gemäß der Dokumentation kann die Verwendung von PIPE zwischen zwei benachbarten Aktionsknoten als INPUT und OUTPUT zusätzliche Verarbeitung eliminieren und den verwendeten Speicher reduzieren). Die Transformationsdatei ist lokal: ///RoutingMPG/transform/errors.xsl. Die Datei error.xsl empfängt den Fehlercode und den Text aus der Antwort von der Transformations-MPG und generiert eine JSON-Fehlermeldung in dem vom Client erwarteten Format.

  5. Das endgültige politische Ergebnis sollte folgendermaßen aussehen:


  6. Die MPG-Erstellung ist abgeschlossen. Speichern Sie die Änderungen.
  7. Führen Sie beispielsweise mit dem Dienstprogramm curl die folgende Abfrage aus:

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

  8. Wenn Sie den folgenden Fehler erhalten, wird alles korrekt ausgeführt. Dieser Fehler bedeutet, dass die Nachricht erfolgreich empfangen und verarbeitet wurde, der Versuch, das Backend (in diesem Fall IIBMPG) aufzurufen, jedoch nicht erfolgreich war. Fahren Sie mit dem nächsten Schritt fort.



4.2.4. Erstellung von IIBMPG


Der nächste Schritt ist das Erstellen eines transformativen MPG. Angenommen, das externe System hat das JSON-Anforderungsformat und das interne ist XML. Wir müssen die Eingabenachricht transformieren, damit das interne System sie verstehen kann. Es ist erwähnenswert, dass dies nicht immer eine einfache Konvertierung der gesamten Nachricht ist. Es ist häufig erforderlich, eine abgeschnittene oder erweiterte Nachricht zu übermitteln, manchmal mit einer vollständig neu gestalteten Struktur.


  1. Gehen Sie zur Trunk-Domain.
  2. Erstellen Sie ein neues Multiprotokoll-Gateway gemäß den Abschnitten 2-10 von Abschnitt 4.2.2 mit den folgenden Werten:
    • 3 - Name: IIBMPG, Backend-Typ: Dynamisch
    • 4 - Rq: JSON, Rs: XML
    • 6 - Name: IIBHTTP_FSH, IP: 127.0.0.1 (nur Anforderungen von derselben DataPower), Port: 7172, + Get-Methode
    • 8 - Name: IIBPolicy
    • 9 - Name: IIBPolicy_rule_req, Richtung: Client zu Server

  3. Fügen Sie eine Beschreibung hinzu. Basierend auf dem X-DP-Transform-Namen in den Anforderungsheadern empfängt die Datei IIBRuleRoute.xsl aus der lokalen Datei: ///IIB/route/IIBRouteRules.xml die Namen der Anforderungsumwandlungs-, Antwort- und Fehlerdateien für diesen Dienst und setzt ihre Werte auf die entsprechenden Kontextvariablen var: // context / IIB / reqTransform, var: // context / IIB / ansTransform, var: // context / IIB / errTransform. Andere Werte aus Headern (URL, URL, Ablaufdatum, Zeitlimit) werden ebenfalls in Kontextvariablen platziert.


  4. Fügen Sie eine weitere Aktion hinzu, indem Sie Erweitert auf Ihre Regel ziehen und Abfrageparameter in XML konvertieren aus der Liste auswählen und konfigurieren. Sie müssen eine neue Eingabekonvertierungszuordnung hinzufügen, die einen Namen (cmnJSONParseCNVM) und den erforderlichen Typ (JSON) enthält.




  5. Fügen Sie die Transformation nach der Standardkonvertierung hinzu und konfigurieren Sie sie. In diesem Fall wird die in der vorherigen Transformation festgelegte Variable verwendet, um die Transformationsdatei anzugeben. Dies geschieht so, dass die Transformation universell ist und die Datei selbst abhängig von der Eingabenachricht "on the fly" ersetzt wird. Der Nachrichtentext ist bereit. Der nächste Schritt besteht darin, die Nachricht weiterzuleiten. Der Nachrichtentext ändert sich nicht. Daher erstellen wir die Variable dpvar_1 und speichern das Ergebnis darin. Auf diese Variable verweisen wir auf die Eingabe für die Aktion Ergebnisse. Speichern Sie die Änderungen.


  6. Fügen Sie eine Routing-Aktion hinzu und stellen Sie die folgenden Parameter ein. Die Datei IIBURLRoute.xsl empfängt die Werte von Kontextvariablen, von denen einige als Dienstanforderungsvariablen festgelegt sind, und bildet im Übrigen den URI für die Anforderung an das Zielsystem, das auch in der Dienstvariablen gespeichert ist.


  7. Erstellen Sie auf ähnliche Weise zwei weitere Regeln und speichern Sie alle Änderungen:
    • Richtung: Server-Client, Name: IIBPolicy_rule_resp;
      Transformation: Input INPUT, Output PIPE, Transformationsdatei var: // context / IIB / ansTransform (Kontextvariable zum Ersetzen der Transformation der Antwort "on the fly").
    • Richtung: Fehler, Name: IIBPolicy_rule_error;
      Transformation: Eingabe NULL, Ausgabe PIPE, Transformationsdatei var: // context / IIB / errTransform (Kontextvariable, um die Fehlertransformation im laufenden Betrieb zu ersetzen).

  8. Das endgültige politische Ergebnis sollte folgendermaßen aussehen:

  9. Die MPG-Erstellung ist abgeschlossen. Speichern Sie die Änderungen.

Teil 5. Testen


5.1. Vorbereitung


  1. Laden Sie beispielsweise das Dienstprogramm rfhutil zum Lesen und Schreiben von Nachrichten in die Warteschlange herunter.
  2. Testdateien befinden sich im Testordner des gleichen Verzeichnisses wie die Projektdateien.

5.2. Gesundheitscheck


  1. Senden Sie die Anfrage mit dem Dienstprogramm curl (für die unten stehende Anfrage sollte das aktuelle Verzeichnis mit example.json identisch sein).

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

  2. Öffnen Sie zwei Instanzen des Dienstprogramms rfhutil und subtrahieren Sie die Nachricht mit der ersten Instanz von der Warteschlange DP.IIB.REQIN.
  3. Gehen Sie zur Registerkarte MQMD und kopieren Sie die MessageID.
  4. Öffnen Sie in der zweiten Instanz die Datei rs.xml auf der Registerkarte MQMD, fügen Sie die Nachrichtenkennung in CorrelID ein und stellen Sie die Nachricht in die Warteschlange DP.IIB.RESIN.
  5. Sie sollten eine ähnliche Antwort erhalten:


  6. Wiederholen Sie die Schritte 1-3.
  7. rs_error.xml correllId;




6.


6.1. Theorie


Log Targets , .


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


6.2. Übe


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

– .

Source: https://habr.com/ru/post/de442686/

More articles:


All Articles