Warehouse ノード

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

目的

指定された ODBC データ・ソース内のデータベースと対話するには、Warehouse ノードを使用します。 Warehouse ノードは Database ノードの特殊な形で、メッセージの全体や一部をデータベース内のテーブルに保管します。 入力メッセージからのデータを使用して必要なアクションを識別するマッピングを定義することにより、保管する情報を定義します。

メッセージ・ウェアハウスは以下の目的で使用できます。

  • ブローカーを通るメッセージの監査証跡の保守。
  • ブローカーを通じて渡されたメッセージのオフラインまたはバッチ処理 (データ・マイニング)。
  • ブローカー内で選択したメッセージを再処理するソースとして。

標準的なデータベース照会およびマイニング技法を使用して、ウェアハウス内に保管したメッセージを取り出すことができます。 WebSphere Business Integration Message Broker による明示的なサポートはありません。

以下を作成 (または他のユーザーによって作成済みの場合は確認) しておく必要があります。

  • メッセージ・セットおよびメッセージの形式の入力データ。
  • データベースへの ODBC 接続。
  • メッセージを保管するデータベースおよびデータベース・テーブル。
  • テーブルの少なくとも 2 つの列。1 つはバイナリー・オブジェクト (メッセージ) のためのもので、もう 1 つはタイム・スタンプのためのものです。

ワークベンチでは、Warehouse ノードは次のアイコンで表されます。

Warehouse ノード・アイコン

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

Warehouse ノードを使用するとき、そのノードに関連するデータベースに以下を保管することを選択できます。

  • メッセージ全体と、関連するタイム・スタンプ (オプション)。 メッセージはバイナリー・オブジェクトとしてタイム・スタンプとともにそれぞれの列に保管されます。 これには、以下の 2 つの利点があります。
    1. ウェアハウスに入れるデータの使用方法を前もって決定しておく必要がありません。 これは、データすべてが取り出されるため、後日すべてのデータにアクセスして、データ・マイニング・ツールを適用することができるためです。
    2. ブローカーを通るメッセージのタイプごとに特定のデータベース・スキーマを定義する必要がありません。 複雑なシステムではさまざまなメッセージ・タイプが使用されていることがあり、メッセージ・タイプごとに 固有のスキーマを定義することのオーバーヘッドが極端に大きくなる可能性があります。 共通のスキーマを使用してそれぞれのメッセージを正規のウェアハウス形式に変換する Compute ノードを 持つ Warehouse ノードを先行させるか、すべてのメッセージをバイナリー・オブジェクトとして 保管することができます。
  • 選択したメッセージのパーツと、関連するタイム・スタンプ (オプション)。 これを保管するには、そのメッセージ・タイプに定義されたデータベース・スキーマが必要です。 メッセージは本来のタイプ、たとえばメッセージ内の文字ストリングは文字ストリングとしてデータベースに保管されます。

Warehouse ノードの構成

Warehouse ノードのインスタンスをメッセージ・フローに入れると、Warehouse ノードを構成することができます。 エディター・ビューでノードを右マウス・ボタンでクリックし、「プロパティー (Properties)」をクリックします。 ノードの基本プロパティーが表示されます。

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

以下のように、Warehouse ノードを構成します。

  1. 「データ・ソース (Data Source)」に、メッセージ・フローが実行されるシステム上で該当するデータベースが認識される名前を指定します。 ブローカーは、mqsicreatebrokermqsichangebroker、または mqsisetdbparms コマンドを使用してセットアップしたユーザー ID およびパスワード情報を使用して、このデータベースに接続します。

    z/OS システムの場合、ブローカーは、ブローカーが開始したタスクの ID を使用します。

  2. 「フィールド・マッピング (Field Mapping)」に、このノードで実行されるマッピング・ルーチンを指定します。 デフォルトでは、マッピング・ルーチンに割り当てられる名前は、ルーチンが定義されているマッピング・ファイルの名前と同一です。 ファイルのデフォルト名は、メッセージ・フローの名前にメッセージ・フローに組み込む際のノードの名前を連結したものです (たとえば、メッセージ・フロー MFlow1 の最初の Warehouse ノードの場合は、MFlow1_Warehouse.mfmap)。 スペースを含む値は指定できません。

    この入力フィールドの隣の「ブラウズ (Browse)」をクリックすると、このノードからアクセス可能なすべての使用可能なマッピング・ルーチンをリストしたダイアログが表示されます。 必要なルーチンを選択し、「OK」をクリックします。 ルーチン名が「フィールド・マッピング (Field Mapping)」に設定されます。

    このノードに関連するマッピング・ルーチンを処理するには、ノードを右クリックして「マッピングを開く (Open Mappings)」を選択します。 マッピング・ルーチンが存在しない場合は、デフォルト名で、デフォルト・ファイルの中に作成されます。 すでに存在する場合には、「ナビゲーター (Navigator)」ビューで <flow_name>_<node_name>.mfmap ファイルを開くこともできます。

    マッピング・ルーチンの内容は、データベースに保管される情報、およびその形式を決定します。 たとえば、各メッセージのすべてまたは一部分のみを保管するかを選択できます。 また、データをバイナリー・データとして保管するか、それとも各フィールドをメッセージ内と同じ形式で保管するかを選択できます (たとえば、メッセージ内の文字フィールドをデータベース内で文字として保管します)。

    マッピング・ルーチンは、関連するノードのタイプに特有のものです。 Warehouse ノード用に開発したマッピング・ルーチンを、マッピングを使用する他のノード (DataInsert ノードなど) と一緒に使用することはできません。 マッピング・ルーチンを作成した場合、それを他のマッピング・ルーチンから呼び出すことはできません。 ただし、ESQL ルーチンから呼び出すことは可能です。

  3. ドロップダウン・メニューから「トランザクション (Transaction)」を選択します。 値は以下のとおりです。
    • 「自動 (Automatic)」 (デフォルト)。 Warehouse ノードが属するメッセージ・フローが正常に行われると、そのメッセージ・フローがコミットされます。 つまり、マッピングで定義したアクションが実行され、メッセージはメッセージ・フローを通して継続します。 メッセージ・フローは、失敗するとロールバックされます。 そのため、「自動 (Automatic)」を選択した場合、データベース上で Warehouse ノードのアクションを コミットするかロールバックするかは、メッセージ・フロー全体の成功または失敗に依存します。
    • 「コミット (Commit)」。メッセージ・フロー全体の成功または失敗に関係なく、このノードに接続しているデータベースのメッセージ・フローで実行されたコミットされていないアクションをコミットしたい場合は、「コミット (Commit)」を選択します。 メッセージ・フロー自体が失敗しても、データベースへの変更はコミットされます。
  4. プロパティー・ダイアログ・ナビゲーターで「基本 (Basic)」を選択し、次の 2 つのチェック・ボックスを選択するかまたはチェックを外します。
    • データベース警告メッセージをエラーとして扱い、ノードから出力メッセージを failure ターミナルに伝搬したい場合は、「警告をエラーとして扱う (Treat warnings as errors)」チェック・ボックスを選択します。 最初、このチェック・ボックスはチェックされていません。

      このボックスを選択した場合、ノードはデータベースからのすべての正の戻りコードをエラーとして扱い、負の戻りコードについてと同じ方法で例外を生成するか、問題がより重大である場合はエラーを生成します。

      このボックスを選択しなかった場合、ノードは警告を通常の戻りコードとして扱い、例外を生成しません。 生成される最も重大な警告は「見つかりません (not found)」であり、これはほとんどの状況で正常な戻りコードとして安全に扱うことができます。

    • データベース・エラーが検出されたときにブローカーが例外を生成するようにしたい場合は、「データベース・エラーで例外を発生させる (Throw exception on database errors)」チェック・ボックスを選択します。最初、このチェック・ボックスは選択されています。

      このチェック・ボックスのチェックを外す場合には、メッセージ・フロー内のエラーを処理してブローカーとデータベースの整合性を確認する必要があります。ブローカーによるデフォルト・エラー処理を呼び出さないように選択してあるため、自分でエラーを処理しない限り、エラーは無視されます。 たとえば、エラー処理サブルーチンに failure ターミナルを接続できます。

  5. 簡略説明または詳細説明 (あるいはその両方) を入力するには、プロパティー・ダイアログ・ナビゲーターの「説明 (Description)」を選択します。
  6. 「適用」をクリックすると、プロパティー・ダイアログを閉じずに Warehouse ノードが変更されます。 「OK」をクリックすると、変更を適用してプロパティー・ダイアログを閉じます。

    「キャンセル (Cancel)」をクリックすると、ダイアログを閉じてプロパティーの変更をすべて破棄します。

ターミナルおよびプロパティー

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

ターミナル 説明
In ノードが処理するメッセージを受け入れる入力ターミナル。
Failure 計算時に障害が検出された場合、入力メッセージが伝搬される出力ターミナル。 「警告をエラーとして扱う (Treat warnings as errors)」を選択した場合、処理が正常に完了してもメッセージはノードからこのターミナルに伝搬されます。
Out データベース・ステートメントの実行後にメッセージを出力する出力ターミナル。

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

Warehouse ノードの「基本 (Basic)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
データ・ソース (Data Source) いいえ はい   このノードに関連付けられたマッピング (「フィールド・マッピング (Field Mapping)」プロパティーで識別される) で参照するテーブルを含むデータベースの ODBC データ・ソース名。
フィールド・マッピング (Field Mapping) はい いいえ Warehouse データベースまたはメッセージ・ツリーに対して実行されるステートメントが含まれるマッピング・ルーチンの名前。 このルーチンは、このタイプのノードに固有のものです。
トランザクション (Transaction) はい いいえ 自動 (Automatic) ノードのトランザクション・モードです。 「自動 (Automatic)」または「コミット (Commit)」を選択できます。
警告をエラーとして扱う (Treat warnings as errors) はい いいえ 選択されていない データベース SQL 警告をエラーとして扱います。 チェック・ボックスを選択すると、このアクションが実行されます。
データベース・エラーで例外を発生させる (Throw exception on database error) はい いいえ 選択されている データベース・エラーによりブローカーが例外を発生させます。 チェック・ボックスを選択すると、このアクションが実行されます。

Warehouse ノードの「説明 (Description)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
簡略説明 (Short Description) いいえ いいえ   ノードの簡単な説明
詳細説明 (Long Description) いいえ いいえ   メッセージ・フロー内のノードの目的を説明するテキスト

関連概念
メッセージ・フロー
メッセージ・フロー、マッピング、および ESQL

関連タスク
DB2 のセットアップ
使用するノードの決定
整合されたメッセージ・フローの構成
メッセージ・フローのエラー処理
マッピングの開発
構成可能プロパティーの編集

関連資料
mqsichangebroker コマンド
mqsicreatebroker コマンド
mqsisetdbparms コマンド
Datalnsert ノード