WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

DatabaseRoute ノード

DatabaseRoute ノードを使用することにより、XPath 式を併用し、データベースからの情報を使って、メッセージをルーティングします。

このトピックには、以下のセクションが含まれています。

目的

DatabaseRoute ノードは、選択されたデータベースの行から名前の挙げられた列値の集合を使用し、並行して 1 つ以上の XPath 式をこれらの取得された値に適用して、ルーティングを決定します。

XPath 1.0 の照会構文について詳しくは、W3C XPath 1.0 Specificationを参照してください。

DatabaseRoute ノードはメッセージ・フローのノード・パレットの「データベース」 ドロワーに含まれ、WebSphere® Message Broker Toolkit では、次のアイコンで表されます。

DatabaseRoute ノード・アイコン

メッセージ・フロー内でのこのノードの使用

このノードの使用法については、以下のサンプルを参照してください。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

着信メッセージ内のメッセージ・エレメントからとられた入力パラメーター値は、このノードで使用される準備済みのステートメントへの挿入に関してサポートされます。 そのような値は、解析済みの着信入力メッセージ内の名前、値、および名前値エレメントから取得されます。 エレメントは最初は com.ibm.broker.plugin.MbElement オブジェクトの形式で取得されるので、そのような値がとりうる、サポートされる Java™ オブジェクト・タイプの範囲は、このオブジェクトのインターフェースの支配下に置かれます。 値が Java プリミティブ・タイプまたはオブジェクトの形式である場合、以下の表に示されているとおり、その値は、同等の JDBC データ・タイプに変換されます。
Java JDBC
Integer INTEGER
Long BIGINT
Double DOUBLE
BigDecimal NUMERIC
Boolean BIT
byte[] VARBINARY または LONGVARBINARY
BitSet VARBINARY または LONGVARBINARY
String VARCHAR または LONGVARCHAR
MbTime java.sql.Time
MbTimestamp java.sql.Timestamp
MbDate java.sql.Date
エレメントの値が使用されるのは、そのエレメントが既知のタイプであって、しかもその値の状態が有効になっている場合のみです。それ以外の場合、例外が発行されます。 このノードによって実行された SQL 照会での結果セットで取得された出力列の値は、以下の表に示されているとおり、まず一致する Java タイプに変換されてから、内部メッセージ・エレメント値タイプに変換されます。
JDBC Java ESQL タイプ
SMALLINT Integer INTEGER
INTEGER Integer INTEGER
BIGINT Long DECIMAL
DOUBLE Double FLOAT
REAL Double FLOAT
FLOAT Double FLOAT
NUMERIC BigDecimal DECIMAL
DECIMAL BigDecimal DECIMAL
BIT Boolean BOOLEAN
BOOLEAN Boolean BOOLEAN
BINARY byte[] BLOB
VARBINARY byte[] BLOB
LONGVARBINARY byte[] BLOB
CHAR String CHARACTER
VARCHAR String CHARACTER
LONGVARCHAR String CHARACTER
TINYINT byte[1] BLOB
TIME java.util.Date TIME
TIMESTAMP java.util.Date TIMESTAMP
DATE java.util.Date DATE
障害のない両方の出力ターミナルを同一の出力場所につなぐことで、指定したデータベースに対して照会が成功したかどうかに関わらず、同一の場所にメッセージをルーティングすることができます。

パターンの XPath 式でエラーが検出されると、エラーは WebSphere Message Broker Toolkit での検証中に報告されます。 報告されたエラー・メッセージには誤った式のストリングのほか、式に関連付けられた固有の動的または静的なターミナル名が含まれる可能性があります。 また、そのストリングは表内で壊れているものとしてマークされている場合があります。

ノードには、SQL SELECT 照会の形成に使用する照会情報が必要です。 この照会は、複数のテスト条件を使用して、データベース内の複数の表にアクセスすることができます。 場合によっては、結果セットに取り出す必要のあるすべての情報が、1 つのデータベース表に入っていないこともあります。 必要な列値を取得するには、複数の表から取り出す必要があるかもしれません。 このノードは、1 つの結果セットに 1 つ以上の表から簡単に列を取り出すための SELECT ステートメントの使用をサポートします。 サポートされている通常の結合構文は、内部結合とも呼ばれます。

照会の作成のために収集される内部結合情報には、検索対象の表名修飾列値のリストと、SELECT ステートメントの WHERE 節を成すテスト条件のリストなどがあります。 表名修飾列値は、テスト条件で左側のオペランドに使用することができます。 このオペランドに適用する比較演算子を選択し、オプションで、右側のオペランドを指定して、テスト条件を完成させます。 演算子は NULL 比較テストにすることが可能で、その場合、右側のオペランドは不要です。 右側のオペランドの値には、データベース・タイプ (Integer、Boolean、または Long など)、別の表名修飾列、あるいは受信メッセージ内のエレメントから取得した値のいずれかを、XPath 1.0 一般式を介した表現で指定することができます。

DatabaseRoute ノードをメッセージ・フローにデプロイすると、「データ・ソース名」プロパティーに関連した値を選択できます。 値のリストには、ブローカーが最初に作成されたときに定義された既存の IBM® 事前定義 JDBC プロバイダー・エントリーの参照が入っています。 そのようなエントリーは不完全であるため、作業で使用する予定のデータ・ソース定義にアクセスするように変更する必要があります。 既存のデフォルトの IBM 事前定義 JDBC プロバイダーが、異なる設定を必要とする別の JDBC データベース・ノードですでに参照されて使用されている場合、WebSphere Message Broker Explorer を使用するか (詳しくはWebSphere Message Broker Explorer を使用した構成可能サービスの処理を参照)、mqsicreateconfigurableservice コマンドを使用して、新規の JDBC プロバイダー・エントリーを指定します。

WebSphere Message Broker Explorer または mqsideleteconfigurableservice コマンドを使用して、不要な JDBC プロバイダー・エントリーを任意で削除することもできます。

カスタム名が指定された構成可能サービスのみ削除できます。IBM 定義の構成可能サービスは削除できません。

DatabaseRoute ノードは、1 つの入力ターミナルと、Match、keyNotFound、Default、および Failure の最低 4 つの出力ターミナルを持っています。 keyNotFound、Default、および Failure 出力ターミナルは静的であるため、常にノード上に存在します。 動的な Match ターミナルは、新しい DatabaseRoute ノードが選択されてメッセージ・フロー・エディターで使用されるたびに、自動的に作成されます。 この動作から、このノードの操作に必要なターミナルの最低数を満たす、このノードの最初の動的出力ターミナルの作成は必ずしも必要ありません。 「Match」という名前が適さない場合は、この動的ターミナルを名前変更することができます。

フィルター式のいずれも True にならない場合は、メッセージは Default ターミナルにコピーされます。 フィルター操作中に例外が発生した場合は、メッセージは Failure ターミナルに伝搬されます。 ノードのデータ・ソースに対して適用されたデータベース照会によって空の結果セットが作成された (つまり、どのデータベース行も一致しなかった) 場合、メッセージが keyNotFound ターミナルにコピーされます。 DatabaseRoute ノードは 1 つ以上の動的な出力ターミナルを定義できます。 すべてのターミナルで、関連付けられたフィルター式が入力メッセージに適用され、 結果が True の場合はメッセージのコピーが指定されたターミナルにルーティングされます。

フィルター・テーブル内の各フィルター式の適用先は次のとおりです。
  • 入力メッセージ
  • 一致したデータベース行から選択した名前付き列値の集合
  • 入力メッセージと戻された列の両方の値
  • どれにも適用されない
その理由は、式は、任意の有効な一般 XPath 1.0 式で構わないからです。

Route ノードの場合と同様に、式は、フィルター・テーブル内で指定された順序で適用されます。 結果が True の場合は、メッセージのコピーがそのメッセージに関連付けられた動的な出力ターミナルにルーティングされます。 「配布モード」プロパティーを First に設定すると、フィルター式の適用はすべては行われない可能性があります。

返された列値をストリング・リテラルに対して比較すると、フィルター式が失敗するおそれがあります。 列エントリーの格納方法 (固定長の文字フィールドなど) によって、データベースから指定した列に返される値が決まります。 空白の埋め込みは、データベースから取得された固定長の文字フィールドで、指定された列の文字を格納する長さより格納されている値が小さかった場合に付加されます。 この場合、埋め込みは返された文字ストリングの右側に、ストリングの一部を形成するように付加されます。 列値をストリング・リテラルと比較するときなど、このことに留意する必要があります。 リテラル側が埋め込み文字を含め、厳密に同じ数のストリングでない限り、等価比較式は失敗する可能性があるためです。

例えば、Employee という名前の表で、char(10) と定義された LastName データベース列に「Smith」という値が入っている場合は、「Smith 」が返されます。 そのため、フィルター式は次のように指定する必要があります。
$Employee_LastName = 'Smith     '
これは True になります。 式:
$Employee_LastName = 'Smith'
は、False になります。
あるいは、XPath 式で以下の関数を使用できます。
Function: string normalize-space(string?)   
normalize-space 関数は先頭と末尾の空白文字を除去し、空白文字のシーケンスをシングル・スペースで置き換えることで、空白文字を正規化した引数ストリングを返します。 したがって、式は次のようになります。
normalize-space($Employee_LastName) = 'Smith'

DatabaseRoute ノードで JDBC プロバイダー・サービスを使用できるようにする

DatabaseRoute ノードは、構成可能サービスとしてブローカーのレジストリーに保管されている接続詳細を使用して、自身の JDBC 接続を確立します。 JDBCProvider 構成可能サービスは、サポートされているすべてのデータベースで提供されます。 選択したデータベース用として提供されているサービスの設定を変更するには mqsichangeproperties コマンドを使用し、新規のサービスを作成するには mqsicreateconfigurableservice コマンドを使用します。 JDBCProvider サービスに関する詳細と、その処理に関する解説は、Type 4 接続用の JDBC プロバイダーのセットアップを参照してください。 接続先になる各データベースごとに、それぞれ異なる JDBCProvider サービスをセットアップする必要があります。

注: maxConnectionPoolSize プロパティーは、DatabaseRetrieve ノードまたは DatabaseRoute ノードで使用される JDBC 接続には適用されません。

このサービスの定義を完了したら、このノードの「データ・ソース名」プロパティーを JDBCProvider サービスの名前に設定します。つまり、このサービスの属性が使用されて、DatabaseRoute ノードの接続が確立されます。

このノードを含むメッセージ・フローのデプロイ先のブローカー上で新規の実行グループを作成するつもりでない限り、ブローカーを停止してから再始動して、変更を有効化する必要があります。

データ・ソースの照会のための Data Source Explorer ビューの使用

ターゲット・データベース内の表の名前と、その表内の任意の列の名前を見つけ出すには、Data Source Explorer ビューを使用します。 表と列の名前を Data Source Explorer ビューで表示するには、該当するデータベースのデータベース定義をWebSphere Message Broker Toolkit に事前にインポートする必要があります。
  1. 「ブローカー・アプリケーション開発」パースペクティブに切り替えます。
  2. Data Source Explorer ビューで「接続」を展開します。 データベース接続がリストされます。
  3. データベースをリストするためにデータベース接続を展開し、続いて適切なデータベースを展開します。
  4. スキーマをリストするために「スキーマ」を展開し、続いて適切なスキーマを展開します。
  5. すべての表をリストするために「表」を展開します。
  6. 「プロパティー」ビューでプロパティーを表示するために表をクリックします。
  7. 「プロパティー」ビューで、「列」タブをクリックし、列名を表示します。

DatabaseRoute ノードの構成

DatabaseRoute ノードのインスタンスをメッセージ・フローに入れたら、そのノードを構成することができます。 詳しくは、メッセージ・フロー・ノードの構成を参照してください。 ノードのプロパティーが、「プロパティー」ビューに表示されます。

値を入力する必要のある (デフォルト値が定義されていない) すべての必須プロパティーには、アスタリスクが表示されます。

Employee という名前のデータベース表を使用する次の例を考慮してください。
EmployeeNumber FamilyName FirstName Salary
00001 Smith John 20000
00002 Jones Harry 26000
00003 Doe Jane 31000
以下の DatabaseRoute ノード・プロパティーは次のように設定されます。
表名 列名 演算子 値タイプ
Employee FamilyName ASC なし なし
Employee Salary ASC なし なし
Employee EmployeeNumber = エレメント $Body/EmployeeRecord/EmployeeNumber
DatabaseRoute ノードは Employee データベース表に接続し、それぞれの着信メッセージから比較用の値を抜き出します。 メッセージの本文をナビゲートするために使用される XPath 式は、 $Body/EmployeeRecord/EmployeeNumber です。 SQL 照会は次のようになります。
SELECT Employee.FamilyName, Employee.Salary
FROM Employee
WHERE EmployeeNumber=?
ORDER BY Employee.FamilyName ASC, Employee.Salary ASC
? は、着信メッセージから取り出した値です。 この値は、Element という値タイプの照会エレメント表の 3 番目の行内の Value プロパティーを通して見つけ出します。
  • この場所にある値が 00001 の場合は、John Smith の情報が取得されます。 out_expr1 という動的ターミナルに関連付けられた最初の XPath 式が一致せず、条件を満たさなかったので、Out ターミナルにはメッセージが伝搬されません。 2 つめの XPath 式は一致しているので入力メッセージのコピーが out_expr2 動的ターミナルにルーティングされます。
  • この場所にある値が 00002 の場合は、Harry Jones の情報が取得されます。 out_expr1 動的ターミナルに関連付けられた最初の XPath 式は一致するため、入力メッセージのコピーが out_expr1 ターミナルにルーティングされます。 2 つめの XPath 式は「配布モード」プロパティーが First に設定されているため処理されません。

ターミナル

DatabaseRoute ノードのターミナルについては、次の表に説明されています。

ターミナル 説明
In ノードが処理するメッセージを受け入れる静的な入力ターミナル。
Match 処理が正常に完了したときに元のメッセージのルーティング先となる動的出力ターミナル。 追加の動的ターミナルを作成することができます。動的ターミナルを参照してください。
デフォルト True になるフィルター式が存在しない場合に、メッセージがルーティングされる静的な出力ターミナル。
keyNotFound どのデータベース行も一致しなかった場合に、メッセージがコピーされる先の静的出力ターミナル。
Failure 処理で障害が検出された場合に、メッセージがルーティングされる静的な出力ターミナル。

動的ターミナル

DatabaseRoute ノードには動的な出力ターミナルをさらに加えることができます。 DatabaseRoute ノードで作成される動的な出力ターミナルのすべてを、フィルター・テーブルの式にマップする必要はありません。 マップされていない動的な出力ターミナルの場合、メッセージがターミナルに伝搬されることはありません。 同一の動的な出力ターミナルに複数の式をマップできます。 動的ターミナルの使用の詳細は、動的ターミナルの使用を参照してください。

プロパティー

以下の表は、ノード・プロパティーについて説明しています。 M の見出しの列は、プロパティーが必須 かどうかを示します (デフォルトが定義されていない場合に値を入力することが必要なら、アスタリスクのマークが付きます)。 C の見出しの列は、プロパティーが構成可能 (メッセージ・フローを BAR ファイルに追加してデプロイするとき、値を変更できる) かどうかを示します。

DatabaseRoute ノードの「説明」プロパティーについては、次の表に説明されています。
プロパティー M C デフォルト 説明
ノード名 いいえ いいえ ノード・タイプ、DatabaseRoute ノードの名前。
簡略説明 いいえ いいえ   ノードの簡単な説明
詳細説明 いいえ いいえ   メッセージ・フロー内のノードの目的を説明するテキスト
DatabaseRoute ノードの「基本」プロパティーについては、次の表に説明されています。
プロパティー M C デフォルト 説明 mqsiapplybaroverride コマンド・プロパティー
データ・ソース名 はい はい DB2 ブローカーのレジストリーに保管されている JDBCProvider サービス定義を見つけ出すのに使用する別名。 別名は、DBMS に接続するために使用される JDBC 接続 URL の位置指定とビルドに使用されます。 接続 URL はドライバー固有ですが、接続先のデータベース名が含まれます。

データベースへの接続がログイン・アカウントとパスワードによって行われる場合、ノードはこのプロパティーをルックアップ・キーとして使用することができます。そのルックアップ・キーを通して、これらの値は、期待される合致ブローカーのレジストリー DSN エントリーから取得できます。

DBMS がパスワードで保護されている場合は、JDBC の固有セキュリティー・キー用として mqsisetdbparms コマンドに -n パラメーターを定義してから、この DatabaseRoute ノードを含むメッセージ・フローをデプロイします。

dataSource
照会エレメント はい いいえ   単一の SQL SELECT ステートメントを構成するために使用される照会エレメントの表。 5 つの列と 1 つ以上の行で構成される表です。 列は 「表名」「列名」「演算子」「値タイプ」、 および「値」です。 これら 5 つのプロパティーは、照会エレメントを記述し、データベースから取り出す表名修飾列値を示します。 この場合、このエレメントは、生成後の照会内の SELECT 節と ORDER BY 節の一部を成します。 それ以外の場合、照会エレメントは、生成後の照会の WHERE 節内の述部を成すテスト条件として働きます。  
表名 はい いいえ   SQL の SELECT ステートメントの一部を構成するデータベース表の名前。 スキーマ名も含みます。myschema.mytable など。  
列名 はい いいえ   結果セットで取得されるデータベース表の列の名前。 「表名」 プロパティーの値で修飾されます。 この SELECT 節は照会から返される列の値として、あるいは WHERE 節の中のテスト条件で参照される値として、この名前を参照することができます。  
演算子 はい いいえ   左側のオペランド (行の最初の 2 列に指定されている表列) に適用されるとともに、オプションで右側のオペランド値にも適用される比較演算子。 昇順の 'ASC' または降順の 'DESC' 演算子の値をこのプロパティーに指定した場合、この行は、生成後の照会中の SELECT 節と ORDER BY 節の一部を成す表名修飾列の宣言を意味します。また、オプションで、右側のオペランド値として今後の行内でこの行を参照することができます。  
値タイプ はい いいえ   「なし」に設定されるか、または、この行の最終列内で表現される値のタイプを示す値。 このプロパティーは、「なし」に設定されなかった場合、SQL SELECT ステートメントの WHERE 節内のテスト条件を記述する行を参照します。  
はい いいえ   「なし」に設定されるか、または、「値タイプ」プロパティーで表現される一連の指定のプロパティー・タイプのうちの 1 つを指定する値。 例えば、「値タイプ」プロパティーを「エレメント」に設定すると、「値」プロパティーは XPath 1.0 一般式を収集します。 ノードの着信メッセージへの適用時に式から戻された値は、この述部を通して比較する右側オペランド値として使用されます。 右側オペランドの比較値は、左側のオペランドとして比較される表列のために取得されるタイプと一致している必要があります。 ゼロ個以上の値を着信メッセージから取り出し、処理を加えて比較用の単一値を形成できる場合は、複合式も使用できます。 例えば、着信メッセージ内の複数のフィールドの値の合計を、「エレメント」の値タイプ用として提供されている一般式で計算することができます。  
配布モード いいえ はい すべて このプロパティーは、インバウンド・メッセージが複数の式に一致する場合の、このノードのルーティング動作を指定します。 「配布モード」 プロパティーが First に設定されている場合は、メッセージは最初に一致する出力ターミナルに伝搬されます。 「配布モード」プロパティーが「すべて」に設定されている場合は、 メッセージは一致する出力ターミナルのすべてに伝搬されます。 一致する出力ターミナルが存在しない場合は、メッセージは Default ターミナルに伝搬されます。  
DatabaseRoute ノードの「フィルター式テーブル」プロパティーについて、以下の表で説明します。
プロパティー M C デフォルト 説明
フィルター・テーブル はい いいえ   このノードで実行されるすべての追加フィルターを定義するフィルター (XPath 1.0 一般式) とそれに関連したターミナルの名前のテーブル。 このテーブルは、2 つの列と 1 つ以上の行で構成されます。 ノードがルーティング論理を実行できるようにするには、少なくとも 1 つの行がこのテーブルに入っていなければなりません。 Route ノードの場合と同様に、式は、テーブルでの表示順に評価されます。 パフォーマンスを改善するには、最も一致率の高い XPath 式をフィルター・テーブルの最上位に置いてください。
ノードのモニター・プロパティーが、次の表に説明されています。
プロパティー M C デフォルト 説明
イベント いいえ いいえ なし ノードに対して定義したイベントが、このタブに表示されます。 デフォルトでは、メッセージ・フローのどのノードに対してもモニター・イベントは定義されません。 ノードのモニター・イベントを作成、変更、または削除するには、「追加」「編集」、および「削除」を使用します。詳しくは、モニター・プロパティーを使用したモニター・イベント・ソースの構成を参照してください。

「使用可能」チェック・ボックスを選択またはクリアすることによって、ここに表示されているイベントを使用可能および使用不可に設定できます。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:55


参照トピック参照トピック | バージョン 8.0.0.5 | ac37380_