レベル: 初級 Bob Moore (remoore@us.ibm.com), Advisory Software Engineer, IBM
Brad Topol (btopol@us.ibm.com), Senior Software Engineer, IBM
Jie Xing (jiexing@us.ibm.com), Advisory Software Engineer, IBM
2005年 5月 24日
2006年 3月 07日 更新 AutoPDツール（Automated Problem Determination Tool：自動問題判別ツール）を拡張する方法を学びましょう。このツールに含まれているAntスクリプトを基に追加のAntスクリプトを作成するだけで、あるいはツールに同梱されているXML文書を編集するだけで、他の製品や問題シナリオにも対応できるようになります。またこの記事では、このツールの持つ国際化機能と、その使い方についても学びます。
はじめに
この記事は、AutoPDツール（Automated Problem Determination Tool）に関するシリーズの2回目です。（第1回ではツールを紹介しています。）この記事では、他の製品や問題シナリオに対応するためにツールを拡張する方法について説明します。拡張の方法には、（ツールに含まれているAntスクリプトを基に）追加のAntスクリプトを作成する方法と、ツールに同梱されているXML文書を編集する方法があります。また今回の記事では、このツールの持つ国際化機能と、その使い方についても学びます。カスタム化に関しては、2つの記事に分けます。1つの記事ではツールのシンプトン（症状）分析機能の拡張に関して説明し、もう1つの記事では（コモン・ベース・イベント『Common Base Event』を含む）XMLフォーマットのログ・レコードに関して説明します。
AutoPDツールには約50のAntタスクのJava™実装が含まれていますが、ツールの振る舞いは、実際にはXML文書によって制御されます。これらのXML文書は2つのカテゴリーに分けることができます。つまり、事前定義された一連のタスクを通してツールに指図するAntスクリプトの集合と、位置やオプション、実行パラメーターなどを規定する追加のXML文書、という2つです。ほとんどの場合、このツールを新しい製品や新しい問題タイプに応用するために新しいJavaコードを書く必要はありません。変更を行うには、ツールに同梱されているXML文書を変更するか、あるいは、同梱されているXML文書の代わりにツール用の新しいXML文書を作成するだけでよいのです。
ツールの問題タイプ・メニューを変更する
図1は、ツールを開いた時のメインGUIを示しています。このインターフェースのうち変更する必要があるのは、ユーザーが利用可能な、問題タイプのツリーのみです。ユーザーは、ツールに含まれている収集スクリプトを、こうした問題タイプを使って呼び出します。そのため、新しい収集スクリプトを作成する場合には、ユーザーがそうしたスクリプトを呼び出すための手段を提供する必要があります。
図1. AutoPDツールのユーザー・インターフェース
Problem Typeツリーを変更するには、図1に示す幾つかのフォルダーをユーザーが拡張した後に、インターフェースを調べます。図2を見ると、最上位レベルのフォルダーであるIBM WebSphere® Portalの下に、2番目のレベルのフォルダー（Installation and ConfigurationやSecurity and Administrationなど）があることが分かります。同じような、2番目のレベルのフォルダーは、最上位レベルのフォルダーであるWebSphere Application Serverの下にもあります。こうした2番目のレベルのフォルダーは、ある特定な製品に対する問題タイプを、ユーザーにとって意味を持つサブカテゴリーにグループ分けするために使われています（サブカテゴリーによって、ユーザーは特定な問題タイプを簡単に見つけられるようになります）。実際には、AutoPDツールは第3レベルのフォルダーを使って、さらに別レベルのカテゴリー分けをすることができます。しかし今のところ、WebSphere Application ServerでもWebSphere Portalでも、この第3のレベルは必要はありません。
図2. フォルダーを拡張したGUI
Problem Typeツリーのエントリーは、AutoPDMenu.xsdスキーマに準拠したXML文書で規定されます。このスキーマはツールのpropertiesディレクトリーにあるので、AutoPDMenu文書を妥当性検証するためにXMLツーリングの中にインポートすることができます。リスト1は、バージョン1.2のAutoPDツールのメニュー・エントリーを規定するAutoPDMenu-full.xml文書から引用した何行かを示しています。リスト1と図2を比較すると、それぞれのフォルダーの中での個々のエントリーの位置を、topLevelとsecondLevelというXML属性がコントロールしていることが分かります。thirdLevelという属性も、まったく同じように動作します。皆さんが独自の製品サブツリーを定義する場合、topLevelの値には、その製品を特定するような値を選択する必要があります。その点を除けば、ユーザーにとって分かりやすいものである限り、secondLevel属性もthirdLevel属性も好きなようにに使用することができます。
リスト1. AutoPDMenu.xml文書
<autoPDMenuItem title="Portal_Config_Problem"
link="scripts/wps/portalconfig.xml"
bundle="autopdtoolstrings"
topLevel="WebSphere_Portal"
secondLevel="Portal_Installation_And_Configuration"/>
<autoPDMenuItem title="Portal_Upgrade_Problem"
link="scripts/wps/portalupgrade.xml"
bundle="autopdtoolstrings"
topLevel="WebSphere_Portal"
secondLevel="Portal_Installation_And_Configuration"/>
<autoPDMenuItem title="Portal_XML_Config_Interface_Problem"
link="scripts/wps/portalaccesscontrol.xml"
bundle="autopdtoolstrings"
topLevel="WebSphere_Portal"
secondLevel="Portal_Installation_And_Configuration"/>
<autoPDMenuItem title="Portal_Access_Control_Problem"
link="scripts/wps/portalaccesscontrol.xml"
bundle="autopdtoolstrings"
topLevel="WebSphere_Portal"
secondLevel="Portal_Security_And_Admin"/>
<autoPDMenuItem title="Portal_Login_Problem"
link="scripts/wps/portallogin.xml"
bundle="autopdtoolstrings"
topLevel="WebSphere_Portal"
secondLevel="Portal_Security_And_Admin"/>
|
リスト1の中にある、titleやtopLevel、secondLevelなどの属性は、それ自体は表示可能なストリングではなく､変換キーであることに注意してください。AutoPDツールのメインGUIを構築する際にAutoPDエンジンがアクセスできる言語バンドルの中に、対応するエントリーが存在している必要があります。後ほど説明する、Antスクリプトを国際化するでは、AutoPDエンジン用に言語バンドルをパッケージする方法について学びます。ここで重要なことは、AutoPDメニュー・エントリーが言語バンドルを指すための方法です。この方法には、リスト1で示したように明示的に行う方法と、暗黙的に行う方法の2つがあります。もし、あるautoPDMenuItem要素にbundle属性が無い場合には、その要素の言語バンドルがAutoPDツールのデフォルトになります。このデフォルト言語バンドルは、properties/autopd.propertiesファイルの中でnlsbundleプロパティーの値として規定されます。
またproperties/autopd.propertiesファイルは、どのAutoPDMenu文書を使ってProblem Typeツリーに読み込むのかをAutoPDエンジンが知るための場所でもあります。バージョン1.2のAutoPDツールに含まれているautopd.propertiesには、autopdmenu=properties/autoPDMenu-full.xmlというエントリーが含まれています。独自の収集スクリプトを起動するためにautoPDMenuItem要素を追加するには、2つの方法があります。
- バージョン1.2のAutoPDツールに含まれている収集スクリプトではなく、皆さんが作成した収集スクリプトをユーザーが起動できるようにしたい場合には、まったく最初から独自のAutoPDMenuを作成し、それを指すようにautopd.propertiesの中のautopdmenuプロパティーをアップデートする必要があります。
- 皆さんが作成した収集スクリプトの他に、バージョン1.2のAutoPDツールに含まれている収集スクリプトもユーザーが使えるようにしたい場合には、皆さんのスクリプトにautoPDMenuItem要素を追加してツールのautoPDMenu-full.xml文書を拡張する必要があります。その場合でも、アップデートされた文書を別のファイル名で保存し、それを指すようにautopdmenuプロパティーの値を調整した方が良いでしょう。アップデートされた文書の保存に同じファイル名を使用してしまうと、ユーザーがAutoPDツールをアップデートすると変更が上書きされてしまう危険性があります。
念のために、リスト2は、autoPDMenuItem要素を定義するAutoPDMenu.xsd スキーマの一部を示しています。
リスト2. autoPDMenuItem要素のスキーマ定義
<xsd:element name="autoPDMenuItem">
<xsd:complexType>
<xsd:attribute name="bundle" type="xsd:string" use="optional"/>
<xsd:attribute name="link" type="xsd:string" use="required"/>
<xsd:attribute name="title" type="xsd:string" use="required"/>
<xsd:attribute name="topLevel" type="xsd:string" use="optional"/>
<xsd:attribute name="secondLevel" type="xsd:string" use="optional"/>
<xsd:attribute name="thirdLevel" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element> |
AutoPDツール用に独自のAntスクリプトを書く
Antは非常に豊富な機能を備えているため、ほとんど何でもAntスクリプトで行うことができます。そのため私達は、何か特別なことをするためのスクリプトを作る場合には、どこから始めればよいのか戸惑ってしまいます。このツールは独自の収集スクリプトを備えた完全機能の問題判別ツールとして配布されており、カスタムで書かれたスクリプトをサポートするための単なるエンジン・コンポーネントではありませんが、その理由の1つは、この点にあります。実際のスクリプトを幾つか含めることによって、独自のスクリプトを開発するための出発点を提供しているのです。
こうしたスクリプトは、カスタム・スクリプトで可能なことを制限するわけではありません。AutoPDツールでは、標準のAntタスクは全て利用でき、しかも自由な使い方ができます。しかし同梱されているスクリプトは、少なくとも次の3つの点で参考になるはずです。
- このスクリプトでAutoPDツールが実現していること、つまり問題情報を収集しシンプトン分析を行う、というスクリプトを書く際の全体的な様子が分かります。
- AutoPDツール実装が想定している一定の規則が分かるため、AutoPDツール用のAntスクリプトを書く場合にも、こうした規則に従えばよいことが分かります。
- ツールに用意されているカスタムのAntタスクを、いつ、どのように、なぜ使うのかが分かります。こうしたカスタム・タスクは標準のAntの資料には説明されていないため、この記事ではそれらを詳しく説明しています。しかし一部は非常に単純なため、それらがツール自体のスクリプトの中でどう使われているかを見るだけで、必要なことがすべて分かるはずです。
AutoPDスクリプトの全体的な構造
まず、第1回の記事で使用したものと同じAntスクリプト、つまりPortal Login問題用のスクリプトを、全体的な構造という面から見てみましょう。下記の説明は、Antの基礎に慣れていることを想定しています。（ApacheのAntマニュアルについては、参考文献に挙げたリンクを見てください。）
autopdmainターゲット
下記（リスト3）はPortal Loginスクリプトの中のプライマリー・ターゲットです。
リスト3. PortalLoginスクリプトの中のプライマリー・ターゲット
<!-- This target is the main entry point into the script. It is the target
that is called by the AutoPD tool after this collection type has been selected,
and collection is started.
-->
<target name="autopdmain" description="This is AutoPD main to control running steps"
depends="set_problem_type,
setup_autopd,
validate_os,
ask_for_roots,
verify_roots,
was_version,
was_version_level,
wps_common_setup,
cell_type,
input_cell_name,
wps_config_setting_for_cluster,
deployment_manager_root,
was_log_redirect,
security_type,
was_admin_info,
detect_was_status,
warnuser,
stop_wps,
backup_log_properties,
recovery_needed,
set_log_properties,
set_wmm_properties,
start_wps,
pause,
stop_wps1,
collect_wps_information_common,
collect_wps_information_security_admin,
restorewps,
recovery_completed,
autopd_feedbacks,
ftp_message,
ftp_collected_information,
restart_wps,
script_completed">
</target>
|
コレクション（collection）がメインGUIから呼び出されると、ツールはそれに関連したスクリプトの実行をautopdmainという名前のターゲットで開始します。従って、各スクリプトの中に、この名前を持つターゲットを含める必要があります。AutoPDツールに含まれるスクリプトの場合、このターゲットは、スクリプト中の他のターゲットをAntのdepends属性を使って順次開始するための方法にすぎません。Antでは、もっと複雑な使用パターンでdepends属性を使用することができます（例えばターゲットAがターゲットBに従属し、ターゲットBはターゲットCに従属し、ターゲットCはターゲットDに従属する、など）。そして、そうした使用パターンを使うことは自由です。しかし私達は、こうした複雑な従属パターンはAutoPDツール独自のスクリプトには必要ないと考えました。各WebSphere Portalスクリプトの中で、他のターゲットへの従属関係を表現しているのは2つのターゲットのみです（つまりメインのエントリー・ポイントであるautopdmainと、オプションとしての、別のエントリー・ポイントであるautopdmainrecoveryの2つです。後者についてはautopdmainrecoveryターゲットのセクションで説明します。）
autopdmainターゲット用にリストアップされた従属関係の中に、stop_wps1とstop_wps2という1対のターゲットがあることに注意してください。この2つのターゲットは、実際は名前以外は同じです。Antが従属関係を処理する方式の都合上、1対のターゲットのターゲットが必要なのです。つまり、あるターゲットが実行された後は、それに対する従属関係はすべて満足されるのです。従ってターゲットが再度実行されることはありません。このスクリプトはWebSphere Portalを2度停止する必要があるため、2つの停止コマンドを発行するために2つの別々なターゲットが必要なのです。
AutoPDツールが最近Ant 1.5からAnt 1.6に移行された際、ある機能を1つのスクリプトの中で複数回実行したいというスクリプト作成者のために、もう1つのオプション、Antマクロが利用できるようになりました。Antマクロは、今やAutoPDツールで完全にサポートされています。将来、新しい収集スクリプトを開発する際には、私達も必ずAntマクロを使うようになるでしょう。しかしオリジナルの手法はAnt 1.6でも問題なく動作するため、Antマクロを使うように既存のスクリプトをアップデートする必要があるという状況には、今のところまだ突き当たったことはありません。
autopdmainrecoveryターゲット
autopdmainrecoveryターゲット（リスト4）は、Portal Loginスクリプトの中で2番目のターゲットであり、スクリプトへのエントリー・ポイントとしての役割を果たします。
リスト4. Portal Loginスクリプトの中のRecoveryターゲット
<!-- This target provides an alternate entry point into the script. The
AutoPD tool calls this target when it detects that a problem has occurred so
that the script has an opportunity to restore the system to the correct state
before terminating.
-->
<target name="autopdmainrecovery" description="Recover Portal Server state from AutoPD's failure"
depends="stop_wps2,
collect_wps_information_for_recovery_common,
collect_wps_information_security_admin_for_recovery,
reset,
recovery_completed,
recovery_script_completed">
</target>
|
従属関係リストの中の最初のターゲット、stop_wps2に注意してください。これはWebSphere Portalを停止する3番目のターゲットであり、これは先ほどautopdmain従属関係リストの中で示した2つと同じです。これらのターゲットはリカバリー用に再利用することはできません。リカバリーが必要となる前に、これらがautopdmain従属関係リストから実行されたかも知れないためです。そうした場合には、リカバリーに必要になっても、これらが再度実行されることはありません。
autopdmainrecoveryというターゲット名は、ツールから特別な扱いも受けています。ツールはスクリプトが異常終了したことを検出すると、回復が必要なポイントでスクリプトが失敗したのかどうかを、次のようにして調べます
- 失敗が起きた時に、どのスクリプトが実行されていたのかを判定します。
- 不成功に終わったスクリプトの実行中に設定された可能性のある、2つの特定なAntプロパティーを検証します。（ツールは、ある特定な組み合わせを探します。つまりtrueという値を持つautopdNeedRecoveryというプロパティーと、（未定義、あるいはfalseという値を持つ）autopdRecoveryPerformedというプロパティー、という組み合わせです。言い換えると、前回のスクリプト実行は、「回復が必要なものの、まだ回復は実行されていない」というポイントで停止したのか、という問題です。）
- この組み合わせを検出すると、ツールは同じスクリプトを再度呼び出します。しかし今度は通常のターゲットであるautopdmainではなく、autopdmainrecoveryというターゲットから開始するのです。
このロジックを適切に使用するためには、autopdNeedRecoveryプロパティーとautopdRecoveryPerformedプロパティーを、Portal LoginスクリプトやAutoPDツールに含まれるスクリプトが扱っている方法と同じ方法で扱う必要があります。リスト5とリスト6は、スクリプトの中で行うべきことを要約しています。ここで言う「実行パス」はスクリプトが呼び出すタスクのシーケンスを指しており、どのターゲットの中にタスクがあるかは無関係です。
リスト5. autopdmainの実行パス
...
// break stuff
<property name="autopdNeedRecovery" value="true" />
// break stuff
...
// break stuff
...
// fix stuff
...
// fix stuff
...
// fix stuff
<property name="autopdRecoveryPerformed" value="true" />
...
|
リスト6. autopdmainrecoveryの実行パス
...
// fix stuff
...
// fix stuff
...
// fix stuff
<property name="autopdRecoveryPerformed" value="true" />
...
|
メインの実行パスで、何かを「いじったら」、すぐにautopdNeedRecoveryというプロパティーをtrueに設定します。（つまり、スクリプトに対して後でアンドゥ（「回復」）する予定の変更を加えたら、即座にtrueに設定します。）例えばPortal Loginスクリプトは、ポータル・サーバー・ログの幾つかをバックアップ位置にコピーした後、ログイン問題の再現処理を行う一方、元の位置にあるログを削除します。スクリプトが終了に近づくと、スクリプトはログのコピーを元の位置に戻し、スクリプトの実行前にWebSphere Portalが持っていた履歴データがWebSphere Portalに残るようにします。autopdmainrecovery実行パスは、こうしたログ回復が、たとえそのポイントに達する前にスクリプトのautopdmain実行パスが中断された場合であっても確実に行われるように保証します。
必ずしもすべてのスクリプトに回復パスが必要なわけではありません。もしスクリプトが何も「いじらない」のであれば、回復すべきものもありません。しかし回復の実行が必要な場合には、必要な回復ステップを厳密に決めなければなりません。また、autopdmainrecoveryのエントリー・ポイントでスクリプトが呼び出された時に実行されるターゲットに対して、確実にこうしたステップを実行させる必要があります。（スクリプトが正常終了に向かって進行する場合には、autopdmain実行パスの終わり近くで実行されるターゲットに対して、確実にこうしたステップを実行させる必要があります。）回復が必要な場合に、この2つのプロパティーに対して行うべきことは下記の通りです。
- autopdmain実行パスで、何かを「いじったら」、即座にautopdNeedRecoveryをtrueに設定します。このプロパティーをtrueに設定した後は、続いて他のものを「いじる」ことは問題ありません。
- autopdmain実行パスで、それまでにいじったものを『すべて』「回復」したら、すぐにautopdRecoveryPerformedをtrueに設定します。
- autopdmainrecovery実行パスで、それまでautopdmain実行パスでいじった可能性のあるものを『すべて』「回復」したら、すぐにautopdRecoveryPerformedをtrueに設定します。
- リスト4と5に示した2つの<property>タスクをターゲットの中に直接挿入することも可能ですが、私達としては、ツールに含まれているrecovery_neededとrecovery_completedという共有ターゲットを利用するようにお勧めします。これらのターゲットには、何が起きているかをユーザーに伝える<wsnlsecho>タスクと共に<property>タスクが含まれており、リカバリー・プロパティーを設定することができます。しかしこれらを使うことによる本当の価値は、autopdmain実行パスの従属関係リストを単純に検証するだけでスクリプトの「リカバリー・ゾーン」の始まりと終わりが非常に容易に分かるようになる、という点にあります。autopdmainrecovery実行パスには、recovery_completedターゲットも使うことができます。もしこのパスが呼び出されているのであれば、このターゲットがautopdmain実行パス上で呼び出されたはずのポイントには達していないことが分かるからです。
もしスクリプトがautopdmain実行パス中に失敗した場合、その失敗が、回復を必要とする動作（「// break stuff」）を何か行った後であって、なおかつ回復の実行（「// fix stuff」）をする前である場合には、ツールは、autopdmainrecoveryにおいてスクリプトを起動させるようなプロパティー値の組み合わせに突き当たります。同じことは、回復の完了前に回復そのものが失敗した場合にも起こります。autopdRecoveryPerformedをtrueに設定した後は、スクリプトがどちらの実行パスを続行しても問題はありません。しかし、ここでスクリプトが失敗した場合には、回復は呼び出されません。ですから、この時点では何も「いじらない」ように注意する必要があります。
共有ターゲットを含むXML文書をインポートする
多くのWebSphere Portalスクリプトは同じようなステップを実行する（例えば、収集したzipファイルをIBMサポートに送るためにFTPコマンドを発行する、など）ため、同じターゲットを共有している場合がよくあります。ツールに含まれるスクリプトの維持管理を単純にするために、こうした共通ターゲットは別のXML文書の中に集められます。そしてこれらのXML文書は、リスト7に示すカスタムのAntスクリプトによって、各スクリプト文書の中に入れられます。各インポート操作は別々なので、ある1つのスクリプトが、幾らでも必要なだけ多くの共有ターゲット文書からインポートすることができます。ただし、どのスクリプトも、sharedtargets.xmlという文書からのインポートを行う必要があります。この文書には、どのスクリプトでも呼び出す必要のある共有ターゲットが含まれているからです（また、どのスクリプトにも必要なわけではありませんが一般的に便利な、他の共有ターゲットも含まれています）。
リスト7. 共有ターゲット文書をインポートする
<!-- Targets shared among multiple scripts are in the XML documents *-sharedtargets.xml.
The following imports pull these shared targets into this script.
-->
<autopdimport file="${autopdimportdir}/scripts/sharedtargets.xml"
osgiBundle="com.ibm.autopd"/>
<autopdimport file="${autopdimportdir}/scripts/portal-was-sharedtargets.xml"
osgiBundle="com.ibm.autopd"/>
<autopdimport file="${autopdimportdir}/scripts/wps/portal-sharedtargets.xml"
osgiBundle="com.ibm.esupport.client.product.SSYJJC"/> |
OSGiのコンポーネント化環境特性にAutoPDエンジンを適合させるために、<autopdimport>というカスタム・タスクが作成されています。（OSGiに関して詳しくは、参考文献に挙げたOSGi AllianceのWebサイトを見てください）。この話題に関しては、osgiBundle属性の値の選び方の詳細と併せて、今後の記事で扱う予定です。リスト7に挙げた3つの共有ターゲットをインポートするためには、リスト7の中に示した値を使うことができます。
スクリプトの中に繰り返しが多い場合には、共有ターゲットと同じ方法を使うことができます。つまり独自のXML共有ターゲット文書を定義し、それらを指すautopdimportタスクを、それぞれのスクリプトの中に含めるようにします。当然ですが、これがうまく行くのは、どのスクリプトも同じターゲットを使用している場合のみです。
Antスクリプトを国際化する
幾つかの標準Antタスク（例えば<echo>タスクや<input>など）では、テキスト・ストリングを、ある方式で表示したり別の方式で表示したりすることができます。しかしこうした標準タスクは表示されるテキスト・ストリングの国際化をサポートしておらず、表示されるものは、スクリプトの中に現れるテキスト・ストリングそのものです。AutoPDツールには、こうした標準Antタスクの拡張版を実装したカスタムのAntタスクが幾つか含まれており、それらは表示ストリングの国際化をサポートしています。
まず、<wsnlsecho>というカスタム・タスクを考えてみてください。このタスクは標準の<echo>を拡張しています。実のところ<wsnlsecho>タスクは、最初はWebSphere Application Server用に開発されたのですが、その後AutoPDツール用に拡張されています。リスト8は、このタスクの例です。これはPortal Loginスクリプトによってインポートされた共有ターゲットから引用したものです。
リスト8. <wsnlsecho>タスク
<wsnlsecho key="Zip_all_log_and_related_information_to_a_zip_file_pmrfilename"
bundle="autopdtoolstrings"
message="Zipping all log and related information to a zip file: {0}"
replace="${pmrfilename}"
id="2225"
level="info"
component="\scripts\wps\portal-sharedtargets.xml"/>
|
ここで、key属性には鍵の値が含まれており、この値は、（bundle属性で指定されるバンドルの中の）テキスト・ストリングを指すインデックスです。（実際の鍵の値、Zip_all_log_and_related_information_to_a_zip_file_pmrfilenameは任意です。このツールが使用している、非常に長く醜悪な値は、国際化に向けた当初の試みからの遺産です。この当初の試みは、<wsnlsecho>カスタム・タスクに基づく現在の手法が採用されたため、廃案となりました。）ここでは通常のJavaバンドル処理が適用されるため、デフォルト・ファイルであるautopdtoolstringsを、ロケール特有ファイル（autopdtoolstrings_enなど）でオーバーライドすることができます。全てのバンドル・ファイルは、ツールのpropertiesディレクトリー、あるいはそのサブディレクトリーのどれかに置くことになっています。もしバンドルがpropertiesディレクトリーのサブディレクトリーにある場合には、次のような方法で参照されます。
bundle="properties/SSEQTP/autopdtoolstrings_was".
message属性には、指定された名前を持つバンドル・ファイルが見つからない場合に使用されるメッセージ・テキストが含まれています。replace属性には置換変数のリストが含まれています。（置換変数が複数ある場合は二重セミコロン（;;）で区切られます。）置換変数は、メッセージ・テキストの中の、番号がつけられた置換ポイント（例えば {0} など）にプラグインされます。最後に、id、level、componentという属性は、このタスクを実行した際に作成されるAutoPDのログ・エントリーに関する情報を提供します。
スクリプトの中で実行される典型的なアクティビティー
これから先のセクションでは、AutoPDツール自体のスクリプトが実行するアクティビティーの幾つかを簡単に見て行きます。より詳しく学ぶためには、皆さん自身でスクリプトそのものを注意深く検証してください。
プログレス・レポートを提供する
ツールのAntスクリプトは、1つの標準Antタスクと3つのカスタム・タスクを組み合わせて、タイムスタンプの付いた一連のプログレス・レポートを提供しており、スクリプトがタスク・シーケンスを実行する様子を知ることができます。こうしたプログレス・レポートには、下記のような2つの目的があります。
- ツールのユーザーに対して、ツールが何をしているかを即座にフィードバックする。
- プログレス・レポートはAutoPDログ・ファイルの中に保存されるため、ツールがWebSphere Portalの停止、再起動といったステップを具体的にいつ実行していたのか、という情報をIBMサポートに提供することができます。こうしたタイムスタンプを、分析レポートの中にあるタイムスタンプや基礎となっているログの中にあるタイムスタンプと比較することによって、IBMサポートはログ・エントリーが書かれたコンテキストを、よりよく理解することができます。
リスト9は、Portal Loginスクリプトから引用した4つのカスタム・タスクの例を示しています。
リスト9. プログレス・レポートを発行するためのカスタム・タスク
<echo message=" "/>
<stepcount />
<autopdtimestamp property="autopdts" pattern="yyyy.MM.dd-HH.mm.ss.SSSz" />
<wsnlsecho key="Step_stop_Portal_Server"
bundle="autopdtoolstrings"
message="[{0}] Step {1}: Stopping Portal Server"
replace="${autopdts};;${step.count}"
id="2243"
level="info"
component="\scripts\wps\portal-sharedtargets.xml" />
|
スクリプトでプログレス・レポートを出力したい時には、このパターンを（適当なメッセージ・キーを付けて）単純に繰り返します。下記は、ここで示したタスクを組み合わせて得られるプログレス・レポートの例です。
[2005.05.15-08.24.51.717EDT] Step 4: Stopping Portal Server
プログレス・レポートに必要なステップとしては、最初のプログレス・レポートの前に実行されるAntターゲットの中で、ステップ・カウンターを0に初期化することだけです。
<stepcount count="0" />
このステップは、WebSphere Portalスクリプトでの処理方法と同じ方法で処理するのが最善です。つまり、autopdmain実行パス上にautopd_setupという共有ターゲットを含めるようにします。
ユーザーからの情報を取得する
AutoPDツールの主な設計目標の1つは、収集プロセスを可能な限り自動化し、ユーザーの介在なしに収集を行えるようにすることです。しかし実際には、ある地位にあるユーザーしか答えられないような質問をするために、ツールがユーザーの介在を必要とする状況が数多くあります。こうした質問としては、次のようなものがあります。
- どの製品インスタンスに対して収集を実行すべきか。（ツールはシステム上に存在する製品の全インスタンスを検出できますが、どのインスタンスに対してユーザーが問題データを収集したいのかは、知るすべがありません。）
- この時点でサーバーを停止、再起動しても問題ないか。（この時点でサーバーを停止してしまうことと、現在の問題を解決することの相対的な重要性を判断できるのは、ユーザーのみです。）
- ツールが収集した問題データをIBMサポートにFTPすべきかどうか。（ツールは、問題データをIBMサポートにFTPするための機構は自動化できますが、ツール自体はデータをFTPすべきか否かを判断できません。IBMサポートは、分析レポートの中の特定な情報を検証するようにユーザーに指示するかも知れません。そしてその情報に基づいて、別の設定で2度目の収集を行い、その結果をFTPするように指示するかも知れません。あるいは場合によると、ユーザーのエンタープライズ・ファイアーウォールの設定が、ツールから直接IBMに問題データをFTPできないように設定されているかも知れません。）
どの場合も、Antスクリプトが実行を開始した後、ツールは何らかのユーザー入力を必要とします。こうしたユーザー入力が、どのように提示され、また受け取られるのかを見て行きましょう。
概要を説明した前回の記事では、ツールが収集した問題データをIBMサポートにFTPすべきかどうかをユーザーに尋ねるポップアップ・ウィンドウを説明しました。このポップアップ・ウィンドウを図3に再掲します。
図3. 収集されたデータをIBMサポートにFTPするか否かユーザーが選択する
このポップアップ・ウィンドウは、リスト10に示すPortal Loginスクリプトの中にあるカスタムAntタスクの結果として表示されたものです。
リスト10. ポップアップ・ウィンドウを表示するためのカスタムAntタスク
<autopdinput message="Would_you_like_the_AutoPD_Tool_to_FTP_the_logs_to_IBM_Support"
validargs="FTP_the_logs_to_IBM_Support,No_Thanks"
addproperty="ftpresponse" />
|
Antスクリプトを国際化するで説明した通り、このツールには、表示ストリングの国際化をサポートするように標準Antタスクを拡張したカスタムAntタスクが含まれています。<autopdinput>タスクは、そうしたタスクの1つです。先に説明した通り、下線を持つ3つのストリングは、リソース・バンドルの中にある変換された表示ストリングのインデックスを示す鍵です。messageとvalidargsという属性は、変換されたストリングを図3に示す位置に置きます。addpropertyという属性は、ユーザーが押すボタンに関連付けられた『変換されていない』ストリング（つまり鍵そのもの）を、ftpresponseというAntプロパティーに割り当てます。<autopdinput>要素の中で鍵値に対するテキスト・ストリングを探すために、ツールのデフォルト・バンドルであるautopdtoolstrings.propertiesの代わりに独自のバンドルを使いたい場合には、ここでもbundle属性を含める必要があります。
次に、もしユーザーがFTP the logs to IBM supportボタンを押したら、そして押した時のみ、このスクリプトは標準のAnt<condition>タスクを使って、2番目のプロパティーであるdo.FTPを作ります（リスト11）。
リスト11. <condition>タスクを使ってdo.FTPプロパティーを作る
<condition property="do.FTP">
<equals arg1="FTP_the_logs_to_IBM_Support" arg2="${ftpresponse}" />
</condition>
|
2番目のプロパティーは、Antの条件付き処理の方式から必要なものです。つまり条件付き処理は、プロパティーの値ではなく、プロパティーの『存在』に基づいて行われるのです。ユーザーがどのボタンを押すかによらず、<autopdinput>タスクが完了する時には、ftpresponseというプロパティーは常に存在します。しかしdo.FTPというプロパティーは、ユーザーがFTP操作の実行を要求するボタンを押した場合、そしてその場合にのみ存在するのです。
最後に、このスクリプトは、do.FTPというプロパティーが存在する場合にのみ、FTP操作を行うターゲットを実行します（リスト12）。
リスト12. ftp_collected_informationターゲットの条件付き実行
<target name="ftp_collected_information"
description="FTP info to IBM Support" if="do.FTP">
...
</target>
|
ユーザーからの入力に基づいてスクリプトの振る舞いを変える必要がある場合には、下記のパターンを使います。
- <autopdinput>タスクを使ってユーザーに入力を要求し、その結果を最初のプロパティーに保存する。
- <condition>タスクを使って、最初のプロパティーの値を2番目のプロパティーの存在にマップする。
- 2番目のプロパティーの存在を使って、その後にあるAntターゲットの条件付き実行を制御する。
カスタムのAntタスク、<if>
Antで標準の条件付きターゲット実行は、確かにスクリプトのランタイム実行パスを制御できるのですが、多くの場合は非常に面倒です。そのためAutoPDツールは<if>というカスタムのAntタスクを実装しており、ターゲットごとに条件付き実行を制御できるようになっています。リスト13は一例として、Portal Loginスクリプトが、verify_rootsという共有ターゲットの中をチェックしています。このチェックによって、先ほど図1で見た入力フィールドに、WebSphere Portalのルート・ディレクトリーとして有効な値をユーザーが入力したかどうかを確認しています。
リスト13. Portal Loginスクリプトの初期ターゲットでの有効性チェック
<wsnlsecho key="Verify_Portal_root_directory"
bundle="autopdtoolstrings"
message="Verifying WebSphere Portal root directory."
id="2202"
level="info"
component="\scripts\wps\portal-sharedtargets.xml" />
<available file="${portal.root}/config/wpconfig.properties"
type="file"
property="portal.root.existing" />
<if isNotTrue="${portal.root.existing}" >
<autopdinput message="Portal_Root_value_is_not_valid"
validargs="OK"
addproperty="portalroot.wrong" />
<wsnlsecho key="Portal_Root_Directory_Inputed_Doesn't_Exist"
bundle="autopdtoolstrings"
message="The WebSphere Portal root directory input by the user does not exist."
id="2203"
level="error"
component="\scripts\wps\portal-sharedtargets.xml" />
</if>
<condition property="do.abort.portalroot.wrong">
<equals arg1="OK" arg2="${portalroot.wrong}" />
</condition>
<fail if="do.abort.portalroot.wrong"> WebSphere Portal root directory input by user doesn't exist.
Automated Problem Determination Tool terminated.</fail>
<!-- Now that Portal root is available and verified, save it for next time in
autopdcurrentstate.properties. -->
<persistproperty property="portal.root"/> |
ここには最上位レベルのタスクが６つあり、<if>タスクの始まりと終わりは太字で示してあります。
- カスタムのAntタスク、<wsnlsecho>は、ツールがWebSphere Portalのルート・ディレクトリーを検証中であることを伝えるメッセージを、プログレス・ウィンドウとAutoPDログ・ファイルに提供します。
- 標準タスク、<available>は、ルート・ディレクトリー値を使おうとし、成功するとportal.root.existingプロパティーをtrueに設定します。このテストは、もし指示された位置にWebSphere Portalがあるならwpconfig.propertiesというファイルもあるはず、と想定しています。
- カスタムのAntタスク、<if>は、portal.root.existingの値をチェックし、このプロパティーの値がtrueと等しくない場合には、そしてその場合のみ、その子タスクを実行します。こうした子タスクは、再試行するようにユーザーに対して伝え、また何が起きているのかをプログレス・ウィンドウとAutoPDログ・ファイルの中に記録します。<if>タスクのインスタンスは、指定されたisTrueとisNotTrueという2つの属性のうち、必ずどちらか1つを持っている必要があります。
- 標準Antタスク、<condition>は、先にdo.FTPの例の中で見た動作と同じ動作を行います。
- 標準Antタスク、<fail>は、WebSphere Portalのルート・ディレクトリーが無効であった場合にはスクリプトをアボートします。この理由は、ツールがWebSphere Portalのインスタンスを見つけられない限り、その先の収集ステップを実行できないためです。
- スクリプトが<fail>タスクを通過すれば、ユーザーが提供するWebSphere Portalルート・ディレクトリー値は有効なはずです。カスタムのAntタスク、<persistproperty>は、この値を不揮発性ストレージに保存します。これによって、スクリプトが次回WebSphere Portalルートをユーザーに尋ねる際には、この値がデフォルトとしてユーザーに表示されます。
先に触れた通り、これらはすべて、Ant標準の条件付きターゲット実行を使っても可能なことばかりです。しかし、そうしてしまうと、できあがるスクリプトはずっと大きく、ずっと理解が難しく、維持管理もずっと困難になってしまいます。検証が必要となるのはWebSphere Portalのルート・ディレクトリーだけではありません。スクリプトは本来のアクティビティーに進む前に、ツールのGUIを使って取得する「正しいはず」の値をすべて検証しなければなりません。例えばverify_rootsターゲットがWebSphere Application Serverのルート・ディレクトリーを検証し、保存する方法は、WebSphere Portalルート・ディレクトリーを検証、保存する方法とまったく同じです。<if>タスクを使うことによって、本来の目的からは派生事項にすぎない多くのターゲットによってスクリプトを乱雑にすることなく、この両方の検証アクティビティーをverify_rootsという1つのターゲットに置くことができます。
シンプトン分析を行う
シンプトン分析は、<infocollect>という1つのカスタムAntタスクで制御されます。リスト14には、Portal Loginスクリプトの中にある、このタスクの例が含まれています。
リスト14. <infocollect>タスク
<infocollect problem="${infocollectProblemType}"
patternFile="${portal.shared.targets.bundle.basedir}/properties/wps/pattern_template.xml"
levelreport="${autopdtmp}/autopd/levelreport.html"
autopdreport="${autopdtmp}/autopd/autopd_analysis_report.html"
productname="${wps.product.name}"
productversion="${wps.product.version}"
autopdname="${autopd_name}"
autopdversion="${autopd_version}"
timeout="${infocollector.timeout}">
<autopdfileset filesetName="wpslog" filesetDir="${portal.root}/log" />
<autopdfileset filesetName="tracelog" filesetDir="${trace.log.file}" />
<autopdfileset filesetName="systemoutlog" filesetDir="${systemout.log.file}" />
<autopdfileset filesetName="systemerrlog" filesetDir="${systemerr.log.file}" />
<autopdfileset filesetName="configtrace" filesetDir="${portal.root}/log" />
<autopdfileset filesetName="eventhistory" filesetDir="${portal.root}/version/history" />
<autopdfileset filesetName="eventhistory" filesetDir="${was.root}/properties/version/history" />
</infocollect>
|
ここでは一体何が行われているのでしょう。
- problem属性は、シンプトン分析の対象となる問題タイプを指定しています。
- patternFile属性は、分析に使用されるシンプトンや分析レポートに含むべき情報、この情報用にレポートで使用するフォーマットなどを含んだファイルを示します。（パターン・ファイルの書き方の詳細は、この記事に続く2回の記事で説明します。）
- 次の2つの属性、levelreportとautopdreportは、分析レポートそのものや、分析レポートにマージされるべきレベル・レポートの別コピーなどを、ツールがどこに保存すべきかを示します。分析レポートに関して言うと、この後に続く<zip>タスクがzipファイルの中に含めるためのレポートを探すのは、この場所です。
- productname属性とproductversion属性は、シンプトン分析の対象となる特定な製品とバージョンを示します。ツールは、patternFile属性を使って指定されるパターン・ファイルの中にある製品やバージョン専用の分析手順に対して、こうした属性値を使ってインデックスを付けます。
- autopd_name属性とautopd_version属性は、具体的にどのバージョンのツールがレポートを作成したかを示す値を渡します（この値が分析レポートの中に入ります）。
- 最後に、timeout 属性は、タイムアウト（分析が停止され収集スクリプトが再開されます）の値をミリ秒で示します。
- <infocollect>タスクには、独自の属性の他に、どのファイルを分析するかを示すための一連の従属<autopdfileset>タスクが含まれています。それぞれの<autopdfileset>タスクには、次の2つの属性が含まれています。
- 分析対象となる、1つあるいは複数のファイルを指定するfilesetDir属性。
- filesetName属性。この属性にはストリング値が含まれており、ツールはこのストリング値と、パターン・ファイルの中にある対応する値（具体的なシンプトン・セットを指します）とを一致比較します。また、この属性には、この特定なファイル・セットの分析に使用するための詳細手順も含まれています。こうしたfilesetNameの値の使い方に関しての詳細は、今後シンプトン分析を説明する記事の中で説明する予定です。
この例では、filesetNameを除いて、全ての属性値にはAntプロパティーが含まれていることに注意してください。（これらのAntプロパティーは、（スクリプトの中の）これ以前のどこかで初期化されています。）こうしたプロパティー値の一部は、単純にプロパティー・ファイルから読み込まれます。しかしそれ以外は、Antターゲット全体を使って解決する必要があります。例えば、filesetDirの値の一部がどのように解決されるかを調べるためには、Portal Loginスクリプトの中のlogRedirectターゲットを調べる必要があります。
problem属性に対する、${infocollectProblemType}という値から、AutoPDツールのスクリプト中のパラメーター、『スクリプト・レベル・パラメーター』をどうやって渡すのか、という問題が起きてきます。リスト14の<infocollect>タスクは共有ターゲットで発生するため、様々な問題タイプに対する様々な収集スクリプトで使用できる必要があります。しかし分析そのものは、問題タイプ毎に別々に設計されています。そもそも<infocollect>タスクに問題タイプを渡すのは、正にそのためです。これに対する解決策として、収集スクリプトに対する問題タイプをinfocollectProblemTypeというAntプロパティーに保存してから、このプロパティーの値を共有ターゲットの中の<infocollect>タスクに渡すようにします。共有ターゲットは様々なスクリプトによって呼び出されるため、<infocollect>タスクには様々な値が渡されます。しかし共有ターゲットの内容そのものは一定のままです。この方法は、同様な他の値（つまりスクリプト毎に異なる必要があり、複数のスクリプトで呼び出される共有ターゲットで使われる値）の場合も同じです。
WebSphere Portalの場合は、<wpsversiontask>というカスタムのAntタスクが、product.nameプロパティーとproduct.versionプロパティーへの値の割り当てを処理します。このタスクはWebSphere Portalのプロパティー・ファイルを検証し、そこで見つかる値をAntプロパティーに追加します。また、<wpsversiontask>が製品から動的に情報を取得できない場合には、こうしたプロパティーをAntスクリプトの中で直接設定することもできます。
新しいカスタム・タスク
AutoPDツールはAntスクリプトに基づいているため、必要な場合にはAntの標準機能をすべて利用することができます。こうした機能を利用すると、独自のカスタム・タスクを実装することができ、またそうしたタスクを、ツールに含まれているカスタム・タスクのリストに追加することができます。そのためには下記のようにします。
- 独自のカスタム・タスクをJavaコードで実装する。
- 独自に作ったJAR（Java Archive）ファイルをツールにリンクする。
- ツールのautopdtaskdef.propertiesファイルを編集し、独自のカスタム・タスクと、それらを実装するJavaクラスの間に関連付けを追加する。
- スクリプトの中で独自のカスタム・タスクを使う。
カスタム・タスクの実装の詳細については、Apache Antのマニュアルを参照してください（参考文献にリンクがあります）。
ツールがアップデートされても変更を保存する
新しいツールをインストールする場合には、それまでにツールの振る舞いに加えた変更を失わないように注意する必要があります。そのためには様々な方法がありますが、推奨される方法としては下記を挙げることができます。
まず、アップデートされたバージョンのツールをダウンロードする場合には、既存の /RasGUIディレクトリー・ツリーを完全に削除した後、ダウンロードしたRasGUI.zipファイルまたはRasGUI.tarファイルを解凍して新しいディレクトリー・ツリーを作成するようにします。もちろん、新しく取得したアーカイブを既存のRasGUIディレクトリーの上に解凍し、従って皆さんが行った変更の一部をそのまま保存することはできます。しかし、この方法は推奨できません。それまでにインストールされたバージョンの「残り」によって、新たにインストールされたバージョンが予期せぬ振る舞いをする可能性があるためです。
ツールの振る舞いを変更するための方法としては2つありますが、変更を保存するために必要なアクションはそれぞれ異なります。
- ツールと共に配布されるAntスクリプトやXML文書と共に、新しいAntスクリプトまたはXML文書を作成することによって実現する方法。（この場合には、新しく作られたRasGUIディレクトリー・ツリーにファイルをコピーする必要があります。）
- ツールの一部となっている既存のAntスクリプトや、他の既存のXML文書を編集することによって実現する方法。（この場合には、アップデートされたツールに付いてくる新しいバージョンのファイルの中に、皆さんが行った変更をマージさせる必要があります。）
できる限り、既存ファイルの中に変更内容をマージさせるよりも、新しいファイルを作成するという選択をすべきです。幸い、絶対にマージが必要な場合は、1つしかありません。ツールは最初に、自分のメイン・プロパティー・ファイルであるautopd.propertiesを、ツールが実行しているディレクトリー位置から見て固定した位置、properties/autopd.propertiesで見つけなければなりません。また、（そのスクリプトをツール自体に同梱されているものへの追加として位置付けるのか、あるいはツールのスクリプトに対する置き換えとして位置付けるのかによって）、新しい内容をツールのAutoPDMenu.xml文書の中にマージする必要があるかも知れません。最後に、独自のカスタム・タスクを書く場合には、そうしたタスクのエントリーを、ツールのautopdtaskdef.propertiesファイルの中にマージさせる必要があります。
アップデートされたツールのコピーをダウンロードする準備として、リスト15のようなディレクトリー構造を作ります。
リスト15. 独自のアップデートを保存するためのディレクトリー構造
MyRasGUI
mergeback
autoPDMenu.xml
autopd.properties
autopdtaskdef.properties
properties
my_pattern_template.xml
mylanguagebundle.properties
mylanguagebundle_en.properties
mylanguagebundle_de.properties
scripts
my_script_1.xml
my_script_2.xml
lib
myTasks.jar
|
こうしたファイルすべての現在のバージョンを、ツールのRasGUIディレクトリー・ツリーからMyRasGUIディレクトリー・ツリーにコピーし終わったら、既存のRasGUIツリーを削除し、アップデートされたツールを解凍して新しいツリーを作成します。
残った作業は、独自に行った変更をRasGUIディレクトリー・ツリーにコピーしてマージさせることだけです。コピー操作は容易に自動化することができます（ただし私達も実際にはまだ自動化したことはありません）。しかしマージ操作は、下記のように詳細が様々に異なるため、手動で行う必要があります。
- autopd.propertiesの場合、皆さんが望むファイルは恐らく、ツールの最新バージョンに含まれているもの全てを含み、かつ、それまでオーバーライドしたプロパティーは相変わらず皆さんが指定した値でオーバーライドされたままになっているものでしょう。
- autoPDMenu.xmlの場合は、GUIをどのように見せたいかに大きく依存します。例えば、ツールがサポートしている問題すべての他に、皆さんが指定する新しい問題もメインのProblem Typeツリーの中に含めたい場合には、autoPDMenuItem要素をツールのautoPDMenuItem要素とマージさせる必要があります。しかし、ツールがサポートする問題ではなく、皆さんが指定した新しい問題をメインのProblem Typeツリーに含めるようにしたい場合には、ツールのautoPDMenuItem要素を皆さん独自のものに置き換える必要があります。
まとめ
この記事では、AutoPDツールの拡張方法を、すべてとは言えないまでも数多く検証しました。このツールを最初にダウンロードした状態では特定な問題シナリオにしか対応できませんが、こうした拡張によって、様々なシナリオに対応できるようになります。ここでは主に2つの特定な領域、つまりツールのユーザー・インターフェースに新しい問題タイプを追加する方法と、ツールの機能を活用する新しいAntスクリプトを作成する方法という領域に絞って解説しましたが、ツールの主要機能の1つであるパターン・ベースのシンプトン分析と、その拡張やカスタム化については触れませんでした。これについては次回の記事で取り上げることにします。
参考文献
著者について  | 
| | 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です。
|
記事の評価
| 
