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

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

CMP アプリケーションでのブローカーとブローカー・リソースのナビゲート

CMP アプリケーションが接続されているブローカーの状況と属性を探索し、そのリソースについての情報をディスカバーします。

始める前に

このステップの開始前に、CMP アプリケーションからブローカーへの接続を完了する必要があります。

ブローカーから制御可能な各リソースは、CMP API で単一オブジェクトとして表されています。 アプリケーションは、以下のオブジェクトについて、状況などの情報を要求することができます。
  • ブローカー
  • 実行グループ
  • デプロイ済みメッセージ・フロー
  • 管理ログ
  • アクティビティー・ログ
  • データ・キャプチャー・ストア

CMP はデプロイ済みメッセージ・セットを処理します。これらのリソースはデプロイ済み実行グループの属性として扱われます。

これらのオブジェクトは集合的に管理対象オブジェクトとして知られ、ブローカーへのほとんどのインターフェースを提供します。 また、CMP を理解するための基礎となります。

各管理対象オブジェクトは、ブローカー内のオブジェクトの基礎となるタイプを記述する Java™ クラスのインスタンスです。 主な Java クラスを以下の表に示します。
Java クラス クラスの機能
BrokerProxy ブローカーを記述します。
ExecutionGroupProxy 実行グループを記述します。
MessageFlowProxy 実行グループにすでにデプロイされているメッセージ・フローを記述します。WebSphere® Message Broker Toolkit「ブローカー・アプリケーション開発」パースペクティブ内のメッセージ・フローは記述しません。
LogProxy ブローカーで最近実行された管理アクティビティーのログに対応します (すべてのユーザーが対象です)。
ActivityLogProxy 最近のメッセージ・フローおよびリソースのアクティビティーのログを表します。
DataCaptureProxy ブローカー・データ・ストアに保持されているデータを表します。 取得されるデータは、DataCaptureEntry オブジェクトに入ります。
各管理対象オブジェクトは、ブローカーから制御可能な単一オブジェクトを記述します。 例えば、ブローカー内のどの実行グループにも、アプリケーション内にあることを表す 1 つの ExecutionGroupProxy インスタンスがあります。

LogProxy オブジェクトには、管理オブジェクトに加えられた 最近の変更を記録する、LogEntry オブジェクトとして 作成されたメッセージが含まれます。 これらのメッセージには、以下の情報が含まれます。

ActivityLogProxy オブジェクトには、メッセージ・フロー、およびメッセージ・フローと外部リソースとの対話に関する最近の全体的なアクティビティーを記録するために ActivityLogEntry オブジェクトとして作成されたメッセージが含まれています。 これらのメッセージについて詳しくは、アクティビティー・ログ の使用を参照してください。 アクティビティー・ログは、メッセージ・フローに関するものと特定のリソース・タイプに関するものが生成されます。

メッセージ・フローに関する ActivityLogProxy オブジェクトは、MessageFlowProxy オブジェクトから取得できます。 リソース・タイプに関する ActivityLogProxy オブジェクトを取得するには、ResourceManagerProxy オブジェクトを使用します。 MessageFlowProxy オブジェクトまたは ResourceManagerProxy オブジェクトに対するメソッド getActivityLog() を呼び出します。 詳細については、CMP アプリケーションでのアクティビティー・ログの処理を参照してください。

AdminQueueProxy オブジェクトを使用して、 ブローカーによる処理が進行中の作業項目や、処理を待機中の作業項目を調べます。 以下のコードは、キューへのアクセス方法を示します。

BrokerConnectionParameters bcp =
		new MQBrokerConnectionParameters("localhost", 1414, "QMGR");
BrokerProxy b = BrokerProxy.getInstance(bcp);
AdminQueueProxy l = b.getAdministrationQueue();

各管理対象オブジェクトでは、アプリケーションがインスタンスの参照先になっている基盤ブローカーのプロパティーを照会して操作するために使用できる一連の public メソッドが用意されています。 API を通して管理対象オブジェクトにアクセスするには、まず、管理対象オブジェクトを論理的に所有するオブジェクトから、その管理対象オブジェクトへのハンドルをアプリケーションが要求する必要があります。

例えば、ブローカーが実行グループを論理的に所有しているため、ブローカー B1 で実行する実行グループ EG1 へのハンドルを取得するには、アプリケーションは、B1 で表される BrokerProxy オブジェクトに依頼して、EG1 で表される ExecutionGroupProxy オブジェクトへのハンドルを取得する必要があります。

ブローカー B1 を参照する BrokerProxy オブジェクトでは、ブローカーがその実行状態を明らかにするか、またはブローカーがそのすべてのメッセージ・フローを開始するメソッドを、アプリケーションが呼び出すことができます。 LogEntry オブジェクトとして保存されているメッセージを読み取ることによってブローカー・オブジェクトに対する変更を追跡管理するアプリケーションを作成できます。

次の例では、BrokerProxy オブジェクトへの ハンドルが要求されます。 BrokerProxy は、論理的には管理対象オブジェクト・ツリーの ルートです。したがって、アプリケーションは、ブローカー内のその他すべての オブジェクトに直接的または間接的にアクセス可能です。

ブローカーは実行グループを直接所有します。そのため、アプリケーションは ExecutionGroupProxy オブジェクトへのハンドルを取得するために BrokerProxy オブジェクトでメソッドを呼び出すことができます。同様に、実行グループにはすべてのメッセージ・フローのセットが論理的に含まれているため、アプリケーションは、MessageFlowProxy オブジェクトにアクセスするためのメソッドを ExecutionGroupProxy オブジェクトで呼び出すことができます。

このようなアクセス関係の完全な階層は、以下の図に示すとおりです。
この図については、前後のテキストで説明されています。
名前の後にアスタリスクが付いているオブジェクトはそれぞれ DeployedObjectGroupProxy クラスから継承するため、以下の図に示すような子オブジェクトをさらに持ちます。
この図については、前後のテキストで説明されています。

以下のアプリケーションでは、管理対象オブジェクト階層を全探索して、デプロイ済みのメッセージ・フローの実行状態を見付けます。 アプリケーションでは、メッセージ・フロー MF1 がブローカー B1 上の EG1 にデプロイされることを前提としています。コード内のこれらの値をブローカー内で有効なその他の値に置換することが可能です。

import com.ibm.broker.config.proxy.*;

public class GetMessageFlowRunState {

  public static void main(String[] args) {
        
    BrokerProxy b = null;
    try {
      BrokerConnectionParameters bcp =
         new MQBrokerConnectionParameters(
           "localhost",
           1414,
           "");
      b = BrokerProxy.getInstance(bcp);   
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (b != null) {
      System.out.println("Connected to broker!");
      displayMessageFlowRunState(b, "EG1", "MF1");
      b.disconnect();
    }      
  }

  private static void displayMessageFlowRunState(
                                 BrokerProxy b,
                                 String egName,
                                 String flowName) {
    try {
      ExecutionGroupProxy eg =
        b.getExecutionGroupByName(egName);

      if (eg != null) {
        MessageFlowProxy mf = 
          eg.getMessageFlowByName(flowName);

        if (mf != null) {
          boolean isRunning = mf.isRunning();
          System.out.print("Flow "+flowName+" on " + 
            egName+" on "+b.getName()+" is ");

          if (isRunning) {
            System.out.println("running");
          } else {
            System.out.println("stopped");
          }
        } else {
          System.err.println("No such flow "+flowName);
        }
      } else {
        System.err.println("No such exegrp "+egName+"!");
      }
        
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
      System.err.println("Comms problem! "+ex);
    }
  }
}
メソッド displayMessageFlowRunState() によってこの処理のほとんどが実行されます。 このメソッドは、以前に取得した有効な BrokerProxy ハンドルを使用し、メッセージ・フローの実行状態を以下の方法で見付けます。
  1. BrokerProxy インスタンスが、ストリング egName で記述された名前を持つ、その ExecutionGroupProxy オブジェクトへのハンドルを取得するために使用されます。
  2. 有効な実行グループが戻される場合、ExecutionGroupProxy インスタンスが、ストリング flowName で記述された名前を持つ、MessageFlowProxy オブジェクトへのハンドルを取得するために使用されます。
  3. 有効なメッセージ・フローが戻される場合、MessageFlowProxy オブジェクトの実行状態が照会され、結果が表示されます。

アプリケーションは、取り扱うことができるオブジェクトの名前を知っている必要はありません。 各管理対象オブジェクトには、それが論理的に所有するオブジェクトのセットを戻すメソッドが含まれています。 以下の例では、ブローカー内のすべての実行グループの名前を検索することによって、この技法を示します。

import java.util.Enumeration;
import com.ibm.broker.config.proxy.*;

public class DisplayExecutionGroupNames {

  public static void main(String[] args) {
        
    BrokerProxy b = null;
    try {
      BrokerConnectionParameters bcp =
         new MQBrokerConnectionParameters(
           "localhost",
           1414,
           "");
      b = BrokerProxy.getInstance(bcp);   
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (b != null) {
      System.out.println("Connected to broker!");
      displayExecutionGroupNames(b);
      b.disconnect();
    }
  }

  private static void displayExecutionGroupNames(BrokerProxy b)
  {
    try {
      Enumeration<ExecutionGroupProxy> allEGs = b.getExecutionGroups(null);
        
      while (allEGs.hasMoreElements()) {
        ExecutionGroupProxy thisEG =
          allEGs.nextElement();
        System.out.println("Found EG: "+thisEG.getName());
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
        System.err.println("Comms problem! "+ex);
    }
  }
}

かぎとなるメソッドは BrokerProxy.getExecutionGroups(Properties) です。 このメソッドにヌル引数が指定されると、ブローカー内のすべての ExecutionGroupProxy オブジェクトの列挙が戻されます。 アプリケーションはこのメソッドを使用して、それぞれの ExecutionGroupProxy を順番に調べ、その名前を表示します。

メソッド BrokerProxy.getExecutionGroups(Properties) の Properties 引数を使用して、検索された実行グループの特性を厳密に指定することができます。 管理対象オブジェクトを戻すメソッドの大多数でこの引数を使用することができます。また、これは、それらのオブジェクトをアプリケーションが処理する必要のある対象でフィルタリングするための有効な方法です。

オブジェクトのルックアップをフィルタリングするために使用できるそれらの特性の例には、名前や UUID などのより明白なプロパティーだけでなく、実行状態と簡略説明があります。 フィルタリング済みのルックアップを行うための論理を作成するには、管理対象オブジェクトがその情報をどのように保管するのかを理解する必要があります。

各管理対象オブジェクトのプロパティーは、ハッシュ・テーブルを使用してオブジェクトの内部に論理的に保管されます。このとき、各プロパティーは {key, value} の組で表されます。 各 key は属性の名前 (例えば、name) で、各 value は値 (例えば、BROKER1) です。

各キー名は、AttributeConstants クラスからの定数 (com.ibm.broker.config.proxy) を使用して表現する必要があります。 各管理対象オブジェクトのキーと考えられる値のセットのすべてについては、Java の資料の AttributesConstant クラスで説明されています。また、CMP API エクササイザー のサンプル・アプリケーションの「このオブジェクトのロー・プロパティー・テーブルを表示」機能を使用することもできます。 後者では、管理対象オブジェクトごとの {key, value} の対の完全なリストが表示されます。

ルックアップ・メソッドに提供されるプロパティー引数は {key, value} の対のセットで、これらは戻された列挙で管理対象オブジェクトに存在していなければなりません。 次のコードの断片をご覧ください。

Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration<MessageFlowProxy> mf = executionGroup.getMessageFlows(p);

変数 executionGroup が有効な ExecutionGroupProxy オブジェクトである場合、戻される列挙にはアクティブの メッセージ・フロー (OBJECT_RUN_STATE_PROPERTY が OBJECT_RUNSTATE_RUNNING に等しい) だけが含まれます。

プロパティーのフィルタリングが、オブジェクトの列挙ではなく単一の管理対象オブジェクトを戻すメソッドに適用される場合、最初の結果だけが戻されます (複数の一致が該当する場合、この結果は決定的ではありません)。 したがって、以下のコードのようになります。
Properties p = new Properties();
p.setProperty(AttributeConstants.NAME_PROPERTY,
              "EG1");
ExecutionGroupProxy eg1 = brokerProxy.getExecutionGroup(p);
これは以下のステートメントに代わるものです。
ExecutionGroupProxy eg1 = brokerProxy.getTopicByName("EG1");

複数の {key, value} の対がプロパティー・フィルターに追加される場合、オブジェクトが一致するには、すべてのプロパティーが子オブジェクトの中に存在しなければなりません。 フィルターで論理 OR、または論理 NOT を実行するメソッドを必要とする場合は、この目的のために特定のアプリケーション・コードを作成しなければなりません。

AdministeredObjects がアプリケーションで最初にインスタンス化されている場合、CMP API はブローカーにそのオブジェクトのプロパティーの現行セットを求めます。 このアクションは非同期に起こるので、プロパティーが最初に要求されると、ブローカーによって提供される情報を CMP API が待機する間、一時停止する場合があります。 一定の時間内に情報が届かない場合 (例えば、ブローカーが実行中ではない場合)、ConfigManagerProxyPropertyNotInitializedException がスローされます。 ご使用のアプリケーションで、BrokerProxy.setRetryCharacteristics() メソッドを使用して CMP API が待機する最大時間を制御できます。

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

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

        
        最終更新:
        
        最終更新: 2015-02-28 17:49:01


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | be43040_