JP6096392B2 - サービスを作成する管理システム及び管理方法 - Google Patents

Description

本発明は、概して、運用対象装置の運用自動化技術に関する。

近年の計算機システムは大規模化しており、それに伴い、計算機システムを構成し、運用対象となる装置（運用対象装置）の運用の手間も増えている。自動化技術はこのような運用対象装置の管理及び保守（以後はまとめて運用と呼ぶ）を自動化する技術である。特許文献１に開示の技術ではこうした自動化技術を実現した管理システムに於いて、特定の運用対象装置（群）に対する運用内容を、運用項目に分割し、各運用項目にアイコンを割り当てて表示させることが開示されている。

WO2013/140609

特許文献１では運用項目が汎用化されていないため、ユーザが自動実行できる運用内容に限りがあり、結果としてユーザの運用コストは軽減できない。

１以上の運用対象装置を含む運用対象システムに接続された管理システムが、（１）部品入力プロパティと、部品入力プロパティに入力された入力値に基づいて実行する処理内容を含む部品を複数管理し、（２）１以上の部品と実行順序と共に関連付けられ、１以上のテンプレート入力プロパティを含むサービステンプレートを作成又は編集し、（３）サービステンプレートと、テンプレート入力プロパティに入力する入力値の指定を受信し、（４）指定された入力値とサービステンプレートに基づいて、部品に含まれる処理内容を指定された入力値で実行するための運用サービスを生成し、（５）生成した運用サービスを実行することで、運用対象装置を運用する。

ユーザが自動実行可能な運用内容が増えるため、ユーザの運用コストが削減できる。

実施形態の第１の概要を示す 実施形態の第２の概要を示す。 実施形態に係るシステム全体の構成を示す。 管理サーバの構成を示す。 管理クライアントの構成を示す。 部品管理テーブルの構成を示す。 部品プロパティ管理テーブルの構成を示す。 ＳＴ（サービステンプレート）管理テーブルの構成を示す。 フロー管理テーブルの構成を示す。 ＳＴプロパティ管理テーブルの構成を示す。 サービス管理テーブルの構成を示す。 サービスプロパティ設定テーブルの構成を示す。 ＳＴ入力プロパティとＳＴ出力プロパティの関係の一例を示す。 図１３のＳＴに対応したサービス作成画面の一例である。 ＳＴ作成画面の一例を示す。 バージョン毎の関連ＳＴリストの一例を示す。 サービス作成画面の具体例を示す。 カスタムＵＩのバリエーションを示す。 カスタムＵＩの別のバリエーションを示す。 部品インポート処理のフローチャートである。 ＳＴ編集処理のフローチャートである。 ＳＴ確定処理のフローチャートである。 関連ＳＴ表示処理のフローチャートである。 サービス作成画面表示処理のフローチャートである。 サービス実行処理のフローチャートである。 ＵＩ変更処理のフローチャートである。

以下、一実施形態を説明する。なお、以下に説明する実施形態は請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

また、以下の説明では、「ｋｋｋテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「ｋｋｋテーブル」のうちの少なくとも１つを「ｋｋｋ情報」と呼ぶことができる。また、テーブルの構成は一例であり、２以上のテーブルが１つのテーブルにまとめられたり、１つのテーブルが複数のテーブルに分割されたりしてもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェイスデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウエア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記憶メディアであってもよい。

また、以下の実施形態では、計算機システムを管理する第１の管理システム（以下、計算機管理システム）と、システム運用の自動化を支援する第２の管理システム（以下、運用自動化システム）とがある。しかし、計算機管理システムと運用自動化システムは１つの管理システムであってもよい。また、計算機管理システムは運用対象装置に含まれていてもよい。

また、以下の説明において、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合（具体的には、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合）、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。本実施形態では、運用自動化システムの管理サーバが管理計算機であり、運用自動化システムの管理クライアントが表示用計算機である。

また、管理計算機は、表示システムを含むＩ／Ｏシステムに接続されたインターフェースデバイスと、情報を記憶する記憶資源（例えばメモリ）と、インターフェースデバイス及び記憶資源に接続されたプロセッサとを有する。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。Ｉ／Ｏシステムは、管理計算機が有するＩ／Ｏデバイス（例えばキーボード及びポインティングデバイス、タッチパネル）でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。また、管理計算機が情報を入出力するとは、管理計算機が有するＩ／Ｏデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機（例えば表示用計算機）との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。

また、以下の説明において、要素の識別情報として、「ｕｋ（ユニークキー）」、「キー名」という表現を用いるが、これらのうちの少なくとも１つに代えて又は加えて他種の識別情報（例えば番号）が使用されてもよい。

図１は、実施形態の第１の概要を示す。図２は、実施形態の第２の概要を示す。

運用自動化システムは、システム運用の多数の部品を管理する。ここで、「システム運用」とは、計算機システムの運用のことである。「部品」とは、システム運用の一部分であり、１つの独立した処理（業務）である。部品は、例えば、スクリプトを実行する処理モジュールであり、実行ファイルでよい。部品は、運用自動化システムに予め設けられるが、これに限らず、後から運用自動化システムに追加することもできる。部品は、例えば、ストレージ装置の構成変更（例えば論理ボリュームの作成）を実行させる部品でよいが、これに限らず、部品同士を組み合わせるために使用する部品、汎用的に使用可能な部品などがあってもよい。例えば、部品としては、繰り返し実行するためのソフトウェア部品、ファイル転送部品、ファイル実行部品などがあってもよい。

なお、運用自動化システムの外部より部品（パッケージ）がダウンロードされインポートされる場合、運用自動化システムのユーザが部品を作成又は改善する場合、又はサービステンプレートが部品とされる場合、といったことが考えられるが、これ以外で運用自動化システムにて部品がインポートされてもよい。ちなみに部品の改善例として、（１）部品内部の不具合の修正、（２）内部処理効率の改善、（３）部品が運用対象とする装置が変更された（例えば、ある装置の管理をするコマンドの仕様が変わったので、そのコマンドを実行する部品も変える必要が出た）、（４）部品が運用対象とする装置が増えた（例えば、第１のベンダーの装置に加えて新たに第２ベンダーの装置も運用できるようになった）、（５）部品の入出力プロパティ数が増減した、（６）部品の入出力プロパティに与える値のフォーマットが変更された、（７）部品に関連付けられているデフォルト値が変更又は追加された、（８）部品として処理できることが増加又は処理効率の改善、のうちの少なくとも１つが考えられる。

運用自動化システムは、多数の部品（部品群）を管理する。本実施形態では、多数の部品のうちの２以上の部品を基にサービステンプレート（ＳＴ）が作成され、作成されたＳＴを基にサービスが作成され、作成されたサービスが実行される。以下、部品管理、ＳＴ作成、ＳＴ確定、サービス作成及びサービス実行の概要を説明する。

＜部品管理＞

運用自動化システムは、多数の部品（部品群）を管理する。部品は、部品提供ユーザにより追加又は編集されてよい。運用自動化システムは、部品毎に、部品に関連付けられる１以上の部品プロパティを管理する。また、運用自動化システムは、部品毎に、部品のバージョンを管理する。図１では、部品ＢＢＢを例に取って、部品プロパティ及びバージョンを示しているが、別の部品にも、その別の部品の部品プロパティ及びバージョンが関連付けられている。

「部品プロパティ」とは、部品のプロパティである。部品プロパティとして、部品入力プロパティと部品出力プロパティの２種類がある。部品入力プロパティは、定義された項目（表示名）についての値の入力に関するプロパティであり、部品出力プロパティは、定義された項目（表示名）についての値の出力に関するプロパティである。１つの部品に、１以上の部品入力プロパティと０以上の部品出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、部品によっては、出力プロパティが０個の場合もあるが、入力プロパティは、各部品につき１個以上関連付けられている。入力値は、例えば、過去に作成されたサービスのプロパティとして入力された値のコピーであってもよいし、実行済みの他の部品について出力された値のコピーであってもよい。出力値は、部品実行後の構成情報等でよい。

バージョン００１の部品ＢＢＢと、バージョン００２の部品ＢＢＢがそれぞれ管理されている。すなわち、同一部品でも「バージョン」が異なれば、異なる部品のように扱われる。別の言い方をすれば、部品が更新（例えば改善）されても、更新後の部品が更新前の部品に上書きされることなく、更新前の部品とは別に更新後の部品が管理される。部品が更新された場合にいわゆるソフトウェアの更新のように更新前の部品が自動で更新後の部品に置き換わると、運用自動化においてトラブルの原因となり得る。特に、更新前の部品が既に作成されたサービスの要素の場合には、トラブルの原因となる可能性が高い。そこで、本実施形態では、運用自動化システムは、部品が更新された場合、更新後の部品の第１種の識別情報（例えば部品名）を更新前の部品の第１種の識別情報と同じとするが、更新後の部品のバージョン及び第２の識別情報（例えば部品ｕｋ（部品ユニークキー））のうちの少なくとも１つを、更新前の部品のバージョン及び第２の識別情報と違う値とする。これにより、運用自動化システムは、更新後の部品を更新前の部品と別部品のように管理できる。

「部品提供ユーザ」とは、部品の作成、追加又は更新等を行う運用自動化システムのユーザである。部品提供ユーザは、例えばＧＵＩ（Graphical User Interface）、ＣＬＩ（Common Language Infrastructure）、ＡＰＩ（Application Programming Interface）などを介して、部品を作成、追加、又は更新等行うことができる。

＜ＳＴ作成＞

運用自動化システムが、ＳＴ作成画面を表示する。ＳＴ作成画面に、情報の入力ＵＩが表示される。ＳＴ作成ユーザが、ユーザ操作により、ＳＴ作成画面に情報を入力する。例えば、運用自動化システムは、ＳＴ作成画面を介して、多数の部品のうちの２以上の部品の選択と、２以上の部品の実行順序の指定とを受け付ける。運用自動化システムが、選択された２以上の部品と指定された実行順序とに基づきサービスフローのサービステンプレートを作成する。

「ＳＴ作成ユーザ」とは、サービステンプレートを作成するユーザである。ＳＴ作成ユーザは、上述のように、ＳＴ作成画面を用いてサービステンプレートを作成する。ＳＴ作成ユーザは、部品提供ユーザと同一であってもよいし異なっていてもよい。

「ユーザ操作」とは、画面に対してユーザが入力デバイスを使用して行う操作である。ユーザ操作に使用される入力デバイスは、一般に、ポインティングデバイス（例えばマウス）とキーボードの組合せ、又は、タッチスクリーンである。画面を介した入力は、ユーザ操作により行われる。

「サービステンプレート」とは、サービスのテンプレートである。本実施形態では、サービステンプレートが「ＳＴ」と略記されることもある。

「サービスフロー」とは、典型的には、選択された２以上の部品の並びである。部品の並びは、指定された実行順序に従う。選択された部品の数が１つだけの場合、サービスフローを構成する部品の数も１つである。

上述のように、運用自動化システムは、ＳＴ作成画面を介して選択された２以上の部品及び指定された実行順序を基にサービステンプレートを作成する。具体的には、例えば、運用自動化システムは、選択された２以上の部品に関連付けられている複数の部品プロパティ（例えば部品プロパティ００１及び００２）にそれぞれ対応した複数のＳＴプロパティ（例えばＳＴプロパティ００Ａ及び００Ｂ）を作成し、作成した複数のＳＴプロパティをサービステンプレート（例えばＳＴ００１）に関連付ける。部品プロパティに対応したＳＴプロパティは、その部品プロパティを基に運用自動化システムにより自動作成される。ＳＴプロパティの作成中又は作成後にユーザ操作により入力された値がＳＴプロパティに含まれてもよいが、ユーザ操作による入力（つまり手動入力）無しにＳＴプロパティが作成されてよい。「ＳＴプロパティ」とは、ＳＴのプロパティである。ＳＴプロパティとして、ＳＴ入力プロパティとＳＴ出力プロパティの２種類がある。ＳＴ入力プロパティは、定義された項目（表示名）についての値の入力に関するプロパティであり、ＳＴ出力プロパティは、定義された項目（表示名）についての値の出力に関するプロパティである。１つのサービステンプレートに、１以上のＳＴ入力プロパティと０以上のＳＴ出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、ＳＴ出力プロパティが必ず１個あるとは限らない。

図１の例では、サービスフローは、部品ＢＢＢ「Provisioning volume」（ストレージ装置に論理ボリュームを作成する）と、部品ＤＤＤ「Create pair volume」（論理ボリューム（プライマリボリューム）とペアになる論理ボリューム（セカンダリボリューム）を作成する）の組合せであり、そのサービスフローのサービステンプレート（ＳＴ００１）が作成されたとする。

＜ＳＴ確定＞

運用自動化システムは、作成されたサービステンプレートについて、ユーザ操作により確定を受けた場合、その作成されたサービステンプレートのＳＴ種別を「Release」として管理する（図２参照）。ＳＴ種別「Release」は、サービステンプレートが確定しており、そのサービステンプレートを基にサービスを作成することが可能であることを意味する。一方、確定していないサービステンプレートは、ＳＴ種別「Debug」である。ＳＴ種別「Debug」は、サービステンプレートが編集中であることを意味する。なお、運用自動化システムは、サービス実行において、ＳＴ種別「Debug」のサービステンプレートの選択を受け付けないようにしてもよい（例えば、ＳＴ種別「Debug」のサービステンプレートを、選択可能に表示しない（ディスエーブル））。その一例としては、後述するサービス作成ユーザは、ＳＴ種別が「Release」であるサービステンプレートだけサービスの作成を可能とし、サービステンプレート作成ユーザは、テスト目的もあるため、ＳＴ種別が「Release」と「Debug」両方でサービス作成を可能としてもよい。なお、こうした処理を実現するため、運用自動化システムはユーザ認識を行っていることは言うまでも無い。

＜サービス作成＞

運用自動化システムは、作成済のサービステンプレートを管理する。運用自動化システムは、ＳＴ種別「Release」のサービステンプレートのうちのいずれかのサービステンプレートの選択をサービス作成ユーザから受け、選択されたサービステンプレートを基にサービス作成画面を表示する。サービス作成ユーザが、ユーザ操作により、サービス作成画面に情報を入力する。運用自動化システムは、サービス作成画面を介して入力された情報を基にサービスを作成する。

「サービス作成ユーザ」とは、サービスを作成（実行）するユーザである。サービス作成ユーザとＳＴ作成ユーザは異なるユーザであってもよいし同一ユーザであってもよい。

「サービス」とは、インスタンス化されたサービステンプレートである。具体的には、サービステンプレートは、サービスの実行に必要な値がブランクとなっており、その必要な値がサービステンプレートに入力されたものが、サービスである。なお、前述のサービスの実行に必要な値については、デフォルト値がＳＴのプロパティの情報として設定できる場合もある。

なお、サービスは運用に関係するものであることを表すために「運用サービス」と記載する場合がある。なお、特定の状況に於いては「サービス」は、ユーザが指定した運用対象装置に対して行うべき運用処理を示しているとも言える。例えば、図１３の例でＳＴ入力プロパティ１３０４Ｃを指定した場合はこの表現に該当する。また、部品自体に指定する運用対象装置を埋め込んだり、部品の入力プロパティのデフォルト値として与えたりしない場合は、「サービス」と「サービステンプレート」間の別な見方として、「サービス」が示す処理内容では入力値の定めにより構成変更や情報取得先として指定する運用対象装置が明確になっている一方で、「サービステンプレート」では指定する運用対象装置が不明であるとも言える。

なお、運用自動化システムは、作成されたサービスに、サービスプロパティを関連付けらよい。「サービスプロパティ」とは、サービスの入力・出力プロパティ（入力及び出力のうちの少なくとも一方のプロパティ）である。サービスの入力・出力プロパティには、サービス作成においてサービステンプレートに入力された値と、サービス実行において部品から出力された値とのうちの少なくとも１つが設定される。具体的には、例えば、サービスの実行では、サービス作成において入力プロパティに入力された値が、そのサービスのサービステンプレートに関連付けられている部品に入力されて、処理が実行されてよい。また、部品から出力された値が、サービスの出力プロパティに設定されることで、サービスの実行結果画面において、その設定された値（例えば、部品が実行された後の構成情報等）が表示されてよい。

＜サービス実行＞

運用自動化システムが、作成したサービスの実行の命令を、計算機管理システムに送信する。計算機管理システムが、その命令に従い、サービスを実行する。

以上が、部品管理、ＳＴ作成、サービス作成及びサービス実行の各々の概要である。

複数のＳＴプロパティのうちの少なくとも１つのＳＴ入力プロパティの各々に、カスタムＵＩを定義した情報であるカスタムＵＩ生成情報が関連付けられている。但し、デフォルトＵＩに関しては、カスタムＵＩ生成情報は「Null」（デフォルトＵＩ用の情報）である。カスタムＵＩ及びデフォルトＵＩについては後述する。また、図面では、「カスタムＵＩ生成情報」を、「カスタムＩｎｆｏ．」のように略記することもある。ＳＴプロパティのカスタムＵＩ生成情報は、そのＳＴプロパティに対応した部品プロパティに関連付けられているＵＩ生成情報（例えば、ＵＩの生成に必要な情報を含んだ情報）である。複数の部品プロパティのうちの少なくとも１つの部品入力プロパティの各々に、カスタムＵＩ生成情報が関連付けられている場合がある。

運用自動化システムは、ＳＴ作成画面及びサービス作成画面等の画面を、一連の流れにおいて表示することができる。少なくとも１つの画面には、ＵＩが表示される。本実施形態において、ＵＩは、画面に表示される１つの要素である。１以上のＵＩを含んだ画面をＧＵＩと呼ぶこともできる。なお、以後の説明ではＵＩを「ＵＩ要素」と呼ぶことがある。

＜ＵＩの生成及び表示＞

本実施形態では、運用自動化システムは、少なくともサービス作成画面に表示されるＵＩを、例えば次のように生成する。

すなわち、運用自動化システムは、選択されたサービステンプレートの複数のＳＴプロパティにそれぞれ対応した複数のカスタムＵＩ生成情報を基に、複数のＵＩをそれぞれ生成する。運用自動化システムは、生成した複数のＵＩを１つのサービス作成画面に表示する。本実施形態では、１つのカスタムＵＩ生成情報を基に１つのＵＩが生成される。つまり、カスタムＵＩ生成情報とＵＩの関係は、１：１である。しかし、カスタムＵＩ生成情報とＵＩの関係は、ｎ：１でもよいし、１：ｎでもよいし、ｍ：ｎでもよい（ｍとｎは２以上の整数）。

このようなＵＩ生成によれば、例えば、部品ＢＢＢと部品ＤＤＤで構成されたサービスフローのうち部品ＤＤＤが部品ＥＥＥと入れ替えられても、部品入れ替え後のサービス作成画面に表示されるＵＩとして、部品ＤＤＤに代えて部品ＥＥＥのＵＩが生成され表示される。このように、ＵＩの生成が効率的である。

＜カスタムＵＩ＞

また、本実施形態では、ＵＩとして、デフォルトＵＩに代えて又は加えて、カスタムＵＩが用意されている。

「デフォルトＵＩ」は、テキストフィールドのkey-value形式でのＵＩであり、具体的には、ＳＴプロパティ（部品プロパティ）の表示名と、テキストフィールドとの組である。なお、デフォルトＵＩにてテキストフィールドが採用される理由は、幅広い入力形式に対応できることが理由である。ＳＴプロパティ（部品プロパティ）の表示名（入力項目）に関わらず、テキストフィールドが表示される。従って、ユーザは、表示名を見て、入力する値又は名称等の情報を考えなければならず、そして、その情報をキータイプによりテキストフィールドに入力する必要がある。このため、タイプミス等の誤入力が生じ得る。また、ＳＴプロパティ（部品プロパティ）に無効な値や名称等があってもそのような無効な値や名称等が入力されるおそれもある。また、ユーザに高い知識が必要とされ得る。

それに対し、「カスタムＵＩ」は、テキストフィールドのkey-value形式でのＵＩではなく、ユーザビリティが考慮されたＵＩである。例えば、カスタムＵＩは、ＳＴプロパティ（部品プロパティ）の表示名と、プルダウンメニュー、チェックボックス及びラジオボタン等のうちの少なくとも１つのような、１以上のＧＵＩ要素（ウィジェット）とを含んだＵＩである。このため、デフォルトＵＩに比べて、誤入力は生じないし、ユーザに高い知識が必要とされない。なお、カスタムＵＩも、テキストフィールドを含んでよいが、デフォルトＵＩのようなＵＩ（テキストフィールドのkey-value形式でのＵＩ）よりもユーザビリティの高いＵＩ（例えば、テキストフィールドの近傍に表示される無効な値や名称等のリストを含んだＵＩ）である。

図１の例によれば、１つのサービス作成画面において、デフォルトＵＩ（表示名：ＬＵＮと、テキストフィールドとの組）と、カスタムＵＩ（表示名：Volume Capacityと、ボリューム容量のプルダウンメニューと、ボリューム容量の単位（例えばＭＢ（メガバイト））のプルダウンメニューとの組）が混在している。

このように、本実施形態では、全てのＵＩが、カスタムＵＩである必要は無い。カスタムＵＩが関連付いていない部品とカスタムＵＩが関連付いた部品とが１つのサービスフローに混在しても、サービス作成画面では、デフォルトＵＩの他にカスタムＵＩも定義通り表示される。システム運用の部品は多数存在するので、全てのＵＩをカスタムＵＩにしてから部品提供するとなると、運用自動化システムのベンダーが自社製品を提供するまでに時間がかかる。本実施形態によれば、カスタムＵＩのカスタムＵＩ生成情報が関連付いていない部品が早期に提供されたり、ＳＴ作成ユーザが部品を独自に作成してサービステンプレートに組み込んだりしても、サービス作成ユーザが、サービス作成においてカスタムＵＩの恩恵を受けることができる。

なお、部品プロパティ（ＳＴプロパティ）にカスタムＵＩが追加された場合、及び、古いカスタムＵＩから新しいカスタムＵＩに変わった場合でも、画面に表示されるＵＩは、変更前のＵＩ（すなわち、デフォルトＵＩ又は古いカスタムＵＩ）とされる。具体的には、例えば、運用自動化システムは、既存のＳＴに関連付いている部品のＵＩの変更要求を受け付けた場合、ＵＩの変更要求を受けた部品のコピーを作成（既存の部品を基にバージョンの異なる新たな部品を作成）し、ＵＩを変更した部品を作成する。次に、既存のＳＴのコピーを作成し（既存のＳＴを基にバージョンの異なる新たなＳＴを作成）、その作成した新しいＳＴに、既存の部品とバージョンが異なる新しい部品を入れ替える。既存のＳＴで使用されている部品に関連付いているＵＩを自動的に変更してしまうと、元々はうまく使えていたＳＴが使えなくなる可能性がある（例えば、元々は入力できていた値が入力できなくなった等）。本実施形態によれば、使用可能なＳＴに悪影響を及ぼさずに部品のＵＩの入れ替えが可能となる。

また、作成済のサービステンプレートに関連付いている部品の部品プロパティに関連付いたＵＩが変更されて新規部品が追加されても、運用自動化システムは、そのサービステンプレートに基づくサービス作成画面において、既存の部品を使用して変更前のＵＩを表示する。これにより、サービステンプレートの作成後に関連するＵＩが変更されることで元々入力可能だった値の入力が不可能になるといったおそれを回避できる。変更前のＵＩの生成及び表示を維持する具体例は、図２６を参照して説明する。

＜部品バージョンと関連ＳＴの表示＞

運用自動化システムは、図１を参照して説明したように、部品のバージョンと、そのバージョンの部品が関連付いたサービステンプレート（関連ＳＴ）との関係を管理する。サービス作成又はサービス作成開始前等において、運用自動化システムは、図２に示すように、部品（例えば部品ＢＢＢ）の選択をユーザから受けた場合に、選択された部品のバージョン毎に、関連ＳＴリストを表示する。関連ＳＴリストは、関連ＳＴ毎に、関連ＳＴの情報（例えば、ＳＴ名、ＳＴバージョン及びＳＴ種別）を有する。これにより、下記の（Ａ）乃至（Ｂ）のうちの少なくとも１つを実現し得る。
（Ａ）更新後の部品がインポートされた場合、更新前の部品を選択することで、ユーザは、更新前の部品についてのバージョン毎の関連ＳＴリストから、更新前の部品について関連ＳＴの有無がわかる。また、更新前の部品に関連ＳＴがあれば、その関連ＳＴのＳＴ種別もわかる。ユーザは、関連ＳＴの有無及びＳＴ種別を基に、既存のサービステンプレートに関連付いている部品を、更新後の部品に入れ替えるか否かを判断できる。例えば、更新前の部品について関連ＳＴが存在しなければ、ユーザは、ＳＴに関連付いている部品を更新後の部品に置換することは不要であると判断できる。また、例えば、更新前の部品（例えばバージョン００１の部品ＢＢＢ）についてＳＴ種別「Release」の関連ＳＴが存在していれば、ユーザは、その関連ＳＴに関連付いている更新前の部品を更新後の部品に入れ替えると不具合が生じ得ること、及び、それ故に更新前の部品を更新後の部品に入れ替えた新たなＳＴを作成することとを、判断できる。また、例えば、更新前の部品について関連ＳＴが存在するもののＳＴ種別「Release」の関連ＳＴが存在していなければ（例えばバージョン００２の部品ＢＢＢ）、ユーザは、関連ＳＴに関連付いている更新前の部品を更新後の部品に入れ替えても良いことを判断できる。
（Ｂ）ユーザは、選択した部品（例えば部品ＢＢＢ）についてのバージョン毎の関連ＳＴリストから、選択した部品について関連ＳＴの有無と、関連ＳＴのＳＴ種別がわかる。ユーザは、関連ＳＴの有無及びＳＴ種別を基に、選択した部品を更新することによる影響（例えば、新たなバージョンの部品とすることの必要性、関連ＳＴに関連付いている部品の交換の必要性、新たにＳＴを作成することの必要性等）を判断できる。例えば、選択した部品についてＳＴ種別「Release」の関連ＳＴが存在していなければ、ユーザは、選択した部品のバージョンを変更すること無しに部品を更新して良い（つまりバージョンの異なる部品を追加するのではなく部品それ自体を入れ替えてよい）と判断できる。また、例えば、選択した部品についてＳＴ種別「Release」の関連ＳＴが存在していれば、ユーザは、選択した部品について新たなバージョンの部品を更新後の部品とする必要があると判断できる。

通常、部品が更新されても（バージョンアップされても）、確定したサービステンプレートに関連付いている部品を更新後の部品に入れ替えることは避けることが望ましい。本実施形態によれば、上述の通り、各バージョンの部品がどのサービステンプレートに関連づいているのかのリストが表示される。このため、更新後の部品に入れ替えられるべき又は入れ替えられてはならない部品が関連付いているサービステンプレートがどれであるかの判断が容易である。

以上が、実施形態の概要である。以下、実施形態を詳細に説明する。

図３は、実施形態に係るシステム全体の構成を示す。

計算機システム３１０に、計算機管理システム３０２が接続されており、計算機管理システム３０２に運用自動化システム３０１が接続されている。運用自動化システム３０１は計算機管理システム３０２と一体でもよい。

計算機システム３１０は、１以上のホスト計算機（以下、ホスト）３０３と、１以上のストレージ装置３０４とを含む。ホスト３０３とストレージ装置３０４は通信ネットワーク３０６を介して接続されている。ホスト３０３は、ストレージ装置３０４に接続されたＩ／Ｆ（通信インターフェースデバイス）と、メモリのような記憶資源と、それらに接続されたプロセッサとを有する。ストレージ装置３０４は、１以上のＰＤＥＶ（物理記憶デバイス）と、１以上のＰＤＥＶに接続されたコントローラとを有する。コントローラは、ホスト３０３に論理ボリュームを提供する。ホスト３０３は、提供された論理ボリュームを指定したＩ／Ｏ（Input/Output）要求をストレージ装置３０４に送信する。ストレージ装置３０４のコントローラが、そのＩ／Ｏ要求に従い、論理ボリュームに対するデータＩ／Ｏを行う。Ｉ／Ｏ対象のデータが、論理ボリュームのＩ／Ｏ先領域に基になっている１以上のＰＤＥＶに対して入出力される。なお、ホスト３０３とストレージ装置３０４とは運用対象装置の一例である。

計算機管理システム３０２は、計算機システム３１０を管理する管理システムである。計算機管理システム３０２は、運用自動化システム３０１からの命令に従いサービスを実行する。サービス実行では、例えば、ストレージ装置３０４に論理ボリュームを作成すること、及び、ストレージ装置３０４にセカンダリボリュームを作成することが行われる。

運用自動化システム３０１は、システム運用の自動化を支援する管理システムである。運用自動化システム３０１は、管理サーバ３１１と、管理サーバ３１１に接続された管理クライアントとを有する。管理サーバ３１１が管理クライアント３１２に送信した表示用情報を基に、管理クライアント３１２により情報が表示される。つまり、管理サーバ３１１が管理クライアント３１２を介して情報を表示する。

具体的には、例えば、管理サーバ３１１は、部品と関連ＳＴとの関係を特定し（Ｐ１１）、部品のバージョン毎の関連ＳＴリストを表示する（Ｐ１２）。

また、例えば、管理サーバ３１１は、ＳＴ作成画面を表示し（Ｐ２１）、ＳＴ作成ユーザからＳＴ作成画面を介してＳＴの作成（編集を含む）を受け付ける（Ｐ２２）。管理サーバ３１１は、確定したＳＴに基づきサービス作成画面を表示する（Ｐ２３）。管理サーバ３１１は、サービス作成ユーザからサービス作成画面を介して情報を受け、入力された情報を基にサービスを作成し保持する（Ｐ２４）。管理サーバ３１１は、サービスの編集のための画面を表示し（Ｐ２５）、サービスの編集を受け付けることもできる。管理サーバ３１１は、作成（編集を含む）されたサービスの実行画面を表示する（Ｐ２６）。管理サーバ３１１は、サービス実行画面を介してサービスの実行をサービス作成ユーザから受け付け、受け付けたサービスの実行の命令を、計算機管理システム３０２に送信する（Ｐ２７）。

図３に示した処理Ｐ１１、Ｐ１２及びＰ２１〜Ｐ２７の各処理群（１以上の処理）が、プログラム群（１以上のコンピュータプログラム）がプロセッサにより実行されることにより行われる。

図４は、管理サーバ３１１の構成を示す。

管理サーバ３１１は、通信ポート４１４（Ｉ／Ｆの一例）、メモリ４１２（記憶資源の一例）、及び、それらに接続されたプロセッサ（典型的にはＣＰＵのようなマイクロプロセッサ）４１１を有する。管理サーバ３１１は、通信ポート４１４を介して、少なくとも計算機管理システム３０２及び管理クライアント３１２と通信する。

メモリ４１２は、半導体メモリに限らずハードディスクドライブでもよい。メモリ４１２は、コンピュータプログラムと管理テーブルを記憶する。具体的には、例えば、メモリ４１２は、部品管理テーブル４２１、部品プロパティ管理テーブル４２２、ＳＴ管理テーブル４２３、フロー管理テーブル４２４、ＳＴプロパティ管理テーブル４２５、サービス管理テーブル４２６、サービスプロパティ設定テーブル４２７、及び、管理プログラム４３１を記憶する。管理プログラム４３１が、プロセッサ４１１により実行され、それにより、例えば図３に示した処理Ｐ１１、Ｐ１２、Ｐ２４及びＰ２７を行う。

図５は、管理クライアント３１２の構成を示す。

管理クライアント３１２は、通信ポート５１４（Ｉ／Ｆの一例）、入出力デバイス５１３、メモリ５１２（記憶資源の一例）、及び、それらに接続されたプロセッサ（典型的にはＣＰＵのようなマイクロプロセッサ）５１１を有する。

メモリ５１２は、半導体メモリに限らずハードディスクドライブでもよい。メモリ５１２は、表示プログラム５３１を記憶する。表示プログラム５３１が、プロセッサ５１１により実行され、それにより、例えば図３に示した処理Ｐ１２、Ｐ２１、Ｐ２３、Ｐ２５及びＰ２６を行う。

以下、管理サーバ３１１が有する管理情報（テーブル４２１〜４２７）の構成を説明する。

図６は、部品管理テーブル４２１の構成を示す。

部品管理テーブル４２１は、部品に関する情報を有する。部品管理テーブル４２１は、部品毎にレコードを有し、各レコードに、管理番号６０１、部品名６０２、バージョン６０３、実行ファイルパス６０４、及び部品ｕｋ６０５が格納される。管理番号６０１は、レコードの通し番号である。部品名６０２は、部品の名称である。バージョン６０３は、部品のバージョンを表す。実行ファイルパス６０４は、部品の実行ファイルへのパス（パス名）を表す。部品ｕｋ６０５は、部品のユニークキー（番号）である。ｕｋは、識別情報の一例である。

図６から分かるように、バージョンが異なる同一部品は、部品名６０２が同じであり（例えば、「Provisioning Volume」）、バージョン６０３が異なる（例えば「01.00.00」、「01.10.00」）。つまり、バージョンが異なる同一部品は、別々の部品として管理される。しかし、複数の部品の部品名６０２が同一であれば、それら複数の部品のオリジナルは同一であることがわかる。

図７は、部品プロパティ管理テーブル４２２の構成を示す。

部品プロパティ管理テーブル４２２は、部品プロパティに関する情報を有する。部品プロパティ管理テーブル４２２は、部品プロパティ毎にレコードを有し、各レコードに、管理番号７０１、部品ｕｋ７０２、表示名７０３、キー名７０４、初期値７０５、入出力タイプ７０６、プロパティグループ７０７及びカスタムＵＩ生成情報７０８が格納される。

管理番号７０１は、レコードの通し番号である。部品ｕｋ７０２は、部品のユニークキーである。表示名７０３は、画面に表示される部品プロパティ名であり、例えば入力項目又は出力項目に相当する。

キー名７０４は、部品プロパティを一意に特定するための名称であり、部品プロパティの識別情報の一例である。初期値７０５は、生成されたＵＩに予め設定される値である。初期値７０５「Null」は、初期値が存在しないことを意味する。つまり、ＵＩが表示されたとき、入力欄又は出力欄がブランクである。

入出力タイプ７０６は、部品プロパティが部品入力プロパティであるか部品出力プロパティであるか（言い換えれば、ＵＩ上の値が入力値であるか出力値であるか）区別するための情報である。入出力タイプ７０６の値は、対応する部品プロパティが部品入力プロパティの場合に「In」であり、対応する部品プロパティが部品出力プロパティの場合に「Out」である。

プロパティグループ７０７は、部品プロパティが属するプロパティグループの名称を示す。すなわち、本実施形態では、少なくとも１つのプロパティグループが存在し、プロパティグループに、１以上の部品プロパティと、１以上のＳＴプロパティ（例えば、その１以上の部品プロパティにそれぞれ対応する１以上のＳＴプロパティ）とのうちの少なくとも一方が関連付けられる。プロパティグループ７０７の値「Null」は、対応する部品プロパティがいずれのプロパティグループにも属さないことを意味する。

カスタムＵＩ生成情報７０８は、生成されるカスタムＵＩの種別を表す。カスタムＵＩ生成情報７０８の値「Null」は、カスタムＵＩ生成情報がデフォルトＵＩ用の情報であることを意味する。

図８は、ＳＴ管理テーブル４２３の構成を示す。

ＳＴ管理テーブル４２２は、サービステンプレートに関する情報を有する。ＳＴ管理テーブル４２３は、ＳＴ毎にレコードを有し、各レコードに、管理番号８０１、ＳＴ名８０２、ＳＴバージョン８０３、ＳＴ ｕｋ８０４、フローｕｋ８０５及びＳＴ種別８０６が格納される。

管理番号８０１は、レコードの通し番号である。ＳＴ名８０２は、サービステンプレートの名称である。ＳＴバージョン８０３は、サービステンプレートのバージョンである。ＳＴ ｕｋ８０４は、サービステンプレートのユニークキーである。フローｕｋ８０５は、サービステンプレートに対応するサービスフローのｕｋである。ＳＴ種別８０６は、サービステンプレートの種別を表す。ＳＴ種別８０６の値「Debug」は、サービステンプレートが編集可能であることを意味し、ＳＴ種別８０６の値「Release」は、サービステンプレートが確定していること（編集不可）であることを意味する。

図８から分かるように、バージョンが異なる同一ＳＴは、ＳＴ名８０２が同じであり（例えば、「Provisioning & Pair」）、ＳＴバージョン８０３が異なる（例えば「01.00.00」、「01.10.00」）。つまり、ＳＴバージョンが異なる同一ＳＴは、別々のＳＴとして管理される。しかし、複数のＳＴのＳＴ名８０２が同一であれば、それら複数のＳＴのオリジナルは同一であることがわかる。

上述したように、ＳＴに関連付いている部品のバージョンの入れ替え（つまり部品の更新）が可能なのは、その部品が関連付いているＳＴが未確定（Debug）である場合である。なお、既にサービスとして存在してしまっているＳＴが編集されることで生じる混乱（例えば、そのＳＴに関連付いている部品への影響）を回避するために、本実施形態では、管理プログラム４３１が、確定したＳＴ（ＳＴ種別「Release」のＳＴ）を編集状態（Debug）に戻すことを禁止する。管理プログラム４３１は、確定したＳＴの編集要求をユーザから受け付けた場合、確定したＳＴのコピーを生成し、そのＳＴコピーを、編集対象のＳＴとして表示する。変形例として、管理プログラム４３１は、確定したＳＴであっても実行中又は実行待ちのサービスが無ければ（例えば、ＳＴを基にサービスを作成中及び作成済で無ければ）、確定したＳＴを編集状態に戻すことを許可し、ＳＴが確定しており且つ実行中又は実行待ちのサービスが１つでもあれば、そのＳＴを編集状態に戻すことを禁止してよい。

図９は、フロー管理テーブル４２４の構成を示す。

フロー管理テーブル４２４は、サービスフローに関する情報を有する。フロー管理テーブル４２４は、サービスフロー毎にレコードを有し、各レコードに、管理番号９０１、フローｕｋ９０２、構成部品ｕｋリスト９０３及びプロパティマッピングリスト９０４が格納される。

管理番号９０１は、レコードの通し番号である。フローｕｋ９０２は、フローのユニークキー（番号）である。

構成部品ｕｋリスト９０３は、サービスフローを構成する部品のｕｋのリストである。構成部品ｕｋリスト９０３では、サービスフローにおける部品の並び順に（部品の実行順序通りに）、部品のｕｋが並ぶ。

プロパティマッピングリスト９０４は、サービスフローに対応するサービスのサービスプロパティのｕｋのリストである。リスト９０４において、サービスプロパティのｕｋは、例えば、部品ｕｋと、部品のキー名との組合せである。なお、「{部品uk(1). storage.pathinfo = 部品uk(2). storage.pathinfo}」のような、部品ukの部品プロパティの組合せは、一方の部品からの出力値が他方の部品への入力値となることを意味する。

図１０は、ＳＴプロパティ管理テーブル４２５の構成を示す。

ＳＴプロパティ管理テーブル４２５は、ＳＴプロパティに関する情報を有する。ＳＴプロパティ管理テーブル４２５は、ＳＴプロパティ毎にレコードを有し、各レコードに、管理番号１００１、ＳＴ ｕｋ１００２、ＳＴプロパティｕｋ１００３、表示名１００４、キー名１００５、入出力タイプ１００６、プロパティグループ１００７及びカスタムＵＩ生成情報１００８が格納される。

管理番号１００１は、レコードの通し番号である。ＳＴ ｕｋ１００２は、ＳＴプロパティが関連付いているＳＴのＳＴ ｕｋである。

ＳＴプロパティｕｋ１００３は、ＳＴプロパティのユニークキー（例えば番号）である。

表示名１００４は、画面に表示されるＳＴプロパティ名である。キー名１００５は、ＳＴプロパティを一意に特定するための名称であり、ＳＴプロパティの識別情報の一例である。

入出力タイプ１００６は、ＳＴプロパティがＳＴ入力プロパティであるかＳＴ出力プロパティであるか（言い換えれば、ＵＩ上の値が入力値であるか出力値であるか）区別するための情報である。入出力タイプ１００６の値は、対応するＳＴプロパティがＳＴ入力プロパティの場合に「In」であり、対応するＳＴプロパティがＳＴ出力プロパティの場合に「Out」である。

プロパティグループ１００７は、ＳＴプロパティが属するプロパティグループの名称を示す。すなわち、上述したように、本実施形態では、後述するNullも含めて少なくとも１つのプロパティグループが存在し、プロパティグループに、１以上の部品プロパティと、１以上のＳＴプロパティとのうちの少なくとも一方が関連付けられる。プロパティグループ１００７の値「Null」は、対応するＳＴプロパティがいずれのプロパティグループにも属さないことを意味する。

カスタムＵＩ生成情報１００８は、生成されるカスタムＵＩの種別を表す。カスタムＵＩ生成情報１００８の値「Null」は、対応するＳＴプロパティにデフォルトＵＩが関連付けられていることを意味する。なお、カスタムＵＩ生成情報は、カスタムＵＩ生成詳細情報（例えば、ウィジェットの数、各々のウィジェットの種別、表示対象のテキスト、表示されるリスト等）を含んでよい。カスタムＵＩ生成詳細情報（図示せず）は、ＳＴプロパティに関連付けられてよい。ＳＴプロパティに関連付いているカスタムＵＩ生成詳細情報を基に、カスタムＵＩが生成されてよい。

図１１は、サービス管理テーブル４２６の構成を示す。

サービス管理テーブル４２６は、サービスに関する情報を有する。サービス管理テーブル４２６は、サービス毎にレコードを有し、各レコードに、管理番号１１０１、サービス名１１０２、サービス説明１１０３、ＳＴ ｕｋ１１０４及びサービスｕｋ１１０５が格納される。

管理番号９０１は、レコードの通し番号である。サービス名１１０２は、サービスの名称である。サービス説明１１０３は、サービスに関する説明の記述であり、例えば、サービスにおける処理とその順序を含んでよい。ＳＴ ｕｋ１１０４は、サービスに対応するＳＴのＳＴ ｕｋである。サービスｕｋ１１０５は、サービスのユニークキー（番号）である。

図１２は、サービスプロパティ設定テーブル４２７の構成を示す。

サービスプロパティ設定テーブル４２７は、サービスプロパティに関する情報を有する。サービスプロパティ設定テーブル４２７は、サービスプロパティ毎にレコードを有し、各レコードに、管理番号１２０１、プロパティ設定値１２０２、ＳＴプロパティｕｋ１２０３及びサービスｕｋ１２０４が格納される。

管理番号１２０１は、レコードの通し番号である。プロパティ設定値１２０２は、対応するＳＴプロパティの入力値（又は出力値）である。「Null」は、入力値（又は出力値）が存在しないことを意味する。ＳＴプロパティｕｋ１２０３は、対応するＳＴプロパティのＳＴプロパティｕｋである。サービスｕｋ１２０４は、対応するサービスのサービスｕｋである。

図１２によれば、サービスｕｋ「１」のサービスに、５つのＳＴプロパティが関付けられていて、５つのＳＴプロパティにそれぞれ対応した５つのＵＩ（デフォルトＵＩ及びカスタムＵＩのうちの少なくとも１つ）に、「STORAGEHOST」、「1」等の値が入力（又は出力）されたことがわかる。

以上が、テーブル４２１〜４２７の構成の説明である。なお、上述の説明において、表示名、キー名及びｕｋのような識別情報は、ユーザにより入力された情報でもよいし、管理プログラム４３１により決められた情報でもよい。

以下、ＳＴ入力プロパティとＳＴ出力プロパティの関係の詳細と、ＵＩ生成／表示の詳細のそれぞれの例を説明する。

図１３は、ＳＴ入力プロパティとＳＴ出力プロパティの関係の一例を示す。

サービステンプレート１３０１に対応するサービスフローが、部品１３０２Ａ（「Provisioning Volume」）と、部品１３０２Ｂ（「Create pair volume」）とにより構成されている。そのサービスフローでは、部品１３０２Ａの次に部品１３０２Ｂが実行されるような実行順序となっている。

部品１３０２Ａには、４つの部品入力プロパティ１３０３Ａ〜１３０３Ｄが関連付けられている。４つの部品入力プロパティ１３０３Ａ〜１３０３Ｄのそれぞれの表示名は、「Number of Volume」、「Volume Capacity」、「Host Name」及び「Number of path」である。また、部品１３０２Ａには、２つの部品出力プロパティ１３０３Ｅ及び１３０３Ｆが関連付けられている。２つの部品出力プロパティ１３０３Ｅ及び１３０３Ｆのそれぞれの表示名は、「Volume uk」及び「Path info」である。

部品１３０２Ｂには、４つの部品入力プロパティ１３０３Ｇ〜１３０３Ｊが関連付けられている。４つの部品入力プロパティ１３０３Ｇ〜１３０３Ｊのそれぞれの表示名は、「Volume uk」、「Host Name」、「Path info」及び「Path世代数」である。また、部品１３０２Ｂには、１つの部品出力プロパティ１３０３Ｋが関連付けられている。その部品出力プロパティ１３０３Ｋの表示名は、「Path info」である。

これらの部品プロパティにおいて、表示名「Volume uk」の部品出力プロパティ１３０３Ｅと、同じ表示名「Volume uk」の部品入力プロパティ１３０３Ｇは、同一のキー名を有する。同様に、表示名「Path info」の部品出力プロパティ１３０３Ｆと、同じ表示名「Path info」の部品入力プロパティ１３０３Ｉも、同一のキー名を有する。これにより、部品出力プロパティ１３０３Ｅからの出力値が、部品入力プロパティ１３０３Ｇの入力値とされ、また、部品出力プロパティ１３０３Ｆからの出力値が、部品入力プロパティ１３０３Ｉの入力値とされる。このように、「Volume uk」及び「Path info」については、出力値がそのまま入力値と使用されるので、ＳＴ作成ユーザがわざわざ「Volume uk」及び「Path info」について値を入力する必要が無い。従って、誤入力を防止できる。

このような部品を有するサービスフローのサービステンプレート１３０１には、ＳＴ入力プロパティ１３０４Ａ〜１３０４Ｅと、ＳＴ出力プロパティ１３０４Ｆ及び１３０４Ｇが、管理プログラム４３１により関連付けられる。ＳＴ入力プロパティ１３０４Ａは、部品入力プロパティ１３０３Ａを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Number of Volume」である。ＳＴ入力プロパティ１３０４Ｂは、部品入力プロパティ１３０３Ｂを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Volume Capacity」である。ＳＴ入力プロパティ１３０４Ｃは、部品入力プロパティ１３０３Ｃ及びＨを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Host Name」である。ＳＴ入力プロパティ１３０４Ｄは、部品入力プロパティ１３０３Ｄを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Number of path」である。ＳＴ入力プロパティ１３０４Ｅは、部品入力プロパティ１３０３Ｊを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Path世代数」である。ＳＴ出力プロパティ１３０４Ｆは、部品出力プロパティ１３０３Ｅを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Volume uk」である。ＳＴ出力プロパティ１３０４Ｇは、部品出力プロパティ１３０３Ｋを基に生成されたＳＴ入力プロパティであり、故に、表示名は「Path info」である。これらのＳＴ入力プロパティ及びＳＴ出力プロパティは、部品入力プロパティ及び部品出力プロパティを基にそれぞれ管理プログラム４３１により生成される。

図１４は、図１３のＳＴに対応したサービス作成画面の一例である。

サービス作成画面１４０１には、ＳＴ入力プロパティ１３０４Ａ〜１３０４Ｅにそれぞれ対応したＵＩ１４１１〜１４１５が表示される。ＵＩ１４１１〜１４１５は、それぞれ管理プログラム４３１により生成されたＵＩである。ＵＩ１４１１〜１４１５のうち、ＵＩ１４１１及び１４１５がそれぞれデフォルトＵＩであり、ＵＩ１４１２〜１４１４がそれぞれカスタムＵＩである。ＵＩ１４１１〜１４１５の各々は、ＳＴ入力プロパティに関連付いているカスタムＵＩ生成情報を基に生成される。

サービス作成画面１４０１には、実行ボタン１４１７と取消ボタン１４１８が設けられている。ＳＴ作成ユーザは、ＵＩ１４１１〜１４１５に入力した値でよければ、実行ボタン１４１７を押し、それにより、入力された値を基にサービスが作成され、そのサービスの実行命令が計算機管理システム３０２に送信される。ＳＴ作成ユーザは、ＵＩ１４１１〜１４１５に入力した値を取り消すのであれば、取消ボタン１４１８を押し、それにより、全てのＵＩ１４１１〜１４１５がブランクとされる。

なお、サービス作成画面１４０１に表示されるＵＩが、デフォルトＵＩであるかカスタムＵＩであるかは、ＳＴのＳＴプロパティに関連付いているカスタムＵＩ生成情報次第なので、画面１４０１に表示される全てのＵＩがカスタムＵＩであることもある。

また、管理プログラム４３１は、ＳＴ入力プロパティ１３０４Ａ〜１３０４Ｅがそれぞれいずれのプロパティグループに属しているかを基に、プロパティグループ別に、ＵＩを表示してもよい。例えば、同一のプロパティグループに属する２以上のＵＩが１つの枠で囲まれてもよい。分野が同一のＳＴプロパティが同一のプロパティグループに属していれば、ＵＩの配置がプロパティグループに応じた配置となる。これにより、視認性の向上が期待される。

以下、本実施形態での表示の具体例を説明する。

図１５は、ＳＴ作成画面の一例を示す。

ＳＴ作成画面は、部品リストプレーン１５１１と、部品詳細プレーン１５１２と、フロー作成プレーン１５１３と、ＳＴ種別選択ツール１５１４とを有する。

部品リストプレーン１５１１には、管理されている部品の部品名のリスト（部品管理テーブルに記録されている部品名のリスト）１５３１が、管理プログラム４３１により表示される。

部品詳細プレーン１５１２には、部品リスト１５３１から選択された部品に対応する詳細（例えば部品名及びバージョン）が、管理プログラム４３１により表示される。

フロー作成プレーン１５１３には、部品リスト１５３１から選択された部品のアイコン１５４１Ａ及び１５４１Ｂがユーザ操作に従い表示され、部品アイコン１５４１Ａ及び１５４１Ｂ同士の接続により、サービスフローが定義される。例えば、管理プログラム４３１は、部品リスト１５３１から選択された部品をフロー作成プレーン１５１３にドラッグ＆ドロップするユーザ操作に従い、その部品のアイコン１５４１Ａ及び１５４１Ｂをフロー作成プレーン１５１３に表示する。部品リスト１５３１から部品がドラッグ＆ドロップされる都度に、管理プログラム４３１は、部品アイコンをフロー作成プレーン１５１３に追加する。また、管理プログラム４３１は、ユーザ操作に従い、第１の部品アイコンから第２の部品アイコンへの矢印リンクを張ることで、第１の部品の次に第２の部品を実行することを定義する。

ＳＴ種別選択ツール１５１４は、Debugボタン１５２１とReleaseボタン１５２２とを含む。管理プログラム４３１は、Releaseボタン１５２２が押された場合、フロー作成プレーン１５１３に表示されているサービスフローのＳＴを、ＳＴ種別「Release」として保存する。一方、管理プログラム４３１は、Debugボタン１５２１が押された場合、フロー作成プレーン１５１３に表示されているサービスフローのＳＴを、ＳＴ種別「Debug」として保存する。

以上が、ＳＴ作成画面１５０１の構成の説明である。

新たにインポートされた部品があれば、ＳＴ作成画面１５０１の部品リスト１５３１には、その新たにインポートされた部品の部品名も含まれる。ＳＴ作成ユーザが、その新たな部品の部品名を選択し、関連ＳＴ表示のためのユーザ操作を行うと（選択された部品名を関連ＳＴ表示の対象として指定すると）、管理プログラム４３１が、例えばポップアップで、バージョン毎の関連ＳＴリストを表示する。

図１６は、バージョン毎の関連ＳＴリストの一例を示す。

管理プログラム４３１は、部品リスト１５３１から選択された部品名と同一の部品名のバージョン及び部品ｕｋを部品管理テーブル４２１から特定する。管理プログラム４３１は、特定した部品ｕｋに対応するフローｕｋをフロー管理テーブル４２４から特定し、特定したフローｕｋに対応するＳＴ名及びＳＴ種別をＳＴ管理テーブル４２３から特定する。これにより、管理プログラム４３１は、部品リスト１５３１から選択された部品のバージョン毎の関連ＳＴリスト（関連ＳＴのＳＴ名、バージョン及びＳＴ種別のリスト）１６１１Ａ及び１６１１Ｂを生成し表示する。それらのリスト１６１１Ａ及び１６１１Ｂは、例えばＳＴ作成画面１５０１上のポップアップ画面１６０１に表示される。

例えば、ＳＴ作成ユーザは、通常、新たに部品がインポートされた場合、その新たな部品を、古いバージョンの部品を使用する既存のＳＴに適応する必要があるかを検討することになる。この時、部品とＳＴの関係が把握できないと、どのＳＴをエンハンスすればよいのか不明である。

本実施形態によれば、部品リスト１５３１から選択された部品について、関連ＳＴ（選択された部品と部品名が同じ部品が関連付いているＳＴ）がバージョン毎に表示される。これにより、ＳＴ作成ユーザは、選択した部品と同一部品名の部品を使用しているＳＴを把握できる。このため、新しい部品がインポートされた場合に、どのサービステンプレートを新しい部品に入れ替える必要があるか容易に判別できる。

なお、関連ＳＴリストの表示のためのユーザ操作は、部品更新前に行われてよい。例えば、ＳＴ作成ユーザが、部品を更新するか否かの判断のために、その部品についての関連ＳＴを管理プログラム４３１に表示させる。ＳＴ作成ユーザは、その部品についてＳＴ種別「Release」が存在しないことがわかった場合に、選択した部品を、バージョンを更新すること無しに更新することを決めてよい。一方、ＳＴ作成ユーザは、その部品についてＳＴ種別「Release」が存在することがわかった場合に、選択した部品をバージョンと共に更新することを決めてよい。

ところで、上述したように、ＳＴ作成画面１５０１を用いて作成されたＳＴを基に、サービス作成画面を用いてサービスを作成することができる。

図１７は、サービス作成画面の具体例を示す。

サービス作成画面１７０１は、フロー概要プレーン１７２１と、ＵＩプレーン１７２２とを有する。管理プログラム４３１が、確定したＳＴのサービスフローの概要図を例えばフロー管理テーブル４２４を基に生成し、生成した概要図をフロー概要プレーン１７２１に表示する。

また、管理プログラム４３１が、確定したＳＴのＳＴ入力プロパティに関連付いているカスタムＵＩ生成情報を基に、ＵＩを生成し、生成したＵＩをＵＩプレーン１７２２に表示する。ＵＩプレーン１７２２には、例えば図示のように、デフォルトＵＩ１７１１とカスタムＵＩ１７１２が混在する。

カスタムＵＩは、デフォルトＵＩよりユーザビリティが高く、値の入力がサービス作成ユーザにとって容易である。そのため、例えば図１６に示したＳＴ作成画面１５０１の部品リスト１５３１に、部品名に加えて、有効なカスタムＵＩ生成情報（「Null」ではないカスタムＵＩ生成情報）が関連付けられているか否かも表示されてよい。ＳＴ作成ユーザは、部品名が同一の複数の部品にカスタムＵＩが関連付けられた部品とカスタムＵＩが関連付けられていない部品とあれば、カスタムＵＩが関連付けられている部品をＳＴに関連付ける部品として選択する。これにより、サービス作成において値を入力し易いＳＴを作成することができる。

なお、サービス作成画面１７０１には、例えば図示のように、ＳＴのサービスフローの概要図が表示されてもよい。

図１８は、カスタムＵＩのバリエーションを示す。

図１８によれば、表示名「Volume Capacity」を含むカスタムＵＩ１８１２が、プルダウンメニュー以外のウィジェット、例えば、ラジオボタン及びチェックボックスを含む。このように、カスタムＵＩは、１種類以上のウィジェットを含んでよい。

図１９は、カスタムＵＩの別のバリエーションを示す。

図１９によれば、表示名「Volume Capacity」を含むカスタムＵＩ１９１２が、よりユーザビリティの高いカスタムＵＩとなっている。例えば、表示名「Volume Capacity」に対応した値の入力は、スライダー１９０１の位置の調整でよい。値の上限（図１９の例によれば「１００ＧＢ」）は、例えば、管理プログラム４３１が、ストレージ装置３０４の構成に関する情報を基に算出した容量上限でよい。また、カスタムＵＩ１９１２は、使用可能なボリューム容量を示すオブジェクト１９０２を表示してよい。管理プログラム４３１は、そのオブジェクト１９０２が示す使用可能ボリューム容量を、「Volume Capacity」のスライダー１９０１の位置の調整に応答して変更してよい。

以下、本実施形態で行われる処理を説明する。

図２０は、部品インポート処理のフローチャートである。

管理プログラム４３１は、部品の情報パッケージ（例えば、実行ファイル及び部品プロパティを含む）を受け、部品の実行ファイルを、メモリ４１２（又は、外部のストレージ装置等の補助ストレージ装置）に格納する（Ｓ２００１）。部品の情報パッケージは、カスタムＵＩ生成情報の一部又は全部を含んでよい。

管理プログラム４３１は、実行ファイルのパス名等の情報を、部品管理テーブル４２１に格納する（Ｓ２００２）。

また、管理プログラム４３１は、部品プロパティに関する情報を部品プロパティ管理テーブル４２２に格納する（Ｓ２００３）。なお、部品プロパティ管理テーブル４２２の属性の一部は、インポート後に部品提供ユーザ又はＳＴ作成ユーザが追加又は変更してもよい。例えば、表示名７０３は他の部品の表示名と混乱することが好ましくない場合である。そして、プロパティグループについてはＵＩの配置をグループ化できることから、ＳＴ作成ユーザが追加又は変更してもよい。

本実施形態では、カスタムＵＩ生成情報は、予め運用自動化システム３０１に存在するものではなく（運用自動化システム３０１にビルトインされているものではなく）、インポートされる部品に付随して入力される。これにより、インポートされる部品に適したＵＩを、部品のインポートという適切なタイミングで、自動的に運用自動化システム３０１の運用対象として追加することができる。

なお、部品インポート処理では例え同じ部品名であったとしても異なるバージョンの部品である場合は、インポートした部品に対して新しい部品ｕｋを部品管理テーブルにて割り当てる。そのため、作成済みのサービステンプレートやサービスで用いる部品が自動で変更されることはない。そのメリットはこれまで説明してきた通りである。しかし、同じ部品名であった場合は異なるバージョンであっても従来のバージョンと同じ部品ｕｋを割り当てる等によって、部品インポート処理によって自動的に作成済みのサービステンプレートやサービスで用いる部品を変更してもよい。

図２１は、ＳＴ編集処理のフローチャートである。

ＳＴ編集処理とは、ＳＴ作成処理における処理である。ＳＴ作成ユーザがＳＴ作成画面１５０１のフロー作成プレーン１５１３上に必要な部品を置いて部品の順番を決めるが、図２１に示すＳＴ編集処理は、フロー作成プレーン１５１３上のサービスフローのＳＴを一時保存する処理である。

管理プログラム４３１は、ＳＴの情報（ＳＴ名、ＳＴバージョン、ＳＴ ｕｋ等）を、ＳＴ管理テーブル４２３に格納する（Ｓ２１０１）。また、管理プログラム４３１は、そのＳＴのサービスフローの情報（フローｕｋ、構成部品ｕｋリスト等）を、フロー管理テーブル４２４に格納する。

管理プログラム４３１は、そのＳＴのサービスフローの構成部品ｕｋリストが表す全ての部品の各々について（例えば、構成部品ｕｋリストが表す部品順序通りに）、Ｓ２１０４〜Ｓ２１０６を行う（Ｓ２１０３）。すなわち、管理プログラム４３１は、構成部品ｕｋリストから選択された部品の部品プロパティに対応したＳＴプロパティに関する情報を、ＳＴプロパティ管理テーブル４２５に格納する（Ｓ２１０４）。この処理には、部品プロパティ管理テーブルのカスタムＵＩ生成情報７０８及びプロパティグループ７０７の値をＳＴプロパティ管理テーブル４２５のカスタムＵＩ生成情報１００８及びプロパティグループ１００７に格納することも含む。Ｓ２１０４では、例えば、管理プログラム４３１は、前の部品の出力プロパティと、次の部品の入力プロパティの関連付けが可能か否か（キー名が同一か否か）を判断し、その判断の結果が肯定であれば、その出力プロパティ及び入力プロパティを関連付けてよい。管理プログラム４３１は、対応するプロパティマッピングリスト９０４に、Ｓ２１０４で格納したＳＴプロパティに基づく情報を追加する（Ｓ２１０５）。そして、管理プログラム２１０４は、構成部品ｕｋリストが表す部品のうちの次の部品を選択する（Ｓ２１０６）。なお、ある部品の入力プロパティが、他の部品の出力プロパティと関連付いている場合は、ＳＴプロパティ管理テーブル４２５への登録を省略してもよい。

図２２は、ＳＴ確定処理のフローチャートである。

管理プログラム４３１は、作成済（登録済）のＳＴから選択されたＳＴについて、ＳＴ種別「Release」が指定を受け付け、そのＳＴのＳＴ種別を、「Debug」から「Release」に変更する（Ｓ２２０１）。ＳＴ種別が「Release」となったＳＴについて、管理プログラム４３１は、編集を禁止する。なお、この編集禁止の例としては編集に関するユーザ操作を拒否したり、またそもそも編集の際に編集禁止としたＳＴを選択したりできないようにする、といったことが考えられる。

図２３は、関連ＳＴ表示処理のフローチャートである。

管理プログラム４３１は、選択された部品（例えば図１５の部品リスト１５３１から選択された部品）の部品名と同一の部品名のバージョン及び部品ｕｋを部品管理テーブル４２１から特定する（Ｓ２３０１）。管理プログラム４３１は、特定した部品ｕｋに対応するフローｕｋをフロー管理テーブル４２４から特定する（Ｓ２３０２）。管理プログラム４３１は、特定したフローｕｋに対応するＳＴ名及びＳＴ種別をＳＴ管理テーブル４２３から特定する（Ｓ２３０３）。管理プログラム４３１は、Ｓ２３０２及びＳ２３０２を、Ｓ２３０１で特定された全ての部品ｕｋについて行う（Ｓ２３０４）。その後、管理プログラム４３１は、選択された部品のバージョン毎の関連ＳＴリスト（関連ＳＴのＳＴ名、バージョン及びＳＴ種別のリスト）を生成し表示する（Ｓ２３０５）。

図２４は、サービス作成画面１７０１表示処理のフローチャートである。

管理プログラム４３１は、確定したＳＴの選択をサービス作成ユーザから受け、選択されたＳＴに対応したサービス情報（例えばＳＴ ｕｋ）を、サービス管理テーブル４２６に格納する（Ｓ２４０１）。管理プログラム４３１は、選択されたＳＴのＳＴ ｕｋに対応する全てのＳＴプロパティに関する情報をＳＴプロパティ管理テーブル４２５から特定する（Ｓ２４０２）。管理プログラム４３１は、特定したＳＴプロパティに関連付いているカスタムＵＩ生成情報１００８を基に、各ＳＴ入力プロパティについてＵＩ（デフォルトＵＩ又はカスタムＵＩ）を生成し（Ｓ２４０３）、生成したＵＩを含んだサービス作成画面１７０１（プロパティ入力画面）を表示する（Ｓ２４０４）。

なお、Ｓ２４０３が参照するカスタムＵＩ生成情報１００８の代わりとして、フロー管理テーブル４２４のプロパティマッピングリスト９０４の値を参考にした上で対応する部品の部品プロパティを特定し、部品プロパティ管理テーブル４２２のカスタムＵＩ生成情報７０８を参照してもよい。サービス生成画面のＵＩを決定するにあたって、直接的又は間接的かに関わらず部品のカスタムＵＩ生成情報を参照することで、サービステンプレート作成ユーザが各サービステンプレート毎にサービス作成画面をデザインしなくても利便性の高い画面を生成できるからである。

図２５は、サービス実行処理のフローチャートである。

図２４の処理により表示された画面のＵＩに値が入力され、サービス作成ユーザにより実行が指定された場合に、サービス実行処理が開始される。なお、作成されたサービスが登録されて実行待ちの状態となり、実行待ちの状態のサービスについて実行が指示されることで、サービス実行処理が乖離されてもよい。

管理プログラム４３１は、サービス作成画面１７０１（プロパティ入力画面）に入力された値を、サービスプロパティ設定テーブル４２７に格納する（Ｓ２５０１）。その後、管理プログラム４３１は、入力された設定値を基に、サービスを実行する（Ｓ２５０２）。具体的には、管理プログラム４３１は、例えば下記を行う。
（Ａ）管理プログラム４３１は、サービスの元となったサービステンプレートを選択する。
（Ｂ）管理プログラム４３１は、（Ａ）で選択したサービステンプレートのフローの構成部品ukリスト９０３を参照し、実行すべき部品を実行順序と共に特定する。
（Ｃ）管理プログラム４３１は、（Ｂ）で特定した通りに部品を実行する。（Ｃ）において、管理プログラム４３１は、プロパティマッピングリスト９０４を参照することで、適切なサービスプロパティの入力プロパティ又は他の部品の出力プロパティを選び、その値を入力する。その入力された値が、実行対象の部品の入力プロパティに設定される入力値である。なお、「部品の実行」とは、実行ファイルパス６０４に記載の実行ファイルを実行することである。
（Ｄ）実行順序通りに部品を実行した後、管理プログラム４３１は、プロパティマッピングリスト９０４を参照の上で、サービステンプレートの出力プロパティに関連する部品の出力プロパティを選び、その値をサービステンプレートの出力プロパティとしてサービスの実行結果として表示する。なお、サービスの実行結果についてもカスタムＵＩ及びプロパティグループの処理を適用してもよいことは言うまでもない。

なお、実行ファイルに記載された処理内容は、典型的には、運用対象装置への構成変更、又は、運用対象装置からの構成情報、メトリック情報、状態の取得、といった要求を運用対象装置に直接又は間接に送信することである。なお、運用対象装置に要求を直接に送信する例としては、運用自動化システムから運用対象装置に要求を直接に送信する場合であり、要求を間接に送信する例としては、計算機管理システム３０２に対して要求を送信する場合と運用対象装置の保守員に保守メッセージを送信し、保守員が運用対象装置の運用として保守業務を行う場合とが考えられる。

図２６は、ＵＩ変更処理のフローチャートである。

管理プログラム４３１は、ＵＩの変更要求を受け付け（Ｓ２６０１）、Ｓ２６０２を実行する。Ｓ２６０２では、管理プログラム４３１は、ＵＩの変更要求に従いＵＩの変更を実行する。ＵＩが変更された場合、変更前のＵＩに関連付いている部品のコピーを作成し、その部品コピーに、新たなバージョン（変更前のＵＩに関連付いている部品のバージョンと異なるバージョン）を割り当てる。そして、管理プログラム４３１は、その部品コピーに、変更後のＵＩ（変更後のＵＩを表すカスタムＵＩ生成情報）を関連付ける。管理プログラム４３１は、その部品コピー（新たなバージョンの部品）に関する情報を部品管理テーブル４２１に格納し（追加）し、その部品コピーに関連付いている部品プロパティに関する情報を部品プロパティ管理テーブル４２２に格納（追加）する。なお、管理プログラム４３１は、変更対象のＵＩが関連付いている部品がいずれの既存ＳＴ（又は、いずれの既存確定ＳＴ（ＳＴ種別「Release」のＳＴ））にも関連付いていなければ、部品コピーを作成すること無しに、ＵＩの変更を受け付けてよい。

管理プログラム４３１は、変更要求で指定されているＵＩが既存のＳＴに関連付いているか否かを判断する（Ｓ２６０３）。

Ｓ２６０３の判断結果が肯定の場合（Ｓ２６０３：ＹＥＳ）、管理プログラム４３１が、既存部品と関連がある既存ＳＴの一覧画面を表示する（Ｓ２６０４）。このとき、ユーザが選択した既存ＳＴについて、管理プログラム４３がその既存のＳＴのコピーを作成し（例えば、既存のＳＴを基にバージョンの異なる新たなＳＴを作成し）（Ｓ２６０５）、その作成したＳＴコピーで使用されている既存部品を新たなバージョンの部品に入れ替える。これにより、変更後のＵＩが、既存のＳＴに関連付けられることが回避される。ここで言う「既存のＳＴ」は、ＳＴ種別が「Release」のＳＴであって、ＳＴ種別が「Debug」のＳＴは対象外でもよい。

なお、部品のＵＩ変更処理は上記以外で実現しても良い。例えば、部品提供ユーザが、ＵＩが更新されることで新しいバージョンとなった部品をインポートしたり、サービステンプレートを部品としてインポートしたりしている場合は、サービステンプレートに関係するカスタムＵＩ生成情報が変更されることでバージョンアップされた場合である。

以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。

３０１：運用自動化システム ３１１：管理サーバ ３１２：管理クライアント

Claims (14)

1. １以上の運用対象装置を含む運用対象システムに接続されたインターフェースデバイスと、
   管理プログラムを記憶する記憶資源と、
   前記管理プログラムを実行するプロセッサと、
   を有し、
   前記プロセッサは前記管理プログラムを実行することで：
   （１）部品入力プロパティと、前記部品入力プロパティに入力された入力値に基づいて実行する処理内容を含む部品を複数管理し、
   （２）１以上の部品と実行順序と共に関連付けられ、１以上のテンプレート入力プロパティを含むサービステンプレートを作成又は編集し、
   （３）プロパティグループごとの前記テンプレート入力プロパティを表示し、前記サービステンプレートと、前記テンプレート入力プロパティに入力する入力値の指定を受信し、
   （４）前記指定された入力値とサービステンプレートに基づいて、前記部品に含まれる処理内容を指定された入力値で実行するための運用サービスを生成し、
   （５）生成した運用サービスを実行することで、前記運用対象装置を運用する、
   管理システム。
2. 前記プロセッサは：
   （１ａ）（１）の部品の管理として、前記部品の識別子とバージョンを記憶資源に格納し、
   （２ａ）前記サービステンプレートと前記部品との関連付けとして、前記サービステンプレートと、当該関連付けられた部品の識別子及びバージョンと、の対応関係を記憶資源に格納し、
   （６ａ）部品とサービステンプレートの対応関係を表示するためのユーザ操作を受信し、
   （６ｂ）前記ユーザ操作の対象となる部品識別子及びバージョンを特定し、
   （６ｃ）特定した部品識別子及びバージョンを持つ部品で構成されるサービステンプレートを選択し、
   （６ｄ）前記特定したサービステンプレートの識別子を表示する、
   請求項１記載の管理システム。
3. 前記プロセッサは：
   （１ｂ）前記部品入力プロパティに対応し、前記部品入力プロパティに対する入力をするためのＵＩ要素を特定するカスタムＵＩ生成情報を前記記憶資源に格納し、
   （２ｂ）前記部品入力プロパティと前記テンプレート入力プロパティとの対応関係を管理し、
   （３）の入力値指定時に表示するサービス作成画面の生成のため：
   （７ａ）（２ｂ）の対応関係及び（１ｂ）のカスタムＵＩ生成情報に基づいて、前記テンプレート入力プロパティに対応するＵＩ要素を前記サービス作成画面上に表示させることを決定し、
   （８）管理中の第１の部品と同じ部品識別子と新しいバージョンを持つ第２の部品をインポートする処理として：
   （８ａ）インポート前に生成済みであって、前記第１の部品と関連付けられたサービステンプレートの対応付けを維持することで、前記インポートに伴う前記サービス作成画面を変更しない、
   請求項２記載の管理システム。
4. 前記プロセッサは：
   （９）前記サービステンプレートの状態種別が確定か否か管理し、
   （１０）前記サービステンプレートを指定した編集するユーザ操作を受信し、
   （１１）前記サービステンプレートの状態種別が確定の場合は、当該ユーザ操作を拒否する、又は当該ユーザ操作を指定できないように制御する、
   請求項３記載の管理システム。
5. 前記プロセッサは：
   ユーザの一部を、サービステンプレート作成ユーザと、サービス作成ユーザと認識し、
   前記状態種別が確定であるサービステンプレートについては前記サービス作成ユーザからの（４）のサービス作成を許可し、
   前記状態種別が確定以外の他の状態であるサービステンプレートについては前記サービス作成ユーザからの（４）のサービス作成を抑止する、
   請求項４記載の管理システム。
6. 前記プロセッサは：
   前記カスタムＵＩ生成情報が無効な場合は、対応するテンプレート入力プロパティのUI要素をテキストフィールドと決定する、
   請求項４記載の管理システム。
7. 前記プロセッサは：
   （７ａ）において、複数のテンプレート入力プロパティがそれぞれいずれのプロパティグループに属しているかを基に、同一のプロパティグループに属する１以上のテンプレート入力プロパティにそれぞれ対応した１以上のＵＩ要素が前記サービス作成画面上にまとめて表示されるよう決定する、
   請求項３記載の管理システム。
8. １以上の運用対象装置を含む運用対象システムに接続された計算機に、
   （１）部品入力プロパティと、前記部品入力プロパティに入力された入力値に基づいて実行する処理内容を含む部品を複数管理し、
   （２）１以上の部品と実行順序と共に関連付けられ、１以上のテンプレート入力プロパティを含むサービステンプレートを作成又は編集し、
   （３）プロパティグループごとの前記テンプレート入力プロパティを表示し、前記サービステンプレートと、前記テンプレート入力プロパティに入力する入力値の指定を受信し、
   （４）前記指定された入力値とサービステンプレートに基づいて、前記部品に含まれる処理内容を指定された入力値で実行するための運用サービスを生成し、
   （５）生成した運用サービスを実行することで、前記運用対象装置を運用する、
   ことを実行させるコンピュータプログラム。
9. （１ａ）（１）の部品の管理として、前記部品の識別子とバージョンを記憶資源に格納し、
   （２ａ）前記サービステンプレートと前記部品との関連付けとして、前記サービステンプレートと、当該関連付けられた部品の識別子及びバージョンと、の対応関係を記憶資源に格納し、
   （６ａ）部品とサービステンプレートの対応関係を表示するためのユーザ操作を受信し、
   （６ｂ）前記ユーザ操作の対象となる部品識別子及びバージョンを特定し、
   （６ｃ）特定した部品識別子及びバージョンを持つ部品で構成されるサービステンプレートを選択し、
   （６ｄ）前記特定したサービステンプレートの識別子を表示する、
   ことを前記計算機に実行させる請求項８記載のコンピュータプログラム。
10. （１ｂ）前記部品入力プロパティに対応し、前記部品入力プロパティに対する入力をするためのＵＩ要素を特定するカスタムＵＩ生成情報を前記記憶資源に格納し、
    （２ｂ）前記部品入力プロパティと前記テンプレート入力プロパティとの対応関係を管理し、
    （３）の入力値指定時に表示するサービス作成画面の生成のため：
    （７ａ）（２ｂ）の対応関係及び（１ｂ）のカスタムＵＩ生成情報に基づいて、前記テンプレート入力プロパティに対応するＵＩ要素を前記サービス作成画面上に表示させることを決定し、
    （８）管理中の第１の部品と同じ部品識別子と新しいバージョンを持つ第２の部品をインポートする処理として：
    （８ａ）インポート前に生成済みであって、前記第１の部品と関連付けられたサービステンプレートの対応付けを維持することで、前記インポートに伴う前記サービス作成画面を変更しない、
    ことを前記計算機に実行させる請求項９記載のコンピュータプログラム。
11. （９）前記サービステンプレートの状態種別が確定か否か管理し、
    （１０）前記サービステンプレートを指定した編集するユーザ操作を受信し、
    （１１）前記サービステンプレートの状態種別が確定の場合は、当該ユーザ操作を拒否する、又は当該ユーザ操作を指定できないように制御する、
    ことを前記計算機に実行させる請求項１０記載のコンピュータプログラム。
12. ユーザの一部を、サービステンプレート作成ユーザと、サービス作成ユーザと認識し、
    前記状態種別が確定であるサービステンプレートについては前記サービス作成ユーザからの（４）のサービス作成を許可し、
    前記状態種別が確定以外の他の状態であるサービステンプレートについては前記サービス作成ユーザからの（４）のサービス作成を抑止する、
    ことを前記計算機に実行させる請求項１１記載のコンピュータプログラム。
13. 前記カスタムＵＩ生成情報が無効な場合は、対応するテンプレート入力プロパティのUI要素をテキストフィールドと決定する、
    ことを前記計算機に実行させる請求項１１記載のコンピュータプログラム。
14. （７ａ）において、複数のテンプレート入力プロパティがそれぞれいずれのプロパティグループに属しているかを基に、同一のプロパティグループに属する１以上のテンプレート入力プロパティにそれぞれ対応した１以上のＵＩ要素が前記サービス作成画面上にまとめて表示されるよう決定する、
    ことを前記計算機に実行させる請求項１０記載のコンピュータプログラム。

Images