|DB2 UDB Version 7.2 enthält eine Reihe von MQSeries-Funktionen zum |Einfügen von Nachrichtenübertragungsoperationen in SQL-Anweisungen. |Diese Unterstützung gilt folglich für alle Anwendungen, die in einer der |unterstützten Sprachen (z. B. C, Java oder SQL) unter |Verwendung einer beliebigen Datenbankschnittstelle geschrieben wurden. |Bei allen nachfolgenden Beispielen wurde SQL verwendet. In diesem Fall |kann SQL von anderen Programmiersprachen für standardmäßige |Verarbeitungsvorgänge verwendet werden. Alle oben beschriebenen |Nachrichtendarstellungen von MQSeries werden unterstützt. Weitere |Informationen zu den MQSeries-Funktionen finden Sie im Abschnitt zum Handbuch |"SQL Reference" in den Release-Informationen.
|In einer Basiskonfiguration befinden sich ein MQSeries-Server und DB2 auf |dem Datenbankserver. Die MQSeries-Funktionen werden in DB2 installiert |und ermöglichen den Zugriff auf den MQSeries-Server. DB2-Clients können |auf allen Maschinen installiert sein, auf die der DB2-Server zugreifen |kann. Mehrere Clients können über die Datenbank gleichzeitig auf die |MQSeries-Funktionen zugreifen. Über die bereitgestellten Funktionen |können DB2-Clients innerhalb von SQL-Anweisungen |Nachrichtenübertragungsoperationen durchführen. Diese |Nachrichtenübertragungsoperationen ermöglichen DB2-Anwendungen die |Kommunikation untereinander oder mit anderen MQSeries-Anwendungen.
|Der Befehl enable_MQFunctions wird zur Aktivierung einer |DB2-Datenbank für die MQSeries-Funktionen verwendet.Dabei wird eine |einfache Standardkonfiguration erstellt, die von Client-Anwendungen ohne |weitere Verwaltungsmaßnahmen verwendet werden kann. Eine Beschreibung |hierzu finden Sie in 20.6, enable_MQFunctions und 20.7, disable_MQFunctions. Die Standardkonfiguration |ermöglicht Anwendungsprogrammierern einen schnellen Einstieg und bietet eine |einfachere Entwicklungsschnittstelle. Weitere Funktionen können bei |Bedarf inkrementell konfiguriert werden.
|Beispiel 1: Die SQL-Anweisung zum Senden einer einfachen Nachricht |unter Verwendung der Standardkonfiguration lautet wie folgt:
|VALUES DB2MQ.MQSEND('einfache nachricht')
|Die Nachricht einfache nachricht wird an den |MQSeries-Warteschlangenmanager und an die von der Standardkonfiguration |definierte Warteschlange gesendet.
|MQSeries Application Messaging Interface (AMI) nimmt eine klare Trennung |zwischen den Nachrichtenübertragungsoperationen und den Definitionen für die |Ausführung dieser Operationen vor. Die Definitionen befinden sich in |einer externen Repository-Datei und werden vom AMI-Verwaltungs-Tool |verwaltet. Aus diesem Grund ist die Entwicklung und Verwaltung von |AMI-Anwendungen einfach. Die DB2 MQSeries-Funktionen basieren auf der |MQSeries-Schnittstelle AMI. AMI unterstützt zur Speicherung von |Konfigurationsdaten eine externe Konfigurationsdatei, die AMI-Repository |genannt wird. Die Standardkonfiguration enthält ein MQSeries |AMI-Repository, das für DB2 konfiguriert ist.
|Die beiden Schlüsselkonzepte von MQSeries AMI, Servicepunkte und |Richtlinien, werden in die DB2 MQSeries-Funktionen übertragen. Ein |Servicepunkt ist ein logischer Endpunkt, von dem eine Nachricht gesendet oder |empfangen werden kann. Im AMI-Repository wird jeder Servicepunkt durch |den Namen einer Warteschlange und einen Warteschlangenmanager von MQSeries |definiert. Richtlinien legen die Qualität von Serviceoptionen fest, die |für einen bestimmten Nachrichtenübertragungsvorgang verwendet werden. |Die wichtigsten Qualitäten sind die Nachrichtenpriorität und der |Datenbankzugriff. Dabei werden Standardservicepunkte und |Standard-Richtliniendefinitionen zur Verfügung gestellt, die der Entwickler |zur weiteren Anwendungsvereinfachung verwenden kann. Beispiel 1 kann |umgeschrieben werden, um den Standardservicepunkt und den Richtliniennamen wie |folgt explizit anzugeben:
|Beispiel 2:
|VALUES DB2MQ.MQSEND('DB2.DEFAULT.SERVICE', 'DB2.DEFAULT.POLICY', 'einfache Nachricht')
|Warteschlangen können von mindestens einer Anwendung auf dem Server bedient |werden, auf dem sich die Warteschlangen und Anwendungen befinden. In |zahlreichen Konfigurationen werden zur Unterstützung unterschiedlicher |Anwendungen und Einsatzmöglichkeiten mehrere Warteschlangen definiert. |Aus diesem Grund ist es oft wichtig, bei MQSeries-Anforderungen |unterschiedliche Servicepunkte zu definieren. Das folgende Beispiel |veranschaulicht dies:
|Beispiel 3:
|VALUES DB2MQ.MQSEND('ODS_Eingabe', 'einfache Nachricht')
|
|MQSeries bietet die Möglichkeit, Nachrichten- und Datenbankoperationen in |einer einzelnen Arbeitseinheit als autarke Transaktion zu kombinieren. |Diese Funktion wird von den MQSeries-Funktionen unter Unix und Windows |ursprünglich nicht unterstützt.
|Bei Verwendung der Sende- oder Empfangsfunktionen beträgt die maximale |Länge einer Nachricht vom Typ VARCHAR 4000 Zeichen. Die maximale Länge |beim Senden und Empfangen einer Nachricht vom Typ CLOB beträgt 1 MB. |Dies sind auch die maximalen Nachrichtengrößen zur Veröffentlichung einer |Nachricht mit MQPublish.
|Manchmal sind beim Arbeiten mit CLOB-Nachrichten und VARCHAR-Nachrichten |unterschiedliche Befehle erforderlich. Im allgemeinem verwendet die |CLOB-Version einer MQ-Funktion die identiche Syntax wie di e entsprechende |VARCHAR-Version. Der einzige Unterschied besteht darin, dass an ihren |Namen "CLOB" angehängt wird. Das CLOB-Äquivalent von MQREAD |z. B. heißt MQREADCLOB. Eine ausführliche Liste |dieser Funktionen finden Sie in 43.6.3, CLOB data now supported in MQSeries functions.
|Die Rückkehrcodes von MQSeries-Funktionen finden Sie in Anhang B des |Handbuchs zu MQSeries Application Messaging Interface.