JP2016126653A - 管理システム、制御方法、および制御プログラム - Google Patents

Abstract

【課題】各システム間で関連する情報を容易な設定で適切に更新することが可能な管理システムを提供する。【解決手段】管理システム５００は、社員情報２２２Ａを保持する連携システム３００Ａと、社員情報２２２Ｂを保持する連携システム３００Ｂとを備える。社員情報２２２Ａ，２２２Ｂは、互いに関連し、更新順序に依存関係を有する。ＩＤ統合システム１００は、社員情報２２２Ａ，２２２Ｂのうちのいずれかの更新を受け付けたときに、上記依存関係と更新内容とに基づいて、社員情報２２２Ａ，２２２Ｂの更新順序を決定し、決定した更新順序で社員情報２２２Ａ，２２２Ｂのそれぞれを更新する。【選択図】図２

Description

本開示は、複数のシステム間で関連する情報を整合性を保ちながら管理する管理システムの制御に関する。

従来、処理の実行順序を適切に制御するための様々な技術が開発されている。たとえば、特開平８−２７２６２６号公報（特許文献１）は、無駄な待ち時間を排除したジョブの並行処理するためのバッチジョブ処理方法を開示している。

特開平９−２１８８６１号公報（特許文献２）は、並列処理のスケジューリングを行なう際に、処理の中間生成データを保持したまま他のジョブを待つような遊休時間を短くするスケジューラを開示している。

特開平８−２７２６２６号公報 特開平９−２１８８６１号公報

ところで、近年では、社員などのアカウントおよび社員のファイルなどの使用権限を一元的に管理する管理システムが開発されている。当該管理システムは、社員の入社、退社、または異動などに応じて、自身が管理している複数のシステム（以下、「連携システム」ともいう。）において、当該社員に関連する社員情報を自動的に更新する。このとき、社員情報の更新処理が各連携システムに対して適切な順序で実行されない場合には、社員情報の互いの整合性が失われ、結果としてエラーが生じる可能性がある。

このようなエラーを回避するために、管理システムの管理者は、各連携システムに対して更新処理の順序を適切に設定する必要があった。特許文献１に開示されるバッチジョブ処理方法や、特許文献２に開示されるスケジューラが当該管理システムに応用されたとしても、管理者は、各連携システムに対して更新処理の順序を事前に適切に設定する必要がある。すなわち、管理者には、処理順序を適切に設定するための知識が必要とされる。そのため、社員情報などの各システム間で関連する情報を容易な設定で適切に更新することが可能な管理システムが望まれている。

本開示は上述のような問題点を解決するためになされたものであって、その目的は、各システム間で関連する情報を容易な設定で適切に更新することが可能な管理システムを提供することである。他の局面における目的は、各システム間で関連する情報を容易な設定で適切に更新することが可能な制御方法を提供することである。さらに他の局面における目的は、各システム間で関連する情報を容易な設定で適切に更新することが可能な制御プログラムを提供することである。

一実施の形態に従うと、管理システムは、互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムと、複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるための第１受付部と、第１受付部が更新を受け付けたときに、依存関係と更新の内容とに基づいて、複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するための決定部と、決定部によって決定された更新順序で複数のシステムに保持されている第１情報のそれぞれを更新するための更新部とを備える。

好ましくは、管理システムは、依存関係の入力を受け付けるための第２受付部をさらに備える。

好ましくは、決定部は、依存関係と更新の内容とに基づいて、複数のシステムの各々について、依存先のシステムを特定し、依存先のシステムにおける第１情報を優先的に更新するように更新順序を決定する。

好ましくは、更新の内容は、第１情報の新規作成と、第１情報の削除とを含む。複数のシステムは、互いに階層関係を有する。決定部は、更新の内容が第１情報の新規作成である場合には、複数のシステムの各々について、当該システムよりも階層が上位にあるシステムを依存先のシステムとして特定し、更新の内容が第１情報の削除である場合には、複数のシステムの各々について、当該システムよりも階層が下位にあるシステムを依存先のシステムとして特定する。

好ましくは、更新の内容は、第１情報の変更を含む。変更は、第１情報の削除処理と、新たな第１情報の新規作成処理とで実現される。管理システムは、削除処理と新規作成処理とのいずれの処理を優先するかの設定を受け付ける。

好ましくは、更新部は、決定部によって決定された更新順序で複数のシステムに保持されている第１情報のそれぞれを順に更新する過程において更新処理が途中で失敗した場合には、システムに対する第１情報の以降の更新を行なわない。

好ましくは、複数のシステムは、互いに関連する第２情報をそれぞれ保持する。決定部は、依存関係と第２情報に対する更新の内容とに基づいて、複数のシステムに保持されている第２情報のそれぞれの更新順序をさらに決定する。更新部は、第１情報の更新タイミングと第２情報の更新タイミングとが異なるシステム間で重なる場合には、第１情報と第２情報とを並列に更新する。

好ましくは、更新部は、第１情報の更新タイミングと第２情報の更新タイミングとが同一のシステム内において重なる場合には、第１情報および第２情報のそれぞれに依存しているシステムの数が多い方の情報を優先的に更新する。

他の局面に従うと、管理システムの制御方法が提供される。管理システムは、互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムを備える。制御方法は、複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるステップと、更新を受け付けたときに、依存関係と更新の内容とに基づいて、複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するステップと、更新順序で複数のシステムに保持されている第１情報のそれぞれを更新するステップとを備える。

さらに他の局面に従うと、管理システムの制御プログラムが提供される。管理システムは、プロセッサと、互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムとを備える。制御プログラムは、プロセッサに、複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるステップと、更新を受け付けたときに、依存関係と更新の内容とに基づいて、複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するステップと、更新順序で複数のシステムに保持されている第１情報のそれぞれを更新するステップとを実行させる。

ある局面において、各システム間で関連する情報を容易な設定で適切に更新することができる。

本発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解される本発明に関する次の詳細な説明から明らかとなるであろう。

管理システムのシステム構成の一例を示す図である。 第１の実施の形態に従うＩＤ（Identification）統合システムの処理を概略的に示した概念図である。 第１の実施の形態に従うＩＤ統合システムの機能構成を示すブロック図である。 システム間の依存関係の一例を示す図である。 更新受付部によって出力される更新情報の内容を示す図である。 特定部によって出力される更新リストの内容を示す図である。 決定部によって出力される処理順リストの内容を示す図である。 更新処理を実行する過程における処理順リストの内容を示す図である。 更新処理を実行する過程における処理順リストの内容を示す図である。 第１の実施の形態に従うＩＤ統合システムと従来のＩＤ統合システムとにおける、更新処理を開始してから完了するまでの時間を比較した図である。 第１の実施の形態に従うＩＤ統合システムが実行する処理を表わすフローチャートである。 管理システムの主要なハードウェア構成を示すブロック図である。 第２の実施の形態における処理順リストの内容を示す図である。 各システムにおいて実行される更新処理を時系列の順に示した図である。

以下、図面を参照しつつ、本発明に従う各実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらについての詳細な説明は繰り返さない。また、以下で説明する各実施の形態または変形例は、適宜選択的に組み合わされてもよい。

＜第１の実施の形態＞
［管理システム５００のシステム構成］
図１を参照して、管理システム５００のシステム構成について説明する。図１は、管理システム５００のシステム構成の一例を示す図である。

図１に示されるように、管理システム５００は、ＩＤ統合システム１００と、連携システム３００Ａ〜３００Ｃと、ＤＢ（DataBase）サーバー４００とを含む。ＩＤ統合システム１００およびＤＢサーバー４００は、ネットワーク１４０Ａを介して互いに接続されている。ＩＤ統合システム１００および連携システム３００Ａ〜３００Ｃは、ネットワーク１４０Ｂを介して互いに接続されている。

管理システム５００は、たとえば、社内の社員情報を一元的に管理するために用いられる。一例として、社員情報は、社員ＩＤと、社員の名前と、当該社員のメールアドレスと、当該社員のフォルダのアクセス権限との対応関係を社員ＩＤ別に含む。管理者は、社員の入社、退社、または異動に応じて、ＤＢサーバー４００で管理される社員情報を更新する操作をＩＤ統合システム１００に対して行なう。ＩＤ統合システム１００は、当該操作を受け付けると、連携システム３００Ａ〜３００Ｃにおける当該社員に関する社員情報を自動的に更新する。これにより、ＩＤ統合システム１００は、連携システム３００Ａ〜３００Ｃの間で社員情報の整合性を保つ。ＩＤ統合システム１００は、たとえば、夜間などの予め定められた時間に定期的に一括して更新処理を行なう。更新処理は、たとえば、社員情報の登録処理、削除処理、および変更処理などを含む。

なお、以下では、管理システム５００が管理する情報として社員情報を挙げて説明を行なうが、当該情報は、社員情報に限定されない。たとえば、当該情報は、ユーザー情報、またはその他の情報などであってもよい。

［ＩＤ統合システム１００の概要］
図２を参照して、ＩＤ統合システム１００の概要について説明する。図２は、ＩＤ統合システム１００の処理を概略的に示した概念図である。なお、説明を簡単にするために、図２においては、管理システム５００が２つの連携システム３００Ａ，３００Ｂによって構成されている例について説明する。

連携システム３００Ａは、社員情報２２２Ａを保持する。連携システム３００Ｂは、社員情報２２２Ｂを保持する。社員情報２２２Ａ，２２２Ｂは、互いに関連する情報であり、互いの更新順序に依存関係を有する。すなわち、社員情報２２２Ａ，２２２Ｂは、少なくとも一部において共通する情報を互いに有する。そのため、ＩＤ統合システム１００が適切な順序で社員情報２２２Ａ，２２２Ｂを更新しない場合には、社員情報２２２Ａ，２２２Ｂの互いの整合性が失われ、結果としてエラーが生じる。

このようなエラーが生じる具体例について説明する。たとえば、連携システム３００ＡがＡＤ（Active Directory）サーバーであり、連携システム３００Ｂがファイルサーバーであるとする。また、管理者が新たな社員のアカウント（社員ＩＤなど）および当該社員の権限をＡＤサーバーに対して新規作成し、他の管理者が当該社員に対するフォルダ権限をファイルサーバーに対して追加したとする。この場合、ファイルサーバーは、当該社員の権限をＡＤサーバーから取得する必要があるため、当該社員のアカウントを新規作成する処理を、当該社員の権限を追加する処理よりも優先的に行なう必要がある。このように、ファイルサーバーの社員情報は、ＡＤサーバーの社員情報に依存しているため、ＩＤ統合システム１００は、整合性を保ちながら社員情報２２２Ａ，２２２Ｂを更新するためには、社員情報２２２Ａ，２２２Ｂの互いの依存関係を把握した上で更新処理を実行する必要がある。

そこで、本実施の形態に従うＩＤ統合システム１００は、社員情報２２２Ａ，２２２Ｂのいずれかに対する更新を受け付けたときに、社員情報２２２Ａ，２２２Ｂの依存関係と、社員情報２２２Ａ，２２２Ｂの更新内容とに基づいて、社員情報２２２Ａ，２２２Ｂのそれぞれの更新順序を決定する。

より具体的には、ＩＤ統合システム１００は、システム間の依存関係と更新内容とに基づいて、各システムの依存先のシステムを特定し、依存先のシステムにおける社員情報を優先的に更新する。依存先のシステムは、下記のルール（１）〜（３）に従って、特定される。

ルール（１）：更新内容が新規作成である場合、各システムについて、当該システムよりも上位階層にあるシステムを依存先のシステムとして特定する。

ルール（２）：更新内容が削除である場合、各システムについて、当該システムよりも下位階層にあるシステムを依存先のシステムとして特定する。

ルール（３）：更新内容が変更である場合、各システムについて、当該システムよりも上位階層にあるシステムを依存先のシステムとして特定する。

たとえば、連携システム３００Ａおよび連携システム３００Ｂは、階層関係を有し、連携システム３００Ａが上位システム、連携システム３００Ｂが下位システムであるとする。この場合、ＩＤ統合システム１００は、社員情報の新規作成処理と変更処理とを実行するときには、上記ルール（１）（３）に従って、連携システム３００Ａを連携システム３００Ｂの依存先として特定する（図２の処理例（Ａ）参照）。その結果、ＩＤ統合システム１００は、連携システム３００Ｂの依存先である連携システム３００Ａの社員情報２２２Ａを更新し、その後、連携システム３００Ｂの社員情報２２２Ｂを更新する。

一方で、ＩＤ統合システム１００は、社員情報の削除処理を実行するときには、上記ルール（２）に従って、連携システム３００Ｂを連携システム３００Ａの依存先として特定する（図２の処理例（Ｂ）参照）。その結果、ＩＤ統合システム１００は、連携システム３００Ａの依存先である連携システム３００Ｂの社員情報２２２Ｂを更新し、その後、連携システム３００Ａの社員情報２２２Ａを更新する。

このように、ＩＤ統合システム１００は、連携システム間の依存関係と更新内容とに基づいて、各連携システムの依存先のシステムを特定し、依存先のシステムにおける社員情報を優先的に更新する。

ＩＤ統合システム１００は、連携システム間の依存関係（階層関係）を設定するだけで、適切に各社員情報を更新することができる。連携システム間の依存関係は、管理者にとって容易に理解できるため、知識のない管理者であっても、連携システム間の依存関係を容易に設定できる。これにより、管理者は、各連携システムに対して更新順序を設定する必要がなくなり、その結果、更新順序の設定ミスを防ぐことができる。なお、連携システム間の依存関係は、管理システム５００の設計時に予め設計者によって決められていてもよい。

［ＩＤ統合システム１００の機能構成］
図３〜図１０を参照して、第１の実施の形態に従うＩＤ統合システム１００の機能について説明する。図３は、ＩＤ統合システム１００の機能構成を示すブロック図である。図３に示されるように、ＩＤ統合システム１００は、プログラム１３０を含む。プログラム１３０は、たとえば、ＩＤ統合システム１００の記憶装置１１０（図１２）に格納される。また、プログラム１３０は、たとえば、ＩＤ統合システム１００のＣＰＵ（Central Processing Unit）１０２によって実行される。プログラム１３０は、依存関係受付部１５０（第２受付部）と、更新受付部１６０（第１受付部）と、特定部１７０と、決定部１８０と、更新部１９０とを有する。以下では、これらの機能について順に説明する。

（依存関係受付部１５０）
図３および図４を参照して、依存関係受付部１５０の機能について説明する。図４は、システム間の依存関係の一例を示す図である。図４の例では、管理システム５００は、連携システム３００Ａ〜３００Ｅによって構成される。

図３に示されるように、依存関係受付部１５０は、管理者によるシステム間の依存関係の入力を受け付ける。すなわち、管理者は、管理システム５００に対して、連携システム３００Ａ〜３００Ｅの間の依存関係を設定することができる。言い換えると、管理者は、各連携システムの階層を設定する。依存関係受付部１５０は、連携システム間の依存関係を受け付けると、当該依存関係を決定部１８０に出力する。

依存関係の設定方法としては、たとえば、図４に示されるように、各連携システム間を線で繋ぐなどして各連携システムを関連付ける方法が挙げられる。図４の例では、連携システム３００Ａと連携システム３００Ｂとが、互いに関連付けられている。連携システム３００Ａと連携システム３００Ｄとが、互いに関連付けられている。連携システム３００Ｂと連携システム３００Ｃとが、互いに関連付けられている。連携システム３００Ｄと連携システム３００Ｅとが、互いに関連付けられている。

（更新受付部１６０）
図３および図５を参照して、更新受付部１６０の機能について説明する。図５は、更新受付部１６０によって出力される更新情報５１の内容を示す図である。

上述のＤＢサーバー４００（図１参照）は、自身のデータベースに更新があった社員情報を更新情報５１として抽出する。すなわち、更新情報５１には、社員情報の変更内容がまとめられている。たとえば、ＤＢサーバーが人事システムである場合には、通常、人事システムは、更新情報５１を生成する機能を基本機能として備えている。図５の例では、更新情報５１は、社員ＩＤが「１」である社員の「入社」を示す更新情報と、社員ＩＤが「２」である社員の「部署異動」を示す更新情報と、社員ＩＤが「３」である社員の「退職」を示す更新情報とを有する。ＤＢサーバー４００は、夜間などの予め定められた時刻に更新情報５１をＩＤ統合システム１００に定期的に送信する。

図３に示されるように、更新受付部１６０は、更新内容がまとめられた更新情報５１をＤＢサーバー４００から受信する。更新受付部１６０は、受信した更新情報５１を特定部１７０に出力する。

（特定部１７０）
図３，図５および図６を参照して、特定部１７０の機能について説明する。図６は、特定部１７０によって出力される更新リスト５３の内容を示す図である。

特定部１７０は、上述の更新情報５１（図５参照）に基づいて、社員情報を更新する対象の連携システムを特定するとともに、更新内容を特定する。より具体的には、特定部１７０は、まず、更新情報５１に含まれる社員ＩＤを利用している連携システムを特定する。

図６の例では、特定部１７０は、図５の更新情報５１に含まれている社員ＩＤ「１」を利用する連携システム３００Ａ〜３００Ｃを更新対象のシステムとして特定する。また、更新情報５１には、社員ＩＤ「１」の変更内容が「入社」であることが示されているので、特定部１７０は、連携システム３００Ａ〜３００Ｃに対して社員ＩＤ「１」の社員情報を新規作成すると判断する。

同様に、特定部１７０は、更新情報５１に含まれている社員ＩＤ「２」を利用している連携システム３００Ｂ，３００Ｃを更新対象のシステムとして特定する。また、更新情報５１には、社員ＩＤ「２」の変更内容が「部署異動」であることが示されているので、特定部１７０は、社員情報を連携システム３００Ａ，３００Ｂに対して社員ＩＤ「２」の社員情報を「変更」すると特定する。

同様に、特定部１７０は、更新情報５１に含まれている社員ＩＤ「３」を利用している連携システム３００Ａ〜３００Ｅを更新対象のシステムとして特定する。また、更新情報５１には、社員ＩＤ「３」の変更内容が「退職」であることが示されているので、特定部１７０は、連携システム３００Ａ〜３００Ｅに対して社員ＩＤ「３」の社員情報を削除すると判断する。

以上のようにして、特定部１７０は、更新対象のシステムと、各システムに対する更新内容を特定し、更新リスト５３を生成する。図３に示されるように、特定部１７０は、生成された更新リスト５３を決定部１８０に出力する。

（決定部１８０）
図４および図７を参照して、決定部１８０の機能について説明する。図７は、決定部１８０によって出力される処理順リスト５５の内容を示す図である。

決定部１８０は、連携システム間の依存関係と更新内容とに基づいて、各連携システムの依存先のシステムを決定する。このとき、決定部１８０は、上述のルール（１）〜（３）に従って、各連携システムの依存先のシステムを決定する。

たとえば、更新内容が「新規作成」である場合には、上述のルール（１）に従って、決定部１８０は、新規作成処理を実行する対象である連携システム３００Ａ〜３００Ｃにおいて、より上位階層にある連携システムを依存先のシステムとして判断する。なお、システム間の階層関係は、図４に示される通りである。その結果、図７の処理順リスト５５に示されるように、決定部１８０は、連携システム３００Ｃの依存先が上位層の連携システム３００Ｂであると判断する。同様に、決定部１８０は、連携システム３００Ｂの依存先が上位層の連携システム３００Ａであると判断する。

また、更新内容が「変更」である場合には、上述のルール（３）に従って、決定部１８０は、変更処理を実行する対象である連携システム３００Ｂ，３００Ｃの各々に、より上位階層にあるシステムを依存先のシステムとして判断する。その結果、図７の処理順リスト５５に示されるように、決定部１８０は、連携システム３００Ｃの依存先が上位層の連携システム３００Ｂであると判断する。

さらに、更新内容が「削除」である場合には、上述のルール（２）に従って、決定部１８０は、削除処理を実行する対象である連携システム３００Ａ〜３００Ｅの各々に対して、下位階層にあるシステムを依存先のシステムとして判断する。その結果、図７の処理順リスト５５に示されるように、決定部１８０は、連携システム３００Ａの依存先が下位層の連携システム３００Ｂ，３００Ｃであると判断する。同様に、決定部１８０は、連携システム３００Ｂの依存先が下位層の連携システム３００Ｃであると判断する。同様に、決定部１８０は、連携システム３００Ｅの依存先が下位層の連携システム３００Ｄであると判断する。

（更新部１９０）
図８〜図１０を参照して、更新部１９０の機能について説明する。図８および図９は、更新処理を実行する過程における処理順リスト５５の内容を示す図である。図１０は、本実施の形態に従うＩＤ統合システム１００と従来のＩＤ統合システムとにおける、更新処理を開始してから完了するまでの時間（以下、「更新時間」ともいう。）を比較した図である。より詳細には、図１０の比較結果（Ａ）が本実施の形態に従うＩＤ統合システム１００の更新時間を表わした図である。図１０の比較結果（Ｂ）が従来のＩＤ統合システムの更新時間を表わした図である。

更新部１９０は、上述の決定部１８０によって出力される処理順リスト５５を参照して、連携システム３００Ａ〜３００Ｅの各々の更新処理を実行する。このとき、更新部１９０は、依存するタスクが少ないタスクほど優先的に実行する。

図８の例では、更新部１９０は、まず、連携システム３００Ａに対する新規作成処理（タスクＮｏ１）、連携システム３００Ｂに対する変更処理（タスクＮｏ４）、連携システム３００Ｃに対する削除処理（タスクＮｏ８）、および連携システム３００Ｄに対する削除処理（タスクＮｏ９）を優先的に実行する。このとき、これらの更新処理は、互いに別のシステムで実行され得るので、更新部１９０は、これらの更新処理を並列に実行する。

別の言い方をすれば、更新部１９０は、ある社員情報（第１社員情報）の更新タイミングと他の社員情報（第２社員情報）の更新タイミングとが異なるシステム間で重なる場合には、第１社員情報と第２社員情報とを並列に更新する、これにより、処理時間を短縮することができる。

更新部１９０は、タスクＮｏ１，Ｎｏ４，Ｎｏ８，Ｎｏ９の各タスクにおける更新処理が完了したタイミングで、各タスクの「状態」を順に「完了」にする。同時に、更新部１９０は、終了したタスクを依存先のタスクから削除する。たとえば、タスクＮｏ１が完了すると、更新部１９０は、タスクＮｏ２の依存先のタスクから完了したタスクＮｏ１を削除する。同様に、更新部１９０は、タスクＮｏ５の依存先のタスクから完了したタスクＮｏ４を削除する。同様に、更新部１９０は、タスクＮｏ６，Ｎｏ１０の依存先のタスクから完了したタスクＮｏ９を削除する。同様に、更新部１９０は、タスクＮｏ７の依存先のタスクから完了したタスクＮｏ８を削除する。これにより、処理順リスト５５は、図９に示されるように更新される。

その結果、更新部１９０は、新たに、連携システム３００Ｂに対する新規作成処理（タスクＮｏ２）、連携システム３００Ｃに対する変更処理（タスクＮｏ５）、連携システム３００Ｂに対する削除処理（タスクＮｏ７）、および連携システム３００Ｅに対する削除処理（タスクＮｏ１０）を実行することが可能になる。このとき、タスクＮｏ２およびタスクＮｏ７は、同一の連携システム３００Ｂで実行されるので同時に実行され得ない。そのため、更新部１９０は、タスクＮｏ２およびタスクＮｏ７のいずれかと、タスクＮｏ５，Ｎｏ１０とを並列に実行する。

以上のようにして、更新部１９０は、連携システム３００Ａ〜３００Ｅの各々に社員情報の更新処理を並列に実行させる。その結果、図１０の比較結果（Ａ）に示されるように、ＩＤ統合システム１００は、時刻Ｔ１で更新処理を終了することができる。一方で、従来のＩＤ統合システムは、更新処理を順次実行するので、時刻Ｔ１よりも後の時刻Ｔ２で更新処理を終了する。このように、本実施の形態に従うＩＤ統合システム１００は、各タスクを並列に処理することにより、従来のＩＤ統合システムと比べて更新処理を短時間で完了することが可能になる。

［ＩＤ統合システム１００の制御構造］
図１１を参照して、第１の実施の形態に従うＩＤ統合システム１００の制御構造について説明する。図１１は、ＩＤ統合システム１００が実行する処理を表わすフローチャートである。図１１の処理は、ＩＤ統合システム１００のＣＰＵ１０２（図１２参照）がプログラム１３０（図３参照）を実行することにより実現される。他の局面において、処理の一部または全部が、回路素子、その他のハードウェアによって実行されてもよい。

ステップＳ１０において、ＣＰＵ１０２は、上述の依存関係受付部１５０（図３参照）として、システム間の依存関係の設定を受け付ける。

ステップＳ２０において、ＣＰＵ１０２は、上述の更新受付部１６０（図３参照）として、ＤＢサーバー４００から更新情報５１（図５参照）を受け付けたか否かを判断する。ＣＰＵ１０２は、ＤＢサーバー４００から更新情報５１を受け付けたと判断した場合（ステップＳ２０においてＹＥＳ）、制御をステップＳ２２に切り替える。そうでない場合には（ステップＳ２０においてＮＯ）、ＣＰＵ１０２は、ステップＳ２０の処理を再び実行する。

ステップＳ２２において、ＣＰＵ１０２は、上述の特定部１７０（図３参照）として、更新情報５１に基づいて、連携システム３００Ａ〜３００Ｅのうちから更新対象のシステムを特定する。

ステップＳ２４において、ＣＰＵ１０２は、上述の決定部１８０（図３参照）として、システム間の依存関係と更新内容とに基づいて、連携システム３００Ａ〜３００Ｅに保持されている社員情報のそれぞれについて更新順序を決定する。更新順序の決定方法は、上述の通りであるので説明を繰り返えさない。

ステップＳ２６において、ＣＰＵ１０２は、上述の更新部１９０（図３参照）として、決定された更新順序で連携システム３００Ａ〜３００Ｅに保持されている社員情報のそれぞれを更新する。

このとき、ＣＰＵ１０２は、ある社員情報（第１社員情報）の更新タイミングと他の社員情報（第２社員情報）の更新タイミングとが異なるシステム内で重なる場合には、第１社員情報と第２社員情報とを並列に更新する。また、ＣＰＵ１０２は、第１社員情報の更新順序と第２社員情報の更新順序とが同一のシステム内で重なる場合には、第１社員情報および第２社員情報のそれぞれに依存しているシステムの数が多い方の情報を優先的に更新する。

なお、ＣＰＵ１０２は、決定された更新順序で社員情報のそれぞれを順に更新する過程において更新処理が途中で失敗した場合には、システムに対する社員情報の以降の更新を行なわない。すなわち、ＣＰＵ１０２は、更新処理が途中で失敗した時点で、更新処理を中断する。

［管理システム５００のハードウェア構成］
図１２を参照して、管理システム５００のハードウェア構成の一例について説明する。図１２は、管理システム５００の主要なハードウェア構成を示すブロック図である。図１２に示されるように、管理システム５００は、ＩＤ統合システム１００と、連携システム３００と、ＤＢサーバー４００とを含む。連携システム３００は、上述の連携システム３００Ａ〜３００Ｅに対応する。ＩＤ統合システム１００、連携システム３００およびＤＢサーバー４００は、ネットワーク１４０を介して互いに接続されている。以下では、ＩＤ統合システム１００のハードウェア構成、連携システム３００のハードウェア構成、およびＤＢサーバー４００のハードウェア構成について順に説明する。

（ＩＤ統合システム１００のハードウェア構成）
図１２に示されるように、ＩＤ統合システム１００は、ＲＯＭ（Read Only Memory）１０１と、ＣＰＵ１０２と、ＲＡＭ（Random Access Memory）１０３と、ネットワークインタフェース（Ｉ／Ｆ）１０４と、モニタ１０５と、記憶装置１１０とを含む。

ＲＯＭ１０１は、オペレーティングシステム、ＩＤ統合システム１００で実行される制御プログラムなどを格納する。ＣＰＵ１０２は、オペレーティングシステム（ＯＳ：Operating System）やＩＤ統合システム１００の制御プログラムなどの各種プログラムを実行することで、ＩＤ統合システム１００の動作を制御する。ＲＡＭ１０３は、ワーキングメモリとして機能し、プログラムの実行に必要な各種データを一時的に格納する。

ネットワークＩ／Ｆ１０４には、アンテナ（図示しない）などが接続される。ＩＤ統合システム１００は、当該アンテナを介して、他の通信機器との間でデータを送受信する。他の通信機器は、たとえば、連携システム３００、ＤＢサーバー４００、その他の通信機器などを含む。ＩＤ統合システム１００は、本実施の形態に従う各種の処理を実現するためのプログラムをダウンロードできるように構成されてもよい。

モニタ１０５は、ＩＤ統合システム１００に格納されている社員情報を管理者が確認できる態様で表示する。なお、モニタ１０５は、タッチセンサ（図示しない）と組み合わされてタッチパネルとして実現されてもよい。タッチパネルは、ＩＤ統合システム１００で管理される社員情報の更新をタッチ操作によって受け付ける。

記憶装置１１０は、たとえば、ハードディスクや外付けの記憶装置などの記憶媒体である。一例として、記憶装置１１０は、本実施の形態に従う各種の処理を実現するためのプログラム１３０と、ＩＤ統合システム１００で管理されている社員情報２２２Ａ（図２参照）と、システム間の依存関係を示す情報とを格納する。プログラム１３０、社員情報２２２Ａ、および当該依存関係は、記憶装置１１０ではなく、ＤＢサーバー４００、他のサーバーに格納されてもよい。

なお、本実施の形態に従う各種の処理を実現するためのプログラム１３０は、単体のプログラムとしてではなく、任意のプログラムの一部に組み込まれて提供されてもよい。この場合、任意のプログラムと協働して本実施の形態に従う処理が実現される。このような一部のモジュールを含まないプログラムであっても、本実施の形態に従うＩＤ統合システム１００の趣旨を逸脱するものではない。さらに、本実施の形態に従うプログラム１３０によって提供される機能の一部または全部は、専用のハードウェアによって実現されてもよい。さらに、ＩＤ統合システム１００とサーバーとが協働して、本実施の形態に従う処理を実現するようにしてもよい。さらに、少なくとも１つのサーバーが本実施の形態に従う処理を実現する、所謂クラウドサービスのような形態でＩＤ統合システム１００が構成されてもよい。

（連携システム３００ハードウェア構成）
次に、連携システム３００のハードウェア構成について説明する。図１２に示されるように、連携システム３００は、ＲＯＭ２０１と、ＣＰＵ２０２と、ＲＡＭ２０３と、ネットワークＩ／Ｆ２０４と、記憶装置２１０とを含む。

ＲＯＭ２０１は、オペレーティングシステム、連携システム３００で実行される制御プログラムなどを格納する。ＣＰＵ２０２は、オペレーティングシステムや連携システム３００の制御プログラムなどの各種プログラムを実行することで、連携システム３００の動作を制御する。ＲＡＭ２０３は、ワーキングメモリとして機能し、プログラムの実行に必要な各種データを一時的に格納する。

ネットワークＩ／Ｆ２０４には、アンテナ（図示しない）などが接続される。連携システム３００は、当該アンテナを介して、他の通信機器との間でデータを送受信する。他の通信機器は、たとえば、ＩＤ統合システム１００、ＤＢサーバー４００、およびその他の通信機器などを含む。

モニタ２０５は、連携システム３００に格納されている社員情報を管理者が確認できる態様で表示する。なお、モニタ２０５は、タッチセンサ（図示しない）と組み合わされてタッチパネルとして実現されてもよい。タッチパネルは、連携システム３００で管理される社員情報の更新をタッチ操作によって受け付ける。

記憶装置２１０は、たとえば、ハードディスクや外付けの記憶装置などの記憶媒体である。一例として、記憶装置２１０は、連携システム３００で実行されるプログラムや、連携システム３００で管理されている社員情報２２２Ａ（図２参照）などを格納する。

（ＤＢサーバー４００のハードウェア構成）
次に、ＤＢサーバー４００のハードウェア構成について説明する。図１２に示されるように、ＤＢサーバー４００は、ＲＯＭ４０１と、ＣＰＵ４０２と、ＲＡＭ４０３と、ネットワークＩ／Ｆ４０４と、記憶装置４１０とを含む。

ＲＯＭ４０１は、オペレーティングシステム、ＤＢサーバー４００で実行される制御プログラムなどを格納する。ＣＰＵ４０２は、オペレーティングシステムやＤＢサーバー４００の制御プログラムなどの各種プログラムを実行することで、ＤＢサーバー４００の動作を制御する。ＲＡＭ４０３は、ワーキングメモリとして機能し、プログラムの実行に必要な各種データを一時的に格納する。

ネットワークＩ／Ｆ４０４には、アンテナ（図示しない）などが接続される。ＤＢサーバー４００は、当該アンテナを介して、他の通信機器との間でデータを送受信する。他の通信機器は、たとえば、ＩＤ統合システム１００、連携システム３００、およびその他の通信機器などを含む。

モニタ４０５は、ＤＢサーバー４００に格納されている社員情報を管理者が確認できる態様で表示する。なお、モニタ４０５は、タッチセンサ（図示しない）と組み合わされてタッチパネルとして実現されてもよい。タッチパネルは、ＤＢサーバー４００で管理される社員情報の更新をタッチ操作によって受け付ける。

記憶装置４１０は、たとえば、ハードディスクや外付けの記憶装置などの記憶媒体である。一例として、記憶装置４１０は、ＤＢサーバー４００で実行されるプログラムや、ＤＢサーバー４００で管理されている社員情報などを格納する。

＜第２の実施の形態＞
［概要］
第１の実施の形態に従うＩＤ統合システム１００は、各タスクの状態に基づいて各システムの社員情報を動的に更新した。これに対して、第２の実施の形態に従うＩＤ統合システム１００は、連携システム間の依存関係に基づいて、各連携システムの更新順序を一括で決定する。なお、第２の実施の形態に従うＩＤ統合システム１００のハードウェア構成などその他の点については第１の実施の形態に従うＩＤ統合システム１００と同じであるので、それらの説明は繰り返さない。

以下では、図１３および図１４を参照して、第２の実施の形態における更新順序の決定方法について説明する。図１３は、第２の実施の形態における処理順リスト５５Ａの内容を示す図である。図１４は、連携システム３００Ａ〜３００Ｅにおいて実行される更新処理を時系列の順に示した図である。

本実施の形態に従うＩＤ統合システム１００は、下記のルール（４）〜（６）に基づいて、各連携システムの更新順序を決定する。

ルール（４）：ＩＤ統合システム１００は、依存するタスクがより少ないタスクほど優先的に実行する。

ルール（５）：更新順序がルール（４）で一意に決まらない場合には、ＩＤ統合システム１００は、依存されているタスクの数（以下、「被依存タスク数」ともいう。）がより多いタスクを優先的に実行する。

ルール（６）：更新順序がルール（５）で一意に決まらない場合には、ＩＤ統合システム１００は、依存されているタスクの深さがより深いタスクを優先的に実行する。ここでいう「深さ」とは、依存されている一連のタスク数のことをいう。

図１３の例では、ＩＤ統合システム１００は、上記ルール（４）に従って、依存するタスクがより少ない、すなわち依存するタスクがないタスクＮｏ１，Ｎｏ４，Ｎｏ８，Ｎｏ９を他のタスクよりも優先的に実行する。

次に、ＩＤ統合システム１００は、更新順序が一意に決まらなかったタスクＮｏ１，Ｎｏ４，Ｎｏ８，Ｎｏ９に対して、上記ルール（５）を適用する。タスクＮｏ１においては、被依存タスク数は、タスクＮｏ２およびタスクＮｏ３の２つである。タスクＮｏ４の被依存タスク数は、タスクＮｏ５の１つである。タスクＮｏ８の被依存タスク数は、タスクＮｏ６およびＮｏ７の２つである。タスクＮｏ９の被依存タスク数は、タスクＮｏ６およびＮｏ１０の２つである。ＩＤ統合システム１００は、被依存タスク数がより多いタスクＮｏ１，Ｎｏ８，Ｎｏ９をタスクＮｏ４よりも優先的に実行する。その結果、ＩＤ統合システム１００は、タスクＮｏ４を４番目に実行する。

次に、ＩＤ統合システム１００は、タスクＮｏ１，Ｎｏ８，Ｎｏ９に対して、上記ルール（６）を適用する。タスクＮｏ１は、タスクＮｏ２を介してタスクＮｏ３に間接的に依存されている。そのため、タスクＮｏ１の被依存タスクの深さは、「２」である。タスクＮｏ８は、タスクＮｏ７を介してタスクＮｏ６に間接的に依存されている。そのため、タスクＮｏ８の被依存タスクの深さは、「２」である。タスクＮｏ９においては、タスクＮｏ６，Ｎｏ１０に直接的に依存されている。そのため、タスクＮｏ９の被依存の深さは、「１」である。ＩＤ統合システム１００は、被依存タスクの深さがより深いタスクＮｏ１，Ｎｏ８をタスクＮｏ９よりも優先的に実行する。その結果、ＩＤ統合システム１００は、タスクＮｏ９を３番目に実行する。

なお、ルール（４）〜（６）で実行順序が決まらなかったタスクＮｏ１，Ｎｏ８については、いずれのタスクが先に実行されてもよい。図１３の例では、ＩＤ統合システム１００は、タスクＮｏ８よりもタスクＮｏ１を優先的に実行している。すなわち、ＩＤ統合システム１００は、タスクＮｏ１を１番目に実行し、タスクＮｏ８を２番目に実行する。

ＩＤ統合システム１００は、ルール（４）〜（６）を処理順リスト５５Ａに規定されている全てのタスクについて適用し、各タスクの実行順序を決定する。これにより、ＩＤ統合システム１００は、図１４に示される順番でタスクＮｏ１〜Ｎｏ１０を実行する。

＜第３の実施の形態＞
上述したように、更新処理は、社員情報の登録処理、削除処理、および変更処理を含む。ここで、第１の実施の形態においては、社員情報の変更処理は、上書き処理による変更を前提としていた。しかしながら、連携システムによっては、変更処理が上書き処理で実現され得ない場合がある。この場合、ＩＤ統合システム１００は、既存の社員情報を削除した後に、変更後の社員情報を連携システム内で新規作成することで変更処理を実現する。すなわち、変更処理は、社員情報の削除処理と、新たな社員情報の新規作成処理とで実現される。第３の実施の形態に従うＩＤ統合システム１００は、当該削除処理と当該新規作成処理とのいずれを優先するかの設定を受け付ける。

たとえば、ＩＤ統合システム１００は、一意性制約のあるデータ（ユニークデータ）を変更する場合には、当該データを削除した後でないと、当該データの内容を変更することができない。そのため、ＩＤ統合システム１００は、当該データの削除処理を実行し、その後に、変更後のデータの新規作成処理を実行する。このような場合には、ＩＤ統合システム１００は、削除処理を新規作成処理よりも優先するために、新規作成処理を削除処理に依存させる。

一方で、ＩＤ統合システム１００は、一意性制約のないデータを変更する場合には、当該データの削除処理よりも当該データの新規作成処理を優先する。なぜならば、削除処理が新規作成処理よりも先に実行された場合において、処理中に問題が生じたときには、削除されたデータを復元できないからである。このような場合には、ＩＤ統合システム１００は、削除処理よりも新規作成処理を優先するために、削除処理を新規作成処理に依存させる。

＜第４の実施の形態＞
第４の実施の形態に従うＩＤ統合システム１００は、同一システム内で処理可能なタスクが複数ある場合は、依存されているタスクがより多いタスクを優先的に実行する。言い換えると、ＩＤ統合システム１００は、ある社員情報（第１社員情報）の更新タイミングと他の社員情報（第２社員情報）の更新タイミングとが同一のシステム内で重なる場合には、第１社員情報および第２社員情報のそれぞれに依存している連携システムの数が多い方の情報を優先的に更新する。これにより、ＩＤ統合システム１００は、依存されているタスクの数が多いタスクを優先的に実行できるようになり、後に続くタスクの実行を早めることができる。その結果、ＩＤ統合システム１００は、全体の処理時間を短縮することができる。

今回開示された実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。

５１ 更新情報、５３ 更新リスト、５５，５５Ａ 処理順リスト、１００ 統合システム、１０１，２０１，４０１ ＲＯＭ、１０２，２０２，４０２ ＣＰＵ、１０３，２０３，４０３ ＲＡＭ、１０４，２０４，４０４ ネットワークＩ／Ｆ、１０５，２０５，４０５ モニタ、１１０，２１０，４１０ 記憶装置、１２２Ａ，２２２Ａ 社員情報、１４０，１４０Ａ，１４０Ｂ ネットワーク、１５０ 依存関係受付部、１６０ 更新受付部、１７０ 特定部、１８０ 決定部、１９０ 更新部、３００Ａ〜３００Ｅ 連携システム、４００ ＤＢサーバー、５００ 管理システム、Ｎｏ１〜Ｎｏ１０ タスク、Ｔ１，Ｔ２ 時刻。

Claims (10)

1. 管理システムであって、
   互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムと、
   前記複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるための第１受付部と、
   前記第１受付部が前記更新を受け付けたときに、前記依存関係と前記更新の内容とに基づいて、前記複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するための決定部と、
   前記決定部によって決定された更新順序で前記複数のシステムに保持されている第１情報のそれぞれを更新するための更新部とを備える、管理システム。
2. 前記管理システムは、前記依存関係の入力を受け付けるための第２受付部をさらに備える、請求項１に記載の管理システム。
3. 前記決定部は、
   前記依存関係と前記更新の内容とに基づいて、前記複数のシステムの各々について、依存先のシステムを特定し、
   前記依存先のシステムにおける第１情報を優先的に更新するように前記更新順序を決定する、請求項１または２に記載の管理システム。
4. 前記更新の内容は、前記第１情報の新規作成と、前記第１情報の削除とを含み、
   前記複数のシステムは、互いに階層関係を有し、
   前記決定部は、
   前記更新の内容が前記第１情報の新規作成である場合には、前記複数のシステムの各々について、当該システムよりも階層が上位にあるシステムを前記依存先のシステムとして特定し、
   前記更新の内容が前記第１情報の削除である場合には、前記複数のシステムの各々について、当該システムよりも階層が下位にあるシステムを前記依存先のシステムとして特定する、請求項３に記載の管理システム。
5. 前記更新の内容は、前記第１情報の変更を含み、
   前記変更は、前記第１情報の削除処理と、新たな第１情報の新規作成処理とで実現され、
   前記管理システムは、前記削除処理と前記新規作成処理とのいずれの処理を優先するかの設定を受け付ける、請求項１〜４のいずれか１項に記載の管理システム。
6. 前記更新部は、前記決定部によって決定された更新順序で前記複数のシステムに保持されている第１情報のそれぞれを順に更新する過程において更新処理が途中で失敗した場合には、システムに対する第１情報の以降の更新を行なわない、請求項１〜５のいずれか１項に記載の管理システム。
7. 前記複数のシステムは、互いに関連する第２情報をそれぞれ保持し、
   前記決定部は、前記依存関係と前記第２情報に対する更新の内容とに基づいて、前記複数のシステムに保持されている第２情報のそれぞれの更新順序をさらに決定し、
   前記更新部は、前記第１情報の更新タイミングと前記第２情報の更新タイミングとが異なるシステム間で重なる場合には、前記第１情報と前記第２情報とを並列に更新する、請求項１〜６のいずれか１項に記載の管理システム。
8. 前記更新部は、前記第１情報の更新タイミングと前記第２情報の更新タイミングとが同一のシステム内において重なる場合には、前記第１情報および前記第２情報のそれぞれに依存しているシステムの数が多い方の情報を優先的に更新する、請求項７に記載の管理システム。
9. 管理システムの制御方法であって、
   前記管理システムは、互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムを備え、
   前記制御方法は、
   前記複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるステップと、
   前記更新を受け付けたときに、前記依存関係と前記更新の内容とに基づいて、前記複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するステップと、
   前記更新順序で前記複数のシステムに保持されている第１情報のそれぞれを更新するステップとを備える、制御方法。
10. 管理システムの制御プログラムであって、
    前記管理システムは、
    プロセッサと、
    互いに関連する第１情報をそれぞれ保持し、互いの第１情報の更新順序に依存関係を有する複数のシステムとを備え、
    前記制御プログラムは、前記プロセッサに、
    前記複数のシステムのうちのいずれかの第１情報に対する更新を受け付けるステップと、
    前記更新を受け付けたときに、前記依存関係と前記更新の内容とに基づいて、前記複数のシステムに保持されている第１情報のそれぞれの更新順序を決定するステップと、
    前記更新順序で前記複数のシステムに保持されている第１情報のそれぞれを更新するステップとを実行させる、制御プログラム。

Images