Verlust von Nachrichten verhindern

Nachrichten, die Ihre Brokerdomäne durchlaufen, sind Geschäftsdaten, die geschützt werden müssen. Konfigurieren Sie die Nachrichten und/oder Ihre Umgebung, um sicherzustellen, dass keine Nachrichten verloren gehen.

Nachrichten, die von Ihren Anwendungen und von Laufzeitkomponenten für die interne Kommunikation zwischen Komponenten generiert werden, sind für den Betrieb Ihrer Broker wichtig. Für interne Nachrichten zwischen Komponenten wird immer das WebSphere MQ-Protokoll verwendet. Anwendungsnachrichten können alle unterstützten Transportprotokolle nutzen.

Bei Anwendungs- und internen Nachrichten, die durch WebSphere MQ transportiert werden, schützen zwei Verfahren vor Nachrichtenverlusten:

Weitere Informationen zur Verwendung dieser Optionen finden Sie im Abschnitt System Administration Guide des WebSphere MQ Version 6 Information Center online oder im Version 5.3-Handbuch auf der Webseite der Bibliothek zu WebSphere MQ.

Interne Nachrichten

WebSphere Event Broker-Komponenten verwenden WebSphere MQ-Nachrichten, um Ereignisse und Daten zwischen Brokerprozessen und Subsystemen sowie dem Konfigurationsmanager und Benutzernamensserver zu übertragen. Die Komponenten stellen sicher, dass die WebSphere MQ-Funktionen zum Schutz vor Nachrichtenverlusten genutzt werden. Es sind keine zusätzlichen Schritte erforderlich, um WebSphere MQ oder WebSphere Event Broker für den Schutz vor dem Verlust interner Nachrichten zu konfigurieren.

Anwendungsnachrichten

Wenn die Zustellung von Anwendungsnachrichten ein kritischer Aspekt ist, müssen Sie Anwendungsprogramme und die von diesen verwendeten Nachrichtenflüsse entwerfen, um sicherzustellen, dass keine Nachrichten verloren gehen. Die eingesetzten Verfahren sind von dem Protokoll abhängig, das von den Anwendungen verwendet wird.

WebSphere MQ Enterprise Transport und WebSphere MQ Mobile Transport
Beachten Sie bei Verwendung der integrierten Empfangsknoten, die Nachrichten über die WebSphere MQ- oder WebSphere MQ Everyplace-Protokolle annehmen, die folgenden Richtlinien und Empfehlungen:
  • Verwenden persistenter Nachrichten

    WebSphere MQ-Nachrichtenübertragungsprodukte bieten Nachrichtenpersistenz, mit der die Langlebigkeit der Nachricht im System definiert und die Nachrichtenintegrität garantiert wird. Nicht persistente Nachrichten gehen im Falle eines System- oder Warteschlangenmanagerfehlers verloren. Persistente Nachrichten werden nach einem Fehler immer wiederhergestellt.

    Sie können die Nachrichtenpersistenz auf folgende Weise steuern:
    • Programmieren Sie Anwendungen, die Nachrichten über MQI oder AMI in eine Warteschlange stellen, sodass die Nachrichten als persistent gekennzeichnet werden.
    • Definieren Sie die Eingabewarteschlange mit Nachrichtenpersistenz als Standardeinstellung.
    • Konfigurieren Sie den Sendeknoten so, dass er persistente Nachrichten bearbeitet.
    • Programmieren Sie Subskribentenanwendungen so, dass Nachrichtenpersistenz angefordert wird.

    Wenn ein Empfangsknoten eine Nachricht aus einer Eingabewarteschlange liest, wird standardmäßig die im WebSphere MQ-Nachrichtenheader (MQMD) definierte Persistenz verwendet, die entweder von der Anwendung, die die Nachricht erstellt hat, oder durch die standardmäßige Persistenz der Eingabewarteschlange festgelegt wurde. Die Nachricht behält diese Persistenz während des Transport durch den gesamten Nachrichtenfluss, sofern dies nicht in einem nachfolgenden Nachrichtenverarbeitungsknoten geändert wird.

    Sie können den Persistenzwert für jede einzelne Nachricht überschreiben, wenn der Nachrichtenfluss an einem Sendeknoten endet. Dieser Knoten besitzt eine Eigenschaft, über die Sie die Nachrichtenpersistenz jeder Nachricht angeben können, wenn sie in die Ausgabewarteschlange gestellt wird, indem Sie die Eigenschaft entweder auf den gewünschten Wert oder einen Standardwert setzen. Wenn Sie den Standardwert angeben, erhält die Nachricht den Persistenzwert, der für die Warteschlangen, in die die Nachrichten geschrieben werden, definiert ist.

    Beim Transport einer Nachricht durch einen Publication-Knoten wird die Persistenz von Nachrichten, die an Subskribenten gesendet werden, durch die Registrierungsoptionen des Subskribenten festgelegt. Wenn der Subskribent eine persistente Nachrichtenzustellung angefordert hat und dazu durch eine explizite oder implizite (übernommene) Zugriffssteuerungsliste berechtigt ist, wird die Nachricht unabhängig vom aktuellen Wert der Persistenzeigenschaft persistent zugestellt. Ebenso gilt, dass die Nachricht unabhängig vom aktuellen Wert der Persistenzeigenschaft nicht persistent zugestellt wird, wenn der Benutzer eine nicht persistente Nachrichtenzustellung angefordert hat.

  • Verarbeiten von Nachrichten unter Synchronisationspunktsteuerung

    Standardmäßig verarbeitet ein Nachrichtenfluss eingehende Nachrichten synchronisationspunktgesteuert in einer brokerverwalteten Transaktion. Das heißt, dass eine Nachricht, die aus irgendeinem Grund nicht verarbeitet werden kann, vom Broker zurückgesetzt wird. Da sie unter Synchronisationspunktsteuerung empfangen wurde, wird die fehlerhafte Nachricht in der Eingabewarteschlange wiederhergestellt und kann erneut verarbeitet werden. Schlägt die Verarbeitung fehl, werden die Fehlerbehandlungsprozeduren ausgeführt, die für diesen Nachrichtenfluss aktiv sind (und entweder von Ihnen bei der Konfiguration des Nachrichtenflusses oder vom Broker definiert wurden).

    Weitere Informationen zur Empfangsknotenverarbeitung finden Sie unter Fehler im Empfangsknoten verwalten.

WebSphere MQ Telemetry Transport
Beachten Sie bei Verwendung des SCADAInput-Knotens, der Nachrichten von Telemetrieeinheiten über das MQIsdp-Protokoll annimmt, dass dieses Protokoll nicht über ein Warteschlangenkonzept verfügt. Clients stellen eine Verbindung mit einem SCADAInput-Knoten her, indem Sie die Portnummer angeben, an der der Knoten empfangsbereit ist. Nachrichten werden unter Verwendung einer Client-ID an Clients gesendet. Sie können in einer SCADA-Subskriptionsnachricht jedoch einen maximalen QoS (Quality of Service) angeben, der mit der Persistenz vergleichbar ist:
  • QoS0 Nicht persistent.
  • QoS1 Persistent, aber mehrfache Zustellung möglich
  • QoS2 Garantiert einmalige Zustellung

Wenn eine persistente SCADA-Nachricht veröffentlicht wird, wird ein Downgrade auf die höchste vom Client akzeptierte Stufe durchgeführt. Unter bestimmten Umständen kann die Nachricht zu einer nicht persistenten Nachricht werden.

WebSphere MQ Real-time Transport und WebSphere MQ Multicast Transport
Wenn Sie die Knoten Real-timeInput und Real-timeOptimizedFlow verwenden, die Nachrichten von JMS und Multicasting-Anwendungen annehmen, sind keine Einsatzmittel zum Schutz vor Datenverlust verfügbar. Sie können jedoch Wiederherstellungsprozeduren bereitstellen, indem Sie für den Nachrichtenfluss eine Fehlerbehandlung für eigene Fehler konfigurieren.
Andere Übertragungsmethoden und -protokolle
Bei benutzerdefinierten Empfangsknoten, die Nachrichten von einem anderen Übertragungsprotokoll empfangen, müssen Sie sich auf die Unterstützung verlassen, die von diesem Protokoll bereitgestellt wird, oder die Wiederherstellungsprozeduren verwenden, die vom Anbieter der benutzerdefinierten Knoten bereitgestellt werden.
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. Alle Rechte vorbehalten.
Letzte Aktualisierung : 2009-02-17 15:49:20

ac00420_