メッセージ・フローは、業務および操作の要件に応じて、広範囲にわたる操作を実行することができます。
パフォーマンスと機能を最大化するには、最適なノードを組み込むように設計する必要があります。
メッセージ・フローの設計の際には、以下の質問およびオプションを考慮してください。
- ブローカーが作業をしているモードによって、使用可能なノード・タイプ、およびデプロイできるメッセージ・フロー数が影響を受ける可能性があります。 詳しくは、各動作モードに適用される制約事項を参照してください。
- 必要な機能を提供するノードはどれか。 多くの場合、適切な機能を提供する複数のノードから選択することができます。
ここにリストされている他の要因を検討して、
どのノードが自分の必要を全体的に満たす最善の機能かを判断する必要があるかもしれません。 組み込みノード、ユーザー定義ノード、およびサブフロー・ノードを組み込むことができます。 詳しくは、使用するノードの決定を参照してください。
- 複数の入力ノードを含めるのが適切かどうか。
詳しくは、複数の入力ノードの使用を参照してください。
- 入力メッセージの特性を指定する方法。 詳しくは、入力メッセージ特性の定義を参照してください。
- メッセージの内容または特性に基づくメッセージ・フローを介して、メッセージが続くパスを判別するかどうか。
いくつかのノードは、メッセージを検査または調査し、特定のメッセージを別のノードに送信するために接続可能な出力ターミナルを持っています。 詳しくは、ノードを使用した意思決定を参照してください。
- よく定義された処理のサブセットを提供するサブフローを使用できるかどうか。 別のプロジェクト用に作成されたサブフロー (例えばエラー処理ルーチンなど) を再利用することが
できる場合があります。または、現行プロジェクトでサブフローを作成し、同じメッセージ・フロー内の複数の場所で再利用できるかもしれません。 詳しくは、サブフローを参照してください。
- メッセージ・フローからアプリケーションが予期する応答時間。
この要因は、ノードおよびメッセージ・フローの構成方法のいくつかの局面に影響されます。
詳しくは、メッセージ・フロー応答時間の最適化を参照してください。
- メッセージ・フローの処理がシステム・リソースに負担をかけるかどうか (スタック・サイズなど)。詳しくは、メッセージ・フローの作成に関するシステム・リソースを参照してください。
- メッセージに関連したローカル環境内の宛先リストを使用して、メッセージ・フロー内の処理 (例えば RouteToLabel および Label ノードを使用) または出力メッセージのターゲット (例えば、MQOutput ノードの「宛先モード」プロパティーを「宛先リスト」 に設定する) を決定できるかどうか。 詳しくは、宛先リストの作成を参照してください。
- WebSphere MQ クラスター・キューを使用するかどうか。 詳しくは、入出力に WebSphere MQ クラスター・キューを使用するを参照してください。
- WebSphere MQ 共用キューを z/OS® 上で使用するかどうか。 詳しくは、入出力に WebSphere MQ 共用キューを使用する (z/OS)を参照してください。
- 入力ノードで受信される入力メッセージや、Compute ノードで生成される出力メッセージ (またはこの両方) を検証するかどうか。
詳しくは、メッセージの妥当性検査を参照してください。
- Trace ノード出力内のメッセージ構造を表示または記録するかどうか。
詳しくは、トレース出力に論理メッセージ・ツリーを表示するを参照してください。
- メッセージ・フローがデータベース内のデータにアクセスするかどうか。 この機能を有効化するには、データベースの処理の説明に従って、ブローカー、データベース、およびデータベース接続を構成する必要があります。 また、メッセージ・フローも構成する必要があります。メッセージ・フローからデータベースへのアクセスを参照してください。
ESQL を使用するノードを組み込む場合は、適切なステートメントをコーディングする方法についてESQL からデータベースへのアクセスを参照してください。JDBC を使用して、Java™ ノードからデータベースにアクセスする予定の場合、JavaCompute ノードを使用したデータベースとの対話または Java メッセージ処理または出力ノードの機能の拡張を参照してください。
- メッセージ・フローが、ファイル内のデータにアクセスするかどうか。
FileInput および FileOutput ノードを使用することによって、メッセージ・フローは、ローカル・ファイル・システム内のファイルとの間や、ブローカーに対してローカルで表示されるネットワーク・ファイル・システム上のファイルとの間で、メッセージの読み取りと書き込みを行えるようになります。 詳しくは、クライアント・アプリケーションの接続を参照してください。
- メッセージがトランザクション内で処理される必要があるか。 トランザクションの管理方法、およびトランザクション内でのメッセージの処理方法を制御するために、一部の組み込みノードのプロパティーを設定できます。 詳しくは、メッセージ・フローのトランザクション特性の構成を参照してください。
メッセージ・フロー・トランザクションに JMSInput および JMSOutput ノードを組み入れる場合は、XA 整合トランザクションをサポートするための JMS および SOAP ノードの構成 の追加情報を考慮する必要があります。
- メッセージをデータ変換させるかどうか。
使用可能なオプションについて詳しくは、データ変換のメッセージ・フローの構成を参照してください。
- MQGet ノードを使用するかどうか。 MQGet ノードによってメッセージが処理される方法について、およびこのノードを使用する要求 - 応答のシナリオについての説明は、MQGet ノードの使用を参照してください。
- メッセージ・フローがユーザー出口からどのようなメリットを得られるか。
詳しくは、ユーザー出口の活用を参照してください。
- メッセージが脱落していないことを確認するためにどんなステップを取るか。 詳しくは、メッセージが失われていないかの確認を参照してください。
- メッセージ・フロー内でエラーが処理される方法。 メッセージ・フロー実行中に発生するエラーを処理するためにブローカーが提供する機能を使用できます (例えば、入力ノードが入力メッセージの検索に失敗した場合、またはデータベースへの書き込みがエラーになった場合など)。ただし、エラーが特定の方法で処理されるようにメッセージ・フローを設計したほうが良い場合もあるかもしれません。
詳しくは、メッセージ・フローのエラー処理を参照してください。
- 実行時にシステム・モニター・ツールを使用して、特定のユーザー定義プロパティーを照会、検出、および設定できるかどうか。詳しくは、CMP アプリケーションでの実行時のメッセージ・フローのユーザー定義プロパティーの設定を参照してください。
メッセージ・フローの開発の概要については、IBM® Redbooks® 資料「WebSphere Message
Broker Basics」を参照してください。 (このリンクは、インターネットに接続している場合にのみ機能します。)