レベル: 中級 Bob Moore (remoore@us.ibm.com), Advisory Software Enginner, IBM
Brad Topol (btopol@us.ibm.com), Senior software engineer, IBM
Jie Xing (jiexing@us.ibm.com), Advisory Software Engineer, IBM
Belinda Chang (belchang@us.ibm.com), Software Engineer, IBM
Scott Kolodzy (skolod@wpi.edu), 2006 Summer Co-op, 요약
Peter Sohn (peter_sohn@us.ibm.com), Senior Engineer, IBM
2006年 11月 07日
AutoPD (Automated Problem Determination) ツールの使用方法に関するシリーズ第 5 回では、このツール独自の <infocollect> タスクに代わる新しい機能、増分分析機能を紹介します。この新機能を使用すると、個別に指定された複数の分析アクティビティーの結果を 1 つの分析レポートに統合することが可能になり、スクリプト作成者が、それぞれが単独に開発されたものであっても以前の分析ターゲットをそのまま再利用できるという柔軟性が追加されます。
この記事は、AutoPD (Automated Problem Determination) に関するシリーズの 5 回目です。今までの記事の内容は、以下のとおりです。
-
第 1 回では、このツールを紹介しました。
-
第 2 回では、他の製品や問題のシナリオにも対応できるようにツールを拡張する方法を説明しました。
-
第 3 回では、ログ・ファイル分析の自動化について取り上げました。
-
第 4 回では、分析の話題をさらに拡げて、Common Base Event を含んでいるような XML フォーマットのログ・ファイルについて説明しました。
今回の記事では、このツール独自の <infocollect> タスクに代わる新しい機能、増分分析機能を紹介します。この新機能では、個別に指定された複数の分析アクティビティーの結果を 1 つの分析レポートに統合できます。このような柔軟性の追加によって、スクリプト作成者が、それぞれが単独で開発されたものであっても以前の分析ターゲットをそのまま再利用できるようになります。この点において、増分分析が分析レポートの作成にもたらす柔軟性は、<zip> タスクが収集 zip ファイルの作成ですでに実現している柔軟性に匹敵します。
分析レポートの概要
AutoPD ツールの分析レポートの役割、そして全体的な構造は、<infocollect> タスクから増分分析機能に移行しても変わりません。分析レポートの第一の目的は、非常に大きくなる可能性があるログ・ファイルから、特定タイプの問題を診断する際に役に立ちそうな少数のログ・レコードを抽出してサブセットを作成することです。
分析レポートは IBM® サポート要員にとって、ユーザーがどのようにして AutoPD 収集スクリプトを呼び出したかを教えてくれる便利な情報源にもなります。この情報には以下が含まれます。
- スクリプトの呼び出しに使用された AutoPD ツールの正確なバージョン
- 収集の実行対象となった製品の名前とバージョン
- 収集の基準となった問題タイプ
- スクリプトが実行された日付と時刻
さらに分析レポートには、システム・ハードウェア、オペレーティング・システム、そしてレポートが作成されたシステムにインストールされている IBM ソフトウェア製品のうち、選択されたソフトウェア製品に関する要約情報が記載されます。
<infocollect> タスクでの基本的な問題は、このタスクが呼び出されると、分析レポートをまるごと一度に作成するという点です。その後、2 番目の <infocollect> タスクが呼び出されると、前の分析レポートが上書きされるか (autopdreport 属性で最初の autopdreport タスクと同じ場所が指定されている場合)、あるいはまったく別の分析レレポートが作成されます (autopdreport 属性で別の場所が指定されている場合)。この制約は、スクリプト作成者が <infocollect> タスクを呼び出す複数のターゲットを 1 つのスクリプトに統合させなければならない場合に問題となります。
新しい設計の具体的な目標
<infocollect> タスクを増分分析機能に置き換えるに至った基本的な使用事例は、以下の 2 つです。
- 1 つの製品が、ほとんど独立した複数のコンポーネントで構成されている場合があります。
例えば、WebSphere® Portal 製品を構成しているのは、基本的なポータル機能を提供するコア・コンポーネント、そして Web Content Management、Portal Document Manager、Portal Personalization などの特化された複数のコンポーネントです。これらの周辺コンポーネントのいずれかに関係する問題を分析する場合、最初にコア・コンポーネント (WebSphere Portal 自体) の問題の 1 つに取り組むときに呼び出す分析と同じ分析を呼び出し、続いて問題の周辺コンポーネントに固有の追加分析を実行するのが理想的です。この作業は <infocollect> タスクでも可能ですが、2 つの分析手順それぞれにまったく別の分析レポートが作成されることになってしまいます。
- ソリューション・レベルの問題には当然、複数のソフトウェア製品が関係します。
その一例が、WebSphere Application Server と DB2® です。この場合、関連製品ごとに通常の分析を呼び出しながらも、それぞれの分析手順の結果はすべて単一の分析レポートに記載されるというのが理想的です。これも、<infocollect> タスクでは実現できません。
上記の 2 つの使用事例に対処する方法を考えるなかで、必要に応じて順次、追加ファイルを zip ファイルに圧縮するという <zip> タスクの機能に着目しました。分析タスクに同じ機能があれば、複数の個別分析レポートを作成することなく、1 つの収集スクリプトで複数のコンポーネントまたは製品に固有の分析アクティビティーを連続して呼び出すことができます。さらに、それぞれの分析アクティビティーを個別に指定して呼び出す必要もありました。その理由は、分析アクティビティーを呼び出す共有ターゲットの作成者には、別の分析アクティビティーによって収集スクリプトが呼び出されるのが、その共有ターゲットが分析アクティビティーを呼び出す前なのか、後なのか、あるいは前後の両方なのかがわからないためです。
独立した分析アクティビティーという基本方針を決定すると、その方針に従って自然と具体的な 3 つの設計目標が決まってきました。そのうちの 2 つは、既存の共有ターゲットを新しい収集シナリオで再利用するには不可欠の目標です。残りの 1 つは、実際には私たちが分析レポートについて検討する間、しばらく潜んでいた単独の要件です。私たちはアプローチ全体を更新するなかで、単にこの要件を目標に加えることにしました。
増分分析機能が実現する 3 つの具体的な設計目標とは、以下のとおりです。
- それぞれの分析アクティビティーを異なる問題タイプで呼び出せるようにする。
- それぞれの分析アクティビティーを異なるパターン・ファイルで呼び出せるようにする。
- 個別の分析アクティビティーの結果をインラインまたは URL リンクのいずれかで分析レポートに組み込めるようにする。
増分分析の仕組みについての概要
お気付きかもしれませんが、これまでのセクションでは増分分析機能ではなく、<infocollect> タスクについて説明しました。その理由は、増分分析には相補的役割を果す複数のカスタム・タスクが関係するからです。図 1 に、これらのカスタム・タスクを要約します。
図1. 増分分析のカスタム・タスク
図 1 の矢印は、カスタム Ant タスク間での継承を表します。この継承は、これらのタスクを実装する Java™ クラス間での継承と多かれ少なかれ同じです。
増分分析機能には、基本的に次の 2 段階があります。
- [analysis] フラグメントの作成 (Fragment-creation)
- [analysis] フラグメントの組み立て (Fragment-assembly)
分析フラグメントは、抽象タスク <create_analysis_report_fragment> の具体的サブタスクが呼び出されるたびに作成されます。サブクラスによって作成されるフラグメントのタイプは異なりますが、すべてのサブタスクに共通なことは、作成されたフラグメントは一時ディレクトリーに配置され、次の基本段階であるフラグメントの組み立てが行われるまでそこに維持されます。
フラグメントのアセンブリーは、単一のカスタム・タスク <assemble_analysis_report> によって実装されます。このタスクはフラグメントが含まれる一時ディレクトリーに行き、そこで見つけたすべてのフラグメントを 1 つの包括的分析レポートに統合します。それと同時に、分析レポートに全体的な情報も追加します。全体的な情報とは、特定の分析アクティビティーに関連付けられていない情報のことで、例えばタイムスタンプや AutoPD ツールのバージョンなどがあります。
フラグメント作成タスク同士や、これらのタスクとフラグメントのアセンブリーを行う <assemble_analysis_report> タスクとの明示的な調整なしで、すべてが正しく行われるようにするには、以下の情報を暗黙的に共有する必要があります。
- フラグメント作成タスクがフラグメントを保管するとともに、<assemble_analysis_report> タスクがアセンブル対象のフラグメントを検索するディレクトリーの場所。
このディレクトリーは、Ant プロパティーの analysis.fragment.directory 内で特定されます。デフォルトでは、AutoPD ツールはこのプロパティーを autopd.properties ファイル内の値 ${autopdtmp}/autopd/fragment に設定します。この値は、必要に応じてファイルを編集することによって別の値に設定することもできます。
- 分析フラグメントが作成された順序。
<assemble_analysis_report> タスクはフラグメントをその作成順で分析レポートに組み込まなければならないため、この順序を判別する手段が必要となります。そのため、各フラグメントのファイル名にはタイムスタンプが組み込まれ、<assemble_analysis_report> タスクが分析フラグメント・ディレクトリーで検出した順にフラグメントを処理するときに、フラグメントが自動的に正しい順序で並べられるようになっています。
- フラグメントを分析レポートに組み込む方法。
<assemble_analysis_report> タスクは、スクリプト作成者がフラグメントをインラインで組み込むように指定したか、または URL リンクを使用して組み込むように指定したかも判別しなければなりません。この情報は、同じくフラグメントのファイル名に組み込まれます。
ここでの総体的効果は、すべてが「とりあえず機能する」ということです。スクリプト作成者は、フラグメント作成タスクから <assemble_analysis_report> タスクにどのように上記の情報が渡されるかについて気にする必要はありません。また、フラグメント作成タスクの振る舞いは抽象タスク <create_analysis_report_fragment> に実装されているため、この抽象タスクの新しいサブクラスを作成する実装者がこれを気にする必要もありません。スクリプト作成者と実装者は、特定タイプのフラグメントを作成するために必要な特定のエクステンションを実装することだけに関心を払っていれば、それで十分です。
新規カスタム・タスクの使用方法
ここからは、いよいよ新しいカスタム・タスクを使用する方法を説明します。全体的なスクリプト構造を重点に、新規カスタム・タスクの詳細もいくつか紹介します。
全体的なスクリプト構造
増分分析機能を呼び出す収集スクリプトの構造は、さまざまなレベルで検討することができます。図 2では、関連するカスタム・タスクだけを取り上げています。
図2. タスク・レベルでのスクリプトの分解
上記の流れは極めて分かりやすいものです。すべてのフラグメントは分析レポートが組み立てられる前に作成され、分析レポートは収集 zip ファイルに組み込まれる前に組み立てられなければなりません。
この全体的構造を念頭に置いた上で、図 3 にスクリプト作成者が使用できる共有ターゲットをいくつか重ねてみます。
図3. タスク・レベルでの分解に重ね合わせた共有ターゲット
スクリプトの最上位に、スクリプト・レベル・パラメーターを設定するためのセクションが追加されていることに注目してください。シリーズ第 2 回では、スクリプト・レベル・パラメーターを、共有ターゲットを呼び出す収集スクリプトの違いによって共有ターゲット内のタスクの振る舞いを変える場合に推奨される手段として紹介しました。
各分析手順を異なる問題タイプで呼び出すことが可能な増分分析では、個別のスクリプト・レベル・パラメーターを使用して、共有ターゲット内で発生する分析手順ごとに問題タイプを設定しなければなりません。この点については、後で詳しく説明します。
図 3 を見ると、1 つの共有ターゲット assemble_analysis_report がどのように、増分分析を呼び出すスクリプトに必要な 3 つの仕上げの手順すべてを処理するかもわかります。その仕上げの手順とは、以下のとおりです。
- フラグメント作成タスク <create_levelreport> を呼び出して、システム情報を組み込むフラグメントを作成する。
この呼び出しには、共有ターゲットで <if isNotTrue="${omit.level.report.info}"> という条件が付いているので、分析レポートにシステム情報が必要なければ、スクリプト・レベル・パラメーター omit.level.report.info を「true」に設定するだけで済みます。ここに <create_levelreport> タスクを配置すると、収集スクリプトのその他すべてのフラグメント作成タスクの後に確実にこのタスクが呼び出され、分析レポートに最後にレベル・レポート情報が記載されます。これによって、前のバージョンの分析レポートでのこの情報の配置が維持されます。
- <assemble_analysis_report> タスクを呼び出して分析レポートを組み立てる。
- 作成された分析レポートを収集 zip ファイルに組み込む。
実際には、この最後のタスクが組み込むのは分析レポートだけではありません。分析レポートが保管されていた analysis.report.directory 全体も組み込まれます。その理由は、URL参照が分析レポートに挿入されるとともに、その URL 参照によってフラグメントが分析レポートに組み込まれると、<assemble_analysis_report> タスクが analysis.fragment.directory 内にある該当フラグメント自体を analysis.report.directory にコピーするため、収集 zip ファイルが圧縮解除されると、この URL 参照に場所が指定されるからです。この URL を変える必要はないため、analysis.report.directory を定義するプロパティーはそのまま assemble_analysis_report 共有ターゲットに設定されてから使用されることになります。
もう一度繰り返しますが、ここで伝えたいメッセージは、スクリプト作成者であるあなたが、上記の仕組みを気にする必要は一切ないということです。すべての <analyze_files> タスクを呼び出した後に assemble_analysis_report 共有ターゲットを autopdmain 実行パスに組み込むだけで、すべてが正しく機能します (「とりあえず機能する」という点に注意してください)。
ここまでのところでは、フラグメントの作成とアセンブリーが確実に正しく機能するスクリプトの構成に焦点を当ててきました。その一方で、分析手順自体が必要な役目を果すように計らう必要もあります。ここで 1 つの課題となるのは問題の再現シナリオです。再現シナリオでは、まず分析対象となる前のバージョンのログ・ファイルのバックアップを取り、次に問題を再現して、それによって生成されるログ・レコードが含まれる新しいバージョンのログ・ファイルをシステムに作成させます。それが終わったら、最後に前のバージョンのログ・ファイルをリストアします。元のバージョンのログ・ファイルをリストアしてから <analyze_files> タスクを呼び出すと誤ったログ・レコードを分析することになるので、常に、バックアップ→再現→分析→リストアの順で行わなければなりません。
新規カスタム・タスクの詳細
大抵の場合、考慮しなければならないカスタム・タスクは <analyze_files> タスクだけです。<create_analysis_report_fragment> タスクは抽象タスクで、<create_levelreport> タスクと <assemble_analysis_report> タスクはあらかじめ assemble_analysis_report 共有ターゲットに提供されています。
<analyze_files> タスクを呼び出す方法を理解するため、WebSphere Portal (図 4) の共通分析ターゲットでのこのタスクの呼び出しと、それによって分析レポート内に作成される該当セクション (図 5) を見比べてみましょう。
図4. WebSphere Portal を対象とした基本分析の呼び出し
図5. Portal Configuration タイプの問題についての分析レポート
図 5 で、上記の <analyze_files> の呼び出しの結果作成された箇所は二重線から下の部分です。二重線の上の要素は、<assemble_analysis_report> タスクによって追加された全体的な情報です。
上記の <analyze_files> タスク呼び出しには、以下の 7 つの属性と多数の子要素 <autopdfileset> があります。
-
problem: 実際の分析で使用される問題タイプです。上記の例では、この値がスクリプト・レベル・パラメーターとなり、共有ターゲットのこの特定の <analyze_files> 呼び出しに対応する問題タイプを設定しています。
-
patternFile: これは、前にリストした設計目標に対応した属性で、各分析手順で異なるパターン・ファイルを参照できるようにするためのものです。
-
productname: この値は、「Product name for analysis」として分析レポート内に表示されます。また、分析アクティビティー自体のスコープ変数の 1 つとしても機能します。詳細は、このシリーズの第 3 回を参照してください。
-
productversion: この値は、「Product version for analysis」として分析レポート内に表示されます。また、分析アクティビティー自体のスコープ変数の 1 つとしても機能します。詳細は、このシリーズの第 3 回を参照してください。
-
includeType: この属性に、<assemble_analysis_report> タスクがフラグメントをインラインで組み込むか (値 = "inline")、または URL として組み込むか (値 = "link") を指定します。
-
fragmentTitle: この値は、分析レポート内の二重線のすぐ下に副見出しとして表示されます。分析レポートが翻訳されることはないため、この属性の値は各国語の様式ではなく、実際に組み込まれるストリングです。
-
timeout: 収集スクリプトが各分析手順で費やす時間をミリ秒単位で指定する数値です。
- 子要素 <autopdfileset>: <infocollect> タスクの場合と同じように機能します。詳細は、このシリーズの第 3 回を参照してください。
図 5 には、Portal Configuration 問題タイプを対象とした分析レポートの始まりが表示されています。先頭に共通の情報を持つ見出しがあり、その下に Basic WebSphere Portal Analysis の分析フラグメントが記載されています。
独自の <analyze_files> 呼び出しの追加方法
図 4 には、<analyze_files> タスクの呼び出しがどのようなものかが示されていますが、呼び出しを行う前には多少の設定が必要になります。
- 「problem」属性で使用する値を用意します。一般的には、これはスクリプト・レベル・パラメーターの値です。
この属性は通常 <analyze_files> の 1 回の呼び出しにだけ使用されます。このようにして、分析の呼び出しごとに異なる問題のタイプを使用するという設計目標を達成しています。属性名には、特定の <analyze_files> 呼び出しでその属性が果す役割を明確に示す名前を選択し、その他のスクリプト作成者が <analyze_files> を呼び出すときに同じ属性名が使われる可能性がないようにしてください。Web Content Management Syndication 収集スクリプトの先頭から抜粋した以下の行を見ると、この意味がわかります。
<property name="collect_wps_information_common_ProblemType"
value="portalcommon" />
<property name="collect_wcm_information_ProblemType"
value="wcm_syndication" />
|
上記では、属性名と属性値の両方が内容を説明しています。最初の属性は、WebSphere Portal に対する一般的な分析手順を制御します。特定の値「portalcommon」によって WebSphere Portal ログの汎用分析が要求されています。この汎用分析が Web Content Management などの周辺コンポーネントに対する収集スクリプトのコンテキストで常に使用されます。
2 番目の属性は、Web Content Management コンポーネントに対する特定の分析手順を制御します。値「wcm_syndication」によって Web Content Management のシンジケート問題に固有の分析が要求されています。この値を一般的な Web Content Management 問題の分析を要求する値「wcm」と比べてみてください。
- 特定のログ・ファイルに関する分析仕様を示す「patternFile」に値を指定します。
AutoPD ツールに付属の pattern_template.xml ファイルを編集することもできますが、独自のパターン・ファイルを作成して指定することをお勧めします。例えば、Content Management Syndication 収集スクリプトではパターン・ファイル wps_extensions_pattern_template.xml を使用します。
- 「includeType」属性と「fragmentTitle」属性に値を指定します。
<analyze_files> 呼び出しが共有ターゲット内にある場合、この共用ターゲットが任意の収集スクリプトから呼び出される可能性があります。そのため、フラグメントのタイトルは、そのフラグメントを呼び出している可能性がある収集スクリプトに関係なく、実行中の分析を特徴付けるものにしなければなりません。
 |
独自のカスタム・タスクの作成方法
増分分析機能は、<analyze_files> および <create_level_report> で情報ブロックを追加するのと同じような増分方式で、独自の情報ブロックを分析レポートに簡単に追加できるように設定されています。ここからは、この機能に必要な手順を説明します。
カスタム・タスクを定義して必要な属性を決定する
ここで用いる非常に単純な例では、カスタム・タスク <create_my_info> を定義し、このタスクに my_name、my_favorite_animal、および my_favorite_food 属性を設定します。スクリプトでは、このタスクを以下のように呼び出すことができます。イタリック体で示した最初の 2 つの属性は、抽象タスク <create_analysis_report_fragment> から継承した属性です。
リスト 1. カスタム・タスクの呼び出し
<create_my_info
includeType="inline"
fragmentTitle="Stuff about Me"
my_name="Otto P. Dee"
my_favorite_animal="ant"
my_favorite_food="ice cream"/>
|
より実際的な場合として、ほとんどのタスクが AutoPD 収集スクリプトの共有ターゲットで呼び出されるとすると、呼び出しはリスト 2 のようになります。
リスト 2. より実際的な呼び出し
<property name="my.name" value="Otto P. Dee"/>
<property name="my.favorite.animal" value="ant"/>
<property name="my.favorite.food" value="ice cream"/>
...
<create_my_info
includeType="inline"
fragmentTitle="Stuff about Me"
my_name="${my.name}"
my_favorite_animal="${my.favorite.animal}"
my_favorite_food="${my.favorite.food}"/>
|
これよりも現実的なシナリオとして、既存のユーティリティーの出力を分析レポートに組み込むことが考えられます(この出力が大規模であれば、URL リンクを使用してフラグメントを分析レポートに組み込むという新規機能を使用するのにふさわしい機会になります)。このシナリオでは、標準 Ant <exec> タスクを使用してユーティリティーを呼び出し、その出力を一時ファイルに保管することも可能です。この場合、一時ファイルの場所をフラグメント作成タスクに渡すと、このタスクが、作成中のフラグメントに挿入する情報を一時ファイルから抽出します。実際の作業はすべて、フラグメント作成タスクを実装する Java クラスの execute() メソッドで行われます。
カスタム・タスクを実装する Java クラスを作成する
|
ありきたりのタイプミス
抽象クラスにはなぜ、CreateAnalysisReportFragment.java ではなく CreateAnalysisReportFragmen.java という名前が付いているのか、きっと不思議に思っていることでしょう。これは AutoPD 実装に紛れ込んでしまった単なるタイプミスで、クラスが同梱されるまでとうとう見つからなかったというのが、その答えです。私たちは、完成したマイグレーションをわざわざいじってタイプミスを修正することで新たなバグの危険を冒すより、このクラスをそのままにしておくことにしました。
|
|
前述したように、すべてのフラグメント作成タスクは抽象カスタム・タスク <create_analysis_report_fragment> から派生しています。この抽象カスタム・タスクは、<assemble_analysis_report> タスクが処理可能なフラグメントを作成する際の詳細をほとんど処理してくれます。カスタム Ant タスク間で継承を実装する方法は、これらのカスタム Ant タスクを実装する Java クラス間の継承関係を定義することです。このようにして、CreateMyInfo.java という新しいクラスを抽象 Java クラス CreateAnalysisReportFragmen.java から派生させます。
このクラス内で行う必要があるのは、スクリプト作成者から渡された値から、タスクに定義された属性を使用してフラグメントを作成することだけです。フラグメントは任意の HTML にできますが、スクリプト作成者が継承属性 fragmentTitle (H3 としてフォーマット設定) で渡したフラグメント・タイトルが先頭についていなければなりません。リスト 3 に、サンプル CreateMyInfo.java クラスの場合の完全なリストを示します。
リスト 3. CreateMyInfo.java クラス
package com.ibm.autopd.anttasks.examples;
import java.io.FileOutputStream;
import java.io.PrintWriter;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import com.ibm.autopd.AutoPDStandardLogger;
import com.ibm.autopd.anttasks.CreateAnalysisReportFragmen;
public class CreateMyInfo extends CreateAnalysisReportFragmen {
String my_name;
String my_favorite_animal;
String my_favorite_food;
public void execute() throws BuildException {
super.execute();
try {
PrintWriter html=null;
html = new PrintWriter(new FileOutputStream(getFilename()));
html.println("");
html.println("<HTML>");
html.println("<HEAD>");
html.println("<TITLE>"+getFragmentTitle()+"</TITLE>");
html.println("<meta http-equiv=\"Content-Type\" content=\"text/html;
charset=utf-8\" >");
html.println("</HEAD>");
html.println("<BODY>");
html.println("<H3>"+getFragmentTitle()+"</H3>");
html.println("<BR>");
html.println("My name is "+ getMy_name()+"<BR>");
html.println("My favorite animal is the "+
getMy_favorite_animal()+"<BR>");
html.println("My favorite food is "+
getMy_favorite_food()+"<BR>");
html.println("</BODY>");
html.println("</HTML>");
html.close();
}catch(Exception e)
{
AutoPDStandardLogger.getLogger(getProject()).log(
"Oops!", e, 9999, Project.MSG_ERR,this);
throw new BuildException(e);
}
}
public String getMy_favorite_animal() {
return my_favorite_animal;
}
public void setMy_favorite_animal(String my_favorite_animal) {
this.my_favorite_animal = my_favorite_animal;
}
public String getMy_favorite_food() {
return my_favorite_food;
}
public void setMy_favorite_food(String my_favorite_food) {
this.my_favorite_food = my_favorite_food;
}
public String getMy_name() {
return my_name;
}
public void setMy_name(String my_name) {
this.my_name = my_name;
}
}
|
カスタム・タスクを実装に関連付ける
第 2 回の記事で説明したように、カスタム・タスクは、そのタスクを実装する Java クラスに Ant <taskdef> を使用して関連付けなければなりません。AutoPD ツールに含まれているメインの autopdtaskdef.properties ファイルを編集するのではなく、独自のファイルを作成してスクリプトが確実にそのファイルとメインのファイルを指定するようにしてください。
スクリプトでは以下のようになります。
<taskdef file="${autopdrootdir}/properties/autopdtaskdef.properties" />
<taskdef file="${myrootdir}/properties/mytaskdef.properties" />
|
この記事の単純な例では、mytaskdef.properties ファイルに以下の行が必要です。
create_my_info=com.ibm.autopd.anttasks.examples.CreateMyInfo
|
新規カスタム・タスクの呼び出し結果
図 6 に示す分析レポートは、図 5 のレポートを生成した Portal Configuration スクリプトと同じスクリプトで生成されていますが、1 つだけ変更されていることがあります。カスタム・タスク <create_my_info> の呼び出しが、Basic WebSphere Portal Analysis フラグメントを作成する <analyze_files> タスクの呼び出しより先にスクリプトに挿入されているという点です。そのため、分析レポートでは <create_my_info> フラグメントが Basic WebSphere Portal Analysis フラグメントの前に表示されています。
図6. 新しいフラグメントが挿入された図 5 の分析レポート
まとめ
AutoPD ツールが用いられた製品が増えるにつれ、柔軟性がますます重要な要件となってきています。増分分析機能を AutoPD ツールに追加することで、スクリプト作成者が以前に指定した分析手順を必要なあらゆる組み合わせで結合できるようになるため、ソリューション指向の問題分析に道が開かれます。
増分分析では、簡潔で必要なものを完備したスクリプト要素のそれぞれが、分析ジョブの一部分を実行し、それによって得られた結果を 1 つの包括的分析レポートに結合することができるように考慮されています。つまりあらゆる点で、コミュニティー・ベースの疎結合 AutoPD 収集スクリプトの開発と適用が容易になるということです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | | | Bob Mooreは、ノースキャロライナ州Research Triangle ParkにあるIBMのSoftware Group Advanced Design and TechnologyチームのAdvisory Software Engineerです。1977年にDuke Universityにて哲学の博士号を取得しています。1983年にIBMに入社して以来、SNA/Management ServicesやCMIP、SNMP、DMTF CIMなど、ネットワークやシステム管理に関する様々なアーキテクチャーや標準に携わってきました。連絡先はremoore@us.ibm.comです。 |
| | | Brad Topolは、ノースキャロライナ州Research Triangle ParkにあるIBMのSoftware Group Advanced Design and TechnologyチームのSenior Software Engineerです。1998年に、Georgia Institute of Technologyにてコンピューター・サイエンスの博士を取得しています。現在は、自動問題判別サービスツール（Problem Determination Serviceability Tool）の開発リーダーです。これまで、オートノミック・コンピューティングやWebサービス、グリッド・コンピューティング、Webコンテンツ変換、アスペクト指向プログラミングなどの領域で、先端技術プロジェクトに携わってきました。連絡先はbtopol@us.ibm.comです。 |
| 
| | Jie Xingは、ノースキャロライナ州Research Triangle ParkにあるIBMのAdvisory Software Engineerとして、1年半勤務しています。現在は、Webサービスやグリッド・コンピューティング、オートノミック・コンピューティングなどの領域で先端技術に携わっています。2000年に、North Carolina State Universityにてコンピューター・サイエンスにおけるオペレーションズ・リサーチで博士を取得しています。そこでの研究領域は、マルチエージェント・システムや分散システム、ワークフローなどでした。連絡先はjiexing-at-us.ibm.comです。
|
| 
| | Belinda Changは、ノースキャロライナ州Research Triangle ParkにあるIBM Software Group Advanced Design and TechnologyチームのSoftware Engineerです。カーネギー・メロン大学にてコンピューター・サイエンスの学位を取得しています。連絡先はbelchang@us.ibm.comです。 |
| | | Scott Kolodzy はマサチューセッツ州 Worcester Polytechnic University の 3 年生で、コンピューター・サイエンスの理学士号コースを進んでいます。2006 年、マサチューセッツ州 Westford にある Websphere Portal Development チームで実務研修を終えた彼は、Portal v6.0 の AutoPD 拡張機能を複数開発しています。2008 年には WPI を卒業する予定です。連絡先は skolod@wpi.edu です。 |
| | | Peter Sohn は、Software Group Worldwide Consumability チームの Senior Engineer です。1984 年に IBM に入社して以来、RAS (信頼性、可用性、そして保守容易性) を専門として、ハードウェアとソフトウェア両方のテストおよび開発チームで活躍しています。最近は WPLC (Lotus) の主任保守容易性アーキテクトを務める一方、さまざまなプロジェクトで IBM Support Assistant と Automated Problem Determination Tool の発展に積極的に取り組んでいます。連絡先は peter_sohn@us.ibm.com です。 |
記事の評価
| 
