ユーザー定義の入力ノードの計画

このトピックは、ユーザー定義の入力ノードの開発前に考慮すべき計画および設計上の考慮事項を 概説します。

分析

ユーザー定義の入力ノードの開発前に、次のことを考慮してください。
  • カスタム入力ノードを作成する必要があるか。
    最低 1 つの入力ノードをメッセージ・フローに含めることが必要です。 (複数の入力ノードの使用に関する詳細については、複数の入力ノードの使用を参照してください。) 選択するノードは、入力メッセージのソースに依存します。
    • メッセージが WebSphere MQ キューのブローカーに到達する場合、 提供される MQInput ノードを使用します。
    • メッセージが SCADA デバイスによって送信される場合、SCADAInput ノードを使用します。
    • メッセージ・ソースがその他である場合、ユーザー定義の入力ノードを使用することが必要です。
  • 正常に関係するデータを入力するために、入力ノードは第三者ソフトウェアと インターフェースする必要があるか。その場合、このソフトウェアへのアクセスを可能にする API は スレッド化モデルを中断するか。
  • この入力ノードにより生成されるメッセージの本文 (ペイロード) を解釈するための新しいユーザー定義のパーサーが必要か、それとも標準のビルトイン・パーサーにより解析することができるか。
  • グローバルに調整されたトランザクションとして、トランザクション制御下にあるメッセージ・フロー・インスタンスを操作するために、ユーザー定義の入力ノードが必要か。
  • 構成オプションを提供するために、新しいユーザー定義の入力ノードが必要か。
  • 次のプリミティブにより処理されるこの入力ノードが伝搬するメッセージが必要か。
    • すべてのプリミティブ出力ノード
    • リセット内容記述子ノード

設計上の考慮事項

入力ノードの開発およびインプリメント前に、以下の要因を決定する必要があります。
  • 最初に入力メッセージを解析するメッセージ・パーサー。
  • この入力ノードに合わせたデフォルト・メッセージ・パーサー属性をオーバーライドするかどうか。
  • 入力ノードの適切なスレッド化モデル。
  • ノードがサポートするメッセージ処理およびトランザクション・サポートの終了。
  • メッセージ・フロー・デザイナーによる変更のために外部化 するべき入力ノードが必要とする構成属性。
  • ユーザー定義の API が提供するオプションのノード API。
  • 開発上の一般的考慮事項は次のとおりです。
  • ノードが WebSphere Event Broker の拡張機能として実行されるように設計する場合、以下の制約事項を考慮する必要があります。
    • ユーザー定義入力ノードは、XML、BLOB、および WebSphere MQ パーサーのみをサポートします。 MRM は WebSphere Event Broker と一緒に出荷されておらず、ユーザー定義パーサーのサポートはありません。
    • ユーザー定義ノードでは、ユーザー ESQL コードを評価する機能をユーザーに公開しないようにしなければなりません。例えば、MbSQLStatement への入力をノード属性として公開するノードは、実際には計算ノードをエミュレートしています。 WebSphere Event Broker での ESQL の使用はサポートされません。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
as01392_