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