Wenn der Warteschlangenmanager separat erstellt wird, muss eine Warteschlange für nicht zustellbare Nachrichten (Dead Letter Queue, DLQ) definiert werden. WebSphere Event Broker verweist auf die DLQ, wenn bei der Verarbeitung von Nachrichten in Nachrichtenflüsse Fehler auftreten.
Wenn eine Nachricht in einem benutzerdefinierten Nachrichtenfluss oder in einem Publish/Subscribe-Modell nicht verarbeitet werden kann, wird sie als letzte Maßnahme an diese Warteschlange für nicht zustellbare Nachrichten weitergeleitet. Inaktivieren Sie die DLQ, wenn die Nachricht in die Eingabewarteschlange zurückgesetzt werden soll, um den Nachrichtenfluss bis zur Behebung des Fehlers wirkungsvoll anzuhalten.
Diese Warteschlange wird durch den Befehl mqsideletebroker nicht gelöscht (es sei denn, der Warteschlangenmanager wird gelöscht).
Bei der Verwendung eines WebSphere MQ-Warteschlangenmanagers, der unabhängig vom Befehl mqsicreatebroker erstellt wurde, können Sie bei Bedarf Cluster definieren. In den meisten Fällen wird Ihre Konfiguration dadurch vereinfacht.
Falls der Warteschlangenmanager durch diesen Befehl erstellt wurde, wird er nicht als Windows-Service gestartet; der Warteschlangenmanager wird deshalb gestoppt, sobald Sie sich abmelden. Um dies zu vermeiden, müssen Sie entweder angemeldet bleiben oder den Startstatus des Warteschlangenmanager-Service ändern. (Beim Sperren Ihrer Workstation wird der WebSphere MQ-Warteschlangenmanager nicht gestoppt.)
Wenn der Name eines unter z/OS erstellten Brokers in Großbuchstaben gesetzt ist, muss dieser Brokername in der Workbench ebenfalls in Großbuchstaben gesetzt sein.
Informationen zu Einschränkungen bei dem verwendeten Zeichensatz finden Sie unter In Befehlen zulässige Zeichen.Dieser Name kann in jeder gültigen Syntax für Benutzernamen angegeben werden. Auf Windows-Plattformen stehen folgende Möglichkeiten zur Auswahl:
Auf Linux- und UNIX-Systemen ist nur das Format Benutzername gültig.
Wenn Sie auf Windows-Plattformen für diese Benutzer-ID das unqualifizierte Format (Benutzername) verwenden, durchsucht das Betriebssystem seine Domänen nach dieser Benutzer-ID und beginnt dabei auf dem lokalen System. Dieser Suchvorgang kann einige Zeit in Anspruch nehmen.
Die angegebene Servicebenutzer-ID muss ein Element der lokalen Gruppe mqbrkrs sein. Auf Windows-Plattformen kann die ID ein direktes oder indirektes Mitglied der Gruppe sein. Die Servicebenutzer-ID muss auch für den Zugriff auf das Ausgangsverzeichnis, auf dem WebSphere Event Broker installiert wurde, und auf das Arbeitsverzeichnis autorisiert sein (falls durch das Flag -w angegeben).
Wenn Sie auf Windows-Plattformen angeben, dass der Broker als gesicherte WebSphere MQ-Anwendung ausgeführt werden soll (Flag -t), müssen Sie diese Benutzer-ID auch zu der Gruppe mqm hinzufügen. Auf Linux- und UNIX-Systemen muss als Servicebenutzer-ID mqm angegeben werden, wenn das Attribut -t gesetzt wird.
Weitere Informationen zu den Sicherheitsanforderungen für die Servicebenutzer-ID finden Sie im Abschnitt Sicherheitsanforderungen für Windows-Plattformen.
Wenn Sie diese Benutzer-ID für den Zugriff auf die Datenbank verwenden (d. h. wenn Sie keine andere Benutzer-ID mit dem Flag -u angeben) und Sie einen SQL-Server für Ihre Datenbanken verwenden, müssen Sie vor dem Erstellen des Brokers diese Benutzer-ID als Anmelde-ID für den SQL-Server erstellen und der Benutzer-ID die richtigen Zugriffsrechte zuordnen (weitere Informationen dazu finden Sie im Abschnitt Sicherheit für einen Broker planen). Wenn Ihre Brokerdatenbank in DB2 vorhanden ist, diese Benutzer-ID von DB2 aber nicht erkannt wird, wird die Benutzer-ID automatisch erstellt.
Um die Kompatibilität mit vorhandenen Systemen sicherzustellen, kann nach wie vor noch <Kennwort> angegeben werden. Wird jedoch bei Ausführung des Befehls kein Kennwort für diesen Parameter angegeben, werden Sie beim Aufrufen des Befehls aufgefordert, ein Kennwort anzugeben und dieses anschließend noch ein zweites Mal einzugeben, um sicherzustellen, dass es korrekt eingegeben wurde.
Auf Linux- und UNIX-Systemen ist -a aus Gründen der Kompatibilität mit Windows-Plattformen erforderlich, wird aber nicht mit der Servicebenutzer-ID verwendet; das Attribut wird nur dann als Standardwert verwendet, wenn für -p nichts angegeben wurde. (Weitere Informationen dazu finden Sie in den Hinweisen zu dem Parameter -p.)
Falls der Warteschlangenmanager nicht bereits vorhanden ist, wird er durch diesen Befehl erstellt. Er wird nicht als Standard-WS-Manager erstellt; ist dieser WS-Manager auf diesem System als Standard-WS-Manager vorgesehen, müssen Sie entweder den Warteschlangenmanager erstellen, bevor Sie diesen Befehl eingeben, oder die Einstellungen dieses Warteschlangenmanagers ändern, so dass er als Standard-WS-Manager eingerichtet wird. Dies geschieht mit dem WebSphere MQ-Explorer oder dem WebSphere MQ Services-Snap-in, je nachdem, welche Version von WebSphere MQ verwendet wird.
Das WS-Managerattribut MAXMSGLN (max. Länge der Nachrichten, die in Warteschlangen eingereiht werden können) wird auf 100 MB erhöht. Dies geschieht unabhängig davon, ob der Warteschlangenmanager mit diesem Befehl erstellt wurde.
Informationen zu Einschränkungen bei dem verwendeten Zeichensatz finden Sie unter In Befehlen zulässige Zeichen.
Diese Datenbank muss bereits vorhanden sein. Sie müssen für diesen Datenquellennamen eine Verbindung zu dem ODBC-Datenquellennamen eines Systems erstellen, falls diese Verbindung nicht bereits vorhanden ist.
Wenn Sie eine DB2-Datenbank unter Linux verwenden, geben Sie den entsprechenden Aliasnamen der Datenbank an; die Angabe eines ODBC-DSN ist nicht erforderlich.
Diese Benutzer-ID muss über die Berechtigung zum Erstellen von Tabellen in der Datenbank sowie über einen Schreib-/Lesezugriff auf diese Tabellen verfügen.
Wenn auf Windows-Plattformen Ihre Brokerdatenbank in DB2 vorhanden ist, die entsprechende Benutzer-ID von DB2 aber nicht erkannt wird, wird die Benutzer-ID für Sie erstellt. Auf Linux- und UNIX-Systemen muss dem Servicebenutzer zunächst das korrekte Zugriffsrecht erteilt werden. Wenn es sich bei Ihrer Datenbank um einen SQL-Server handelt, müssen Sie vor dem Erstellen des Brokers diese Benutzer-ID als Anmelde-ID des SQL-Servers erstellen und der Benutzer-ID die richtigen Zugriffsrechte erteilen (weitere Informationen dazu finden Sie im Abschnitt Sicherheitsanforderungen für Windows-Plattformen).
Wenn in DB2 eine Anwendungsdatenbank vorhanden ist, die mit dieser Benutzer-ID erstellt wurde oder für die diese Benutzer-ID über die entsprechenden Berechtigungen zum Lesen, Schreiben oder Erstellen verfügt, können die in diesem Broker ausgeführten Nachrichtenflüsse auf darin enthaltene Anwendungsdaten zugreifen und diese bearbeiten, ohne explizite Schemanamen angeben zu müssen.
Um die Kompatibilität mit vorhandenen Systemen sicherzustellen, kann nach wie vor noch <Kennwort> angegeben werden. Wird jedoch bei Ausführung des Befehls kein Kennwort für diesen Parameter angegeben, werden Sie beim Aufrufen des Befehls aufgefordert, ein Kennwort anzugeben und dieses anschließend noch ein zweites Mal einzugeben, um sicherzustellen, dass es korrekt eingegeben wurde.
Für DB2 auf Linux- und UNIX-Systemen können -u und -p als leere Zeichenfolgen (jeweils mit zwei Anführungszeichen "") angegeben werden. In diesem Fall werden WebSphere Event Broker von DB2 die Zugriffsrechte der Servicebenutzer-ID erteilt; daraus ergibt sich eine 'bereits bestätigte' Datenbankverbindung. Wenn der Parameter -a neben -u und -p als leere Zeichenfolge angegeben wird, werden von WebSphere Event Broker keinen Kennwörter gespeichert. Damit wird die sicherste Konfiguration erzeugt.
Dieses Verzeichnis wird auch für Tracesätze verwendet, die bei einer aktiven Tracefunktion erstellt wurden. Diese Tracesätze werden in das Unterverzeichnis Protokoll geschrieben, das vor dem Starten des Brokers erstellt werden muss.
Die von einem Broker bei einem abnormalen Prozessabbruch geschriebenen Fehlerprotokolle werden in diesem Verzeichnis gespeichert. Verwenden Sie auf Windows-Plattformen diese Option, um ein Verzeichnis auf einem Laufwerk anzugeben, auf dem das Produkt nicht installiert ist.
Das Fehlerprotokoll ist nicht begrenzt und wächst ständig an. Überprüfen Sie das Verzeichnis regelmäßig, und löschen Sie alte Fehlerinformationen.
Diese Option kann nicht mit Hilfe des Befehls mqsichangebroker geändert werden. Wenn Sie den Arbeitspfad angeben oder ändern möchten, müssen Sie den Broker löschen und erneut erstellen.
Wenn Sie diese Option auf Windows-Plattformen angeben, fügen Sie die Servicebenutzer-ID (durch das Flag -i gekennzeichnet) zu der Gruppe mqm hinzu. Wenn Sie diese Option unter HP-UX und Solaris verwenden, geben Sie die Servicebenutzer-ID als mqm an. Weitere Informationen zur Verwendung von gesicherten WebSphere MQ-Anwendungen finden Sie im Handbuch WebSphere MQ Intercommunication.
Sie müssen ein eigenes Verzeichnis zum Speichern der LIL- bzw. JAR-Dateien erstellen. Diese Dateien sollten nicht im WebSphere Event Broker-Installationsverzeichnis installiert werden.
Wenn Sie mehrere zusätzliche Verzeichnisse angeben, müssen diese durch das plattformspezifische standardmäßige Pfadtrennzeichen getrennt werden (Semikolon (;) auf Windows-Plattformen, Doppelpunkt (:) auf Linux- und UNIX-Systemen).
In diesem Pfad enthaltene Umgebungsvariablen werden ignoriert.
Wenn ein Nachrichtenfluss eine Anwendungsnachricht verarbeitet, kann er nicht auf eine Änderung in der Konfiguration reagieren. Wenn einer der Nachrichtenflüsse in der Ausführungsgruppe, die zur Änderung der Konfiguration aufgefordert wurde, die Verarbeitung einer Anwendungsnachricht nicht beendet und die Änderung der Konfiguration innerhalb des Zeitlimits ausführt, gibt die Ausführungsgruppe eine negative Antwort auf die implementierte Konfigurationsnachricht zurück.
Der Wert, den Sie für dieses Zeitlimit festlegen, ist von der Systemauslastung (einschließlich CPU-Auslastung) und von der Auslastung der einzelnen Ausführungsgruppen abhängig. Für eine anfängliche Schätzung können Sie die Gesamtkonfiguration des Brokers implementieren. Die bis zur erfolgreichen Beendigung erforderliche Zeit ist ein Richtwert dafür, welchen Wert Sie mindestens festlegen müssen.
Der Wert wird in Sekunden angegeben und liegt in dem Bereich zwischen 10 und 3600. Der Standardwert ist 300.
Die Summe von Konfigurationszeitlimit und Konfigurationszeitlimitverzögerung (unten beschrieben) stellt die maximale Dauer dar, in der ein Broker die Verarbeitung einer implementierten Konfigurationsnachricht durchführen kann, bevor eine negative Antwort generiert wird.
Damit wird die Zeit wiedergegeben, die für die Verarbeitung einer minimal implementierten Konfigurationsnachricht durch den Broker und die zugehörigen Ausführungsgruppen verwendet wird. Die Zeit hängt von den Verzögerungen im Netz der Warteschlangenmanager, von der Auslastung des Broker-Warteschlangenmanagers und von der Systemauslastung ab.
mqsireporttrace Brokername -e "Name_der_Ausführungsgruppe" -u
F MQP1BRK,reporttrace u=yes,e='exgrp1'
Die Reaktionszeit der einzelnen Ausführungsgruppen hängt von der Systemauslastung und von der Auslastung der eigenen Prozesse ab. Der von Ihnen festgelegte Wert muss die maximale Reaktionszeit einer Ausführungsgruppe wiedergeben. Wenn dabei ein zu hoher Wert angegeben wird, gibt der Broker eine negative Antwort zurück und schreibt möglicherweise Fehlernachrichten in das lokale Fehlerprotokoll.
Der Wert wird in Sekunden angegeben und liegt in dem Bereich zwischen 10 und 3600. Der Standardwert ist 60.
Befindet sich der Broker auf einem Produktionssystem, muss ein höherer Wert für Konfigurationszeitlimit und Konfigurationsverzögerungszeitlimit angegeben werden, damit Anwendungsnachrichten, die gerade von Nachrichtenflüssen verarbeitet werden, abgeschlossen werden können, bevor die Konfigurationsänderung übernommen wird.
Wenn sich der Broker auf einem Entwicklungs- oder Testsystem befindet, möchten Sie die Zeitlimitwerte (insbesondere das Konfigurationszeitlimit) möglicherweise verringern, um die erkannte Reaktionszeiten zu verbessern und um eine Reaktionszeit von einem Broker zu erhalten, der sich nicht wie erwartet verhält. Durch das Verringern der Zeitlimitwerte wird jedoch die Wahrscheinlichkeit der erfolgreichen Implementierung einer Konfigurationsänderung reduziert.
Das Empfangsprogramm wird vom Broker gestartet, wenn ein Nachrichtenfluss mit der Web-Serviceunterstützung gestartet wird, und hat einen Standardwert von 7080.
Stellen Sie sicher, dass der von Ihnen angegebene Port nicht für andere Aktionen definiert wurde.
Ein Intervall von null Minuten zeigt an, dass auf der Plattform eine externe Benachrichtigungsmethode und nicht der interne Zeitgeber von WebSphere Event Broker verwendet wird.
Auf Windows-Systemen muss die Benutzer-ID, mit der dieser Befehl aufgerufen wird, auf dem lokalen System über die Berechtigung Administrator verfügen.
Auf UNIX-Systemen muss die Benutzer-ID, mit der dieser Befehl aufgerufen wird, zur Gruppe mqbrkrs gehören.
Auf z/OS-Systemen muss die Benutzer-ID, mit der dieser Befehl aufgerufen wird, zu einer Gruppe gehören, die über Lese- und Schreibzugriff (READ und WRITE) auf das Komponentenverzeichnis verfügt.
Bei Verwendung von LDAP: Stellen Sie sicher, dass die Registrierungsdatenbank ausreichend gegen unbefugte Zugriffe geschützt ist. Ein korrekter Betrieb des Brokers ist nicht davon abhängig, ob die Optionen LDAP-Principal und LDAP-Berechtigungsweise im Befehl mqsicreatebroker gesetzt werden. Das Kennwort wird im Dateisystem nicht als Klartext abgespeichert.
Die WebSphere Event Broker-Gruppe mqbrkrs ist für den Zugriff auf alle diese Warteschlangen berechtigt. Eine aktive Warteschlange für nicht zustellbare Nachrichten verfügt über dieselben Berechtigungen.
Dieser Befehl gibt die folgenden Antworten zurück:
(51002)[IBM][CLI Driver][DB2/NT]SQL0805N Package "NULLID.SQLLF000" was not found. SQLSTATE=51002.
Dieser Fehler tritt auf, wenn die Bindung an die Datenbank nicht erfolgreich ist.
Auf Windows-Plattformen muss die Bindung für Brokerdatenbanken nicht vorhanden sein, sie ist jedoch für Benutzerdatenbanken erforderlich. Bei der Erstellung der Datenbank mit Hilfe der DB2-Steuerzentrale wird die Bindung für Sie beendet. Dies ist bei Verwendung der Befehlsschnittstelle nicht der Fall. Sie können beispielsweise für die Datenbank MYDB eine Bindung erstellen oder erneut erstellen, indem Sie in der Eingabeaufforderung folgende Befehle eingeben:
db2 connect to MYDB user db2admin using db2admin db2 bind X:\sqllib\bnd\@db2cli.lst grant public db2 connect reset
Dabei ist X: das Laufwerk, auf dem DB2 installiert ist.
Auf UNIX-Plattformen ist die Bindung für alle Datenbanken erforderlich. Für die Datenbank WBRKBKDB beispielsweise werden dazu an der Eingabeaufforderung die folgenden Befehle eingegeben (dabei ist <Benutzername> die Benutzer-ID unter der die Datenbankinstanz erstellt wurde):
db2 connect to WBRKBKDB user db2admin using db2admin
db2 bind ~<Benutzername>/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
db2 connect reset
Wenn Sie die Standardeinstellungen für Benutzer-ID und Kennwort (db2admin) unter DB2 nicht verwenden, müssen Sie diese Werte im Befehl db2 connect durch die richtigen Werte ersetzen.
Wenn Sie den Befehl mqsicreatebroker wegen eines Fehlers ein zweites Mal ausführen, erhalten Sie eine Reihe von Nachrichten. Darin wird angegeben, dass keine Elemente erstellt werden können. Dies sollte jedoch keine negativen Auswirkungen haben. Beispiel: Wenn der Grund für das erste Fehlschlagen bei der Erstellung eines Brokers behoben wurde, sollte bei einem erneuten Versuch der Broker korrekt erstellt werden.