Es ist wichtig, die Nachrichten zu schützen, welche die Brokerdomäne passieren. Dies gilt sowohl für von Anwendungen generierte Nachrichten als auch für diejenigen, die intern für die Kommunikation zwischen Komponenten verwendet werden. Letztere nutzen immer das WebSphere MQ-Protokoll. Anwendungsnachrichten können alle unterstützten Übertragungsprotokolle verwenden.
Bei Anwendungsnachrichten und internen Nachrichten, die WebSphere MQ durchlaufen, schützen zwei Verfahren vor Nachrichtenverlust:
Wenn eine Nachricht persistent ist, stellt WebSphere MQ sicher, dass sie beim Auftritt eines Fehlers nicht verlorengeht, indem sie auf Festplatte kopiert wird.
Eine Anwendung kann anfordern, dass eine Nachricht in einer synchronisierten Arbeitseinheit verarbeitet wird.
Weitere Informationen zur Verwendung dieser Optionen finden Sie im Handbuch WebSphere MQSystem Administration Guide.
WebSphere Event Broker-Komponenten nutzen WebSphere MQ-Nachrichten zum Übertragen von Ereignissen und Daten zwischen Brokerprozessen und Subsystemen und zwischen Konfigurationsmanager und Benutzernamensserver. Die Komponenten stellen sicher, dass die WebSphere MQ-Funktionen zum Schutz vor Datenverlust genutzt werden. Sie müssen keine weiteren Schritte unternehmen, um WebSphere MQ oder WebSphere Event Broker für den Schutz vor Verlust interner Nachrichten zu konfigurieren.
Wenn die Übermittlung von Anwendungsnachrichten wichtig ist, müssen Sie Anwendungsprogramme und Nachrichtenflüsse dafür erstellen, um sicherzustellen, dass sie nicht verlorengehen. Die verwendeten Verfahren hängen vom Protokoll ab, das von den Anwendungen genutzt wird.
WebSphere MQ-Messaging-Produkte bieten Nachrichtenpersistenz, welche die Langlebigkeit der Nachricht im System bestimmt und die Nachrichtenintegrität garantiert. Nicht persistente Nachrichten gehen im Falle eines System- oder Warteschlangenmanagerausfalls verloren. Persistente Nachrichten werden im Falle eines Ausfalls immer wiederhergestellt.
Wenn ein Empfangsknoten liest, dass eine Nachricht von einer Eingabewarteschlange gelesen wird, besteht die Standardaktion darin, die Persistenz zu verwenden, die im WebSphere MQ-Nachrichtenheader (MQMD) definiert wurde, der entweder von der Anwendung festgelegt wurde, welche die Nachricht erstellt, oder von der Standardpersistenz der Eingabewarteschlange. Die Nachricht behält diese Persistenz während des gesamten Nachrichtenflusses bei, es sei denn, sie wird in einem nachfolgenden Nachrichtenverarbeitungsknoten verändert.
Der Persistenzwert jeder Nachricht kann überschrieben werden, wenn der Nachrichtenfluss bei einem Sendeknoten endet. Dieser Knoten verfügt über eine Eigenschaft, mit der Sie die Nachrichtenpersistenz jeder Nachricht angeben können, wenn sie in die Ausgabewarteschlange eingereiht wird - entweder als erforderlicher Wert oder als ein Standardwert. Wenn Sie den Standardwert angeben, nimmt die Nachricht den Wert an, der für die Warteschlangen definiert wurde, in welche die Nachrichten geschrieben werden.
Wenn eine Nachricht einen Veröffentlichungsknoten passiert, wird die Persistenz von Nachrichten, die Subskribenten gesendet werden, durch die Registrierungsoptionen der Subskribenten bestimmt. Wenn ein Subskribent die Übermittlung einer persistenten Nachricht angefordert hat und dazu durch implizite (übernommene) oder explizite ACL autorisiert ist, wird die Nachricht persistent übermittelt, unabhängig von ihrem vorhandenen Persistenzmerkmal. Und wenn der Benutzer die Übermittlung einer nicht persistenten Nachricht angefordert hat, wird die Nachricht nicht persistent übermittelt, unabhängig von ihrem vorhandenen Persistenzmerkmal.
Die Standardaktion eines Nachrichtenflusses besteht darin, eingehende Nachrichten unter dem Synchronisationspunkt in einem durch einen Broker kontrollierten Arbeitsgang zu verarbeiten. Dies bedeutet, dass eine Nachricht, die aus irgendeinem Grund nicht verarbeitet wird, vom Broker zurückgesetzt wird. Da sie unter dem Synchronisationspunkt empfangen wurde, wird sie erneut in die Eingabewarteschlange eingereiht und kann wieder verarbeitet werden. Schlägt die Verarbeitung fehl, werden die Fehlerbehandlungsprozeduren für diesen Nachrichtenfluss (entweder durch Ihre Konfiguration des Nachrichtenflusses oder durch den Broker definiert) ausgeführt.
Weitere Informationen zur Empfangsknotenverarbeitung finden Sie unter Fehler im Empfangsknoten verwalten.
Wird eine persistente SCADA-Nachricht publiziert, wird unter Umständen für sie ein Downgrade für die höchste vom Client annehmbare Ebene durchgeführt. In einigen Fällen kann das bedeuten, dass die Nachricht nicht mehr persistent ist.