Verlust von Nachrichten verhindern

Es muss sichergestellt sein, dass Nachrichten, die durch eine Brokerdomäne fließen, nicht verloren gehen. Dies gilt sowohl für von Anwendungen generierte Nachrichten als auch für Nachrichten, die intern für die Kommunikation zwischen Komponenten verwendet werden. 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 Handbuch WebSphere MQ System Administration Guide.

Interne Nachrichten

WebSphere Message Broker-Komponenten verwenden WebSphere MQ-Nachrichten, um Ereignisse und Daten zwischen Brokerprozessen und Sybsystemen 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 Message 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, so dass 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 Veröffentlichungsknoten 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.

    Wenn ein Nachrichtenfluss eine neue Nachricht erstellt (z. B. in einem Rechenknoten), wird die Persistenz im MQMD der neuen Nachricht aus der Persistenz im MQMD der eingehenden Nachricht kopiert.

  • 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 integrierten SCADAEmpfangsknotens, der Nachrichten von Telemetrieeinheiten über das MQIsdp-Protokoll annimmt, dass dieses Protokoll nicht über ein Warteschlangenkonzept verfügt. Clients stellen eine Verbindung mit einem SCADAEmpfangsknoten 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 dies bedeuten, dass die Nachricht zu einer nicht persistenten Nachricht wird.

WebSphere MQ Real-time Transport, WebSphere MQ Multicast Transport und WebSphere MQ Web Services Transport
Bei Verwendung der integrierten Empfangsknoten für Echtzeiteingabe (Real-timeInput-Knoten) und EchtzeitoptimierterFluss (Real-timeOptimizedFlow-Knoten), die Nachrichten von JMS- und Multicasting-Anwendungen annehmen, oder des HTTPEmpfangsknotens und HTTPAnforderungsknotens, die Nachrichten von Web-Service-Anwendungen annehmen, stehen keine Funktionen zum Schutz vor Nachrichtenverlusten zur Verfügung. Sie können jedoch Wiederherstellungsprozeduren bereitstellen, indem Sie für den Nachrichtenfluss eine Fehlerbehandlung für eigene Fehler konfigurieren.
Sonstige Transportmethoden und Protokolle
Wenn Sie eigene benutzerspezifische Empfangsknoten, die Nachrichten von anderen Transportprotokollen empfangen, erstellt haben, müssen Sie auf die vom jeweiligen Transportprotokoll bereitgestellte Unterstützung zurückgreifen oder eigene Wiederherstellungsprozeduren zur Verfügung stellen.
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac00420_