元の要求メッセージの ReplyToQ と相関 ID の値を後で取り出せるよう、これらの値を JMS メッセージに保存する際には、ReplyToQ と相関 ID の詳細情報のみが保存されるのではなく、JMSHeader 全体が保存されます。 JMSHeader 全体が保存される理由は、ReplyToQ と相関 ID の 2 つの値を保管して取り出す必要があるにもかかわらず、JMSReceive ノードが保管して取り出せるのは 1 つの値のみだからです。 したがって、個々の値を保存する代わりに、必要な値の入った構造を保存しなければなりません。 異なる値を保管するようにサンプルを変更する際には、JMSReceive ノードの動作を考慮する必要があります。
このサンプルで提供されているサブフローのインプリメンテーションの代わりに、Request および Reply フローで使用されるサブフローの独自のインプリメンテーションを使用できます。 例えば、最初の要求メッセージから ReplyToQ 詳細情報を保管するためにデータベースを使用することもできます。 代わりに、ReplyToQ および相関 ID を JMS メッセージに保管して取り出すためのサブフローを、他のメッセージ・フローで使用することもできます。
ご使用のメッセージ・フロー内で StoreOriginalJMSHeader_Sub サブフローを使用できます。 このサブフローは、JMS メッセージ内に JMSHeader を保存するのと同じ方法で機能します。 要求メッセージの JMSHeader を保存するには、JMSHeader が使用されるメッセージ・フロー内の適切なポイントでサブフローを組み込む必要があります。 変更を加えずにサブフローを組み込めますが、以下の考慮事項に注意しなければなりません。
変更できる重要なパラメーターは上に示すとおりですが、サブフロー内のノードのパラメーター設定をすべて調べて、実際の要件との互換性を確認する必要があります。
代替的なデータ保管機能を使用するように、サブフローを変更できます。 例えば、JMS メッセージを書き込む代わりにデータベースを使用することを選択する場合、サブフローはデータベースにデータを挿入する必要があります。
保管機能を変更すると、サブフローのパフォーマンス特性が変わります。 選択したインプリメンテーションの特性がメッセージ・フローのパフォーマンス要件にかなったものかどうかを確認することは重要です。 データベースを使って情報を保持する場合、データベースに挿入するたびにデータベース・マネージャー・ログへの書き込みが必要になるので、パフォーマンスが入出力制約を受ける可能性は高くなります。
代わりの保管機能を使用すると、サブフローのトランザクションのプロパティーにも変化が生じるかもしれません。JMS メッセージを使ってデータを保管する場合、メッセージ・フローの別の箇所で読み取られる JMS メッセージと同じリソース・マネージャーが使用されます。 JMS メッセージがメッセージ・フローでのみ処理される場合には、単一のリソース・マネージャーが使用されます。 データベースまたは他のリカバリー可能リソース・マネージャーを使用する場合、データ保全性を確保するため、WebSphere Message Broker キュー・マネージャーと、データ保管先のデータベースのデータベース・マネージャーとの間で、2 フェーズ・コミット・リカバリー・プロトコルが必要になります。
変更を加える際には、サブフロー内のノードのパラメーター設定をすべて検討し、実際の要件と互換性のある設定になっているかどうかを確認する必要があります。
RestoreOriginalJMSHeader_Sub サブフローを他のメッセージ・フロー内で使用して、JMS メッセージから最初の要求メッセージの JMSHeader を取り出すことができます。 JMSHeader を取り出すには、MQMD が使用されるメッセージ・フロー内の適切なポイントでサブフローを組み込む必要があります。 変更を加えずにサブフローを組み込めますが、以下の考慮事項に注意しなければなりません。
変更する可能性のある重要なパラメーターは上に示すとおりですが、サブフロー内のノードのパラメーター設定をすべて調べて、実際の要件との互換性を確認する必要があります。
代替的なデータ保管機能を使用するようにサブフローを変更できます。 例えば、JMSReceive ノードを使って JMS メッセージを読み取る代わりにデータベースを使用することを選択する場合、サブフローはデータベースからデータを読み取ることができます。
保管機能を変更すると、サブフローのパフォーマンス特性が変わります。 選択したインプリメンテーションの特性がメッセージ・フローのパフォーマンス要件にかなったものかどうかを確認することは重要です。 データベースを使用して情報を保持すると、インプリメンテーションに応じてさまざまなオーバーヘッドが加わる可能性があります。 データベース・インプリメンテーションの場合、読み取りを使ってデータを取り出すだけで、更新や削除は行わないようにすれば、オーバーヘッドは最小限になります。 ただし、データベースからデータを削除しないと、データベースのサイズは大きくなり続け、ハウスキーピングを実行しない限り使用時に次第に低速になります。 取り出し処理の際、データが取り出されたことを示すために行を更新したり、行を削除したりする場合には、データベース・マネージャー・ログへの書き込みが処理に含まれることになり、結果として読み取り専用の場合よりはるかに大きな処理オーバーヘッドが生じます。
代わりの保管機能を使用すると、サブフローのトランザクションのプロパティーにも変化が生じるかもしれません。JMS メッセージを使ってデータを保管する場合、メッセージ・フローの別の箇所で読み取られる JMS メッセージと同じリソース・マネージャーが使用されます。 JMS メッセージがメッセージ・フローでのみ処理される場合には、ただ 1 つのリソース・マネージャーが使用されます。 データベースまたは他のリカバリー可能リソース・マネージャーを使用する場合、データ保全性を確保するため、WebSphere Message Broker キュー・マネージャーと、データ保管先のデータベースのデータベース・マネージャーとの間で、2 フェーズ・コミット・リカバリー・プロトコルを使用する必要があります。
サブフロー内のノードのパラメーター設定をすべて検討し、実際の要件と互換性のある設定になっているかどうかを確認する必要があります。