Wenn die Werte für ReplyToQ und die Korrelations-ID der ursprünglichen Anforderungsnachricht in einer JMS MQ-Nachricht für eine spätere Abfrage gespeichert werden, wird dabei der gesamte JMSHeader gespeichert und nicht nur die Details von ReplyToQ und der Korrelations-ID. Dies ist darauf zurückzuführen, dass zwei Werte (ReplyToQ und die Korrelations-ID) gespeichert und abgerufen werden müssen, während der JMSReceive-Knoten nur einen einzelnen Wert speichern oder abrufen kann. Daher muss statt der einzelnen Werte die Struktur gespeichert werden, die die erforderlichen Werte enthält. Wenn Änderungen am Mustercode vorgenommen werden, um verschiedene Werte zu speichern, müssen Sie das Verhalten des JMSReceive-Knotens berücksichtigen.
Sie können die im Mustercode bereitgestellten Implementierungen durch Ihre eigenen Implementierungen der untergeordneten Nachrichtenflüsse ersetzen, die in den Anforderungs- und Antwortnachrichtenflüssen verwendet werden. Beispielsweise können Sie eine Datenbank zum Speichern von ReplyToQ-Details der ersten Anforderungsnachricht verwenden. Als Alternative dazu können die untergeordneten Nachrichtenflüsse verwendet werden, die zum Speichern und Abrufen von ReplyToQ und der Korrelations-ID in einer JMS-Nachricht in anderen Nachrichtenflüssen genutzt werden.
Sie können den untergeordneten Nachrichtenfluss 'StoreOriginalJMSHeader_Sub' in Ihren Nachrichtenflüssen verwenden; dieser untergeordnete Nachrichtenfluss verhält sich genau wie beim Speichern des Headers 'JMSHeader' in einer JMS-Nachricht. Um den JMSHeader der Anforderungsnachricht zu speichern, muss der untergeordnete Nachrichtenfluss an der entsprechenden Stelle in dem Nachrichtenfluss eingeschlossen werden, in dem er verwendet werden soll. Sie können den untergeordneten Nachrichtenfluss unverändert einschließen, müssen jedoch folgende Punkte berücksichtigen:
Obwohl die Schlüsselparameter, die Sie ändern können, im vorherigen Text angegeben wurden, müssen Sie alle Parametereinstellungen auf Knoten innerhalb des untergeordneten Nachrichtenflusses überprüfen, um sicherzustellen, dass diese mit Ihren Anforderungen kompatibel sind.
Sie können den untergeordneten Nachrichtenfluss dahingehend ändern, dass er eine alternative Speichereinrichtung für die Daten nutzt. Beispielsweise können Sie eine Datenbank wählen, in die der untergeordnete Nachrichtenfluss Daten einfügt, anstatt eine JMS-Nachricht zu schreiben.
Mit der Änderung der Speichereinrichtung ändern sich die Leistungsmerkmale des untergeordneten Nachrichtenflusses. Es ist wichtig sicherzustellen, dass die Merkmale der von Ihnen ausgewählten Implementierung mit den Leistungsanforderungen für den Nachrichtenfluss übereinstimmen. Die Verwendung einer Datenbank zum Speichern von Informationen führt dazu, dass die Leistung im Verarbeitungsprozess eher E/A-gebunden ist, da für jeden Eintrag in die Datenbank auch ein Eintrag in das Datenbankmanagerprotokoll erforderlich ist.
Durch die Verwendung einer alternativen Speichermöglichkeit können auch die transaktionsorientierten Eigenschaften des untergeordneten Nachrichtenflusses geändert werden. Wenn Daten mithilfe einer JMS-Nachricht gespeichert werden, verwendet diese denselben Ressourcenmanager wie die JMS-Nachrichten, die an anderer Stelle im Nachrichtenfluss gelesen werden. Wenn die Verarbeitung der JMS-Nachrichten nur im Nachrichtenfluss ausgeführt wird, ist nur ein einzelner Ressourcenmanager involviert. Bei Verwendung einer Datenbank oder eines anderen wiederherstellbaren Ressourcenmanagers ist es erforderlich, dass ein Wiederherstellungsprotokoll für eine zweiphasige Festschreibung zwischen dem Warteschlangenmanager für WebSphere Message Broker und dem Datenbankmanager der Datenbank, in der Daten gespeichert werden, verwendet wird, um die Datenintegrität sicherzustellen.
Wenn Sie Änderungen vornehmen, müssen Sie alle Parametereinstellungen auf den Knoten überprüfen, um sicherzustellen, dass sie Ihre Anforderungen erfüllen.
Sie können den untergeordneten Nachrichtenfluss 'RestoreOriginalJMSHeader_Sub' in anderen Nachrichtenflüssen verwenden, um den JMSHeader der ursprünglichen Anforderungsnachricht aus einer JMS-Nachricht abzurufen. Um den JMSHeader abzurufen, muss der untergeordnete Nachrichtenfluss an der entsprechenden Stelle in dem Nachrichtenfluss eingeschlossen werden, in dem er verwendet werden soll. Sie können den untergeordneten Nachrichtenfluss unverändert einschließen, müssen jedoch folgende Punkte berücksichtigen:
Obwohl die Schlüsselparameter, die Sie möglicherweise ändern möchten, im vorherigen Text angegeben wurden, müssen Sie alle Parametereinstellungen auf Knoten innerhalb des untergeordneten Nachrichtenflusses überprüfen, um sicherzustellen, dass diese mit Ihren Anforderungen kompatibel sind.
Sie können den untergeordneten Nachrichtenfluss dahingehend ändern, dass er eine alternative Speichereinrichtungen für die Daten nutzt. Beispielsweise können Sie eine Datenbank verwenden, aus der der untergeordnete Nachrichtenfluss Daten liest, anstatt mithilfe des JMSReceive-Knotens eine JMS-Nachricht zu lesen.
Mit der Änderung der Speichereinrichtung ändern sich die Leistungsmerkmale des untergeordneten Nachrichtenflusses. Es ist wichtig sicherzustellen, dass die Merkmale der von Ihnen ausgewählten Implementierung mit den Leistungsanforderungen für den Nachrichtenfluss übereinstimmen. Durch die Verwendung einer Datenbank zum Speichern der Informationen kann abhängig von der Implementierung ein anderer Verarbeitungsaufwand hinzu kommen. Wenn Daten mithilfe eines Lesevorgangs abgerufen und nicht aktualisiert oder gelöscht werden, ist der Verarbeitungsaufwand für eine Datenbankimplementierung am geringsten. Wenn Daten jedoch nicht aus der Datenbank gelöscht werden, wird die Datenbank immer größer und langsamer in der Verwendung, solange keine Verwaltung eingerichtet wird. Wenn beim Abrufprozess eine Zeile aktualisiert oder gelöscht werden muss, um zu zeigen, dass die Daten abgerufen wurden, impliziert dies, dass in das Datenbankmanagerprotokoll geschrieben wird, wodurch ein bedeutend größerer Verarbeitungsaufwand entsteht als beim reinen Lesevorgang.
Durch die Verwendung einer alternativen Speichermöglichkeit können auch die transaktionalen Eigenschaften des untergeordneten Nachrichtenflusses geändert werden. Wenn Daten mithilfe einer JMS-Nachricht gespeichert werden, verwendet diese denselben Ressourcenmanager wie die JMS-Nachrichten, die an anderer Stelle im Nachrichtenfluss gelesen werden. Wenn die Verarbeitung der JMS-Nachrichten nur im Nachrichtenfluss ausgeführt wird, ist nur ein einzelner Ressourcenmanager involviert. Bei der Verwendung einer Datenbank oder eines anderen wiederherstellbaren Ressourcenmanagers ist es erforderlich, ein Wiederherstellungsprotokoll für eine zweiphasige Festschreibung zwischen dem WS-Manager für WebSphere Message Broker und dem Datenbankmanager der Datenbank, in der Daten gespeichert werden, zu verwenden, um die Datenintegrität sicherzustellen.
Sie müssen alle Parametereinstellungen auf den Knoten innerhalb des untergeordneten Nachrichtenflusses überprüfen, um sicherzustellen, dass sie Ihre Anforderungen erfüllen.