生成されたサンプル Java アプリケーション

Agent Builder が生成するコード、およびモニターするリソース用に追加または置換する必要があるコードについて説明するリファレンス。

1 つ以上の Java™ API データ・ソースを持つエージェントを作成すると、Agent Builder は Java アプリケーション・ソース・コードを生成します。このコードはエージェント・プロジェクト内に生成され、エージェントの構造に従います。生成されたアプリケーションに独自の Java コードを追加する必要があります。このコードは、サンプル属性グループに関するデータを収集し、イベント・ベースの属性グループに送信されるイベントを処理し、問題が発生した場合はエラーを報告し、タスクを実行します。生成されたアプリケーションによってエージェントにデータが提供されますが、それはサンプル・データであるため、モニター対象のリソースから取得されたデータに置き換えられます。

サンプル・エージェントには、以下の特性があるものと想定されます。
  • 製品コード: K91
  • Java API Main クラス: agent.client.MainClass
  • 図 1 に示すエージェント・データ・ソース構造:
    図 1. エージェント構造の例
    ナビゲーション・ツリー・グラフィックに表示されるエージェント・データ・ソース構造の例
  • 何らかのサブノード 構成プロパティー: K91_INSTANCE_KEY

クラス構造

生成された Java アプリケーションは、多くの場合、エージェントとのインターフェースをとるコードと、モニターするリソースとのインターフェースをとるコードを分離しています。 ここには、変更するファイルと変更しないファイルが含まれています。

Agent Builder によって以下の Java クラスが作成されます。
MainClass (agent.client パッケージ)
「グローバル Java API データ・ソース情報」ページで指定したクラス。このクラスには、main メソッドと、アクション実行要求を処理するメソッドが含まれています。このクラスは、次に説明するヘルパー・クラスから継承されます。 モニターするリソースと実行するアクションとのインターフェースをとるには、このクラスを変更する必要があります。
MainClassBase (agent.client パッケージ)
サーバーとの接続を初期化し、属性グループを登録し、サーバーからの要求を待つヘルパー・クラス。 このクラスは変更しないでください。
Sampled_Data、Sampled_Subnode、Event_Data、および Event_Subnode クラス (agent.client.attributeGroups パッケージ)
Java API 属性グループごとに、その属性グループに関するデータ収集要求を処理する、またはその属性グループに関するイベントを生成するクラスが 1 つずつ存在します。 これらのクラスはそれぞれ、次に説明するヘルパー・クラスのいずれかから継承されます。 モニターするリソースからデータを収集するには、これらのクラスを変更する必要があります。
Sampled_DataBase、Sampled_SubnodeBase、Event_DataBase、 および Event_SubnodeBase クラス (agent.client.attributeGroups パッケージ)
Java API 属性グループごとに 1 つずつ存在するヘルパー・クラス。このクラスは、内部クラス内のグループの属性の構造を定義します。これらのクラスは変更しないでください。
ICustomAttributeGroup インターフェース (agent.client.attributeGroups パッケージ)
各属性グループ・クラス内の public メソッドを定義するインターフェース。このインターフェースは変更しないでください。

変更可能なクラスは、Agent Builder によって上書きされることはありません。Agent Builder は、それらのクラスが存在しない場合のみ、クラスを新規に作成します。

ヘルパー・クラスおよびインターフェースは、Agent Builder が保存されるたびに上書きされます。エージェントを変更して保存すると、Java API 属性グループに対する構造上の変更を反映するためにヘルパー・クラスが更新されます。このインターフェースとヘルパー・クラスのヘッダーには、そのファイルを変更しないように通知する警告が記述されています。

初期化とクリーンアップ

エージェントの開始時に MainClass の main メソッドが呼び出されます。 このメソッドは MainClass インスタンスを作成した後、エージェントの要求を受信し、処理するための長時間実行メソッドを入力します。

初期化およびクリーンアップ・コードのほとんどは、MainClass に追加する必要があります。コンストラクターで、リソースの作成またはリソースへのアクセスに必要な初期化を追加します。リモート・リソースへの接続のオープン、ハンドルの作成、またはデータ構造の初期化を行うことができます。

エージェントが終了する前に、stopDataCollection メソッドが呼び出されます。Java アプリケーションの終了前に接続を閉じるかクリーンアップする場合は、stopDataCollection メソッドにそのコードを追加します。

特定の属性グループにのみ初期化が必要な場合、その属性グループのクラスのコンストラクターにその初期化を追加できます。同様に、特定の属性グループについてのみクリーンアップが必要な場合は、その属性グループの stopDataCollection メソッドにクリーンアップ・コードを追加することができます。

Java アプリケーションのどのコードも、ロガー・オブジェクトを使用してログ項目を書き込むことができます。 (メイン・ヘルパー・クラスは、保護されたロガー・オブジェクトをそのコンストラクター内に作成します。属性グループのヘルパー・オブジェクトは、このロガーに対する保護された参照を、自分のコンストラクター内に作成します)。ロガー・オブジェクトは、Java トレース・ログ・ユーティリティーを使用します。このロガーによって作成されるトレース・ログから、エラーおよび詳細なトレース情報を取得できます。 このトレース情報は、プロバイダーに関する問題のトラブルシューティングを行う場合の重要な情報です。

stopDataCollection の呼び出し時に、クリーンアップ作業を別のスレッドに渡す場合は、そのスレッドが終了するのを待ってから、stopDataCollection メソッドから戻る必要があります。そうしないと、main スレッドが完了していることが原因で、プロセスの終了時にクリーンアップ作業が突然終了してしまう可能性があります。

エージェント構成設定の 1 つは、Java トレース・レベルに関するものです。 次の表に、JAVA_TRACE_LEVEL 構成プロパティーで設定できる値を示します。API によってユーザー用のロガーが作成される場合は、そのロガーが使用するレベルも以下の表に示します。
表 1. Java トレース・レベル・オプション
構成するトレース・レベル Java ロギング・トレース・レベル 説明
オフ オフ ロギングは行われません。
エラー SEVERE Java アプリケーションで発生した問題をトレースします。
警告 WARNING エラーおよび潜在的なエラーをトレースします。
情報 INFORMATION Java アプリケーションに関する重要情報をトレースします。
デバッグ詳細度 - 低 FINE Java アプリケーションの動作分析に必要な詳細の概要をトレースします。
デバッグ詳細度 - 中 FINER Java アプリケーションのプログラム・フローに関する詳細をトレースします。
デバッグ詳細度 - 高 FINEST Java アプリケーションに関するすべての詳細をトレースします。
すべて ALL すべてのメッセージをトレースします。
この例で、Java アプリケーションによって作成されたログ・ファイルの名前は k91_trace0.log です。エージェントが複数インスタンス・エージェントの場合、ログ・ファイル名にそのインスタンス名が含まれます。
注: 標準エラーまたは標準出力にメッセージを書き込まないでください。Windows システムでは、これらのメッセージは失われます。 UNIX および Linux システムでは、ラップされないファイルにこのデータが書き込まれます。

サンプル属性グループ・データの収集

サンプル属性グループ (1 つ以上のデータ行を収集する属性グループ) のクラスには、Sampled_Data.collectData などの collectData メソッドが含まれています。 このメソッドは、エージェントがデータを要求すると必ず呼び出されます。

属性グループのヘルパー・クラスは、Attributes という内部クラスを定義します。このクラスには、属性グループで定義されている属性ごとにフィールドが 1 つずつあります。派生属性はエージェントが計算するため、ここに含まれません。 表 2 に示すように、属性フィールドのデータ・タイプは、Java において Tivoli® Monitoring 属性タイプに相当するものです。
表 2. 属性フィールドのデータ・タイプとそれに相当する IBM Tivoli Monitoring 属性タイプ
Tivoli Monitoring タイプ 属性フィールドのデータ・タイプ
ストリング ストリング
数値、32 ビット、小数部の調整なし int
数値、64 ビット、小数部の調整なし long
数値、ゼロ以外の小数部の調整 double
タイム・スタンプ カレンダー
collectData メソッドは以下を行う必要があります。
  1. モニター対象リソースから適切なデータを収集する。
  2. 属性オブジェクトを作成する。
  3. 属性オブジェクトのフィールドにデータを追加する。
  4. Attributes.setAttributeValues メソッドを呼び出して、内部バッファーにデータをコピーする。
  5. 各データ行で必要に応じてステップ 1 から 4 を繰り返す。 (ステップ 1 から 4 をまとめてスキップし、行を返さないようにすることもできます。この場合、「パフォーマンス・オブジェクト状況」テーブルの「エラー・コード」列に NO_INSTANCES_RETURNED の値が表示されます。エラー・コードについて詳しくは、エラー・コードを参照してください。)
  6. AgentConnection.sendData を呼び出してデータをエージェントに送信するか、または sendError を呼び出して、setAttributeValues に対する呼び出しでコピーされたデータを破棄し、代わりにエラー・コードを送信する。

リソースからデータを収集し (ステップ 1)、生成されたアプリケーションで使用されているサンプル・データを置き換える必要があります。

属性オブジェクトにデータを取り込むには、(生成されたアプリケーションで行うのと同様に) 属性コンストラクターを使用する際にデータを渡すことができます。あるいは、ゼロ引数コンストラクターを使用して属性オブジェクトを作成してから、収集した属性値に属性オブジェクトのフィールドを割り当てます。フィールドの名前は属性と同じですが、英小文字で始まります。

サブノードに関するサンプル・データの収集

サンプル属性グループがサブノード内にある場合、モニター対象のリソースは複数存在すると考えられます (サブノードごとにそれぞれ異なるリソース)。 どのリソースからデータを収集するかを判別する必要があります。モニターするリソースを識別する 1 つ以上の構成プロパティーが存在するはずです。

この例では、1 つの構成プロパティー K91_INSTANCE_KEY に、データを収集するリソースを識別する値が含まれていると想定します。

正しいリソースを見つけるには、以下のステップを使用します。
  1. AgentConnection.getConfiguredSubnodeInstanceIDs を呼び出して、構成されているすべてのサブノードのインスタンス ID を取得します。構成されている各サブノードには固有のインスタンス ID があります。
  2. インスタンス ID ごとに、AgentConnection.getSubnodeConfigurationProperty を呼び出して K91_INSTANCE_KEY 構成プロパティーを取得します。
  3. K91_INSTANCE_KEY 内の値によって表されるリソースを見つけます。
これらのステップは、サンプル属性グループ・データの収集で説明している一連のステップの前に、collectData メソッドで実行することができます。

または、これらのステップを属性グループ・クラス・コンストラクターで実行して、インスタンス ID からリソースへの直接マッピングを作成することもできます。サンプルの属性グループのクラス・コンストラクターは Sampled_Subnode コンストラクターです。このプロシージャーにより、エージェントの存続期間を通して使用可能なハンドルを作成したり接続を開いたりすることもできます。ハンドルを作成したり接続を開いたりすることで、より効率的にリソースにアクセスできるようになります。

生成されたコードはコンストラクター内に MonitoredEntity タイプのサンプル・リソース・オブジェクトを作成し、それらを configurationLookup マップに追加します。MonitoredEntity 内部クラスを削除して、MonitoredEntity オブジェクトを、ユーザー自身のリソースにアクセスするオブジェクトに置き換える必要があります。 collectData メソッドですべてのルックアップ手順を実行する場合、そのクラスから configurationLookup マップを削除することができます。

コンストラクターを使用する場合は、サブノード・インスタンス ID をリソースにマップするために collectData メソッドで行うステップは以下のようになります。
  1. Request.getSubnodeInstanceID を呼び出して、要求パラメーターからサブノードのインスタンス ID を取得します。
  2. コンストラクターで作成されたマップからリソース・オブジェクトを取得します。
  3. サンプル属性グループ・データの収集で詳しく説明されている一連のステップを実行して、エージェントにデータを送信します。

Agent Builder の例では、任意のサブノード・プロパティーが選択されます (ここでは K91_INSTANCE_KEY)。正しいプロパティーではない場合、または正しいリソースを識別するために複数のプロパティーが必要な場合は、リソースを識別するためのプロパティーを選択する必要があります。

イベントの送信

イベントを生成する属性グループでは、collectData メソッドは定期的に呼び出されません。イベントは、リソースがそのイベントを通知するとユーザーのアプリケーションによって送信されます。

イベント生成の 1 つの例として、イベント・ベースの属性グループ用に生成されたコードが、SampleEventClass という内部クラスから実行されるスレッドを作成および開始する場合があります。 この例で使用されるイベント・ベースの属性グループは Event_Data クラスです。このスレッドは定期的にウェイクアップして、イベントを送信します。定期的にリソースをポーリングしてイベントがあるか確認する場合は、イベントが生成されたときの Event_Data クラスの構造を使用することができます。
  1. Event_Data コンストラクターから、スレッドを作成および開始します。
  2. そのスレッドの run メソッドで、エージェントが終了するまでループします。
  3. イベントが発生したかどうかを確認するまで、一定期間スリープします。ポーリング間隔を、5000 ミリ秒からエージェントに適した数値に変更することもできます。
  4. 1 つ以上のイベントが発生したかどうかを確認します。生成されたアプリケーションはチェックしませんが、常に 1 つのイベントを通知します。
  5. 通知が必要なイベントごとに、通知するイベント・データを取得します。
  6. 属性オブジェクトを作成し、データを取り込みます (collectData メソッドがサンプル属性グループに対して行った場合と同様にします)。
  7. Attributes.sendEventData メソッドを呼び出します。イベントは 1 行で構成されるため、一度に送信できるイベントは 1 つのみです。
また、自身のスレッドからイベントを報告する Java API で作業している場合は、Event_Data コンストラクターでそのスレッドを初期化することができます。 また、独自のイベント処理オブジェクトをリソースのイベント処理メカニズムに登録することもできます。イベント・ハンドラーで、以下のステップを実行します。
  1. 通知されるイベント・データを取得します。
  2. 属性オブジェクトを作成し、データを取り込みます。
  3. Attributes.sendEventData メソッドを呼び出します。
この場合、Event_Data クラスで独自のスレッドを作成する必要はなく、SampleEventClass クラスも必要ありません。

サブノードでのイベントの送信

サブノード属性グループに関するイベントが検出された場合、Java アプリケーションはそのイベントを正しいサブノードに通知する必要があります。

この例では、1 つの構成プロパティー K91_INSTANCE_KEY に、イベントを生成する可能性のあるリソースのインスタンスを識別する値が含まれていると想定します。 さらに、イベントで通知されるデータとともに、K91_INSTANCE_KEY プロパティーの値が取得されると想定します。 プロパティーとデータを取得するために、Java アプリケーションは以下のステップを実行します。
  1. 通知されるイベント・データを「インスタンス・キー」とともに取得します。
  2. 属性オブジェクトを作成し、データを取り込みます。
  3. AgentConnection.getConfiguredSubnodeInstanceIDs を呼び出して、構成されているすべてのサブノード・インスタンス ID のリストを取得します。
  4. サブノード・インスタンスごとに、AgentConnection.getSubnodeConfigurationProperty を呼び出して K91_INSTANCE_KEY の値を取り出します。
  5. イベント・データとともに取得した値と一致する K91_INSTANCE_KEY の値を検出したら、対応するサブノード・インスタンス ID を覚えておきます。
  6. Attributes.sendSubnodeEventData を呼び出して、覚えておいたサブノード・インスタンス ID を渡します。
生成されたアプリケーションは、ステップ 4 と 5 に示す検索処理は実行しませんが、代わりにすべてのサブノードの属性グループにイベントを通知します。この動作は、実動エージェントの正しい動作ではない可能性があります。

アクション実行コマンド

アクション実行コマンドは、Tivoli Enterprise Portal 内で、または tacmd createaction コマンドを使用して定義されます。アクションをエージェントの Agent Builder プロジェクトにインポートすることにより、エージェントのインストール時にそれらのアクションを作成することができます。アクション実行コマンドのインポートについて詳しくは、アプリケーション・サポート・ファイルのインポートを参照してください。

生成された Java アプリケーションは、エージェントの製品コードで始まるアクション (K91Refresh など) に登録します。 この登録処理は、メイン・ヘルパー・クラス (MainClassBase) 内の registerActionPrefix メソッドから実行します。他の接頭部を登録したい場合、またはどのアクションについても登録しない場合は、MainClassBase で registerActionPrefix をオーバーライドします。

ユーザーのエージェントによって登録された接頭部で始まるアクションをエージェントが実行する必要がある場合、MainClass.takeAction メソッドが呼び出されます。Request.getAction() を呼び出すコードを追加し、適切なアクションを実行してから AgentConnection.sendActionReturnCode を呼び出して、アクションからの戻りコードを送信します。戻りコード 0 はアクションが成功したことを意味し、それ以外の戻りコードはアクションが失敗したことを意味します。

例外処理

collectData メソッドと takeAction メソッドは任意の Java 例外をスローできるため、収集コードを使用して、例外をキャッチすることなくスローすることができます。ヘルパー・クラスが例外を受け取ると、handleException メソッド (collectData の場合) または handleActionException メソッド (takeAction の場合) が呼び出されます。

collectData 例外の場合、例外の発生時、またはデータ収集での問題発生時に、AgentConnection.sendError を呼び出す必要があります。生成されたアプリケーションは、エラー・コード GENERAL_ERROR を渡します。ただし、このエラー・コードは、検出された問題を最も的確に記述する、エージェントによって定義されたエラー・コードに置き換える必要があります。エラー・コードの追加について詳しくは、ステップ 13 を参照してください。

takeAction 例外では、ゼロ以外の戻りコードが送信されるように AgentConnection.sendActionReturnCode を呼び出す必要があります。

AgentConnection メソッドによっては、com.ibm.tivoli.monitoring.agentFactory.customProvider.CpciException から派生した例外をスローするものがあります。 データの収集中に CpciException がスローされた場合、ヘルパー・クラスがこの例外を処理するため、handleException メソッドは呼び出されません。
注: handleException メソッドを使用するのではなく、collectData メソッド内で例外をキャッチする場合は、必ず CpciException を再スローしてください。CpciException を再スローすることにより、基本クラスで CpciException を処理することができます。

エラー・コード

例外またはその他のリソース・エラーに対する典型的な応答は、AgentConnection.sendError メソッドを呼び出してエージェントにエラー・コードを送信することです。イベント・ベースの属性グループに関するエラーは、いつでも送信できます。 サンプル属性グループに関するエラーは、データ収集要求への応答として、および sendData 呼び出しの代わりとしてのみ送信できます。

エージェントにエラーを送信する場合、以下のようになります。
  1. エージェント・トレース・ログにエラー・メッセージが記録されます。このエラー・メッセージには、エラー・コードと、そのエラー・コードに対して定義されているメッセージが含まれます。
  2. 属性グループに関する状況情報を取得するために、「パフォーマンス・オブジェクト状況」照会を表示できます。 「エラー・コード」列は、送信されたエラーに対して定義されているエラー・コード・タイプに設定されます。 属性グループに関するデータをエージェントが正常に受信すると、エラー状況はクリアされます。 sendData 呼び出しによるデータ収集要求に応答してもデータ行を取得できない場合は、「エラー・コード」列に NO_INSTANCES_RETURNED が表示されます。
次の表に、特定の状態で表示されると想定できる、エージェント内部のエラー・コードをいくつか示します。
表 3. エージェントの内部エラー・コード
エラー・コード 説明
NO_ERROR 現在のところ、属性グループに問題はありません。
NO_INSTANCES_RETURNED Java アプリケーションはデータ収集要求に応答しましたが、データは提供しませんでした。 データが提供されなくても、エラーではありません。これは通常、その属性グループによってモニターされているリソースのインスタンスがないことを示しています。
OBJECT_NOT_FOUND エージェントは、クライアント API によって登録されていない属性グループに関するデータを収集しようとしました。このエラーは、アプリケーションを開始できなかったか、またはエージェントがデータを収集しようとしたときに属性グループの登録が実行されなかったことを示している可能性があります。
OBJECT_CURRENTLY_UNAVAILABLE アプリケーションは、エラー・コードのグローバル・リストに定義されていないエラー・コードをエージェントに送信しました。
GENERAL_ERROR アプリケーションからのデータ収集中に問題が発生しました。アプリケーションがタイムアウト間隔内に要求に応答しなかったことが原因である可能性があります。詳しくは、エージェント・トレース・ログを参照してください。

アプリケーションはエラー・コードに GENERAL_ERROR を指定することもありますが、 さらに詳細なエラー・コードが定義されている場合は、そのコードを参照することをお勧めします。

エージェントへの変更

エージェントに特定の変更を加えると、Java アプリケーションでも、それに対応する変更を行う必要が生じます。構造上の変更が複雑な場合は、エージェントを保存する前に、任意またはすべての Java ソース・ファイルを削除することができます。行ったカスタマイズを適用せずにやり直す場合も、これらのファイルを削除することができます。

次の表では、エージェントを保存する際に、Agent Builder で特定の変更を行うと必要になる、Java アプリケーション・ソース・ファイルへの変更について説明します。
表 4. Java ソースへの変更が必要となるエージェントへの変更
エージェントの変更 Agent Builder の動作 Java ソースに必要な手動による変更
メイン・クラス・パッケージ名の変更
  • 新しいパッケージ構造内ですべてのクラスを生成する。
  • 古いパッケージからすべてのヘルパー・クラスを削除する。
  • メイン・クラスと属性グループ・クラスの内容を、古いパッケージのクラスから新しいパッケージのクラスに移植する。
  • マイグレーションの完了後に古いパッケージからクラスを削除する。
メイン・クラス名の変更
  • 新しいメイン・クラスを作成する。
  • 古いメイン・ヘルパー・クラスを削除する。
  • メイン・クラスの内容を新しいクラスに移植する。
  • 属性グループ・クラスのクラス名への参照を更新する。
Java API 属性グループの追加
  • 新しい属性グループのクラスを作成する。
  • メイン・ヘルパー・クラスで新しい属性グループの登録を追加する。
 属性グループ・クラスでサンプル・コードにカスタム・ロジックを上書きする。
Java API 属性グループの削除 メイン・ヘルパー・クラスから登録を削除する。
  • 属性グループ・クラスを削除する、またはカスタマイズしたロジックを他のクラスに移植する。
  • 属性グループ・ヘルパー・クラスを削除する。
Java API 属性グループの名前変更
  • 属性グループの新規名に応じたクラスを作成する。
  • メイン・ヘルパー・クラスで名前変更した属性グループの登録を更新する。
  • 古い名前の属性グループ・クラスのカスタマイズされたロジックを、新しい名前の属性グループ・クラスに移植する。
  • 古い名前の属性グループ・クラスを削除する。
  • 古い名前の属性グループ・ヘルパー・クラスを削除する。
Java API 属性グループへの属性の追加 属性グルー・ヘルパー・クラス内の属性内部クラスを更新する。 属性グループ・クラス内の新しい属性に関するデータを収集する。
Java API 属性グループからの属性の削除 属性グループ・ヘルパー・クラス内の属性クラスを更新する。 属性グループ・クラス内の以前の属性に関するデータ収集を削除する。
Java API 属性グループ内の属性の名前変更 属性グループ・ヘルパー・クラス内の属性クラスの属性名を更新する。 属性クラス内の属性名への参照を更新する (多くの場合、定位置引数を持つ属性コンストラクターが使用されるため、参照はありません)。
Java API 属性グループ内の属性の再配列 属性グループ・ヘルパー・クラス内の属性クラスで属性の順序を更新する。 属性コンストラクターの呼び出しでの引数の順序を更新する。
Eclipse のリファクタリング (名前変更) アクションを使用する場合は、上の表に示した変更の一部を簡素化できます。変更したエージェントを保存する前に、影響を受けるすべての名前 (ヘルパー・クラス名を含む) でこのアクションを使用してください。

Java API の使用

Java API は、生成された Java アプリケーション全体でエージェントとの通信用に使用されます。 多くの場合、Java API との直接対話は、既存のメソッド呼び出しのパラメーターを変更する場合に限られます。 例えば、GENERAL_ERROR から通知されたエラー・コードを、エージェントで定義されたエラー・コードに変更する場合などです。

Java API を使用してより大規模なコーディングを行う場合は、Eclipse テキスト・エディターから Javadoc を表示することができます。以下の手順を実行すると、Java コードの編集中に Javadoc を表示することができます。
  1. API でパッケージ、クラス、またはメソッドの名前を強調表示します。
  2. F1 を押して、Eclipse のヘルプ・ビューを開きます。
  3. Javadoc リンクを選択してください。
クラスまたはメソッドの名前の上にカーソルを移動することで、Javadoc からの要旨を参照することもできます。API の Javadoc は、Tivoli Monitoring Knowledge Center でも見つけることができます。そこで、Javadoc を参照してください。

Java API のクラスは cpci.jar の中にあります。cpci.jar ファイルは、Java API 属性グループを含むエージェントを作成すると、自動的にプロジェクトの Java ビルド・パスに追加されます。このファイルは、Java API 属性グループを含むエージェントをインポートした場合にも追加されます。また、既存のエージェントに Java API 属性グループを追加した場合にも、このファイルが追加されます。また、cpci.jar は、自動的に Java API 属性グループを含む各エージェントと一緒にパッケージ化され、Java アプリケーションの CLASSPATH に追加されます。