Cisco UCS Director Open Automation 開発者ガイド、リリース 5.0
モジュールの開発および展開
モジュールの開発および展開

モジュールの開発および展開

この章は、次の内容で構成されています。

モジュールの概要

モジュールは、Cisco UCS Director への最上位の論理エントリ ポイントです。 機能の追加や拡張を行うには、モジュールを開発して Cisco UCS Director にデプロイする必要があります。

モジュールを開発してデプロイするには、次の手順を実行します。

  • AbstractCloupiaModule クラスを拡張するクラスを実装してモジュールを作成します。

  • カスタム タスクおよびレポートを追加します。

    必要に応じて、必要なタスク インターフェイスを実装してタスクを作成します。

  • モジュールをパッケージ化します (推奨事項:Apache ANT™ または Apache Maven™ ビルド ツールを使用します)。

    (注)  


    このマニュアルの説明は、Eclipse に付属の ANT ビルド ツールを使用することを前提にしています。 代わりに Apache Maven ビルド ツールを使用することも、ご自身でビルドを作成することもできますが、ANT でビルドした場合と同じ特性のパッケージを提供する必要があります。


  • Cisco UCS Director にパッケージをデプロイします。

これらの手順は、個別のトピックで説明しています。


(注)  


このマニュアルでは新規モジュールのタスク コンポーネントに重点を置いて、新しいタスクを既存のタスク ライブラリに追加することでワークフローの機能を拡張する手順を説明します。

モジュールの作成

モジュール クラスは AbstractCloupiaModule クラスを拡張し、単一メソッド getTasks( ) の実装を提供します。

getTask( ) メソッドの次のコメントは、基本的な要件を説明しています。

/**
	 * External modules  extending this class shall provide implementation for this method.
	 * @return an array of tasks supported by this module
	 */

モジュールにタスクを追加することは重要な目的です。 モジュールにワークフロー タスクを追加する詳細な手順については、ワークフロー タスクの概要を参照してください。

モジュールの公開

モジュールをプラットフォーム ランタイムに公開するには、モジュールとともに module.properties というファイルを用意します。 このプロパティ ファイルは、モジュール自体の特定のプロパティを定義します。

サンプルの module.properties ファイルを次に示します。

moduleID=foo
version=1.0
ucsdVersion=5.1.0.0
category=/foo
format=1.0
name=Foo Module
description=UCSD Open Automation Sample Module
contact=support@cisco.
key=5591befd056dd39c8f5d578d39c24172

 

次の表で内容について説明します。

表 1 新しいモジュール プロパティ(module.properties)
名前 説明

moduleID

モジュールの一意の識別子。 必須。*

例:moduleID=foo

ヒント   

推奨されているベスト プラクティスは、この ID を 3 ~ 5 文字の小文字の ascii アルファベット文字列に限定することです。

version

モジュールの現在のバージョン。 必須。*

例:version=1.0

ucsdVersion

モジュールをサポートする(モジュールが最適に動作する)ように設計された Cisco UCS Director のバージョン。 必須。*

例:ucsdVersion=5.1.0.0

category

すべてのタスクが配置されるパス(/location)。 必須。*

例:category=/foo

(注)     

カテゴリは、タスクが配置される場所へのフル パスです。 タスク モジュールが検証されていない場合は、既定で、Open Automation Community Tasks/Experimental などの下に パスが作成されます。 一方、タスク モジュールが検証されている場合は、ルート相対で任意の場所に配置できます。 たとえば、/Physical Storage Tasks/foo を使用する場合は、このフォルダーの下に配置されます。または、/Open Automation Community Tasks/Validated/foo や /foo にも配置できます。 この最後のケースでは、理論上、foo という名前のフォルダーがルート レベルに存在することになります。 この変更により、開発者は Open Automation の下以外にあるカテゴリにタスクを配置することができます。

format

このモジュールの形式のバージョン。 「1.0」が本書執筆時点で唯一の許容値です。 必須。*

例:format=1.0

制約事項:

Cisco UCS Director リリース 5.0.0.0 現在、「1.0」が唯一の許容値です。

name

open automation レポート内のモジュールの識別に使用されるわかりやすい文字列。

例:name=Foo Module

description

モジュールの機能に関するわかりやすいテキスト。

例:description=UCSD Open Automation Sample Module

contact

モジュールのユーザがサポートを依頼するための電子メール アドレス。

例:contact= support@cisco.com

key

モジュールが検証済みであることを指定するために含めることが可能なシスコ発行キー。

例:key=5591befd056dd39c8f5d578d39c24172

(注)     

キーは、Cisco UCS Director Open Automation グループがモジュールを検証する目的で提供する暗号化キーです。


(注)  


上の表で必須として指定された要素に関して:これらのプロパティのいずれかを変更しようとすると、モジュールが無効になることに注意してください。 これらのプロパティのいずれかを変更した場合は、再度、検証を依頼する必要があります。 対照的に、必須ではない name、description、および contact の値は、再検証を依頼しなくても、変更または省略できます。


タスクの作成

タスクの作成は、モジュールを操作する際に実行できる重要な手順の 1 つですが、この手順に関わる詳細には踏み込んだ説明が必要になるため、もう少し先に進んで、モジュールとそのコンポーネントの概要で取り上げます。

モジュールのパッケージ化

モジュールには、必要なすべての依存 JAR ファイル、クラス、および module.properties ファイルが、.feature ファイルとともにパッケージ化されます。 .feature(発音は「ドット フィーチャー」)ファイルは、プロジェクトのルートと同じフォルダに配置されます。 このファイルには、このモジュールに関連付けられている JAR と、依存 JAR ファイルへのパスが示されます。

次の例は .feature ファイルを示しています。 ファイルの名前は、<moduleID>-module.feature になります。

{
      jars:  [ "features/feature-chargeback.jar", 
      "features/chargeback/activation-1.1.jar", 
      "features/chargeback/axis2-jaxbri-1.5.6.jar", 
      "features/chargeback/bcel-5.1.jar", 
      "features/chargeback/jalopy-1.5rc3.jar", 
      "features/chargeback/neethi-2.0.5.jar", 
      "features/chargeback/antlr-2.7.7.jar", 
      "features/chargeback/axis2-jaxws-1.5.6.jar",]
      features: [ "com.cloupia.feature.oabc.OABCModule" ]
}

build.xml から ANT ターゲットのビルドを実行します。 これにより、必要な Zip ファイルが生成され、プロジェクトのベース ディレクトリに保存されます (これは、サンプル プロジェクトをプロジェクトのベースとして使用していることを前提とします。 サンプル プロジェクトをこのように使用することは推奨されませんが、このデモでは基礎としています)。

モジュールが、サンプル ソース コードで提供されていない JAR に依存する場合、必ず build.xml に追加して、Zip ファイルに含まれるようにします。 次の例は、サードパーティの JAR を含むモジュール レイアウトを示しています。

feature-oabc
    feature oabc.jar
    oabc
      lib
        flex
          flex-messaging-common.jar
    oabc.feature

モジュール jar と .feature が zip ファイルのトップレベルに置かれています。 その後、サードパーティ jar を /moduleID/lib/ の下に配置します。 必須ではありませんが、ベスト プラクティスはサードパーティ jar を /moduleID/lib の下に置いてから、その他のサブ ディレクトリを必要に応じて追加することです。

{
      jars:  [ 'features/feature-oabc.jar", features/oabc/lib/flex-messaging-common.jar ],
      features: [ "com.cloupia.feature.oabc.OABC(Module" ]
}

jar ファイルへの参照は、必ず features/ で始めます。 これは必須です。 .feature ファイルに jar を列挙する際は、先頭に features/ を付けます。 これにより、目的の jar へのパスを含めることができます。 各 jar のパスは、zip ファイルで使用しているパスと同じパスにする必要があります。 ベスト プラクティスは、先頭にモジュール jar を置き、その後に依存性を追加して、モジュールが確実にロードされるようにすることです。

Cisco UCS Director へのモジュールのデプロイ

Cisco UCS Director ユーザ インターフェイスには [オープンオートメーション] コントロールが用意されており、これを使用してモジュールのアップロードや管理を行うことができます。 これらのコントロールを使用して、モジュールの Zip ファイルを Cisco UCS Director にアップロードします。


(注)  


アップロードでは、Zip ファイル形式のみがサポートされます。


はじめる前に

モジュールをデプロイまたは非アクティブ化するには Cisco UCS Director サービスを再起動する必要がありますが、そのためには shell admin アクセスが必要です。 このアクセスは、システム管理者の許可を受けて行います。 Cisco(CUIC)シェル メニューをシェル管理者として使用するには、ログイン shelladmin と管理者が支給するパスワードを使用して、SSH で Cisco UCS Director にアクセスする必要があります。 Windows システムでの SSH アクセスには PuTTY(http:/​/​www.putty.org/​ を参照)を使用し、Mac ではビルトインの SSH ユーティリティを使用します。

手順
    ステップ 1   Cisco UCS Director で、[管理] > [オープンオートメーション] を選択します。
    [モジュール] 表が開いて、次の列が表示されます。

    縦棒グラフ

    説明

    ID

    モジュールの ID。

    名前

    モジュールの名前。

    説明

    モジュールの説明。

    バージョン

    モジュールの現在のバージョン。 モジュール開発者は、モジュールのバージョンの管理方法を決定する必要があります。

    互換性あり

    このモジュールに最も適切な Cisco UCS Director のバージョンを表示します。

    連絡先

    モジュールのテクニカル サポート担当者の連絡先情報。

    アップロード時間

    モジュールがアップロードされる時間。

    ステータス

    モジュールのステータス。 ステータスには、有効、無効、アクティブ、および非アクティブが含まれます。

    ユーザは、モジュールを有効にするか、無効にするかを制御できます。 有効になっている場合は、Cisco UCS Director がモジュールの初期化を試みます。無効になっている場合は、Cisco UCS Director がモジュールを完全に無視します。 Cisco UCS Director がモジュールを例外なしで正常に初期化できる場合、そのモジュールはアクティブです。
    (注)     

    アクティブは、必ずしも、モジュール内のすべてが正しく機能していることを意味しているわけではなく、単に、モジュールが起動したことを示しているに過ぎません。 非アクティブは、Cisco UCS Director がモジュールの初期化を試みたときに、重大なエラーが発生して初期化ができなかったことを意味します。 非アクティブ フラグの一般的な原因:モジュールが誤ったバージョンの Java でコンパイルされたか、モジュールにクラスが含まれていなかった。

    検証済み

    モジュールが検証済みかどうかを示します。

    ステップ 2   [追加] を選択して新規モジュールを追加します。

    [モジュールの追加] ダイアログボックスが表示されます。ここでは、アップロードする Zip ファイルを指定することができます。

    ステップ 3   必要な情報を入力して、[送信] をクリックします。
    重要: 新しく追加されたモジュールをロードするには、最初に、そのモジュールを有効にしてから、Cisco UCS Director サービスを再起動します。 有効になっている場合は、Cisco UCS Director がモジュールの初期化を試みます。無効になっている場合は、モジュールが完全に無視されます。
    ステップ 4   [モジュール] 表でモジュールを選択してから、[有効] をクリックして、モジュールを有効にします。
    ステップ 5   [モジュール] テーブルでモジュールを選択してモジュールをアクティブ化し、続いて [追加] をクリックします。

    [モジュールのアクティブ化] ダイアログ ボックスが表示されます。

    ステップ 6   [送信] をクリックすると、モジュールがアクティブ化されます。 エラーが発生した場合は、モジュールが許容されなかった理由を明確に示すエラー メッセージが表示されます。 UCSD がモジュールを例外なしで正常に初期化できる場合、そのモジュールは「アクティブ」です。
    (注)     

    「アクティブ」は、必ずしも、モジュール内のすべてが正しく機能していることを意味しているわけではなく、単に、モジュールが起動したことを示しているに過ぎません。 非アクティブは、UCSD がモジュールの初期化を試みたときに、重大なエラーが発生して初期化ができなかったことを意味します。 非アクティブ フラグの一般的な原因:モジュールが誤ったバージョンの Java でコンパイルされたか、モジュールにクラスが含まれていなかった。

    ステップ 7   Cisco UCS Director サービスを停止して再起動します。
    1. shell admin アクセスでシェル メニューを開きます。 Cisco(CUIC)シェル メニューが開き、[Select a number from the menu below] というプロンプトが表示されます。
    2. SELECT プロンプトで、サービスを停止するための番号を入力します。 その後で、サービスを再開するための適切な番号を入力します。

    Cisco UCS Director の再起動には数分かかります。 システムの準備が整うと、モジュールがロードされ、タスクが Cisco UCS Director GUI に表示されます。


    モジュールの非アクティブ化

    モジュールをアクティブ化している場合などに、モジュールを非アクティブ化するには、変更が有効になるように Cisco UCS Director サービスを停止して再起動する必要があります。

    モジュールを非アクティブ化するには、次の手順を実行します。

    手順
      ステップ 1   非アクティブ化する必要のあるモジュールを [モジュール] テーブルで選択し、続いて [非アクティブ化] コントロールをクリックします。
      ステップ 2   Cisco UCS Director サービスを停止して再起動します。 モジュールのアクティブ化後と同じ手順に従います。