以下、一実施形態を説明する。なお、以下に説明する実施形態は請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
また、以下の説明では、「kkkテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「kkkテーブル」のうちの少なくとも1つを「kkk情報」と呼ぶことができる。また、テーブルの構成は一例であり、2以上のテーブルが1つのテーブルにまとめられたり、1つのテーブルが複数のテーブルに分割されたりしてもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit)によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インターフェイスデバイス(例えば通信ポート)等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウエア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記憶メディアであってもよい。
また、以下の実施形態では、計算機システムを管理する第1の管理システム(以下、計算機管理システム)と、システム運用の自動化を支援する第2の管理システム(以下、運用自動化システム)とがある。しかし、計算機管理システムと運用自動化システムは1つの管理システムであってもよい。また、計算機管理システムは運用対象装置に含まれていてもよい。
また、以下の説明において、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合(具体的には、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合)、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機を含んでよい)が、管理システムである。本実施形態では、運用自動化システムの管理サーバが管理計算機であり、運用自動化システムの管理クライアントが表示用計算機である。
また、管理計算機は、表示システムを含むI/Oシステムに接続されたインターフェースデバイスと、情報を記憶する記憶資源(例えばメモリ)と、インターフェースデバイス及び記憶資源に接続されたプロセッサとを有する。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。I/Oシステムは、管理計算機が有するI/Oデバイス(例えばキーボード及びポインティングデバイス、タッチパネル)でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい(後者の場合は表示用計算機によって表示用情報が表示される)。また、管理計算機が情報を入出力するとは、管理計算機が有するI/Oデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機(例えば表示用計算機)との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。
また、以下の説明において、要素の識別情報として、「uk(ユニークキー)」、「キー名」という表現を用いるが、これらのうちの少なくとも1つに代えて又は加えて他種の識別情報(例えば番号)が使用されてもよい。
図1は、実施形態の第1の概要を示す。図2は、実施形態の第2の概要を示す。
運用自動化システムは、システム運用の多数のコンポーネントを管理する。ここで、「システム運用」とは、計算機システムの運用のことである。「コンポーネント」とは、システム運用の一部分であり、1つの独立した処理(業務)である。コンポーネントは、サービステンプレートに関連付けられる1つの単位(サービステンプレートに含まれる1つの単位)である。コンポーネントとしては、プラグインコンポーネントと、STコンポーネント(コンポーネントとして扱われるサービステンプレート)がある。詳細は後述する。
プラグインコンポーネントは、例えば、スクリプトを実行する処理モジュールであり、実行ファイルでよい。プラグインコンポーネントは、運用自動化システムに予め設けられるが、これに限らず、後から運用自動化システムに追加することもできる。プラグインコンポーネントは、例えば、ストレージ装置の構成変更(例えば論理ボリュームの作成)を実行させるコンポーネントでよいが、これに限らず、コンポーネント同士を組み合わせるために使用するコンポーネント、汎用的に使用可能なコンポーネントなどがあってもよい。例えば、プラグインコンポーネントとしては、繰り返し実行するためのソフトウェアコンポーネント、ファイル転送コンポーネント、ファイル実行コンポーネントなどがあってもよい。
なお、運用自動化システムの外部よりコンポーネント(パッケージ)がダウンロードされインポートされる場合、運用自動化システムのユーザがコンポーネントを作成又は改善する場合、又はサービステンプレートがコンポーネントとされる場合、といったことが考えられるが、これ以外で運用自動化システムにてコンポーネントがインポートされてもよい。ちなみにコンポーネントの改善例として、(1)コンポーネント内部の不具合の修正、(2)内部処理効率の改善、(3)コンポーネントが運用対象とする装置が変更された(例えば、ある装置の管理をするコマンドの仕様が変わったので、そのコマンドを実行するコンポーネントも変える必要が出た)、(4)コンポーネントが運用対象とする装置が増えた(例えば、第1のベンダーの装置に加えて新たに第2ベンダーの装置も運用できるようになった)、(5)コンポーネントの入出力プロパティ数が増減した、(6)コンポーネントの入出力プロパティに与える値のフォーマットが変更された、(7)コンポーネントに関連付けられているデフォルト値が変更又は追加された、(8)コンポーネントとして処理できることが増加又は処理効率の改善、のうちの少なくとも1つが考えられる。
運用自動化システムは、多数のコンポーネント(コンポーネント群)を管理する。本実施形態では、多数のコンポーネントのうちの2以上のコンポーネントを基にサービステンプレート(ST)が作成され、作成されたSTを基にサービスが作成され、作成されたサービスが実行される。以下、コンポーネント管理、ST作成、ST確定、サービス作成及びサービス実行の概要を説明する。
<コンポーネント管理>
運用自動化システムは、多数のコンポーネント(コンポーネント群)を管理する。コンポーネントは、コンポーネント提供ユーザにより追加又は編集されてよい。運用自動化システムは、コンポーネント毎に、コンポーネントに関連付けられる1以上のコンポーネントプロパティを管理する。また、運用自動化システムは、コンポーネント毎に、コンポーネントのバージョンを管理する。図1では、コンポーネントBBBを例に取って、コンポーネントプロパティ及びバージョンを示しているが、別のコンポーネントにも、その別のコンポーネントのコンポーネントプロパティ及びバージョンが関連付けられている。
「コンポーネントプロパティ」とは、コンポーネントのプロパティである。コンポーネントプロパティとして、コンポーネント入力プロパティとコンポーネント出力プロパティの2種類がある。コンポーネント入力プロパティは、定義された項目(表示名)についての値の入力に関するプロパティであり、コンポーネント出力プロパティは、定義された項目(表示名)についての値の出力に関するプロパティである。1つのコンポーネントに、1以上のコンポーネント入力プロパティと0以上のコンポーネント出力プロパティのうちの少なくとも1つが関連付けられる。すなわち、コンポーネントによっては、出力プロパティが0個の場合もあるが、入力プロパティは、各コンポーネントにつき1個以上関連付けられている。入力値は、例えば、過去に作成されたサービスのプロパティとして入力された値のコピーであってもよいし、実行済みの他のコンポーネントについて出力された値のコピーであってもよい。出力値は、コンポーネント実行後の構成情報等でよい。
バージョン001のコンポーネントBBBと、バージョン002のコンポーネントBBBがそれぞれ管理されている。すなわち、同一コンポーネントでも「バージョン」が異なれば、異なるコンポーネントのように扱われる。別の言い方をすれば、コンポーネントが更新(例えば改善)されても、更新後のコンポーネントが更新前のコンポーネントに上書きされることなく、更新前のコンポーネントとは別に更新後のコンポーネントが管理される。コンポーネントが更新された場合にいわゆるソフトウェアの更新のように更新前のコンポーネントが自動で更新後のコンポーネントに置き換わると、運用自動化においてトラブルの原因となり得る。特に、更新前のコンポーネントが既に作成されたサービスの要素の場合には、トラブルの原因となる可能性が高い。そこで、本実施形態では、運用自動化システムは、コンポーネントが更新された場合、更新後のコンポーネントの第1種の識別情報(例えばコンポーネント名)を更新前のコンポーネントの第1種の識別情報と同じとするが、更新後のコンポーネントのバージョン及び第2の識別情報(例えばコンポーネントuk(コンポーネントユニークキー))のうちの少なくとも1つを、更新前のコンポーネントのバージョン及び第2の識別情報と違う値とする。これにより、運用自動化システムは、更新後のコンポーネントを更新前のコンポーネントと別コンポーネントのように管理できる。
「コンポーネント提供ユーザ」とは、コンポーネントの追加又は更新等を行う、運用自動化システム301のユーザである。コンポーネント提供ユーザは、例えばGUI(Graphical User Interface)、CLI(Common Language Infrastructure)、API(Application Programming Interface)などを介して、コンポーネントを作成、追加、又は更新等行うことができる。コンポーネント提供ユーザにより追加又は更新されるコンポーネントは、典型的にはプラグインコンポーネントでよい。なお、プラグインコンポーネントは、例えば、管理プログラム431のベンダー、運用対象装置のベンダー等が作成する。サービステンプレートには、プラグインコンポーネント及びSTコンポーネントのいずれも関連付けることができる。プラグインコンポーネントは、最小単位でよく、STコンポーネントは、1以上のプラグインコンポーネントとそれらが関連付けられたサービステンプレートとのパッケージでよい。プラグインコンポーネントは、コンポーネント入力プロパティと、コンポーネント入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。STコンポーネントも、コンポーネント入力プロパティと、コンポーネント入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。STコンポーネントのコンポーネント入力プロパティは、後述するST入力プロパティでよい。
<ST作成>
運用自動化システムが、ST作成画面を表示する。ST作成画面に、情報の入力UIが表示される。ST作成ユーザが、ユーザ操作により、ST作成画面に情報を入力する。例えば、運用自動化システムは、ST作成画面を介して、多数のコンポーネントのうちの2以上のコンポーネントの選択と、2以上のコンポーネントの実行順序の指定とを受け付ける。運用自動化システムが、選択された2以上のコンポーネントと指定された実行順序とに基づきサービスフローのサービステンプレートを作成する。
「ST作成ユーザ」とは、サービステンプレートを作成する、運用自動化システム301のユーザである。ST作成ユーザは、上述のように、ST作成画面を用いてサービステンプレートを作成する。ST作成ユーザは、コンポーネント提供ユーザと同一であってもよいし異なっていてもよい。なお、前述のSTコンポーネントは、典型的には、ST作成ユーザにより作成され検証済みとなったサービステンプレートがコンポーネント化されたものでよい。しかし、STコンポーネントは他のベンダーやユーザが作成したものであってもよい。
「ユーザ操作」とは、画面に対してユーザが入力デバイスを使用して行う操作である。ユーザ操作に使用される入力デバイスは、一般に、ポインティングデバイス(例えばマウス)とキーボードの組合せ、又は、タッチスクリーンである。画面を介した入力は、ユーザ操作により行われる。
「サービステンプレート」とは、サービスのテンプレートである。本実施形態では、サービステンプレートが「ST」と略記されることもある。STは、インスタンス化されていない自動実行内容を指し示すオブジェクトという言い方をすることもできる。
「サービスフロー」とは、典型的には、選択された2以上のコンポーネントの並びである。コンポーネントの並びは、指定された実行順序に従う。選択されたコンポーネントの数が1つだけの場合、サービスフローを構成するコンポーネントの数も1つである。
上述のように、運用自動化システムは、ST作成画面を介して選択された2以上のコンポーネント及び指定された実行順序を基にサービステンプレートを作成する。具体的には、例えば、運用自動化システムは、選択された2以上のコンポーネントに関連付けられている複数のコンポーネントプロパティ(例えばコンポーネントプロパティ001及び002)にそれぞれ対応した複数のSTプロパティ(例えばSTプロパティ00A及び00B)を作成し、作成した複数のSTプロパティをサービステンプレート(例えばST001)に関連付ける。コンポーネントプロパティに対応したSTプロパティは、そのコンポーネントプロパティを基に運用自動化システムにより自動作成される。STプロパティの作成中又は作成後にユーザ操作により入力された値がSTプロパティに含まれてもよいが、ユーザ操作による入力(つまり手動入力)無しにSTプロパティが作成されてよい。「STプロパティ」とは、STのプロパティである。STプロパティとして、ST入力プロパティとST出力プロパティの2種類がある。ST入力プロパティは、定義された項目(表示名)についての値の入力に関するプロパティであり、ST出力プロパティは、定義された項目(表示名)についての値の出力に関するプロパティである。1つのサービステンプレートに、1以上のST入力プロパティと0以上のST出力プロパティのうちの少なくとも1つが関連付けられる。すなわち、ST出力プロパティが必ず1個あるとは限らない。
図1の例では、サービスフローは、コンポーネントBBB「Provisioning volume」(ストレージ装置に論理ボリュームを作成する)と、コンポーネントDDD「Create pair volume」(論理ボリューム(プライマリボリューム)とペアになる論理ボリューム(セカンダリボリューム)を作成する)の組合せであり、そのサービスフローのサービステンプレート(ST001)が作成されたとする。
<ST確定>
運用自動化システムは、作成されたサービステンプレートについて、ユーザ操作により確定を受けた場合、その作成されたサービステンプレートのST種別を「Release」として管理する(図2参照)。ST種別「Release」は、サービステンプレートが確定しており、そのサービステンプレートを基にサービスを作成することが可能であることを意味する。一方、確定していないサービステンプレートは、ST種別「Debug」である。ST種別「Debug」は、サービステンプレートが編集中であることを意味する。なお、運用自動化システムは、サービス実行において、ST種別「Debug」のサービステンプレートの選択を受け付けないようにしてもよい(例えば、ST種別「Debug」のサービステンプレートを、選択可能に表示しない(ディスエーブル))。その一例としては、後述するサービス作成ユーザは、ST種別が「Release」であるサービステンプレートだけサービスの作成を可能とし、サービステンプレート作成ユーザは、テスト目的もあるため、ST種別が「Release」と「Debug」両方でサービス作成を可能としてもよい。なお、こうした処理を実現するため、運用自動化システムはユーザ認識を行っていることは言うまでも無い。
<サービス作成>
運用自動化システムは、作成済のサービステンプレートを管理する。運用自動化システムは、ST種別「Release」のサービステンプレートのうちのいずれかのサービステンプレートの選択をサービス作成ユーザから受け、選択されたサービステンプレートを基にサービス作成画面を表示する。サービス作成ユーザが、ユーザ操作により、サービス作成画面に情報を入力する。運用自動化システムは、サービス作成画面を介して入力された情報を基にサービスを作成する。
「サービス作成ユーザ」とは、サービスを作成(実行)するユーザである。サービス作成ユーザとST作成ユーザは異なるユーザであってもよいし同一ユーザであってもよい。
「サービス」とは、インスタンス化されたサービステンプレートである。具体的には、サービステンプレートは、サービスの実行に必要な値がブランクとなっており、その必要な値がサービステンプレートに入力されたものが、サービスである。なお、前述のサービスの実行に必要な値については、デフォルト値がSTのプロパティの情報として設定できる場合もある。
なお、サービスは運用に関係するものであることを表すために「運用サービス」と記載する場合がある。なお、特定の状況に於いては「サービス」は、ユーザが指定した運用対象装置に対して行うべき運用処理を示しているとも言える。例えば、図13の例でST入力プロパティ1304Cを指定した場合はこの表現に該当する。また、コンポーネント自体に指定する運用対象装置を埋め込んだり、コンポーネントの入力プロパティのデフォルト値として与えたりしない場合は、「サービス」と「サービステンプレート」間の別な見方として、「サービス」が示す処理内容では入力値の定めにより構成変更や情報取得先として指定する運用対象装置が明確になっている一方で、「サービステンプレート」では指定する運用対象装置が不明であるとも言える。
なお、運用自動化システムは、作成されたサービスに、サービスプロパティを関連付けらよい。「サービスプロパティ」とは、サービスの入力・出力プロパティ(入力及び出力のうちの少なくとも一方のプロパティ)である。サービスの入力・出力プロパティには、サービス作成においてサービステンプレートに入力された値と、サービス実行においてコンポーネントから出力された値とのうちの少なくとも1つが設定される。具体的には、例えば、サービスの実行では、サービス作成において入力プロパティに入力された値が、そのサービスのサービステンプレートに関連付けられているコンポーネントに入力されて、処理が実行されてよい。また、コンポーネントから出力された値が、サービスの出力プロパティに設定されることで、サービスの実行結果画面において、その設定された値(例えば、コンポーネントが実行された後の構成情報等)が表示されてよい。
<サービス実行>
運用自動化システムが、作成したサービスの実行の命令を、計算機管理システムに送信する。計算機管理システムが、その命令に従い、サービスを実行する。
以上が、コンポーネント管理、ST作成、サービス作成及びサービス実行の各々の概要である。
複数のSTプロパティのうちの少なくとも1つのST入力プロパティの各々に、カスタムUIを定義した情報であるカスタムUI生成情報が関連付けられている。但し、デフォルトUIに関しては、カスタムUI生成情報は「Null」(デフォルトUI用の情報)である。カスタムUI及びデフォルトUIについては後述する。また、図面では、「カスタムUI生成情報」を、「カスタムInfo.」のように略記することもある。STプロパティのカスタムUI生成情報は、そのSTプロパティに対応したコンポーネントプロパティに関連付けられているUI生成情報(例えば、UIの生成に必要な情報を含んだ情報)である。複数のコンポーネントプロパティのうちの少なくとも1つのコンポーネント入力プロパティの各々に、カスタムUI生成情報が関連付けられている場合がある。
運用自動化システムは、ST作成画面及びサービス作成画面等の画面を、一連の流れにおいて表示することができる。少なくとも1つの画面には、UIが表示される。本実施形態において、UIは、画面に表示される1つの要素である。1以上のUIを含んだ画面をGUIと呼ぶこともできる。なお、以後の説明ではUIを「UI要素」と呼ぶことがある。
<UIの生成及び表示>
本実施形態では、運用自動化システムは、少なくともサービス作成画面に表示されるUIを、例えば次のように生成する。
すなわち、運用自動化システムは、選択されたサービステンプレートの複数のSTプロパティにそれぞれ対応した複数のカスタムUI生成情報を基に、複数のUIをそれぞれ生成する。運用自動化システムは、生成した複数のUIを1つのサービス作成画面に表示する。本実施形態では、1つのカスタムUI生成情報を基に1つのUIが生成される。つまり、カスタムUI生成情報とUIの関係は、1:1である。しかし、カスタムUI生成情報とUIの関係は、n:1でもよいし、1:nでもよいし、m:nでもよい(mとnは2以上の整数)。
このようなUI生成によれば、例えば、コンポーネントBBBとコンポーネントDDDで構成されたサービスフローのうちコンポーネントDDDがコンポーネントEEEと入れ替えられても、コンポーネント入れ替え後のサービス作成画面に表示されるUIとして、コンポーネントDDDに代えてコンポーネントEEEのUIが生成され表示される。このように、UIの生成が効率的である。
<カスタムUI>
また、本実施形態では、UIとして、デフォルトUIに代えて又は加えて、カスタムUIが用意されている。
「デフォルトUI」は、テキストフィールドのkey-value形式でのUIであり、具体的には、STプロパティ(コンポーネントプロパティ)の表示名と、テキストフィールドとの組である。なお、デフォルトUIにてテキストフィールドが採用される理由は、幅広い入力形式に対応できることが理由である。STプロパティ(コンポーネントプロパティ)の表示名(入力項目)に関わらず、テキストフィールドが表示される。従って、ユーザは、表示名を見て、入力する値又は名称等の情報を考えなければならず、そして、その情報をキータイプによりテキストフィールドに入力する必要がある。このため、タイプミス等の誤入力が生じ得る。また、STプロパティ(コンポーネントプロパティ)に無効な値や名称等があってもそのような無効な値や名称等が入力されるおそれもある。また、ユーザに高い知識が必要とされ得る。
それに対し、「カスタムUI」は、テキストフィールドのkey-value形式でのUIではなく、ユーザビリティが考慮されたUIである。例えば、カスタムUIは、STプロパティ(コンポーネントプロパティ)の表示名と、プルダウンメニュー、チェックボックス及びラジオボタン等のうちの少なくとも1つのような、1以上のGUI要素(ウィジェット)とを含んだUIである。このため、デフォルトUIに比べて、誤入力は生じないし、ユーザに高い知識が必要とされない。なお、カスタムUIも、テキストフィールドを含んでよいが、デフォルトUIのようなUI(テキストフィールドのkey-value形式でのUI)よりもユーザビリティの高いUI(例えば、テキストフィールドの近傍に表示される無効な値や名称等のリストを含んだUI)である。
図1の例によれば、1つのサービス作成画面において、デフォルトUI(表示名:LUNと、テキストフィールドとの組)と、カスタムUI(表示名:Volume Capacityと、ボリューム容量のプルダウンメニューと、ボリューム容量の単位(例えばMB(メガバイト))のプルダウンメニューとの組)が混在している。
このように、本実施形態では、全てのUIが、カスタムUIである必要は無い。カスタムUIが関連付いていないコンポーネントとカスタムUIが関連付いたコンポーネントとが1つのサービスフローに混在しても、サービス作成画面では、デフォルトUIの他にカスタムUIも定義通り表示される。システム運用のコンポーネントは多数存在するので、全てのUIをカスタムUIにしてからコンポーネント提供するとなると、運用自動化システムのベンダーが自社製品を提供するまでに時間がかかる。本実施形態によれば、カスタムUIのカスタムUI生成情報が関連付いていないコンポーネントが早期に提供されたり、ST作成ユーザがコンポーネントを独自に作成してサービステンプレートに組み込んだりしても、サービス作成ユーザが、サービス作成においてカスタムUIの恩恵を受けることができる。
なお、コンポーネントプロパティ(STプロパティ)にカスタムUIが追加された場合、及び、古いカスタムUIから新しいカスタムUIに変わった場合でも、画面に表示されるUIは、変更前のUI(すなわち、デフォルトUI又は古いカスタムUI)とされる。具体的には、例えば、運用自動化システムは、既存のSTに関連付いているコンポーネントのUIの変更要求を受け付けた場合、UIの変更要求を受けたコンポーネントのコピーを作成(既存のコンポーネントを基にバージョンの異なる新たなコンポーネントを作成)し、UIを変更したコンポーネントを作成する。次に、既存のSTのコピーを作成し(既存のSTを基にバージョンの異なる新たなSTを作成)、その作成した新しいSTに、既存のコンポーネントとバージョンが異なる新しいコンポーネントを入れ替える。既存のSTで使用されているコンポーネントに関連付いているUIを自動的に変更してしまうと、元々はうまく使えていたSTが使えなくなる可能性がある(例えば、元々は入力できていた値が入力できなくなった等)。本実施形態によれば、使用可能なSTに悪影響を及ぼさずにコンポーネントのUIの入れ替えが可能となる。
また、作成済のサービステンプレートに関連付いているコンポーネントのコンポーネントプロパティに関連付いたUIが変更されて新規コンポーネントが追加されても、運用自動化システムは、そのサービステンプレートに基づくサービス作成画面において、既存のコンポーネントを使用して変更前のUIを表示する。これにより、サービステンプレートの作成後に関連するUIが変更されることで元々入力可能だった値の入力が不可能になるといったおそれを回避できる。変更前のUIの生成及び表示を維持する具体例は、図26を参照して説明する。
<コンポーネントバージョンと関連STの表示>
運用自動化システムは、図1を参照して説明したように、コンポーネントのバージョンと、そのバージョンのコンポーネントが関連付いたサービステンプレート(関連ST)との関係を管理する。サービス作成又はサービス作成開始前等において、運用自動化システムは、図2に示すように、コンポーネント(例えばコンポーネントBBB)の選択をユーザから受けた場合に、選択されたコンポーネントのバージョン毎に、関連STリストを表示する。関連STリストは、関連ST毎に、関連STの情報(例えば、ST名、STバージョン及びST種別)を有する。これにより、下記の(A)乃至(B)のうちの少なくとも1つを実現し得る。
(A)更新後のコンポーネントがインポートされた場合、更新前のコンポーネントを選択することで、ユーザは、更新前のコンポーネントについてのバージョン毎の関連STリストから、更新前のコンポーネントについて関連STの有無がわかる。また、更新前のコンポーネントに関連STがあれば、その関連STのST種別もわかる。ユーザは、関連STの有無及びST種別を基に、既存のサービステンプレートに関連付いているコンポーネントを、更新後のコンポーネントに入れ替えるか否かを判断できる。例えば、更新前のコンポーネントについて関連STが存在しなければ、ユーザは、STに関連付いているコンポーネントを更新後のコンポーネントに置換することは不要であると判断できる。また、例えば、更新前のコンポーネント(例えばバージョン001のコンポーネントBBB)についてST種別「Release」の関連STが存在していれば、ユーザは、その関連STに関連付いている更新前のコンポーネントを更新後のコンポーネントに入れ替えると不具合が生じ得ること、及び、それ故に更新前のコンポーネントを更新後のコンポーネントに入れ替えた新たなSTを作成することとを、判断できる。また、例えば、更新前のコンポーネントについて関連STが存在するもののST種別「Release」の関連STが存在していなければ(例えばバージョン002のコンポーネントBBB)、ユーザは、関連STに関連付いている更新前のコンポーネントを更新後のコンポーネントに入れ替えても良いことを判断できる。
(B)ユーザは、選択したコンポーネント(例えばコンポーネントBBB)についてのバージョン毎の関連STリストから、選択したコンポーネントについて関連STの有無と、関連STのST種別がわかる。ユーザは、関連STの有無及びST種別を基に、選択したコンポーネントを更新することによる影響(例えば、新たなバージョンのコンポーネントとすることの必要性、関連STに関連付いているコンポーネントの交換の必要性、新たにSTを作成することの必要性等)を判断できる。例えば、選択したコンポーネントについてST種別「Release」の関連STが存在していなければ、ユーザは、選択したコンポーネントのバージョンを変更すること無しにコンポーネントを更新して良い(つまりバージョンの異なるコンポーネントを追加するのではなくコンポーネントそれ自体を入れ替えてよい)と判断できる。また、例えば、選択したコンポーネントについてST種別「Release」の関連STが存在していれば、ユーザは、選択したコンポーネントについて新たなバージョンのコンポーネントを更新後のコンポーネントとする必要があると判断できる。
通常、コンポーネントが更新されても(バージョンアップされても)、確定したサービステンプレートに関連付いているコンポーネントを更新後のコンポーネントに入れ替えることは避けることが望ましい。本実施形態によれば、上述の通り、各バージョンのコンポーネントがどのサービステンプレートに関連づいているのかのリストが表示される。このため、更新後のコンポーネントに入れ替えられるべき又は入れ替えられてはならないコンポーネントが関連付いているサービステンプレートがどれであるかの判断が容易である。
<STのバージョンアップ>
本実施形態では、サービステンプレート(ST)に関連付いているいずれかのコンポーネントについて新たなバージョンのコンポーネントがコンポーネント群に追加されても、そのSTは自動でバージョンアップされない。具体的には、そのSTに関連付いているコンポーネントが、追加された新たなコンポーネントに自動で差し替えられることは無い。STのバージョンアップは、ユーザからの明示的な要求に応答して行われる。STが自動バックアップされることは無いので、そのSTを用いて作成されたサービスの動作の保障することが可能である。
ユーザ(例えばST作成ユーザ)からの明示的なバックアップ要求に応答して、その要求において指定されているST(以下、指定ST)のバージョンアップが可能である。「指定STのバージョンアップ」とは、指定ST又はその複製に関連付けられる対象コンポーネントのバージョンを、指定STに既に関連付けられている対象コンポーネントのバージョンと違えることである。「対象コンポーネント」とは、バージョン変更対象のコンポーネントである。対象コンポーネントは、ユーザ(例えばST作成ユーザ)から選択されたコンポーネントでもよいし、運用自動化システムにより自動で選択されたコンポーネントでもよい。バージョン変更前の対象コンポーネントと、バージョン変更後の対象コンポーネントは、バージョン等の所定属性(例えばバージョン及びuk)の違いを除いて同じコンポーネント(例えば、名称が同じコンポーネント)である。
指定STのバージョンアップは、例えば、(a)指定STそれ自体の対象コンポーネントを、異なるバージョンの対象コンポーネントに差し替えること、(b)指定STの対象コンポーネント以外のコンポーネントを、指定STの複製に関連付け、指定STの対象コンポーネントとバージョンの違う対象コンポーネントを、指定STの複製に関連付け、結果として、指定STの複製であるが対象コンポーネントのバージョンが異なる新たなSTを生成すること、のいずれも該当してよい。
また、例えば次のようなケースも考えられる。すなわち、新たにコンポーネントが追加されたが、そのコンポーネントはいずれのSTに関連付けられることも無く、そのコンポーネントの新たなバージョンのコンポーネントが追加される。その新たなバージョンのコンポーネントがいずれかのSTに関連付けられる。しかし、そのSTを用いたサービスの実行(例えばテスト)において不具合が発見され、故に、そのST(又はそのSTの複製)に、いずれのSTに関連付けられたことが無い旧バージョンのコンポーネントが関連付けられる。このようなケースも、「指定STのバージョンアップ」に該当してよい。
従って、指定STのバージョンアップは、典型的には、指定STに関連付けられている対象コンポーネントのバージョンをアップすること(例えば最新バージョンにすること)であるが、指定STに関連付けられている対象コンポーネントのバージョンをダウンすることであっても、指定STのバージョンアップに該当し得る(例えば、バージョンダウンされた対象コンポーネントがいずれのSTにも関連付けられたことが無い場合、又は、対象コンポーネントのバージョンダウン後のST(又はST複製)が、いずれの作成済のSTとも異なるSTである場合)。
運用自動化システムは、STが指定されたバージョンアップ要求(例えば指定STのukが関連付けられた要求)を受信し、そのバージョンアップ要求に応答して、指定ST又はその複製に関連付けられる対象コンポーネントのバージョンを、指定STに既に関連付けられている対象コンポーネントのバージョンと違える。
複数のSTで用いられるコンポーネントであっても、サービステンプレート毎にそのコンポーネントのバージョン変更(例えばバージョンアップ)の可否を変更したい場合がある。例えば、コンポーネントのバージョンアップによってSTの動作不安定化につながる可能性があり、できるだけ不要なバージョンアップは避けたいSTが存在する一方で、一部のSTについては最新機能を持つコンポーネントを使用したい場合がある。これらのうちのいずれのケースにも対応可能である。なお、バージョン変更したコンポーネントを用いてSTを新たに作成することも考えられるが、この場合は、ST作成ユーザに最初からプロパティの設定等のST作成操作をやり直してもらう必要があるため、作成者にとって利便性が悪い。
指定STのバージョンアップは、指定STを作成したST作成ユーザからインターフェースを通じて運用自動化システムが受信したバージョンアップ要求に応答して行われてよい。具体的には、例えば、運用自動化システムに、複数のST作成ユーザが登録されており、運用自動化システムは、指定STのバージョンアップ要求を、指定STのST作成ユーザ以外のユーザから受けた場合、そのユーザの属性に関わらず指定STのバージョンアップを行ってもよいし、そのユーザの属性が所定の条件に適合していれば指定STのバージョンアップを行ってもよいし、バージョンアップ不可をそのユーザに返してもよい。
図18は、実施形態の第3の概要を示す。
「指定STのバージョンアップ」は、指定STそれ自体の対象コンポーネントを別のバージョンの対象コンポーネントに差し替えることを含んでもよいが、本実施形態では、運用自動化システムは、指定STそれ自体を維持し、指定STの新たなバージョンとして指定STの複製(但し、対象コンポーネントについては指定STに関連付いている対象コンポーネントとバージョンが異なる)を作成する。すなわち、指定STのバージョンアップでは、異なるバージョンの対象コンポーネントが、指定STの複製に、バージョン変更前の対象コンポーネントに代えて関連付けられる。
既に安定してバージョンアップ前のSTを使えているのであれば、そのSTは維持される(そのSTそれ自体が更新されることは無い)ので、STのバージョンアップに伴う不具合発生を回避できる。また、そのSTを別なSTのコンポーネントとして使用するためのバージョンを管理し易い。
また、STのバージョンアップのモードとして、「All apply」モードと「Individual apply」モードの2つのモードがある。「All apply」モードは、指定STの複製(バージョン違いの指定ST)に関連付けられている全ての旧バージョンのコンポーネントを全て最新バージョンのコンポーネントに差し替えるモードである。「Individual apply」モードは、指定STの複製に関連付けられるコンポーネントのうちST作成ユーザから選択されたコンポーネントについてバージョン変更を行うモードである。
例えば、図18に示すように、指定ST001(バージョン001)に、コンポーネントBBB(旧バージョン001)とコンポーネントDDD(旧バージョン001)とが関連付いている(含まれている)とする。また、コンポーネントBBBについては、最新バージョン002のコンポーネントBBBが存在し、コンポーネントDDDについても、最新バージョン002のコンポーネントDDDが存在するとする。運用自動化システムは、指定ST001(バージョン001)について、「All apply」モードと「Individual apply」モードのいずれかのモードの選択を、ユーザインターフェース(例えばGUI)経由で受け付ける。
「All apply」モードが選択された場合、運用自動化システムは、指定ST001の複製(バージョン002のST001)に関連付けられる全ての旧バージョンのコンポーネント(コンポーネントBBB(旧バージョン001)及びコンポーネントDDD(旧バージョン001))を全て最新バージョンのコンポーネント(コンポーネントBBB(最新バージョン002)及びコンポーネントDDD(最新バージョン002))に差し替える。
「Individual apply」モードが選択された場合、運用自動化システムは、コンポーネントBBB(旧バージョン001)の選択と、変更後のバージョン002とを、ST作成ユーザからユーザインターフェース経由で受け付けたとする。運用自動化システムは、指定STの複製に関連付けられるコンポーネントのうち選択されたコンポーネントBBB(旧バージョン001)をコンポーネントBBB(変更後バージョン002)に差し替える。
このように、個別にコンポーネントを選択すること無しに簡易にSTをバージョンアップするか、或いは、個別にコンポーネントを選択することでよりユーザのニーズに沿ったSTにバージョンアップするかをユーザが選択することができる。
以上が、実施形態の概要である。以下、実施形態を詳細に説明する。
図3は、実施形態に係るシステム全体の構成を示す。
計算機システム310に、計算機管理システム302が接続されており、計算機管理システム302に運用自動化システム301が接続されている。運用自動化システム301は計算機管理システム302と一体でもよい。
計算機システム310は、1以上のホスト計算機(以下、ホスト)303と、1以上のストレージ装置304とを含む。ホスト303とストレージ装置304は通信ネットワーク306を介して接続されている。ホスト303は、ストレージ装置304に接続されたI/F(通信インターフェースデバイス)と、メモリのような記憶資源と、それらに接続されたプロセッサとを有する。ストレージ装置304は、1以上のPDEV(物理記憶デバイス)と、1以上のPDEVに接続されたコントローラとを有する。コントローラは、ホスト303に論理ボリュームを提供する。ホスト303は、提供された論理ボリュームを指定したI/O(Input/Output)要求をストレージ装置304に送信する。ストレージ装置304のコントローラが、そのI/O要求に従い、論理ボリュームに対するデータI/Oを行う。I/O対象のデータが、論理ボリュームのI/O先領域に基になっている1以上のPDEVに対して入出力される。なお、ホスト303とストレージ装置304とは運用対象装置の一例である。
計算機管理システム302は、計算機システム310を管理する管理システムである。計算機管理システム302は、運用自動化システム301からの命令に従いサービスを実行する。サービス実行では、例えば、ストレージ装置304に論理ボリュームを作成すること、及び、ストレージ装置304にセカンダリボリュームを作成することが行われる。
運用自動化システム301は、システム運用の自動化を支援する管理システムである。運用自動化システム301は、管理サーバ311と、管理サーバ311に接続された管理クライアントとを有する。管理サーバ311が管理クライアント312に送信した表示用情報を基に、管理クライアント312により情報が表示される。つまり、管理サーバ311が管理クライアント312を介して情報を表示する。
具体的には、例えば、管理サーバ311は、コンポーネントと関連STとの関係を特定し(P11)、コンポーネントのバージョン毎の関連STリストを表示する(P12)。
また、例えば、管理サーバ311は、ST作成画面を表示し(P21)、ST作成ユーザからST作成画面を介してSTの作成(編集を含む)を受け付ける(P22)。管理サーバ311は、確定したSTに基づきサービス作成画面を表示する(P23)。管理サーバ311は、サービス作成ユーザからサービス作成画面を介して情報を受け、入力された情報を基にサービスを作成し保持する(P24)。管理サーバ311は、サービスの編集のための画面を表示し(P25)、サービスの編集を受け付けることもできる。管理サーバ311は、作成(編集を含む)されたサービスの実行画面を表示する(P26)。管理サーバ311は、サービス実行画面を介してサービスの実行をサービス作成ユーザから受け付け、受け付けたサービスの実行の命令を、計算機管理システム302に送信する(P27)。
図3に示した処理P11、P12及びP21〜P27の各処理群(1以上の処理)が、プログラム群(1以上のコンピュータプログラム)がプロセッサにより実行されることにより行われる。
図4は、管理サーバ311の構成を示す。
管理サーバ311は、通信ポート414(I/Fの一例)、メモリ412(記憶資源の一例)、及び、それらに接続されたプロセッサ(典型的にはCPUのようなマイクロプロセッサ)411を有する。管理サーバ311は、通信ポート414を介して、少なくとも計算機管理システム302及び管理クライアント312と通信する。
メモリ412は、半導体メモリに限らずハードディスクドライブでもよい。メモリ412は、コンピュータプログラムと管理テーブルを記憶する。具体的には、例えば、メモリ412は、コンポーネント管理テーブル421、コンポーネントプロパティ管理テーブル422、ST管理テーブル423、フロー管理テーブル424、STプロパティ管理テーブル425、サービス管理テーブル426、サービスプロパティ設定テーブル427、ステップ管理テーブル428、及び、管理プログラム431を記憶する。管理プログラム431が、プロセッサ411により実行され、それにより、例えば図3に示した処理P11、P12、P24及びP27を行う。
図5は、管理クライアント312の構成を示す。
管理クライアント312は、通信ポート514(I/Fの一例)、入出力デバイス513、メモリ512(記憶資源の一例)、及び、それらに接続されたプロセッサ(典型的にはCPUのようなマイクロプロセッサ)511を有する。
メモリ512は、半導体メモリに限らずハードディスクドライブでもよい。メモリ512は、表示プログラム531を記憶する。表示プログラム531が、プロセッサ511により実行され、それにより、例えば図3に示した処理P12、P21、P23、P25及びP26を行う。
以下、管理サーバ311が有する管理情報(テーブル421〜428)の構成を説明する。
図6は、コンポーネント管理テーブル421の構成を示す。
コンポーネント管理テーブル421は、コンポーネントに関する情報を有する。コンポーネント管理テーブル421は、コンポーネント毎にレコードを有し、各レコードに、管理番号601、コンポーネント名602、バージョン603、実行ファイルパス604、及びコンポーネントuk605が格納される。管理番号601は、レコードの通し番号である。コンポーネント名602は、コンポーネントの名称である。バージョン603は、コンポーネントのバージョンを表す。実行ファイルパス604は、コンポーネントの実行ファイルへのパス(パス名)を表す。コンポーネントuk605は、コンポーネントのユニークキー(番号)である。ukは、識別情報の一例である。
図6から分かるように、バージョンが異なる同一コンポーネントは、コンポーネント名602が同じであり(例えば、「Provisioning Volume」)、バージョン603が異なる(例えば「01.00.00」、「01.10.00」)。つまり、バージョンが異なる同一コンポーネントは、別々のコンポーネントとして管理される。しかし、複数のコンポーネントのコンポーネント名602が同一であれば、それら複数のコンポーネントのオリジナルは同一であることがわかる。
図7は、コンポーネントプロパティ管理テーブル422の構成を示す。
コンポーネントプロパティ管理テーブル422は、コンポーネントプロパティに関する情報を有する。コンポーネントプロパティ管理テーブル422は、コンポーネントプロパティ毎にレコードを有し、各レコードに、管理番号701、コンポーネントuk702、表示名703、キー名704、初期値705、入出力タイプ706、プロパティグループ707及びカスタムUI生成情報708が格納される。
管理番号701は、レコードの通し番号である。コンポーネントuk702は、コンポーネントのユニークキーである。表示名703は、画面に表示されるコンポーネントプロパティ名であり、例えば入力項目又は出力項目に相当する。
キー名704は、コンポーネントプロパティを一意に特定するための名称であり、コンポーネントプロパティの識別情報の一例である。初期値705は、生成されたUIに予め設定される値である。初期値705「Null」は、初期値が存在しないことを意味する。つまり、UIが表示されたとき、入力欄又は出力欄がブランクである。
入出力タイプ706は、コンポーネントプロパティがコンポーネント入力プロパティであるかコンポーネント出力プロパティであるか(言い換えれば、UI上の値が入力値であるか出力値であるか)区別するための情報である。入出力タイプ706の値は、対応するコンポーネントプロパティがコンポーネント入力プロパティの場合に「In」であり、対応するコンポーネントプロパティがコンポーネント出力プロパティの場合に「Out」である。
プロパティグループ707は、コンポーネントプロパティが属するプロパティグループの名称を示す。すなわち、本実施形態では、少なくとも1つのプロパティグループが存在し、プロパティグループに、1以上のコンポーネントプロパティと、1以上のSTプロパティ(例えば、その1以上のコンポーネントプロパティにそれぞれ対応する1以上のSTプロパティ)とのうちの少なくとも一方が関連付けられる。プロパティグループ707の値「Null」は、対応するコンポーネントプロパティがいずれのプロパティグループにも属さないことを意味する。
カスタムUI生成情報708は、生成されるカスタムUIの種別を表す。カスタムUI生成情報708の値「Null」は、カスタムUI生成情報がデフォルトUI用の情報であることを意味する。
図8は、ST管理テーブル423の構成を示す。
ST管理テーブル422は、サービステンプレートに関する情報を有する。ST管理テーブル423は、ST毎にレコードを有し、各レコードに、管理番号801、ST名802、STバージョン803、ST uk804、フローuk805及びST種別806が格納される。
管理番号801は、レコードの通し番号である。ST名802は、サービステンプレートの名称である。STバージョン803は、サービステンプレートのバージョンである。ST uk804は、サービステンプレートのユニークキーである。フローuk805は、サービステンプレートに対応するサービスフローのukである。ST種別806は、サービステンプレートの種別を表す。ST種別806の値「Debug」は、サービステンプレートが編集可能であることを意味し、ST種別806の値「Release」は、サービステンプレートが確定していること(編集不可)であることを意味する。
図8から分かるように、バージョンが異なる同一STは、ST名802が同じであり(例えば、「Provisioning & Pair」)、STバージョン803が異なる(例えば「01.00.00」、「01.10.00」)。つまり、STバージョンが異なる同一STは、別々のSTとして管理される。しかし、複数のSTのST名802が同一であれば、それら複数のSTのオリジナルは同一であることがわかる。
上述したように、STに関連付いているコンポーネントのバージョンの入れ替え(つまりコンポーネントの更新)が可能なのは、そのコンポーネントが関連付いているSTが未確定(Debug)である場合である。なお、既にサービスとして存在してしまっているSTが編集されることで生じる混乱(例えば、そのSTに関連付いているコンポーネントへの影響)を回避するために、本実施形態では、管理プログラム431が、確定したST(ST種別「Release」のST)を編集状態(Debug)に戻すことを禁止する。管理プログラム431は、確定したSTの編集要求をユーザから受け付けた場合、確定したSTのコピーを生成し、そのSTコピーを、編集対象のSTとして表示する。変形例として、管理プログラム431は、確定したSTであっても実行中又は実行待ちのサービスが無ければ(例えば、STを基にサービスを作成中及び作成済で無ければ)、確定したSTを編集状態に戻すことを許可し、STが確定しており且つ実行中又は実行待ちのサービスが1つでもあれば、そのSTを編集状態に戻すことを禁止してよい。
図9は、フロー管理テーブル424の構成を示す。
フロー管理テーブル424は、サービスフローに関する情報を有する。フロー管理テーブル424は、サービスフロー毎にレコードを有し、各レコードに、管理番号901、フローuk902、構成コンポーネントukリスト903及びプロパティマッピングリスト904が格納される。
管理番号901は、レコードの通し番号である。フローuk902は、フローのユニークキー(番号)である。
構成コンポーネントukリスト903は、サービスフローを構成するコンポーネントのukのリストである。構成コンポーネントukリスト903では、サービスフローにおけるコンポーネントの並び順に(コンポーネントの実行順序通りに)、コンポーネントのukが並ぶ。
プロパティマッピングリスト904は、サービスフローに対応するサービスのサービスプロパティのukのリストである。リスト904において、サービスプロパティのukは、例えば、コンポーネントukと、コンポーネントのキー名との組合せである。なお、「{コンポーネントuk(1). storage.pathinfo = コンポーネントuk(2). storage.pathinfo}」のような、コンポーネントukのコンポーネントプロパティの組合せは、一方のコンポーネントからの出力値が他方のコンポーネントへの入力値となることを意味する。
図10は、STプロパティ管理テーブル425の構成を示す。
STプロパティ管理テーブル425は、STプロパティに関する情報を有する。STプロパティ管理テーブル425は、STプロパティ毎にレコードを有し、各レコードに、管理番号1001、ST uk1002、STプロパティuk1003、表示名1004、キー名1005、入出力タイプ1006、プロパティグループ1007及びカスタムUI生成情報1008が格納される。
管理番号1001は、レコードの通し番号である。ST uk1002は、STプロパティが関連付いているSTのST ukである。
STプロパティuk1003は、STプロパティのユニークキー(例えば番号)である。
表示名1004は、画面に表示されるSTプロパティ名である。キー名1005は、STプロパティを一意に特定するための名称であり、STプロパティの識別情報の一例である。
入出力タイプ1006は、STプロパティがST入力プロパティであるかST出力プロパティであるか(言い換えれば、UI上の値が入力値であるか出力値であるか)区別するための情報である。入出力タイプ1006の値は、対応するSTプロパティがST入力プロパティの場合に「In」であり、対応するSTプロパティがST出力プロパティの場合に「Out」である。
プロパティグループ1007は、STプロパティが属するプロパティグループの名称を示す。すなわち、上述したように、本実施形態では、後述するNullも含めて少なくとも1つのプロパティグループが存在し、プロパティグループに、1以上のコンポーネントプロパティと、1以上のSTプロパティとのうちの少なくとも一方が関連付けられる。プロパティグループ1007の値「Null」は、対応するSTプロパティがいずれのプロパティグループにも属さないことを意味する。
カスタムUI生成情報1008は、生成されるカスタムUIの種別を表す。カスタムUI生成情報1008の値「Null」は、対応するSTプロパティにデフォルトUIが関連付けられていることを意味する。なお、カスタムUI生成情報は、カスタムUI生成詳細情報(例えば、ウィジェットの数、各々のウィジェットの種別、表示対象のテキスト、表示されるリスト等)を含んでよい。カスタムUI生成詳細情報(図示せず)は、STプロパティに関連付けられてよい。STプロパティに関連付いているカスタムUI生成詳細情報を基に、カスタムUIが生成されてよい。
図11は、サービス管理テーブル426の構成を示す。
サービス管理テーブル426は、サービスに関する情報を有する。サービス管理テーブル426は、サービス毎にレコードを有し、各レコードに、管理番号1101、サービス名1102、サービス説明1103、ST uk1104及びサービスuk1105が格納される。
管理番号901は、レコードの通し番号である。サービス名1102は、サービスの名称である。サービス説明1103は、サービスに関する説明の記述であり、例えば、サービスにおける処理とその順序を含んでよい。ST uk1104は、サービスに対応するSTのST ukである。サービスuk1105は、サービスのユニークキー(番号)である。
図12は、サービスプロパティ設定テーブル427の構成を示す。
サービスプロパティ設定テーブル427は、サービスプロパティに関する情報を有する。サービスプロパティ設定テーブル427は、サービスプロパティ毎にレコードを有し、各レコードに、管理番号1201、プロパティ設定値1202、STプロパティuk1203及びサービスuk1204が格納される。
管理番号1201は、レコードの通し番号である。プロパティ設定値1202は、対応するSTプロパティの入力値(又は出力値)である。「Null」は、入力値(又は出力値)が存在しないことを意味する。STプロパティuk1203は、対応するSTプロパティのSTプロパティukである。サービスuk1204は、対応するサービスのサービスukである。
図12によれば、サービスuk「1」のサービスに、5つのSTプロパティが関付けられていて、5つのSTプロパティにそれぞれ対応した5つのUI(デフォルトUI及びカスタムUIのうちの少なくとも1つ)に、「STORAGEHOST」、「1」等の値が入力(又は出力)されたことがわかる。
図19は、ステップ管理テーブル428の構成を示す。
ステップ管理テーブル428は、ステップに関する情報を有する。「ステップ」とは、STが表すサービスフローのエレメントであり、そのエレメントにコンポーネントが対応付けられることで、2以上のコンポーネントの並びとしてサービスフローが構築される。1つのコンポーネントが、STにおける1以上のステップに対応する。つまり、1つのコンポーネント(バージョンは同一でも異なっていてもよい)が、複数のステップに対応付けられることもある。本実施形態の説明において、いずれのSTに関連付けられたコンポーネントを「ステップ」と呼ぶことができる。ステップ管理テーブル428は、ステップ毎にレコードを有し、各レコードに、管理番号1901、Outdated ST uk1902、Outdated STバージョン1903、ステップ名1904、現在コンポーネント名1905、現在バージョン1906、最新コンポーネント名1907、最新バージョン1908及びステータス1909が格納される。
管理番号1901は、レコードの通し番号である。Outdated ST uk1902は、ステップが属するバージョンアップ可能なSTのukである。ステップが関連付いているST(以下、図19の説明において「対象ST」)が、バージョンアップ不可の場合(例えば、対象STに関連付いているいずれのコンポーネントも単一バージョンしか存在しない場合)、Outdated ST uk1902の値は、バージョンアップ不可を意味する値(例えば「Null」)である。ステップ名1904は、ステップの名称(例えば表示名)である(例えば図7の表示名703と同じ値)。現在コンポーネント名1905は、ステップに対応付けられているコンポーネント(現在コンポーネント)の名称(例えば表示名)である。現在バージョン1906は、ステップに対応した現在コンポーネントのバージョンを表す。最新コンポーネント名1907は、ステップに対応した現在コンポーネントの最新のバージョンのコンポーネント(最新コンポーネント)の名称(例えば表示名)である。最新バージョン1908は、ステップに対応した最新コンポーネントのバージョンを表す。最新バージョンのコンポーネントが存在しない場合(言い換えれば、現在バージョンが最新バージョンである場合)、最新コンポーネント名1907の値及び最新バージョン1908の値は、それぞれ、最新バージョンのコンポーネントが存在しないことを意味する値(例えば「Null」)である。また、管理プログラム431は、バージョン変更後のコンポーネントについて、例えばコンポーネントのバージョン変更の際に、バージョン変更前のコンポーネントのコンポーネント名と異なるコンポーネント名の入力をユーザから受け、その異なるコンポーネント名を、バージョン変更後のコンポーネントに関連付けることができる。このため、同一ステップについて、現在コンポーネント名1905と最新コンポーネント名1907は異なっていることがある。また、コンポーネントは、作成したユーザはもちろん他のユーザ(例えばST作成ユーザが作成するST)でも使用するものであり、ステップ名1904として、汎用性のある表示名を定義することができる。すなわち、コンポーネントの表示名とは別に、ステップとしての表示名を定義することができる。また、ステップはユニークである(複数のSTに同一のステップが存在しない)ため、ステップが行う処理目的はコンポーネントよりも明確と言える。例えば、ステップのプロパティに値を設定したり実行順序を定義したりすることで、処理内容を具体化及び差別化の少なくとも一方を実現することができる。コンポーネントの表示名とは別に、ステップの表示名が定義されることで、サービスフロー上でどのような処理が行われるかをユーザが識別し易くなることが期待できる。ステータス1909は、対象STに関連付いているステップのバージョン変更がされたか否かを表す。バージョン変更済の場合、ステータス1909の値は「Applied」であり、バージョン変更が未だ又は最新バージョンが存在しない場合、ステータス1909の値は「Not applied」である。
以上が、テーブル421〜428の構成の説明である。なお、上述の説明において、表示名、キー名及びukのような識別情報は、ユーザにより入力された情報でもよいし、管理プログラム431により決められた情報でもよい。
以下、ST入力プロパティとST出力プロパティの関係の詳細と、UI生成/表示の詳細のそれぞれの例を説明する。
図13は、ST入力プロパティとST出力プロパティの関係の一例を示す。
サービステンプレート1301に対応するサービスフローが、コンポーネント1302A(「Provisioning Volume」)と、コンポーネント1302B(「Create pair volume」)とにより構成されている。そのサービスフローでは、コンポーネント1302Aの次にコンポーネント1302Bが実行されるような実行順序となっている。
コンポーネント1302Aには、4つのコンポーネント入力プロパティ1303A〜1303Dが関連付けられている。4つのコンポーネント入力プロパティ1303A〜1303Dのそれぞれの表示名は、「Number of Volume」、「Volume Capacity」、「Host Name」及び「Number of path」である。また、コンポーネント1302Aには、2つのコンポーネント出力プロパティ1303E及び1303Fが関連付けられている。2つのコンポーネント出力プロパティ1303E及び1303Fのそれぞれの表示名は、「Volume uk」及び「Path info」である。
コンポーネント1302Bには、4つのコンポーネント入力プロパティ1303G〜1303Jが関連付けられている。4つのコンポーネント入力プロパティ1303G〜1303Jのそれぞれの表示名は、「Volume uk」、「Host Name」、「Path info」及び「Path世代数」である。また、コンポーネント1302Bには、1つのコンポーネント出力プロパティ1303Kが関連付けられている。そのコンポーネント出力プロパティ1303Kの表示名は、「Path info」である。
これらのコンポーネントプロパティにおいて、表示名「Volume uk」のコンポーネント出力プロパティ1303Eと、同じ表示名「Volume uk」のコンポーネント入力プロパティ1303Gは、同一のキー名を有する。同様に、表示名「Path info」のコンポーネント出力プロパティ1303Fと、同じ表示名「Path info」のコンポーネント入力プロパティ1303Iも、同一のキー名を有する。これにより、コンポーネント出力プロパティ1303Eからの出力値が、コンポーネント入力プロパティ1303Gの入力値とされ、また、コンポーネント出力プロパティ1303Fからの出力値が、コンポーネント入力プロパティ1303Iの入力値とされる。このように、「Volume uk」及び「Path info」については、出力値がそのまま入力値と使用されるので、ST作成ユーザがわざわざ「Volume uk」及び「Path info」について値を入力する必要が無い。従って、誤入力を防止できる。
このようなコンポーネントを有するサービスフローのサービステンプレート1301には、ST入力プロパティ1304A〜1304Eと、ST出力プロパティ1304F及び1304Gが、管理プログラム431により関連付けられる。ST入力プロパティ1304Aは、コンポーネント入力プロパティ1303Aを基に生成されたST入力プロパティであり、故に、表示名は「Number of Volume」である。ST入力プロパティ1304Bは、コンポーネント入力プロパティ1303Bを基に生成されたST入力プロパティであり、故に、表示名は「Volume Capacity」である。ST入力プロパティ1304Cは、コンポーネント入力プロパティ1303C及びHを基に生成されたST入力プロパティであり、故に、表示名は「Host Name」である。ST入力プロパティ1304Dは、コンポーネント入力プロパティ1303Dを基に生成されたST入力プロパティであり、故に、表示名は「Number of path」である。ST入力プロパティ1304Eは、コンポーネント入力プロパティ1303Jを基に生成されたST入力プロパティであり、故に、表示名は「Path世代数」である。ST出力プロパティ1304Fは、コンポーネント出力プロパティ1303Eを基に生成されたST入力プロパティであり、故に、表示名は「Volume uk」である。ST出力プロパティ1304Gは、コンポーネント出力プロパティ1303Kを基に生成されたST入力プロパティであり、故に、表示名は「Path info」である。これらのST入力プロパティ及びST出力プロパティは、コンポーネント入力プロパティ及びコンポーネント出力プロパティを基にそれぞれ管理プログラム431により生成される。
図14は、図13のSTに対応したサービス作成画面の一例である。
サービス作成画面1401には、ST入力プロパティ1304A〜1304Eにそれぞれ対応したUI1411〜1415が表示される。UI1411〜1415は、それぞれ管理プログラム431により生成されたUIである。UI1411〜1415のうち、UI1411及び1415がそれぞれデフォルトUIであり、UI1412〜1414がそれぞれカスタムUIである。UI1411〜1415の各々は、ST入力プロパティに関連付いているカスタムUI生成情報を基に生成される。
サービス作成画面1401には、実行ボタン1417と取消ボタン1418が設けられている。ST作成ユーザは、UI1411〜1415に入力した値でよければ、実行ボタン1417を押し、それにより、入力された値を基にサービスが作成され、そのサービスの実行命令が計算機管理システム302に送信される。ST作成ユーザは、UI1411〜1415に入力した値を取り消すのであれば、取消ボタン1418を押し、それにより、全てのUI1411〜1415がブランクとされる。
なお、サービス作成画面1401に表示されるUIが、デフォルトUIであるかカスタムUIであるかは、STのSTプロパティに関連付いているカスタムUI生成情報次第なので、画面1401に表示される全てのUIがカスタムUIであることもある。
また、管理プログラム431は、ST入力プロパティ1304A〜1304Eがそれぞれいずれのプロパティグループに属しているかを基に、プロパティグループ別に、UIを表示してもよい。例えば、同一のプロパティグループに属する2以上のUIが1つの枠で囲まれてもよい。分野が同一のSTプロパティが同一のプロパティグループに属していれば、UIの配置がプロパティグループに応じた配置となる。これにより、視認性の向上が期待される。
以下、本実施形態での表示の具体例を説明する。
図15は、ST作成画面の一例を示す。
ST作成画面は、コンポーネントリストプレーン1511と、コンポーネント詳細プレーン1512と、フロー作成プレーン1513と、ST種別選択ツール1514と、ST VUPボタン1523とを有する。
コンポーネントリストプレーン1511には、管理されているコンポーネントのコンポーネント名のリスト(コンポーネント管理テーブルに記録されているコンポーネント名のリスト)1531が、管理プログラム431により表示される。
コンポーネント詳細プレーン1512には、コンポーネントリスト1531から選択されたコンポーネントに対応する詳細(例えばコンポーネント名及びバージョン)が、管理プログラム431により表示される。
フロー作成プレーン1513には、コンポーネントリスト1531から選択されたコンポーネントのアイコン1541A及び1541Bがユーザ操作に従い表示され、コンポーネントアイコン1541A及び1541B同士の接続により、サービスフローが定義される。例えば、管理プログラム431は、コンポーネントリスト1531から選択されたコンポーネントをフロー作成プレーン1513にドラッグ&ドロップするユーザ操作に従い、そのコンポーネントのアイコン1541A及び1541Bをフロー作成プレーン1513に表示する。コンポーネントリスト1531からコンポーネントがドラッグ&ドロップされる都度に、管理プログラム431は、コンポーネントアイコンをフロー作成プレーン1513に追加する。また、管理プログラム431は、ユーザ操作に従い、第1のコンポーネントアイコンから第2のコンポーネントアイコンへの矢印リンクを張ることで、第1のコンポーネントの次に第2のコンポーネントを実行することを定義する。
ST種別選択ツール1514は、Debugボタン1521とReleaseボタン1522とを含む。管理プログラム431は、Releaseボタン1522が押された場合、フロー作成プレーン1513に表示されているサービスフローのSTを、ST種別「Release」として保存する。一方、管理プログラム431は、Debugボタン1521が押された場合、フロー作成プレーン1513に表示されているサービスフローのSTを、ST種別「Debug」として保存する。
ST VUPボタン1523は、STバージョンアップを指示するボタンである。ST VUPボタン1523が押された場合、管理プログラム431は、後述のSTリスト画面(図27参照)を表示する。
以上が、ST作成画面1501の構成の説明である。
新たにインポートされたコンポーネントがあれば、ST作成画面1501のコンポーネントリスト1531には、その新たにインポートされたコンポーネントのコンポーネント名も含まれる。ST作成ユーザが、その新たなコンポーネントのコンポーネント名を選択し、関連ST表示のためのユーザ操作を行うと(選択されたコンポーネント名を関連ST表示の対象として指定すると)、管理プログラム431が、例えばポップアップで、バージョン毎の関連STリストを表示する。
図16は、バージョン毎の関連STリストの一例を示す。
管理プログラム431は、コンポーネントリスト1531から選択されたコンポーネント名と同一のコンポーネント名のバージョン及びコンポーネントukをコンポーネント管理テーブル421から特定する。管理プログラム431は、特定したコンポーネントukに対応するフローukをフロー管理テーブル424から特定し、特定したフローukに対応するST名及びST種別をST管理テーブル423から特定する。これにより、管理プログラム431は、コンポーネントリスト1531から選択されたコンポーネントのバージョン毎の関連STリスト(関連STのST名、バージョン及びST種別のリスト)1611A及び1611Bを生成し表示する。それらのリスト1611A及び1611Bは、例えばST作成画面1501上のポップアップ画面1601に表示される。
例えば、ST作成ユーザは、通常、新たにコンポーネントがインポートされた場合、その新たなコンポーネントを、古いバージョンのコンポーネントを使用する既存のSTに適応する必要があるかを検討することになる。この時、コンポーネントとSTの関係が把握できないと、どのSTをエンハンスすればよいのか不明である。
本実施形態によれば、コンポーネントリスト1531から選択されたコンポーネントについて、関連ST(選択されたコンポーネントとコンポーネント名が同じコンポーネントが関連付いているST)がバージョン毎に表示される。これにより、ST作成ユーザは、選択したコンポーネントと同一コンポーネント名のコンポーネントを使用しているSTを把握できる。このため、新しいコンポーネントがインポートされた場合に、どのサービステンプレートを新しいコンポーネントに入れ替える必要があるか容易に判別できる。
なお、関連STリストの表示のためのユーザ操作は、コンポーネント更新前に行われてよい。例えば、ST作成ユーザが、コンポーネントを更新するか否かの判断のために、そのコンポーネントについての関連STを管理プログラム431に表示させる。ST作成ユーザは、そのコンポーネントについてST種別「Release」が存在しないことがわかった場合に、選択したコンポーネントを、バージョンを更新すること無しに更新することを決めてよい。一方、ST作成ユーザは、そのコンポーネントについてST種別「Release」が存在することがわかった場合に、選択したコンポーネントをバージョンと共に更新することを決めてよい。
ところで、上述したように、ST作成画面1501を用いて作成されたSTを基に、サービス作成画面を用いてサービスを作成することができる。
図17は、サービス作成画面の具体例を示す。
サービス作成画面1701は、フロー概要プレーン1721と、UIプレーン1722とを有する。管理プログラム431が、確定したSTのサービスフローの概要図を例えばフロー管理テーブル424を基に生成し、生成した概要図をフロー概要プレーン1721に表示する。
また、管理プログラム431が、確定したSTのST入力プロパティに関連付いているカスタムUI生成情報を基に、UIを生成し、生成したUIをUIプレーン1722に表示する。UIプレーン1722には、例えば図示のように、デフォルトUI1711とカスタムUI1712が混在する。
カスタムUIは、デフォルトUIよりユーザビリティが高く、値の入力がサービス作成ユーザにとって容易である。そのため、例えば図16に示したST作成画面1501のコンポーネントリスト1531に、コンポーネント名に加えて、有効なカスタムUI生成情報(「Null」ではないカスタムUI生成情報)が関連付けられているか否かも表示されてよい。ST作成ユーザは、コンポーネント名が同一の複数のコンポーネントにカスタムUIが関連付けられたコンポーネントとカスタムUIが関連付けられていないコンポーネントとあれば、カスタムUIが関連付けられているコンポーネントをSTに関連付けるコンポーネントとして選択する。これにより、サービス作成において値を入力し易いSTを作成することができる。
なお、サービス作成画面1701には、例えば図示のように、STのサービスフローの概要図が表示されてもよい。
以下、本実施形態で行われる処理を説明する。
図20は、コンポーネントインポート処理のフローチャートである。
管理プログラム431は、コンポーネントの情報パッケージ(例えば、実行ファイル及びコンポーネントプロパティを含む)を受け、コンポーネントの実行ファイルを、メモリ412(又は、外部のストレージ装置等の補助ストレージ装置)に格納する(P2001)。コンポーネントの情報パッケージは、カスタムUI生成情報の一部又は全部を含んでよい。
管理プログラム431は、実行ファイルのパス名等の情報を、コンポーネント管理テーブル421に格納する(P2002)。
また、管理プログラム431は、コンポーネントプロパティに関する情報をコンポーネントプロパティ管理テーブル422に格納する(P2003)。なお、コンポーネントプロパティ管理テーブル422の属性の一部は、インポート後にコンポーネント提供ユーザ又はST作成ユーザが追加又は変更してもよい。例えば、表示名703は他のコンポーネントの表示名と混乱することが好ましくない場合である。そして、プロパティグループについてはUIの配置をグループ化できることから、ST作成ユーザが追加又は変更してもよい。
また、管理プログラム431は、必要に応じてステップ管理テーブル428を更新する(P2004)。具体的には、例えば、管理プログラム431は、インポートされたコンポーネントの旧バージョンのステップ(コンポーネント)をステップ管理テーブル428から探してよい。管理プログラム431は、旧バージョンのステップ(コンポーネント)が見つかった場合、見つかったステップに対応する最新コンポーネント名1907及び最新バージョン1908を更新してよい。また、管理プログラム431は、見つかったステップ(コンポーネント)に対応するステータス1909の値が「Applied」の場合、その値を「Not applied」に更新してよい。また、管理プログラム431は、見つかったステップ(コンポーネント)に対応するOutdated ST uk1902及びOutdated ST version1903の各々の値が「Null」の場合、Outdated ST uk1902の値を、見つかったステップが関連付いているSTのukに更新し、Outdated ST version1903の値を、見つかったステップが関連付いているSTのバージョンに更新してよい。
本実施形態では、カスタムUI生成情報は、予め運用自動化システム301に存在するものではなく(運用自動化システム301にビルトインされているものではなく)、インポートされるコンポーネントに付随して入力される。これにより、インポートされるコンポーネントに適したUIを、コンポーネントのインポートという適切なタイミングで、自動的に運用自動化システム301の運用対象として追加することができる。
なお、コンポーネントインポート処理では例え同じコンポーネント名であったとしても異なるバージョンのコンポーネントである場合は、インポートしたコンポーネントに対して新しいコンポーネントukをコンポーネント管理テーブルにて割り当てる。そのため、作成済みのサービステンプレートやサービスで用いるコンポーネントが自動で変更されることはない。そのメリットはこれまで説明してきた通りである。しかし、同じコンポーネント名であった場合は異なるバージョンであっても従来のバージョンと同じコンポーネントukを割り当てる等によって、コンポーネントインポート処理によって自動的に作成済みのサービステンプレートやサービスで用いるコンポーネントを変更してもよい。
図21は、ST編集処理のフローチャートである。
ST編集処理とは、ST作成処理における処理である。ST作成ユーザがST作成画面1501のフロー作成プレーン1513上に必要なコンポーネントを置いてコンポーネントの順番を決めるが、図21に示すST編集処理は、フロー作成プレーン1513上のサービスフローのSTを一時保存する処理である。
管理プログラム431は、STの情報(ST名、STバージョン、ST uk等)を、ST管理テーブル423に格納する(P2101)。また、管理プログラム431は、そのSTのサービスフローの情報(フローuk、構成コンポーネントukリスト等)を、フロー管理テーブル424に格納する。
管理プログラム431は、そのSTのサービスフローの構成コンポーネントukリストが表す全てのコンポーネントの各々について(例えば、構成コンポーネントukリストが表すコンポーネント順序通りに)、P2104〜P2107を行う(P2103)。すなわち、管理プログラム431は、構成コンポーネントukリストから選択されたコンポーネントのコンポーネントプロパティに対応したSTプロパティに関する情報を、STプロパティ管理テーブル425に格納する(P2104)。この処理には、コンポーネントプロパティ管理テーブルのカスタムUI生成情報708及びプロパティグループ707の値をSTプロパティ管理テーブル425のカスタムUI生成情報1008及びプロパティグループ1007に格納することも含む。P2104では、例えば、管理プログラム431は、前のコンポーネントの出力プロパティと、次のコンポーネントの入力プロパティの関連付けが可能か否か(キー名が同一か否か)を判断し、その判断の結果が肯定であれば、その出力プロパティ及び入力プロパティを関連付けてよい。管理プログラム431は、対応するプロパティマッピングリスト904に、P2104で格納したSTプロパティに基づく情報を追加する(P2105)。管理プログラム431は、ステップ管理テーブル428を更新、例えば、STに関連付くコンポーネント(ステップ)に対応するレコードをステップ管理テーブル428に追加する(P2106)。そして、管理プログラム2104は、構成コンポーネントukリストが表すコンポーネントのうちの次のコンポーネントを選択する(P2107)。なお、あるコンポーネントの入力プロパティが、他のコンポーネントの出力プロパティと関連付いている場合は、STプロパティ管理テーブル425への登録を省略してもよい。
図22は、ST確定処理のフローチャートである。
管理プログラム431は、作成済(登録済)のSTから選択されたSTについて、ST種別「Release」が指定を受け付け、そのSTのST種別を、「Debug」から「Release」に変更する(P2201)。ST種別が「Release」となったSTについて、管理プログラム431は、編集を禁止する。なお、この編集禁止の例としては編集に関するユーザ操作を拒否したり、またそもそも編集の際に編集禁止としたSTを選択したりできないようにする、といったことが考えられる。
図23は、関連ST表示処理のフローチャートである。
管理プログラム431は、選択されたコンポーネント(例えば図15のコンポーネントリスト1531から選択されたコンポーネント)のコンポーネント名と同一のコンポーネント名のバージョン及びコンポーネントukをコンポーネント管理テーブル421から特定する(P2301)。管理プログラム431は、特定したコンポーネントukに対応するフローukをフロー管理テーブル424から特定する(P2302)。管理プログラム431は、特定したフローukに対応するST名及びST種別をST管理テーブル423から特定する(P2303)。管理プログラム431は、P2302及びP2302を、P2301で特定された全てのコンポーネントukについて行う(P2304)。その後、管理プログラム431は、選択されたコンポーネントのバージョン毎の関連STリスト(関連STのST名、バージョン及びST種別のリスト)を生成し表示する(P2305)。
図24は、サービス作成画面1701表示処理のフローチャートである。
管理プログラム431は、確定したSTの選択をサービス作成ユーザから受け、選択されたSTに対応したサービス情報(例えばST uk)を、サービス管理テーブル426に格納する(P2401)。管理プログラム431は、選択されたSTのST ukに対応する全てのSTプロパティに関する情報をSTプロパティ管理テーブル425から特定する(P2402)。管理プログラム431は、特定したSTプロパティに関連付いているカスタムUI生成情報1008を基に、各ST入力プロパティについてUI(デフォルトUI又はカスタムUI)を生成し(P2403)、生成したUIを含んだサービス作成画面1701(プロパティ入力画面)を表示する(P2404)。
なお、P2403が参照するカスタムUI生成情報1008の代わりとして、フロー管理テーブル424のプロパティマッピングリスト904の値を参考にした上で対応するコンポーネントのコンポーネントプロパティを特定し、コンポーネントプロパティ管理テーブル422のカスタムUI生成情報708を参照してもよい。サービス生成画面のUIを決定するにあたって、直接的又は間接的かに関わらずコンポーネントのカスタムUI生成情報を参照することで、サービステンプレート作成ユーザが各サービステンプレート毎にサービス作成画面をデザインしなくても利便性の高い画面を生成できるからである。
図25は、サービス実行処理のフローチャートである。
図24の処理により表示された画面のUIに値が入力され、サービス作成ユーザにより実行が指定された場合に、サービス実行処理が開始される。なお、作成されたサービスが登録されて実行待ちの状態となり、実行待ちの状態のサービスについて実行が指示されることで、サービス実行処理が乖離されてもよい。
管理プログラム431は、サービス作成画面1701(プロパティ入力画面)に入力された値を、サービスプロパティ設定テーブル427に格納する(P2501)。その後、管理プログラム431は、入力された設定値を基に、サービスを実行する(P2502)。具体的には、管理プログラム431は、例えば下記を行う。
(A)管理プログラム431は、サービスの元となったサービステンプレートを選択する。
(B)管理プログラム431は、(A)で選択したサービステンプレートのフローの構成コンポーネントukリスト903を参照し、実行すべきコンポーネントを実行順序と共に特定する。
(C)管理プログラム431は、(B)で特定した通りにコンポーネントを実行する。(C)において、管理プログラム431は、プロパティマッピングリスト904を参照することで、適切なサービスプロパティの入力プロパティ又は他のコンポーネントの出力プロパティを選び、その値を入力する。その入力された値が、実行対象のコンポーネントの入力プロパティに設定される入力値である。なお、「コンポーネントの実行」とは、実行ファイルパス604に記載の実行ファイルを実行することである。
(D)実行順序通りにコンポーネントを実行した後、管理プログラム431は、プロパティマッピングリスト904を参照の上で、サービステンプレートの出力プロパティに関連するコンポーネントの出力プロパティを選び、その値をサービステンプレートの出力プロパティとしてサービスの実行結果として表示する。なお、サービスの実行結果についてもカスタムUI及びプロパティグループの処理を適用してもよいことは言うまでもない。
なお、実行ファイルに記載された処理内容は、典型的には、運用対象装置への構成変更、又は、運用対象装置からの構成情報、メトリック情報、状態の取得、といった要求を運用対象装置に直接又は間接に送信することである。なお、運用対象装置に要求を直接に送信する例としては、運用自動化システムから運用対象装置に要求を直接に送信する場合であり、要求を間接に送信する例としては、計算機管理システム302に対して要求を送信する場合と運用対象装置の保守員に保守メッセージを送信し、保守員が運用対象装置の運用として保守業務を行う場合とが考えられる。
図26は、UI変更処理のフローチャートである。
管理プログラム431は、UIの変更要求を受け付け(P2601)、P2602を実行する。P2602では、管理プログラム431は、UIの変更要求に従いUIの変更を実行する。UIが変更された場合、変更前のUIに関連付いているコンポーネントのコピーを作成し、そのコンポーネントコピーに、新たなバージョン(変更前のUIに関連付いているコンポーネントのバージョンと異なるバージョン)を割り当てる。そして、管理プログラム431は、そのコンポーネントコピーに、変更後のUI(変更後のUIを表すカスタムUI生成情報)を関連付ける。管理プログラム431は、そのコンポーネントコピー(新たなバージョンのコンポーネント)に関する情報をコンポーネント管理テーブル421に格納し(追加)し、そのコンポーネントコピーに関連付いているコンポーネントプロパティに関する情報をコンポーネントプロパティ管理テーブル422に格納(追加)する。なお、管理プログラム431は、変更対象のUIが関連付いているコンポーネントがいずれの既存ST(又は、いずれの既存確定ST(ST種別「Release」のST))にも関連付いていなければ、コンポーネントコピーを作成すること無しに、UIの変更を受け付けてよい。
管理プログラム431は、変更要求で指定されているUIが既存のSTに関連付いているか否かを判断する(P2603)。
P2603の判断結果が肯定の場合(P2603:YES)、管理プログラム431が、既存コンポーネントと関連がある既存STの一覧画面を表示する(P2604)。このとき、ユーザが選択した既存STについて、管理プログラム431がその既存のSTのコピーを作成し(例えば、既存のSTを基にバージョンの異なる新たなSTを作成し)(P2605)、その作成したSTコピーで使用されている既存コンポーネントを新たなバージョンのコンポーネントに入れ替える。これにより、変更後のUIが、既存のSTに関連付けられることが回避される。ここで言う「既存のST」は、ST種別が「Release」のSTであって、ST種別が「Debug」のSTは対象外でもよい。
なお、コンポーネントのUI変更処理は上記以外で実現しても良い。例えば、コンポーネント提供ユーザが、UIが更新されることで新しいバージョンとなったコンポーネントをインポートしたり、サービステンプレートをコンポーネントとしてインポートしたりしている場合は、サービステンプレートに関係するカスタムUI生成情報が変更されることでバージョンアップされた場合である。
ところで、以下、STバージョンアップの詳細を説明する。
図27は、STリスト画面の構成を示す。
STリスト画面2700は、STのリストを表示する画面である。具体的には、管理プログラム431は、ST管理テーブル423に基づいて複数のSTを特定し、特定した複数のSTにそれぞれ対応した複数のSTブロック(表示オブジェクト)2701を表示するSTリスト画面2700を表示する。
管理プログラム431は、ステップ管理テーブル428を基に、特定された複数のSTの各々について、バージョンアップ可能なSTであるか否か(言い換えれば、最新バージョンのコンポーネントが存在するが旧バージョンのコンポーネント(ステップ)が関連付けられているか否か)を判断してよい。その判断結果は、例えば、Outdated ST uk1902及びOutdated ST version1903の各々の値が「Null」ではなく、ステータス1909「Not applied」に関連付いたSTである場合、肯定となってよい。その判断結果が肯定の場合に、管理プログラム431は、STブロック2701に、バージョンアップ可能なSTであることを意味する表示オブジェクト、例えば「Outdated」と表示されたマーク、を関連付けて表示する。ST作成ユーザは、マーク「Outdated」の有無により、STのバージョンアップが可能か否かわかる。これにより、ST作成ユーザは、ST毎に、バージョンアップするタイミングを決めやすい。
各STブロック2701に、チェックボックスが表示される。チェックボックスにチェックマークが記入された場合、管理プログラム431は、チェックマークが記入されたSTブロック2701に対応するSTの詳細をST管理テーブル423等から特定し、特定した詳細2702を表示する。また、管理プログラム431は、チェックマークが記入されたSTブロック2701について「Update」ボタン2703を表示する。「Update」ボタン2703が押された場合、押された「Update」ボタン2703に対応したSTが、指定STとなり、STバージョンアップ画面が管理プログラム431により表示される。
図28は、STバージョンアップ画面の構成を示す。
STバージョンアップ画面2800では、「All apply」タブ2801を有する「All apply」画面2811と「Individual apply」タブ2802を有する「Individual apply」画面とのいずれを前面表示とするかが、いずれのタブを選択するかによって切り替えられる。図28では、「All apply」タブ2801が選択されている状態であり、故に、「All apply」画面2811が前面表示されている。
「All apply」画面2811には、管理プログラム431により、「Apply」ボタン2803と、「Step list to be applied」ボタン2804とが表示される。
「Apply」ボタン2803が押された場合、指定STが関連付いた(つまりSTが指定された)バージョンアップ要求が管理プログラム431に入力され、管理プログラム431は、その要求に応答して、STバージョンアップ処理を実行する。具体的には、例えば、管理プログラム431は、指定STの複製に関連付けられている全ての旧バーションのステップにそれぞれ対応した全ての最新バーションのコンポーネントをステップ管理テーブル428から特定し、その全ての旧バーションのステップをそれぞれ特定した全ての最新バーションのコンポーネントに差し替える。その処理中、管理プログラム431は、処理進捗(例えば、旧バージョンのコンポーネントの数と、差し替え(バージョンアップ)が済んだ(ステータス1909が「Applied」になった)ステップの数)を表示してもよい。
「Step list to be applied」ボタン2804が押された場合、管理プログラム431は、指定STに対応した全てのレコード(Outdated ST uk1902及びOutdated STバージョン1903が指定STに該当する全てのレコード)をステップ管理テーブル428から特定し、図29に示すように、特定した全てのレコードにそれぞれ対応した全ての旧バージョンステップ(コンポーネント)に関する情報のリスト2901を、「All apply」画面2811に表示する。リスト2901の1以上のレコードは、指定STに関連付いている1以上のステップ(旧バージョン)にそれぞれ対応している。各レコードは、チェックボックスを有する。ST作成ユーザによりチェックボックスにチェックマークが記入され(つまりステップが選択され)「Apply」ボタン2902が押された場合、指定STと選択されたステップとが関連付いたバージョンアップ要求が管理プログラム431に入力される。管理プログラム431は、その要求に応答して、指定STの複製に関連付く旧バージョンステップ(つまりST作成ユーザにより選択されたステップ)を、最新バージョンのコンポーネントに差し替える。なお、ここでは、差し替え後のコンポーネントは必ず最新バージョンのコンポーネントであるが、「All apply」画面2811に、選択されたステップ(コンポーネント)の変更後のバージョンを受け付けるUI(又は他のUI)が、管理プログラム431により表示されてよい。そのUIは、カスタムUIであってもよいしデフォルトUIであってもよい。つまり、STバージョンアップ画面2800におけるUIに関する情報(例えばカスタムUIかデフォルトUIか)も、コンポーネントプロパティに含まれていて、その情報を基に、STバージョンアップ画面2800(例えば「All apply」画面2811及び後述の「Individual apply」画面)に展開されるUIが管理プログラム431により生成されてよい。また、リスト2901に加えて、詳細フィールド2903が、「Step list to be applied」ボタン2804が押された場合に管理プログラム431により「All apply」画面2811に表示されてもよい。詳細フィールド2903には、リスト2901からユーザにより選択されたレコード(例えばマウスカーソルが重ねられてクリックされたレコード)に対応した最新コンポーネント(最新バージョンのコンポーネント)に関する詳細な情報が、管理プログラム431により表示されてもよい。
「Individual apply」タブ2802が選択された場合、図30に示すように、管理プログラム431により、「Individual apply」画面3011が前面表示される(図30)。「Individual apply」画面3011は、コンポーネントリストプレーン3001と、選択コンポーネントプレーン3002とを有する。
コンポーネントリストプレーン3001は、「Individual apply」画面3011の左側に位置する縦長のプレーンである。コンポーネントリストプレーン3001には、指定STに関連付いている全てのコンポーネントのリストではなく、指定STに関連付いているコンポーネントのうち複数バージョンが存在するコンポーネントのみのリストが表示される。具体的には、例えば、管理プログラム431が、ステップ管理テーブル428から、最新コンポーネント名1907及び最新バージョン1908が「Null」ではないレコードを特定し、特定したレコードに記載の最新コンポーネント名1907のリストをコンポーネントリストプレーン3001に表示する。このリストから、ST作成ユーザにより、バージョン変更対象のステップ(コンポーネント)が選択される。コンポーネントリストプレーン3001には、バージョン変更不可のステップ(単一バージョンしか存在しないステップ)は表示されない。このため、視認性が高い。
なお、後述するように、指定STには、複数の同一のコンポーネント(ステップ)が関連付けられていることがあり(但し、バージョンは同じこともあるし異なっていることもある)、リストには、複数の同一のコンポーネントが表示されてもよいが、本実施形態では、指定STに関連付けられている同一コンポーネントの数に関わらず、その同一コンポーネントについて、リストに表示されるコンポーネントの数は、1である。これにより、視認性がより高まる。
また、プレーン3001には、ST管理ユーザからの要求に応答して、指定STに関連付いている全てのコンポーネントのリストが表示されてもよい。
選択コンポーネントプレーン3002には、コンポーネントリストプレーン3001に表示されたリストから選択されたコンポーネントに関する情報が表示される。図30の例によれば、リスト(最新コンポーネント名のリスト)から選択されたコンポーネント(「Volume Capacity」)には2つのステップが対応付けられているため、選択コンポーネントプレーン3002には、その選択されたコンポーネントに対応付けられている2つのステップの各々について、ステップ名が表示される。ステップ毎にステップ名が異なっていてよい。
選択コンポーネントプレーン3002には、選択されたコンポーネントに関する情報が表示される。具体的には、例えば、選択コンポーネントプレーン3002には、バージョン指定プルダウンメニュー3004、詳細フィールド3006、候補ステップリスト3007、及び「Apply」ボタン3005が表示される。
バージョン指定プルダウンメニュー3004は、変更後のバージョンを指定するためのUIである。バージョン指定プルダウンメニュー3004は、選択されたコンポーネントについてコンポーネントプロパティ管理テーブル422から特定された指定可能なバージョンのメニューを表示する。
詳細フィールド3006には、候補ステップリスト3007から選択されたステップ(例えばチェックマークが記入されたレコードに対応するステップ)に関する詳細な情報(例えばステップ管理テーブル428から特定された情報)が表示される。
候補ステップリスト3007は、プレーン3001のリストから選択されたコンポーネントに対応付けられている1以上のステップのリストである。図30では、プレーン3001のリストからコンポーネント「Volume Capacity」が選択されているが、指定STには、そのコンポーネントに2つのステップが対応付けられているため、候補ステップリスト3007は、2つのステップにそれぞれ対応した2つのレコードを有する。各レコードは、チェックボックスと、ステップ管理テーブル428におけるレコードの少なくとも一部(例えば、ステップ名、現在バージョン及びステータス)を有する。
図30によれば、指定STには、バージョン003のコンポーネント(ステップ)「Volume Capacity3」と、バージョン002のコンポーネント(ステップ)「Volume Capacity」が含まれていることがわかる。また、バージョン003のコンポーネント「Volume Capacity3」のステータスが「Applied」なので、コンポーネント「Volume Capacity3」のバージョン003がバージョン指定プルダウンメニュー3004で指定したバージョンと同じである、または、バージョンアップ済みであるため、バージョンアップ対象とする必要がないことがわかる。ステップはユニークであり、異なる複数のSTに同一のステップが存在することはない。また、図30によれば、ステータスが「Not applied」であるコンポーネント「Volume Capacity」(バージョン002)についてチェックマークが記入されたため(つまり、コンポーネント「Volume Capacity」(バージョン002)が選択されたため)、詳細フィールド3006には、そのコンポーネント(ステップ)「Volume Capacity」(バージョン002)に関する詳細な情報が表示される。バージョン指定プルダウンメニュー3004を用いて選択されるバージョンは、選択されたステップ「Volume Capacity」(バージョン002)についての変更後のバージョンである。詳細フィールド3006には、バージョン指定プルダウンメニュー3004で選択したバージョンのコンポーネントに関する詳細な情報が管理プログラム431により表示されてもよい。
「Apply」ボタン3005が押された場合、指定ST、選択されたステップ及び変更後のバージョンが関連付いたバージョンアップ要求が、管理プログラム431に入力される。管理プログラム431は、その要求に応答して、指定STの複製に関連付く旧バージョンステップ(つまりST作成ユーザにより選択されたステップ)を、変更後バージョンのコンポーネントに差し替える。
このように、「Individual apply」モードによれば、ST作成ユーザは、指定STに関連付いているステップのうちの所望のステップのみバージョンを変更することができる。このため、指定STに関連付いているステップのうち、その指定STについてバージョン変更(典型的にはバージョンアップ)しても問題が発生しそうに無いコンポーネントのみを選んでバージョン変更できる。これにより、STのバージョンアップにより問題が生じる確率を低減できる。
「All apply」モードでも「Individual apply」モードでも、STのバージョンアップでは、変更前バージョン(例えば旧バージョン)のコンポーネント(ステップ)が変更後バージョン(例えば最新バージョン)のコンポーネントに差し替えられる。そのSTバージョンアップにおいて、本実施形態では、変更前バージョンのコンポーネントに関連付いているコンポーネント入力プロパティの入力値(少なくともST作成ユーザ又はコンポーネント作成ユーザ等のユーザにより設定された値)が、変更後バージョンのコンポーネントに関連付いているコンポーネント入力プロパティに入力される(引き継がれる)。
図31は、コンポーネント入力プロパティの入力値の引継ぎを示す。
ST001(バージョン001)に、コンポーネントBBB(バージョン001)とコンポーネントDDD(バージョン001)とが関連付いているとする。コンポーネントBBB(バージョン001)に関連付いているコンポーネント入力プロパティの入力値(例えばユーザにより設定された値)が「XXX」であり、コンポーネントYYY(バージョン001)に関連付いているコンポーネント入力プロパティの入力値が「YYY」であるとする。
「All apply」モードでは、上述したように、ST001の複製(バージョン002のST001)に関連付けられる全ての旧バージョンのステップBBB及びステップDDDが、それぞれ、新たなバージョン002のステップBBBと新たなバージョン002のステップDDDに差し替えられる。その際、管理プログラム431は、新たなバージョン002のステップBBBに関連付けられるコンポーネント入力プロパティの値を、「Null」から、旧バージョン001のステップBBBに関連付いているコンポーネント入力プロパティの入力値「XXX」に変更し、且つ、新たなバージョン002のステップDDDに関連付けられるコンポーネント入力プロパティの値を、「Null」から、旧バージョン001のステップDDDに関連付いているコンポーネント入力プロパティの入力値「YYY」に変更する。
「Individual apply」モードでは、上述したように、ST001の複製(バージョン002のST001)に関連付けられる旧バージョンのステップBBB及びステップDDDのうち、選択されたステップBBBのみが、新たなバージョン002のステップBBBに差し替えられる。その際、管理プログラム431は、新たなバージョン002のステップBBBに関連付けられるコンポーネント入力プロパティの値を、「Null」から、旧バージョン001のステップBBBに関連付いているコンポーネント入力プロパティの入力値「XXX」に変更する。一方、バージョン変更されなかったステップDDDに関連付いているコンポーネント入力プロパティの入力値は、「YYY」のままである。
このように、STバージョンアップでは、コンポーネントのバージョン変更に伴い、自動で、バージョン変更前のコンポーネントに関連付いているコンポーネント入力プロパティの入力値が、バージョン変更後のコンポーネントに関連付くコンポーネント入力プロパティに引き継がれる。これにより、バージョン変更前のコンポーネントについての入力値と同じ入力値をバージョン変更後のコンポーネントについてユーザが手入力する手間を削減できる。
また、上述したように、本実施形態では、コンポーネントは、典型的にはプラグインコンポーネントであるが、サービステンプレートそれ自体もコンポーネントになり得る。このため、管理プログラム431は、ユーザからの操作に応答して、STに、少なくとも1つのプラグインコンポーネントと少なくとも1つの作成済STとのうちの1以上をそれぞれコンポーネントとして関連付けることが可能である。
このように、作成済STもコンポーネントの1つとしてSTに関連付けることが可能なので、より高度なSTの作成が可能である。以下、STに関連付いている1つのコンポーネントが別のSTの場合、コンポーネントとして関連付けられているSTを「子ST」と言い、子STが関連付けられているSTを「親ST」と言う。なお、こうした親子間の関係を持つサービステンプレートについてバージョンアップをする場合について考える。例えば下記のケースである。
(ケース1)親STと関連付けられたサービステンプレートを指定してバージョンアップする場合。
(ケース2)子STと関連付けられたサービステンプレートを指定してバージョンアップする場合。
何れのケースでも、指定されたサービステンプレートに加えて、関連付けられた親ST又は子STのバージョンアップを併せて行われても良い。しかし、これらサービステンプレートは複製を伴って別々にバージョンアップされることが好ましい。
まず、ケース1である。複製を伴わずにバージョンアップ後のサービステンプレートだけ存在させると仮定した場合、関連付けられた親STはバージョンアップ前の子STが無くなってしまうため強制的にバージョンアップ後のコンポーネントを使用させてしまう。これはこれまで説明してきたことと同様の発生してしまう。そのため複製を伴うことでバージョンアップ前後の両方のサービステンプレートが存在したほうがよい。また、親STが自動的にバージョンアップ後のサービステンプレートに関連付けられてしまう場合も同じ問題が発生する。よって子STのバージョンアップと親STのバージョンアップは別々に行うほうがよい。
次にケース2である。親STのバージョンアップに伴って子STのバージョンアップを行うと仮定した場合、複製を伴わずに子STのバージョンアップを行うと、バージョンアップ前のサービステンプレートが無くなってしまい、他の親STが実行できなくなる、又はユーザがバージョンアップ前のサービステンプレートを使用できないといった問題が発生する。このため、子STのバージョンアップは複製を伴うほうがよい。しかし複数の親STが共通の子STを持ち、さらに親STのバージョンアップで自動的に子STのバージョンアップの複製を伴って行ってしまうと、子STは親STのバージョンアップの度に複製されてしまう。これは例えば子STに関連づいた親STが4つあり、各親STのバージョンアップが5回行われた場合は、子STの複製が4×5=20存在することになり、子STのバージョン管理が難しくなる。よって子STのバージョンアップと親STのバージョンアップは別々に行うほうがよい。なお、上述の複製を伴った別々なバージョンアップの考えについては「All apply」モードと「Individual apply」モード両方について適用してもよい。なお、「Individual apply」モードに対して適用する一例としては、親STのバージョンアップの際に、関連付けられた子STに関連づいたコンポーネントがバージョンアップ対象である旨の表示をしないことが考えられる。
ところで、1つのSTに、複数の同一のコンポーネントが関連付けられることは、既に上述した通りである(例えば、図18には、コンポーネント群中に、コンポーネントとしてST(バージョン005)が存在)。「All apply」モードでも「Individual apply」モードでも、管理プログラム431は、ステップ管理テーブル428を基に、指定STに複数の同一のコンポーネントが関連付けられているか否かを判断することができる。そして、「All apply」モードにおいてその判断結果が肯定の場合、管理プログラム431は、その複数の同一のコンポーネントの各々について、バージョン変更対象とするか否かの選択と、バージョン変更対象とするのであれば変更後のバージョンの指定とを受け付ける。「Individual apply」モードにおいてその判断結果が肯定の場合、管理プログラム431は、その複数の同一のコンポーネントにそれぞれ対応した複数のレコードを含む候補ステップリスト3007(図30参照)を生成し表示することで、複数の同一のコンポーネントの各々について、バージョン変更対象とするか否かの選択と、バージョン変更対象とするのであれば変更後のバージョンの指定とを受け付ける。このような処理を行う1つの理由は、例えば図32〜図34を参照して説明するユースケースがあり得るからである(図32〜図34では、ステップは「(S)」と表記される)。
すなわち、図32に示すように、1つのST(以下、図32〜図34の説明において「対象ST」と言う)が、次のようなステップのフローを定義しているとする。すなわち、(S1)ストレージH8の情報が記述された表が取得され、(S3)前ステップで取得された表が読み出される。一方、(S2)ストレージH9の情報が記述された表が取得され、(S3)前ステップで取得された表が読み出される。そして、(S5)それぞれ読み出された表に記述されている情報がメールで通知される。このように、対象STは、ステップ(S1)、(S2)、(S4)をそれぞれ1つずつ含み、ステップ(S3)を2つ含む。すなわち、対象STには、2つの同一ステップ(S3)が存在する。いずれのステップ(S3)もバージョンは001である。
そして、図33に示すように、ストレージH9の情報が記述される表のフォーマットが変更されたことが理由で(:例えば項目の増減、表中の時刻表示形式の変更等)、そのフォーマット変更に対応したコンポーネント(S3)(バージョン002)が追加されたとする。この時点で、対象STに関連付いている2つのステップ(S3)はいずれも旧バージョンのステップ(コンポーネント)となる。
この状況によれば、ステップ(S2)の次のステップ(S3)は新たなバージョン002のステップ(S3)に変更する必要があるが、ステップ(S1)の次のステップ(S3)はバージョン変更されてはならない。
そこで、「All apply」モードでも「Individual apply」モードでも、図34に示すように、管理プログラム431は、ステップ管理テーブル428を基に、指定ST(対象ST)に複数の同一のステップ(S3)が関連付けられていることを特定し、その複数の同一のステップ(S3)の各々について、バージョン変更対象とするか否かの選択と、バージョン変更対象とするのであれば変更後のバージョンの指定とを受け付ける。このユースケースによれば、管理プログラム431は、ユーザインターフェース経由で、ST作成ユーザから、ステップ(S2)の次のステップ(S3)の選択を、バージョン変更対象のステップの選択として受け、且つ、変更後のバージョン002の指定を受ける。管理プログラム431は、その選択と指定に従い、ステップ(S2)の次のステップ(S3)(バージョン001)をステップ(S3)(バージョン002)に差し替え、ステップ(S1)とステップ(S3)(バージョン001)の関係を維持する。
図35は、STバージョンアップ処理のフローチャートである。
管理プログラム431は、STの指定を、例えばSTリスト画面2700(図27参照)経由で受けた場合、STバージョンアップ画面2800(図28参照)を表示する。そして、管理プログラム431は、「All apply」タブ2801と「Individual apply」タブ2802のいずれかの選択を受ける(P3500)。
「All apply」タブ2801が選択された場合(P3500:YES)、管理プログラム431は、リスト表示するか否かを判断する(P3501)。例えば、「Step list to be applied」ボタン2804が押された場合、又は、指定STに複数の同一ステップが関連付けられていることが特定された場合、P3501の判断結果が肯定になる。一方、例えば、「Apply」ボタン2803が押された場合、P3501の判断結果が否定になる。
P3501の判断結果が否定の場合(P3501:NO)、管理プログラム431は、指定STが関連付いたバージョンアップ要求を受け、その要求に応答して、P3511を行う。すなわち、管理プログラム431は、指定STの複製を生成し、指定STに関連付いているステップ(コンポーネント)のうちの全ての旧ステップ(旧バージョンのステップ)をそれぞれ全ての最新コンポーネント(最新バージョンのコンポーネント)に差し替える。その際、管理プログラム431は、旧ステップのコンポーネント入力プロパティの入力値を、最新コンポーネントのコンポーネント入力プロパティに入力する。また、管理プログラム431は、旧ステップが子STの場合、その旧ステップについてはバージョンアップをせずスキップする。P3511の後、管理プログラム431は、バージョンアップされたSTである新ST(バージョン変更されたコンポーネントが関連付けられているST複製)に関する情報(例えばSTのバージョンアップ後のバージョン)を表示する(P3541)。
P3501の判断結果が肯定の場合(P3501:YES)、管理プログラム431は、指定STに関連付いている旧ステップ(旧バージョンのステップ)のリスト2901を表示する。そして、そのリスト2901からステップが選択され「Apply」ボタン2902が押された場合、管理プログラム431は、指定STと選択されたステップとが関連付いたバージョンアップ要求を受け、その要求に応答して、P3522を行う。すなわち、管理プログラム431は、指定STの複製を生成し、指定STに関連付いているステップ(コンポーネント)のうちの選択された旧ステップ(旧バージョンのステップ)を、最新コンポーネント(最新バージョンのコンポーネント)に差し替える。その際、管理プログラム431は、旧ステップのコンポーネント入力プロパティの入力値を、最新コンポーネントのコンポーネント入力プロパティに入力する。P3522の後、管理プログラム431は、P3541を行う。
「Individual apply」タブ2802が選択された場合(P3500:NO)、管理プログラム431は、ステップ管理テーブル428を参照して、指定STに関連付いているステップのうち複数バージョンが存在するステップを特定し、特定したステップのみのリストをコンポーネントリストプレーン3001に表示する。具体的には、例えば、管理プログラム431が、ステップ管理テーブル428から、最新コンポーネント名1907及び最新バージョン1908が「Null」ではないレコードを特定し、特定したレコードに記載のステップ名1904のリストをコンポーネントリストプレーン3001に表示する(P3531)。このリストから、ST作成ユーザにより、バージョン変更対象のステップ(コンポーネント)が選択された場合、管理プログラム431は、選択されたステップに関する候補ステップリスト3007を表示する(P3532)。そのリスト3007からステップが選択され、バージョン指定プルダウンメニュー3004から変更後のバージョンが指定され、且つ、「Apply」ボタン3005が押された場合、管理プログラム431は、指定ST、選択されたステップ及び変更後のバージョンが関連付いたバージョンアップ要求を受け、その要求に応答して、P3533を行う。すなわち、管理プログラム431は、指定STの複製を生成し、指定STに関連付いているステップ(コンポーネント)のうちの選択された旧ステップ(旧バージョンのステップ)を、指定された変更後バージョンのコンポーネントに差し替える。P3533の後、管理プログラム431は、P3541を行う。
以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
例えば、カスタムUIは、STバージョンアップ画面(例えばIndividual applyモードでのバージョン指定用のUI(例えばテキストフィールドではなくプルダウンメニュー)に適用されてよい。
また、実施形態では、ST種別が「Release」とされる前にSTについてテストが実行され、不具合が発見されなければ、そのSTのST種別が「Release」とされ、その後、ST種別「Release」に対応したSTの編集は不可とされる。しかし、ST種別が「Release」とされた後にそのSTについて何らかの不具合が発見された場合、そのSTの複製を生成し、そのSTの複製に対応するST種別を「Debug」として、そのSTの複製を改善することが行われてもよい。つまり、ST種別が「Release」とされた後であっても、そのSTの複製を作成することで改善が可能であってよい。
また、例えば、STバージョンアップ処理では、管理プログラム431は、指定STの複製を、必ずしもP3511、P3522及びP3533にて行う必要はなく、それよりも前(例えば、P3500の前)に行ってもよい。例えば、図27の「Update」ボタン2703が押されたことを契機に、管理プログラム431が、指定STの複製を作成し、図28の画面を表示してもよい(指定STの複製を作成した後に、「All apply」モードと「Individual apply」モードの選択を受け付けてもよい)。