Fernverwaltung mit REST API

Sie können die REST API verwenden, um ferne Warteschlangenmanager und die IBM® MQ -Objekte zu verwalten, die diesen Warteschlangenmanagern zugeordnet sind. Diese Fernverwaltung umfasst Warteschlangenmanager, die sich auf demselben System befinden, jedoch nicht in derselben IBM MQ -Installation wie der mqweb-Server. Daher können Sie REST API verwenden, um Ihr gesamtes IBM MQ -Netzwerk mit nur einer Installation zu verwalten, auf der der mqweb-Server ausgeführt wird. Um Remote-Queue-Manager zu verwalten, müssen Sie das Gateway administrative REST API so konfigurieren, dass mindestens ein Queue-Manager in derselben Installation wie der mqweb-Server als Gateway-Queue-Manager fungiert. Anschließend können Sie den Remote-Queue-Manager in URL REST API angeben, um die angegebene Verwaltungsaktion auszuführen.

1. Konfigurieren Sie die Kommunikation zwischen dem Gateway-Warteschlangenmanager und den fernen WS-Managern, die Sie verwalten möchten. Diese Konfigurationsschritte sind dieselben Schritte, die erforderlich sind, um die ferne Verwaltung von runmqsc und PCF zu konfigurieren.
   Weitere Informationen zu diesen Schritten finden Sie unter Konfiguration von Warteschlangenmanagern für die Fernverwaltung.
2. Konfigurieren Sie die Sicherheit auf den fernen WS-Managern:
   1. Stellen Sie sicher, dass die relevanten Benutzer-IDs auf dem System vorhanden sind, auf dem der ferne WS-Manager ausgeführt wird. Die Benutzer-ID, die auf dem fernen System vorhanden sein muss, hängt von der Rolle des Benutzers REST API ab:
      • Wenn der Benutzer REST API zur Gruppe MQWebAdmin oder MQWebAdminRO gehört, muss die Benutzer-ID, die den mqweb-Server gestartet hat, auf dem entfernten System existieren. Auf dem IBM MQ Applianceist der Benutzer, der den mqweb-Server startet, mqsystem.
      • Wenn der Benutzer REST API zur Gruppe MQWebUser gehört, muss diese REST API -Benutzer-ID auf dem fernen System vorhanden sein.
   2. Stellen Sie sicher, dass den relevanten Benutzer-IDs die erforderlichen Berechtigungsstufen für den Zugriff auf die entsprechenden REST API -Ressourcen auf dem fernen Warteschlangenmanager erteilt werden:
      • Berechtigung zum Nachrichteneinlegen in den SYSTEM.ADMIN.COMMAND.QUEUE.
      • Berechtigung zum Nachrichteneinlegen in den SYSTEM.REST.REPLY.QUEUE.
      • Berechtigung zum Zugriff auf die Übertragungswarteschlangen, die für die Fernverwaltung definiert sind.
      • Berechtigung zum Anzeigen von Warteschlangenmanagerattributen.
      • Berechtigung zum Ausführen der REST-Anforderungen. Weitere Informationen finden Sie im Abschnitt zu den Sicherheitsanforderungen in den REST API -Ressourcenreferenzthemen.
3. Konfigurieren Sie, welcher lokale WS-Manager als Gateway verwendet wird. Sie können einen Standard-Gateway-WS-Manager konfigurieren, den Gateway-Warteschlangenmanager in einem HTTP-Header angeben oder eine Kombination aus beiden Methoden verwenden:
   • Konfigurieren Sie einen Standard-Gateway-Warteschlangenmanager mit dem Befehl setmqweb :

     setmqweb properties -k mqRestGatewayQmgr -v qmgrName

     Hierbei steht qmgrName für den Namen des Gateway-Warteschlangenmanagers.

     Dieser Gateway-WS-Manager wird verwendet, wenn die beiden folgenden Anweisungen wahr sind:

     • Es wurde kein Warteschlangenmanager im Header ibm-mq-rest-gateway-qmgr einer REST-Anforderung angegeben.
     • Der in URL der Ressource REST API angegebene Warteschlangenmanager ist kein lokaler Warteschlangenmanager.
   • Konfigurieren Sie den Gateway-Warteschlangenmanager auf jeder REST-Anforderung, indem Sie den HTTP-Header ibm-mq-rest-gateway-qmgr auf den Namen des Gateway-WS-Managers setzen.
4. Geben Sie den Namen des fernen Warteschlangenmanagers an, der in der Ressourcen-URL verwaltet werden soll.
   Um beispielsweise Informationen über den Remote-Queue-Manager remoteQM zu erhalten, verwenden Sie Folgendes: URL :

   https://localhost:9443/ibmmq/rest/v3/admin/qmgr/remoteQM

Beispiel

Im folgenden Beispiel gibt es drei IBM MQ -Installationen auf zwei Maschinen. Unter Machine 1gibt es eine Installation 1 und eine Installation 2. Unter Machine 2gibt es eine Installation 3. Ein mqweb-Server ist für Installation 1konfiguriert. In jeder Installation ist ein einzelner Warteschlangenmanager vorhanden, und diese Warteschlangenmanager sind für die Fernverwaltung konfiguriert. Das heißt, die folgenden Empfangsprogramme, Kanäle und Warteschlangen sind konfiguriert und gestartet:

• Auf WS-Manager QM1 in Installation 1 unter Machine 1:
  • Senderkanal QM1.to.WSM2
  • Empfängerkanal QM2.to.QM1
  • Senderkanal QM1.to.QM3
  • Empfängerkanal QM3.to.QM1
  • Übertragungswarteschlange QM2
  • Übertragungswarteschlange QM3
  • Ein Listener, der an Port 1414 konfiguriert ist
• Auf WS-Manager QM2 in Installation 2 unter Machine 1:
  • Senderkanal QM2.to.QM1
  • Empfängerkanal QM1.to.WSM2
  • Übertragungswarteschlange QM1
  • Ein Listener ist an Port 1415 konfiguriert.
• Auf WS-Manager QM3 in Installation 3 unter Machine 2:
  • Senderkanal QM3.to.QM1
  • Empfängerkanal QM1.to.WSM3
  • Übertragungswarteschlange QM1
  • Der Standardlistener

Eine Warteschlange, Qon2 ist in QM2 definiert, und eine Warteschlange Qon3 ist in QM3 definiert.

Der Benutzer mquser ist auf beiden Maschinen definiert, erhält die Rolle MQWebAdmin in der REST APIund erhält die Berechtigung für den Zugriff auf die entsprechenden Warteschlangen auf jedem Warteschlangenmanager.

Der Befehl setmqweb wird zum Konfigurieren des Warteschlangenmanagers QM1 als Standard-Gateway-Warteschlangenmanager verwendet.

Das folgende Diagramm zeigt diese Konfiguration:

Die folgende REST-Anforderung wird an den mqweb-Server gesendet:

POST https://localhost:9443/ibmmq/rest/v3/admin/action/qmgr/QM2/mqsc

Die REST-Anfrage enthält das folgende JSON:

{
  "type": "runCommandJSON",
  "command": "display",
  "qualifier": "qlocal",
  "name": "Qon2",
  "responseParameters": ["type", "descr"]
}

Die folgende Antwort wird empfangen:

{
   "commandResponse": [   {
      "completionCode": 0,
      "reasonCode": 0,
      "parameters":       {
         "descr": "Queue on QM2, Installation 2",
         "type": "QLOCAL",
         "queue": "Qon2"
      }
   }],
   "overallReasonCode": 0,
   "overallCompletionCode": 0
}

Die folgende REST-Anforderung wird an den mqweb-Server gesendet:

POST https://localhost:9443/ibmmq/rest/v3/admin/action/qmgr/QM3/mqsc

Die REST-Anfrage enthält das folgende JSON:

{
  "type": "runCommandJSON",
  "command": "display",
  "qualifier": "qlocal",
  "name": "Qon3",
  "responseParameters": ["type", "descr"]
}

Die folgende Antwort wird empfangen:

{
   "commandResponse": [   {
      "completionCode": 0,
      "reasonCode": 0,
      "parameters":       {
         "descr": "Queue on QM3, Installation 3",
         "type": "QLOCAL",
         "queue": "Qon3"
      }
   }],
   "overallReasonCode": 0,
   "overallCompletionCode": 0
}