この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章は、次の項で構成されています。
ワークフロー タスクは、Cisco UCS Director が保持するタスク ライブラリへの提供に必要なアーティファクトを提供します。タスクは、ワークフロー定義で使用できます。
タスクには少なくとも次のクラスが必要です。
このインターフェイスを実装するクラスが、タスクの入力になります。つまり、タスクの実行のために入力を受け入れる必要のあるタスクは、TaskConfigIf を実装するクラスに依存することになります。このインターフェイスを実装するクラスには、ユーザにプロンプトを表示するための、適切に注釈を付けたすべての入力フィールド定義も含める必要があります。このクラスには、プラットフォーム ランタイムがデータベースでこのオブジェクトの持続性を維持できるようにする JDO 注釈も必要です。
サンプル コードに、サンプルの Config クラスを示しています。
タスクの実装は AbstractTask 抽象クラスを拡張し、すべての抽象メソッドに対する実装を提供する必要があります。これは、タスクに関連するすべてのビジネス ロジックを処理するメイン クラスです。ビジネス ロジックの実装が記述されるこのクラスで最も重要なメソッドは、executeCustomAction( ) です。その他のメソッドは、プラットフォーム ランタイムでタスクをオーケストレーション デザイナ ツリーに表示したり、ワークフロー内でタスクのドラッグ アンド ドロップを可能にしたりするための十分なコンテキストを提供します。
タスクを開発するには、最初に TaskConfigIf を実装する必要があります。タスク設定インターフェイスの設定プロセス中、タスクの実行に必要なデータを決定します。
次の例では、EnableSNMPConfig が TaskConfigIf の開発プロセスの詳細情報を公開しています。Enable SNMP タスクは、Cisco Nexus デバイスで SNMP を有効にするように設計されています。
処理を進めるには、Nexus デバイスの IP アドレス、ログイン、パスワードが必要です。
EnableSNMPConfig の先頭に注釈が付いています。
@PersistenceCapable(detachable= "true", table = "foo_enable_snmp_config") public class EnableSNMPConfig implements TaskConfigIf {
PersistenceCapable の注釈には、モジュール ID のプレフィックスが付いたテーブル名を指定する必要があります。モジュール ID のプレフィックスが付いていないテーブル名を使用しようとすると、Cisco UCS Director によってタスクの登録が妨げられるため、この規則には必ず従う必要があります。
public static finald String HANDLER_NAME = "Enable SNMP for Nexus"; //configEntryId and actionId are mandatory fields @Persistent private long configEntryId @Persistent private long actionId
handler name はタスクの名前です。この名前は必ず一意の文字列にします。複数のタスクで同じハンドラ名を使用すると、問題が生じることになります。
上の例に示しているとおり、各タスクには、configEntryId と actionId が必要です。これらの 2 つのフィールドに対応する getter と setter を定義する必要があります。これらの 2 つのフィールドは不可欠です。これらのフィールドは config オブジェクトに設定する必要があります。
次に、タスクを実行する上で実際に必要なデータを見ていきます。
//This is the ip address for the Nexus device on which you want to enable SNMP. @FormField(label = "Host IP Address", help = "Host AP Address", mandatory = true, type = FormFieldDefinition.FIELD_TYPE_EMBEDDED_LOV, lovProvider = ModuleConstants.NEXUS_DEVICES_LOV_PROVIDER) @USerInputField(type = ModuleConstants.NEXUS_DEVICE_LIST) @Peristent private String ipAddress = ""; @FormField(label = "Login", help = "Login", mandatory = true @Persistent private String login; @FormField(label = "Password", help = "Password", mandatory = true @Persistent private String password;
上のコード サンプルを確認して、開発者が次の項目を含める必要があることに注意します。
この例では LOV を使用して、この IP アドレスを取得しています。注釈および LOV の詳細については、注釈 を参照してください。
これらを取得するには、フォーム フィールドの注釈を使用して、ユーザが入力するデータとしてこれらのフィールドをマーキングします。
config オブジェクトの定義が終了したら、Java Data Object(JDO)の拡張としてマーキングします。
Cisco UCS Director Open Automation ソフトウェア開発キット(SDK)が必要になります。
ハンドラ オブジェクトは、カスタム コードを実際に実行する場所です。ハンドラ オブジェクトは AbstractTask を実装する必要があります。executeCustomAction メソッドを使用して、コードの実行のために以前に開発した、対応する config オブジェクトを取得できます。
config オブジェクトの準備ができたら、AbstractTask を拡張して、新しい config オブジェクトを実際に使用できるようにする必要があります。この例では、EnableSNMPTask を示しています。
ここで、次のメソッド executeCustomAction について見てみます。
public void executeCustomAction(CustomActionTriggerContext context, CustomActionLogger actionLogger) throws Exception { long configEntryId = context.getConfigEntry().getConfigEntryID(); //retrieving the corresponding config object for this handler EnableSNMPConfig config = (EnableSNMPConfig) context.loadConfigObject();
executeCustomAction は、カスタム ロジックが処理される場所です。context.loadConfigObject() をコールする際、以前に定義した config オブジェクトにキャストできます。この処理により、タスクの実行に必要なすべての詳細情報を取得するできるようになります。この例では、config オブジェクトを取得した後、SSH API を使用して、enable SNMP コマンドを実行しています。
ワークフローをロールバックする場合、行った変更を元に戻す方法をタスクが指定する必要があります。この例では、変更トラッカーを使用しています。
//If the user decides to roll back a workflow containing this task, //then using the change tracker, we can take care of rolling back this task (i.e., //disabling snmp) context.getChangeTracker().undoableResourceAdded("assetType", "idString", SNMP enabled", "SNMP enabled on " + config.getIpAddress(), new DisableSNMPNexusTask().getTaskName(), new DisableSNMPNexusConfig(config));
ロールバック コードはシステムに、Enable SNMP タスクの undo タスクが Disable SNMP タスクであることを伝えます。undo config オブジェクトとその名前を指定してください。その他の引数はデータのロギングを行いますが、指定してもしなくても構いません。
DisableConfig は、実際には EnableConfig 内で処理されます。 この場合、enable config にデバイスの詳細情報が含まれているため、Disable SNMP タスクが呼び出されたとき、どのデバイスで disable SNMP を実行するのかを正確に把握できます。
また、getTaskConfigImplementation も実装する必要があります。この例では、config オブジェクトのインスタンスを返す際にインスタンス化しています。
@Override public TaskConfigIf getTaskConfigImplementation() { return new EnbleSNMPConfig(); }
(注) | このタスクで使用する config オブジェクトを必ず指定してください。 |
次の作業:このタスクをモジュールに含めて、Cisco UCS Director で使用できるようにします。
消去タスクや集約タスク、あるいは繰り返し実行可能な何らかのタスクを開発する必要がある場合は、スケジュール タスク フレームワークを使用できます。これには、次のようなコンポーネントが含まれています。
タスク ロジックを、このクラスの execute() メソッドに含める必要があります。モジュール ID と、このタスクを説明する文字列を指定することから始めます。固有のモジュール ID を指定する必要があります。指定しないと、モジュールが正しく登録されません。
public DummyScheduleTask(){ super("foo"); }
addScheduleTask(new DummyScheduleTask());
詳細については、FooModule.java クラスを参照してください。
独自の入力タイプを Cisco UCS Director で開発できます。詳細については、『Cisco UCS Director Orchestration Guide, Release 4.1』を参照してください。ただし、これらの入力タイプには、モジュール ID のプレフィックスを付ける必要があります。TaskConfigIf の開発 を参照してください。ここでは、追加の注釈を使用してカスタム ワークフローの入力を指定しています。
public static final String NEXUS_DEVICE_LIST = "foo_nexus_device_list"; @UserInputField(type = ModuleConstants.NEXUS_DEVICE_LIST)
この例では、ModuleConstants.NEXUS_DEVICE_LIST が foo_nexus_device_list に解決されています。
カスタム ワークフローに必要な TaskConfigIf および AbstractTask コンポーネントを開発します。
カスタム ワークフローの出力を登録します。カスタム タスクの出力の登録を参照してください。
出力を追加するタスクを有効にできます。
カスタム タスクの出力を作成する方法の例については、EmailDatacentersTask を参照してください。
この項では、出力を別のタスクの入力として使用する方法について説明します。前の項で示した例の一部をここでも使用します。出力の定義は、次のように定義されます。
@Override public TaskOutputDefinition[] get TaskOutputDefinitions() { TaskOutputDefinition[] ops = new TaskOutputDefinitions[1}; //NOTE: If you want to use the output of this task as input to another task. Then the second argument //of the output definition MUST MATCH the type of UserInputField in the config of the task that will //be recieving this output. Take a look at the HelloWorldConfig as an example. ops[0] = new TaskOutputDefinition( FooConstants.EMAIL_TASK_OUTPUT_NAME, FooConstants.FOO_HELLO_WORLD_NAME, "EMAIL IDs"); return ops; } ,
この例では、FooConstants.EMAIL_TASK_OUTPUT_NAME という名前と、FooConstants.FOO_HELLO_WORLD_NAME という型を使用して、出力を定義しています。出力を入力として使用できる別のタスクを設定するには、型を一致させる必要があります。
このため、FooConstants.FOO_HELLO_WORLD_NAME を入力として使用する新規タスクで、設定オブジェクトに次の記述を含める必要があります。
//This field is supposed to consume output from the EmailDatacentersTask. //You'll see the type in user input field below matches the output type //in EmailDatacentersTasks's output definition. @FormField(label = "name", help = "Name passed in from a previous task", mandatory = true) @UserInputField(type = FooConstants.FOO_HELLO_WORLD_NAME) @Persistent private String login;
UserInputField 注釈内の型は、出力定義に登録されている型と一致しています。このように型が一致している場合に、ワークフローの開発中に Cisco UCS Director のワークフロー デザイナで新規タスクをドラッグ アンド ドロップすると、あるタスクの出力を別のタスクの入力としてマップできます。
この項では、組み込みワークフロー タスクの出力を、カスタム タスクの入力として使用する方法を示します。このプロセスは、1 つの重要な点で、カスタム出力を入力として使用できるように設定する場合と似ています。それは、タスクの設定オブジェクトに、出力と全く同じ型のフィールドが必要であるという点です。
モジュールが正常に動作している場合、Cisco UCS Director タスク ライブラリを開き、タスクが表示されていることを確認することで、カスタム タスクの存在を確認できます。
ステップ 1 | Cisco UCS Director で を選択し、続いて [ワークフロー(Workflows)] タブを選択します。
[ワークフロー(Workflows)] タブには、使用可能なすべてのワークフローを一覧したテーブルが表示されます。 |
ステップ 2 | [ワークフロー(Workflows)] ツリー ディレクトリで、タスクが表示されるワークフローに移動して、そのワークフローの行を選択します。
移動を容易にするために、テーブルの上部の右上隅にある [検索(Search)] オプションを使用して、ワークフローに移動します。 ワークフロー テーブルの上部に、ワークフローに関連するその他のコントロールが表示されます。 |
ステップ 3 | ワークフローを選択して、[ワークフローデザイナ(Workflow Designer)] をクリックします。
[ワークフローデザイナ(Workflow Designer)] 画面が開き、[使用可能なタスク(Available Tasks)] リストおよびワークフロー設計グラフィック ビューが表示されます。 |
ステップ 4 | 使用可能なタスクのリスト、およびワークフロー内のタスクのグラフィック表示に、目的のタスクが表示されていることを確認します。 |