業務連携制御装置
【課題】 システム障害等による連携システム間の影響度を即座に把握し、システム運行スケジュールの再調整を速やかに可能とすること。
【解決手段】 複数の業務処理の開始時刻、終了時刻などの業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、各業務処理を実行する情報処理システム名、処理名などから成る処理連携関係情報を受付け、業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成して再開させる第４の手段とを備える。
【解決手段】 複数の業務処理の開始時刻、終了時刻などの業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、各業務処理を実行する情報処理システム名、処理名などから成る処理連携関係情報を受付け、業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成して再開させる第４の手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数また単数からなる情報処理システムにおいて、それら情報処理システム内または複数の情報処理システムにおいて実行される業務処理の連携制御管理を行う業務連携制御装置に関する。
【背景技術】
【０００２】
単数または複数からなる情報処理システム間にわたる業務の統合方法としては、下記の特許文献１のものがあげられる。
下記の特許文献１のものであれば、既存システムや関連する既存業務を容易に統合する仕掛けを提供し、統合業務として各業務をトランザクションを連携実行し管理する方法により、システムの性能低下を無くすことを目的にしている。
しかしながら、統合業務として複数のシステムを統一的に管理するのであれば、総合業務装置に接続されている各情報処理システムの運行スケジュールを詳細に把握し、各システムへのデータ転送等に使用される、ネットワーク機器や、情報処理システムが使用している演算装置、主記憶装置、出力装置、記憶媒体などのリソースの奪い合いによるシステム処理性能の低下を防止することが可能でなければ、統合業務として各システムを集中管理する意味合いが薄れてしまう。
【特許文献１】特開２００１−３４５９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
組織内は特定の目的を果たすための各種情報処理システムが複数存在する。今日においては、情報処理システムＡでの実行結果を情報処理システムＢの入力情報と使用し実行結果を得るような運用形態をとる場合が多い。
このように複数の情報処理システムを使用し、特定の結果を得るために、複数の情報処理システムをネットワークを介して接続し、入力データや処理結果を情報処理システム間においてやり取りすることは、いまや、あたりまえの運用形態となっている。
【０００４】
情報処理システムのダウンサイジング化により、それぞれの情報処理システムが特定の機能を持つものだけに分割されていき、組織内で稼動する情報システムは増えつづける一方である。また、それらを運用管理する部署が組織内に複数存在し、システム運用管理者も複数存在する。
ある業務を処理するにあたり、連携する他の情報処理システムや、それら情報処理システムの運行スケジュールを正しく認識している運用管理者は意外と少ない。
ここで、「業務」とは、各システムが独立して実行する各々の業務ではなく、複数のシステムにて行われる複数の処理からなる一連の情報処理を指す。
【０００５】
各情報処理システムは、予め定義された運行スケジュールによって稼動している。この運行スケジュールを決定する際に考慮される、その他の情報処理システムは、直接データをやり取りすることが必要である情報処理システムのみであることが多い。
【０００６】
組織内において、稼動する情報処理システムが増加するに伴って、各情報処理システムにおいて実行される各種業務の処理結果や、運行スケジュールが他の情報処理システムの運行状況に影響をあたえるケースも増加してきている。
【０００７】
前述したように、各情報処理システムの運用管理者は各自が管理する情報システムと直接連携する前後の情報処理システムしか意識しておらず、各自が担当する情報処理システムに何らかの原因により性能低下やそれに起因する運行スケジュールの変更があった場合において、直接やり取りする前後のシステムの運行スケジュールへの影響のみを考慮するにとどまる。
【０００８】
ある情報処理システムにおいて、障害が発生した場合に情報処理システム運用管理者がとる行動パターンを図８に示す。
図８において、障害が発生した場合、担当システムの入力データを生成すべきシステムの運用管理者からシステムの性能低下により入力データの生成が遅れるとの連絡を受ける（ステップ８０１）。
次に、出力結果を渡すべきシステムの運用管理者に他システムに起因する処理の遅れが発生することを連絡する（ステップ８０２）。
次に、各自が運用管理を担当するシステムの運行スケジュールを確認し、影響度を調査する（ステップ８０３）。
次に、スケジュールの変更が必要かを判断し（ステップ８０４）、必要であれば、担当システムの変更スケジュールを作成し、処理スケジュール案として連携先システムの運用管理者に提示する（ステップ８０５）。必要がなければ、ステップ８０７に進む。
次に、運用管理者間において、合意がなされるまでスケジューリングの調整を行い。業務間連携スケジュールを作成する（ステップ８０６）。
これにより、担当システムの処理実行が可能となり、処理を実行する（ステップ８０７）。
次に、連携先システムの有無を判断し、なければ処理を終了し、あればステップ８０２に戻る（ステップ８０８）。
図８から明らかなように、情報処理システムのスケジュール調整を行うのは人的作業であり、この作業を複数の情報システム運用管理者がそれぞれ実施するのが現状である。
このような人的作業は、組織内に情報処理システムが多く存在する組織ほど複雑になっていく。この作業が増大及び複雑化が進むにつれ、対象業務の正常化には時間を要することとなる。
【０００９】
運行スケジュールが乱れることは、各情報処理システムがネットワークを介して接続されている状態において、ネット―ワーク上を伝送されるデータが予定しているトラフィック量を超えることの原因にもなり得る。
トラフィックの増加はルータやハブ、ＳＳＬ暗号化装置、ファイヤーウォール等のネットワーク機器の負荷を増大させ、そのことが情報処理システム間の連携において新たな障害を生み出すことにもつながる。
【００１０】
複数の情報処理システムを連携して、ひとつの業務を処理するためには、情報処理システム間、業務間、処理間のスケジューリングが重要である。
従来、人的作業によって非効率に行われてきたこの人的作業を、効率よく実現する工夫が必要である。
【００１１】
図９は、従来の方法を用いて複数の情報処理システムにまたがり、一連の業務を実行する場合の例を示す図である。
各処理を実行するシステム１（９１０）、システム２（９２０）、システム３（９３０）とから構成されている。それぞれのシステムにて実行される処理がそれぞれ単一の処理（９４０）、（９５０）、（９６０）であり、これらの処理結果は（９７０）、（９８０）、（９９０）とされ、各システムはそれらの処理結果を処理の入力情報として使用する。
図９において、各処理は番号順に時系列にしたがって実行されるものとする。図９において処理結果（９７０）を生成する処理は（９４０）である。この処理結果（９７０）を入力として使用するシステムはシステム２（９２０）であり、その処理は（９５０）のみである。
システム１（９１０）に障害が発生した場合、処理（９４０）は実行されない。システム２（９２０）の処理（９５０）は処理結果（９７０）を入力とするので、実行可能状態にない。この場合、システム３（９３０）はシステム２（９２０）の処理（２５０）にて生成される処理結果（９８０）を必要とするが、システム１（９１０）が障害のため処理実行が不可能となる。
【００１２】
システム１（９１０）、２（９２０）、３（９３０）のシステム運用管理者が同一でない場合、システム３（９３０）のシステム運用管理者は、システム３（９３０）の処理（９６０）が実行不可能である原因は入力データ（９８０）がシステム２（９２０）から伝送されてこない事しかわからない。
システム１（９１０）が連携するシステムは、システム２（９２０）のみであるので、処理結果（9７０）がシステム２（９２０）を介してどのように使用されるのかはわからない。
【００１３】
上記のような事態が発生した場合、システム１（９１０）のシステム運用管理者が現状分析実施後、全てのシステム運用管理者に対応方針を伝え、各システムの運行スケジュールの調整を依頼することとなる。
また、連携対象システムのシステム運用管理者がすべて同一であった場合においても、各システムの運行スケジュールを調整するために、各システムの運行スケジュールや、障害の影響度を各システム単位に調査し、システム単位で運行スケジュールを再設定しなければならない。
このような作業を人的作業にて行うことは、効率的ではなく、対象システムが増大するほど影響度も大きくなる。
【００１４】
本発明の目的は、システム障害等による連携システム間の影響度を即座に把握し、システム運行スケジュールの再調整を速やかに可能とする業務連携制御装置を提供することにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明に係る業務連携制御装置は、他の情報処理システムの処理結果を引き継いで所定の業務処理を連携して実行する複数の情報処理システムにおける業務処理の連携制御を行う業務連携制御装置であって、
複数の業務処理のそれぞれの開始時刻、終了時刻、先行業務処理名、後続業務処理名から成る業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、
各業務処理を実行する情報処理システム名、処理名および処理必要時間、先行処理名、後続処理名から成る処理連携関係情報を管理者端末から受付け、前記業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成し、前記処理連携管理テーブルに登録し、再作成した連携スケジュールに従って処理を再開させる第４の手段とを備えることを特徴とする。
そして、前記第１の手段は、複数の業務処理を表す図形を表示装置画面上で時間軸に沿って配置する操作によって連携関係を定義する機能を備えていることを特徴とする。
また、前記第３の手段は、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に時間軸に沿って図形表示する機能を備えていることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、複数の情報処理システムが例えばネットワークを介して接続可能状態にある場合において、各情報処理システムにおける各処理の連携スケジュールを作成し、一元的に管理し、処理を実行させる。
そして、いずれかの情報処理システムに障害が発生した場合、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する。
これにより、影響を受けうる情報処理システムとそのシステムにおいて実行される処理、および、関連する業務を特定することが可能となり、システム障害等による連携システム間の影響度を即座に把握し、システム運行スケジュールの再調整を速やかに実施可能になる。
直接的な効果として、人的作業の効率化、間接的な効果として、システムリソースの有効活用が可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一形態を図面を参照して説明する。
図１は、本発明に係るシステム連携制御装置を使用したシステムの全体構成を示す図である。
本システムは、システム連携制御装置（１００）と、分散型情報処理システム１（１１０）と、分散型情報処理システム（１２０）と、分散型情報処理システム（１３０）と統合業務装置（１Ａ１）それらを物理的に接続するネットワーク機器（図示せず）により構成される。
図１においてシステム１の処理（１４０）からシステム３の処理（１６０）までを「１業務」と定義する。
【００１８】
システム連携制御装置（１００）は、統合業務装置（１０１）との連携インタフェースを持ち、統合業務装置（１０１）が監視対象とする各システム１〜３の障害情報、運行状態（処理状況）を元にシステムの運行スケジュールを管理するシステム運行管理手段１０１を備えている。
【００１９】
複数システムの運行スケジュールを統一的に管理制御するには、各システム１（１１０）、２（１２０）、３（１３０）にて実行される処理と、それらの出力結果およびそれらのインプットデータを統合的に管理しなくてはならない。
また、これらには統合的なＩＤを割り当てる必要がある。割り当てられた統合的な処理ＩＤおよび業務ＩＤは、システム連携制御装置（１００）の記憶装置内に設けられるシステム運行管理テーブル１０４において管理される。この登録処理を行う手段は任意のものでよい。
【００２０】
システム運行管理手段（１０１）の特徴について説明する。
システム運行管理手段（１０１）は、複数業務のスケジュールと業務内連携におけるスケジュールを管理する機能を持つ。本説明において「業務内連携」とは図１に示すような業務内の処理単位の連携を指す。
まず、連続する業務の運行スケジュールの作成について説明する。
【００２１】
連続する業務の運行スケジュールについては、システム連携制御装置（１００）に設けられるスケジュールデザイナー手段（１０２）を使用し、業務の運行スケジュールを決定する。
図２にスケジュールデザイナー手段のモデル図を示す。
スケジュールデザイナー手段（１０２）は、業務運行スケジュール定義画面（２１０）をシステム連携制御装置（１００）のシステム運用管理者端末（以下、管理者端末）上に表示し、システム運用管理者が、各業務のスケジュールを決定・修正が可能であり、表示される情報は、時間を縦軸に備え、業務名称が記述されている箱型の図形の大きさがその業務に要する実行時間であることを指し、線で結ばれている業務が連携対象業務であり、それらの実行順序が見て取れる要件を満たすこととする。
スケジュールデザイナー手段（１０２）にて業務実行スケジュールおよび連携情報を登録すると、システム連携制御装置（１００）の内の記憶装置内に設けられた業務間連携管理テーブル（２Ｔ１）に情報が登録される。
図２に例示する業務間連携管理テーブル（２Ｔ１）には、業務ＩＤ、業務種別、業務前連携業務ＩＤ、業務後連携業務ＩＤ、業務開始時刻、業務終了時刻が登録されるようになっている。
【００２２】
業務スケジュールの決定後、システム運用管理者は業務内処理の連携定義を行う。
業務内の処理フローの決定は、スケジュールデザイナー手段（１０２）の図３に示す処理連携フロー定義画面（３１０）により行う。この機能にて定義された情報は、システム連携制御装置（１００）の内の記憶装置内に設けられた処理連携管理テーブル群（３Ｔ１）に反映される。
処理連携管理テーブル群（３Ｔ１）は、図３に示すように、業務構成テーブルモデル（３Ｔ３）、処理テーブルモデル（３Ｔ４）、処理連携管理テーブルモデル（３Ｔ２）で構成され、業務構成テーブルモデル（３Ｔ３）には業務ＩＤ，システムＩＤ、処理ＩＤの関係が登録される。
また、処理連携管理テーブルモデル（３Ｔ２）には、システムＩＤ、処理ＩＤＦ、処理開始時刻、処理終了時刻が登録され、処理管理テーブルモデル（３Ｔ４）には処理ＩＤ、入力処理ＩＤ、出力処理ＩＤ、必要時間、予備時間が登録される。なお、処理連携管理テーブルモデル（３Ｔ２）には、業務１の処理以外にも各システムに多数スケジューリングされているので（処理ＩＤ３ＸＸ）、各システムの運用責任者は、自システムにスケジューリングされている処理がどの業務の処理かについて、常時把握している訳ではない。
【００２３】
スケジュールデザイナー手段（１０２）によって定義された情報は、システム運行管理手段（１０１）が保持するシステム運行管理テーブル（１０２）に格納され、システム連携制御に使用される情報を構成する。
システム運行管理手段（１０１）が保持するシステム運行管理テーブル（１０２）を構成するデータの例を図４に示す。
これらのテーブル構成情報に、統合業務装置（１Ａ１）が各システムを監視しており、その運行状況の情報から得ることのできる各種情報（処理ＩＤ、トランザクションＮｏ、トランザクション結果）を反映させる。
【００２４】
決定されたスケジュール情報をもとに、システム連携制御装置（１００）は、統合業務装置（１Ａ１）に処理の実行を許可する信号を送る。
統合業務装置（１Ａ１）は、各システムの処理実行と処理結果を監視しているので、システム連携制御装置（１００）にて、各システム１（１１０）、２（１２０）、３（１３０）の処理実行制御機能を保持する必要はない。
システム連携制御装置（１００）と統合業務装置（１Ａ１）とを接続するインタフェースについては、導入されている統合業務装置（１Ａ１）のインタフェースに依存するとし、システム連携制御装置（１００）は任意のインタフェースを介して統合業務装置（１Ａ１）と連携するものとする。
【００２５】
一連の業務定義および処理定義が完了したことで、統合業務装置（１Ａ１）によって管理されている処理について、システム連携制御装置（１００）にて確認することが可能となる。
図５に本発明のシステム運行状況確認画面モデル図を示す。
システム運用管理者は、システム連携制御装置（１００）のビューア手段（１０３）にて、定義済みの業務間スケジュールおよび、業務内処理スケジュールに合わせた実行状況等を、システム運用管理者端末上に表示させ、業務連携確認画面モデル（５１０）を確認することで、現時点での運行スケジュールを確認することができる。
システム連携制御装置（１Ａ１）に接続することのできる条件を備えていれば、システム１〜３の各運用管理者が複数であっても、各システム１〜３の運用管理者のクライアント端末にて現在の実行状況および、全体スケジュールから詳細スケジュールまでを閲覧可能にすることができる。
【００２６】
業務連携確認画面モデル（５１０）においては、障害が発生している業務をシステム運用管理者に識別可能な情報を表示して警告する。もし、当該業務に関連するシステムが別々のシステム運用管理者によって管理されている場合、当該警告は関連する全てのシステム運用管理者に対してなされるものとする。
図５に例示する業務連携確認画面モデル（５１０）においては、「業務１」の箱が変色されて表示される。「業務１」の箱を拡大表示させる操作を行うと、業務内連携確認画面モデル（５２０）が表示され、その中に、異常終了したシステム名称、処理ＩＤ、エラーコードなどの詳細な状況が表示される。
業務内連携確認画面モデル（５２０）は、統合制御装置（１Ａ１）にて取得する各情報処理システム１〜３の現在実行中の処理ＩＤ、実行終了の処理ＩＤ、処理ＩＤ単位の処理結果などをシステム連携制御装置（１００）が受け取り、その情報を表示している。
図５には、業務ＩＤ、システムＩＤ、ＥＲＲＣＯＤＥ、開始時間、終了時間、トランザクションＮｏのみを表示した例を示している。
業務内連携確認画面モデル（５２０）を参照した場合、「業務１」において現在の状況が、システム１の処理ＩＤ３４０正常終了後、システム２の処理ＩＤ３５０にて異常終了し、その原因がＥＲＲＣＯＤＥ：ＥＳ０２０００１であることが確認できる。また、その後影響を与える処理としてシステム３の処理ＩＤ３６０が存在することが確認できる。
【００２７】
図５のような業務連携確認画面モデル（５１０）の状況になった場合、システム運用管理者が行うべき作業は、業務単位の再スケジューリングとシステム運行の再スケジューリングをすることである。図１において、このような場合の作業フローを提示したが、システム連携制御装置（１００）はスケジュールデザイナー手段（１０２）を用いることで、人的負荷を軽減させる。
【００２８】
システム連携制御装置（１００）が管理するシステム運行管理テーブル内には、図３に例示したように、処理の開始時刻、処理に必要とされる時間、その処理から次の処理へ移るまでの予備時間とそれら処理の集合からなる業務の開始時刻、それら処理の実行時間と予備時間を合計して算出される業務必要時間と業務全体での終了時刻を保持している。
障害が発生した場合、業務内の処理連携フローをこれらの情報から再生成する。
この処理連携フローを再生成するには、障害が発生している処理の復旧時間を見極めなくてはならない。図５のケースでは、障害はシステム２の処理３５０で発生しているので、システム２のシステム運用管理者は、処理３５０の運用関係者と連携を取って、障害回復に必要とされる時間を算定する。障害回復に必要とされる時間が決定したら、この処理のリスタート時間をスケジュールデザイナー手段（１０２）を使用してシステム連携制御装置（１００）に登録する。
この場合は、障害発生前に登録してあった処理開始時刻を処理再開可能時刻に合わせればよい。
システム連携制御装置（１００）は、対象処理のリスタート時間を基準にして、処理連携テーブル群（３Ｔ１）を再構築する。そして、再構築された処理連携テーブル群（３Ｔ１）から業務間連携テーブル（２Ｔ１）を再構築する。この情報を元に、今回適用される業務運行スケジュールを自動生成し、システム運用管理者の端末に表示する。表示された新規の業務運行スケジュールはスケジュールデザイナー手段（１０２）によって修正が可能であるので、提示されたスケジュールを修正することも可能である。
【００２９】
システム連携制御装置（１００）のアクションフローを図６に示す。
システム連携制御装置（１００）が行う機能の特徴は、統合業務装置（１Ａ１）にて管理対象となるシステムの業務と、業務を構成する処理、複数の業務からなる情報処理のスケジュールをデータとして保持し、それらのスケジュールを図表形式にて表示する機能と、図表を加工する形でスケジュールを修正できる機能と、その図表形式でのデータをテーブル情報として保存することができることである。
図６に示す一連の処理において、人的作業は、ステップ（６０６）、（６１０）の判断と（６０８）、（６１１）の図表修正のみである。それ以外の処理はシステム連携制御装置（１００）のプログラムが行うものである。
【００３０】
図６において、まず、障害が発生した業務を含む業務連携スケジュールを表示し（ステップ６０１）、さらに障害が発生した処理を含む処理連携フローを表示し（ステップ６０２）、障害発生処理の再スタート時刻の入力を待つ（ステップ６０３）。
再スタート時刻が管理者端末から入力されたならば、その再スタート時刻を基準点として、処理連携管理テーブル群（３Ｔ１）を再構築する（ステップ６０４）。
次に、再構築された処理連携管理テーブル群（３Ｔ１）から処理連携フローを再生成し、管理者端末に表示する（ステップ６０５）。
次に、再生成された処理連携フローを採用するかを障害システムの運用管理者及び後続処理のシステム運用管理者に確認させ（図５の例ではシステム２，３の運用管理者）、全てのシステム運用管理者から採用する旨の指示があったならば（ステップ６０６）、業務間連携テーブル（２Ｔ１）を再構築する（ステップ６０７）。
再生成された処理連携フローを不採用とする旨の指示がいずれかのシステム管理者から入力された場合は、
再生成された処理連携フローをシステム管理者からの指示に従って修正する（ステップ６０８）。
この後、再構築された業務間連携テーブル（２Ｔ１）から業務連携スケジュールを再生成し、管理者端末に表示する（ステップ６０９）。
そして、再生成された業務連携スケジュールを採用するかを当該業務に関連するシステム運用管理者及び後続業務に関連するシステム運用管理者に確認させ（図５の例ではシステム１，２，３の運用管理者）、全てのシステム運用管理者から採用する旨の指示があったならば（ステップ６１０）、生成された連携制御情報を統合業務装置（１Ａ１）に転送する（ステップ６１２）。
しかし、再生成された業務連携スケジュールを不採用とする旨の指示がいずれかのシステム管理者から入力された場合は、再生成された業務連携スケジュールをシステム管理者からの指示に従って修正する（ステップ６１１）。
【００３１】
システム連携制御装置（１００）のプログラム処理フローを図７に示す。
図７は、システム運用管理者が決定した再スタート時刻を基準時刻として、各種テーブルに保持している情報より、新規スケジュールを決定するプログラムの処理ステップを簡略的に示している。
まず、システム運用管理者が決定した再スタート時刻を受け付け（ステップ７０１）、処理必要時間と予備時間を保持している図４のテーブル（３Ｔ３）から取得し、合算した時間を合計時間として算出し、基準時刻（再スタート時刻）に加算し、算出された時刻をその処理の新終了時刻として決定する（ステップ７０２）。
対象処理に出力処理ＩＤとして連携すべき処理ＩＤが定義されていた場合（ステップ７０３）、新処理終了時刻がテーブル（３Ｔ２）に登録されている処理開始時刻より後であれば、それより前の時刻になるように再スタート時刻を再度入力させる（ステップ７０４）。
しかし、新終了時刻がテーブル（３Ｔ２）に登録されている開始時刻より前になる場合は、新終了時刻が求められた処理を対象として処理連携テーブル（３Ｔ１）の開始時刻と終了時刻を更新する（ステップ７０５）。
全ての業務内処理の新開始時刻が決定されたならば、処理連携管理テーブル群（３Ｔ１）に登録されたデータをもとに、新処理連携フローを生成し、管理者端末に表示する（ステップ７０６）。
この時点においてシステム管理者が人的判断にて、スケジュールの修正をする場合は（ステップ９０７）、スケジュールデザイナー手段（１０２）を使用して調整する（ステップ７０７、７０８）。
最終的に決定された処理連携スケジュールは、システム連携制御装置（１００）のメモリ上またはディスク上の領域に一次保存される（ステップ７０９）。
一次保存された処理連携スケジュールの最終処理の終了時刻が業務連携スケジュールにおける対象業務の新業務終了時刻としてメモリ上またはディスク上に一次保存される（ステップ７１０）。
【００３２】
次に、テーブル（２Ｔ１）を参照し、後連携する業務があれば（ステップ７１１）、後業務の業務開始時刻と新業務終了時刻を比較する（ステップ７１２）。新業務終了時刻が後業務の開始時刻前であれば、連携する以降の業務のスケジュール変更は発生しない。
しかし、新業務終了時刻が後業務の開始時刻以降であるならば、新業務終了時刻を基準時間として、業務構成テーブルモデル（３Ｔ３）に登録されている、その業務を構成する全ての処理に対して、ステップ９０２からステップ９１３の処理を行うことを繰り返し、業務前連携業務ＩＤの終了時刻を当業務の開始時刻として業務内処理の再計算を行い、業務間連携管理テーブル（２Ｔ１）を更新する（ステップ７１４）。
この後、業務間連携管理テーブル（２Ｔ１）によって定義されている、連携が必要となる業務の全てにおいて、システム連携制御装置（１００）のメモリ上またはディスク上にこれまでの処理によって構築された、新業務間連携管理テーブルと新処理連携管理テーブル群を一次保存する（ステップ７９１５）。
そして、それらのテーブル情報から、新業務連携スケジュールをシステム管理者端末に表示し、新業務連携スケジュールを採用するか否かの指示を待つ（ステップ７１６）。
システム運用管理者がスケジュールデザイナー手段（１０２）を使用して修正した場合は（ステップ７１７）、その修正後の各種情報を一次保存し、最終決定スケジュールが登録された時点で（ステップ７９１８）、新業務間連携テーブルを確定して登録する（ステップ７１９）。
なお、上記の実施形態において、各情報処理システムの運行状態は統合業務装置で監視しているが、システム連携制御装置で直接に監視するようにしてもよい。
【図面の簡単な説明】
【００３３】
【図１】本発明に係る業務連携制御装置を適用したシステムの実施形態を示すシステム構成図である。
【図２】スケジュールデザイナー手段によって業務運行スケジュールを定義する画面の例及び定義情報の例を示す図である。
【図３】スケジュールデザイナー手段によって処理連携関係を定義する画面の例及び定義情報の例を示す図である。
【図４】業務連携関係を定義するテーブルのデータ構成図である。
【図５】システム運行状況確認画面及び障害発生時の確認画面の例を示す図である。
【図６】障害発生時におけるシステム連携制御装置の処理を示すフローチャートである。
【図７】障害発生時において業務再開時刻を受付けた以降のシステム連携制御装置の処理を示すフローチャートである。
【図８】従来の障害発生時の各システム運用管理者の作業フロー図である。
【図９】複数の情報処理システムにて業務を実行する場合のブロック図である。
【符号の説明】
【００３４】
１００ システム連携制御装置
１０１ システム運行管理手段
１０２ スケジュールデザイナー手段
１０３ ビューア手段
１０４ システム運行管理テーブル
１１０ システム１
１２０ システム２
１３０ システム３
２Ｔ１ 業務間連携管理テーブル
３Ｔ１ 処理連携管理テーブル群
【技術分野】
【０００１】
本発明は、複数また単数からなる情報処理システムにおいて、それら情報処理システム内または複数の情報処理システムにおいて実行される業務処理の連携制御管理を行う業務連携制御装置に関する。
【背景技術】
【０００２】
単数または複数からなる情報処理システム間にわたる業務の統合方法としては、下記の特許文献１のものがあげられる。
下記の特許文献１のものであれば、既存システムや関連する既存業務を容易に統合する仕掛けを提供し、統合業務として各業務をトランザクションを連携実行し管理する方法により、システムの性能低下を無くすことを目的にしている。
しかしながら、統合業務として複数のシステムを統一的に管理するのであれば、総合業務装置に接続されている各情報処理システムの運行スケジュールを詳細に把握し、各システムへのデータ転送等に使用される、ネットワーク機器や、情報処理システムが使用している演算装置、主記憶装置、出力装置、記憶媒体などのリソースの奪い合いによるシステム処理性能の低下を防止することが可能でなければ、統合業務として各システムを集中管理する意味合いが薄れてしまう。
【特許文献１】特開２００１−３４５９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
組織内は特定の目的を果たすための各種情報処理システムが複数存在する。今日においては、情報処理システムＡでの実行結果を情報処理システムＢの入力情報と使用し実行結果を得るような運用形態をとる場合が多い。
このように複数の情報処理システムを使用し、特定の結果を得るために、複数の情報処理システムをネットワークを介して接続し、入力データや処理結果を情報処理システム間においてやり取りすることは、いまや、あたりまえの運用形態となっている。
【０００４】
情報処理システムのダウンサイジング化により、それぞれの情報処理システムが特定の機能を持つものだけに分割されていき、組織内で稼動する情報システムは増えつづける一方である。また、それらを運用管理する部署が組織内に複数存在し、システム運用管理者も複数存在する。
ある業務を処理するにあたり、連携する他の情報処理システムや、それら情報処理システムの運行スケジュールを正しく認識している運用管理者は意外と少ない。
ここで、「業務」とは、各システムが独立して実行する各々の業務ではなく、複数のシステムにて行われる複数の処理からなる一連の情報処理を指す。
【０００５】
各情報処理システムは、予め定義された運行スケジュールによって稼動している。この運行スケジュールを決定する際に考慮される、その他の情報処理システムは、直接データをやり取りすることが必要である情報処理システムのみであることが多い。
【０００６】
組織内において、稼動する情報処理システムが増加するに伴って、各情報処理システムにおいて実行される各種業務の処理結果や、運行スケジュールが他の情報処理システムの運行状況に影響をあたえるケースも増加してきている。
【０００７】
前述したように、各情報処理システムの運用管理者は各自が管理する情報システムと直接連携する前後の情報処理システムしか意識しておらず、各自が担当する情報処理システムに何らかの原因により性能低下やそれに起因する運行スケジュールの変更があった場合において、直接やり取りする前後のシステムの運行スケジュールへの影響のみを考慮するにとどまる。
【０００８】
ある情報処理システムにおいて、障害が発生した場合に情報処理システム運用管理者がとる行動パターンを図８に示す。
図８において、障害が発生した場合、担当システムの入力データを生成すべきシステムの運用管理者からシステムの性能低下により入力データの生成が遅れるとの連絡を受ける（ステップ８０１）。
次に、出力結果を渡すべきシステムの運用管理者に他システムに起因する処理の遅れが発生することを連絡する（ステップ８０２）。
次に、各自が運用管理を担当するシステムの運行スケジュールを確認し、影響度を調査する（ステップ８０３）。
次に、スケジュールの変更が必要かを判断し（ステップ８０４）、必要であれば、担当システムの変更スケジュールを作成し、処理スケジュール案として連携先システムの運用管理者に提示する（ステップ８０５）。必要がなければ、ステップ８０７に進む。
次に、運用管理者間において、合意がなされるまでスケジューリングの調整を行い。業務間連携スケジュールを作成する（ステップ８０６）。
これにより、担当システムの処理実行が可能となり、処理を実行する（ステップ８０７）。
次に、連携先システムの有無を判断し、なければ処理を終了し、あればステップ８０２に戻る（ステップ８０８）。
図８から明らかなように、情報処理システムのスケジュール調整を行うのは人的作業であり、この作業を複数の情報システム運用管理者がそれぞれ実施するのが現状である。
このような人的作業は、組織内に情報処理システムが多く存在する組織ほど複雑になっていく。この作業が増大及び複雑化が進むにつれ、対象業務の正常化には時間を要することとなる。
【０００９】
運行スケジュールが乱れることは、各情報処理システムがネットワークを介して接続されている状態において、ネット―ワーク上を伝送されるデータが予定しているトラフィック量を超えることの原因にもなり得る。
トラフィックの増加はルータやハブ、ＳＳＬ暗号化装置、ファイヤーウォール等のネットワーク機器の負荷を増大させ、そのことが情報処理システム間の連携において新たな障害を生み出すことにもつながる。
【００１０】
複数の情報処理システムを連携して、ひとつの業務を処理するためには、情報処理システム間、業務間、処理間のスケジューリングが重要である。
従来、人的作業によって非効率に行われてきたこの人的作業を、効率よく実現する工夫が必要である。
【００１１】
図９は、従来の方法を用いて複数の情報処理システムにまたがり、一連の業務を実行する場合の例を示す図である。
各処理を実行するシステム１（９１０）、システム２（９２０）、システム３（９３０）とから構成されている。それぞれのシステムにて実行される処理がそれぞれ単一の処理（９４０）、（９５０）、（９６０）であり、これらの処理結果は（９７０）、（９８０）、（９９０）とされ、各システムはそれらの処理結果を処理の入力情報として使用する。
図９において、各処理は番号順に時系列にしたがって実行されるものとする。図９において処理結果（９７０）を生成する処理は（９４０）である。この処理結果（９７０）を入力として使用するシステムはシステム２（９２０）であり、その処理は（９５０）のみである。
システム１（９１０）に障害が発生した場合、処理（９４０）は実行されない。システム２（９２０）の処理（９５０）は処理結果（９７０）を入力とするので、実行可能状態にない。この場合、システム３（９３０）はシステム２（９２０）の処理（２５０）にて生成される処理結果（９８０）を必要とするが、システム１（９１０）が障害のため処理実行が不可能となる。
【００１２】
システム１（９１０）、２（９２０）、３（９３０）のシステム運用管理者が同一でない場合、システム３（９３０）のシステム運用管理者は、システム３（９３０）の処理（９６０）が実行不可能である原因は入力データ（９８０）がシステム２（９２０）から伝送されてこない事しかわからない。
システム１（９１０）が連携するシステムは、システム２（９２０）のみであるので、処理結果（9７０）がシステム２（９２０）を介してどのように使用されるのかはわからない。
【００１３】
上記のような事態が発生した場合、システム１（９１０）のシステム運用管理者が現状分析実施後、全てのシステム運用管理者に対応方針を伝え、各システムの運行スケジュールの調整を依頼することとなる。
また、連携対象システムのシステム運用管理者がすべて同一であった場合においても、各システムの運行スケジュールを調整するために、各システムの運行スケジュールや、障害の影響度を各システム単位に調査し、システム単位で運行スケジュールを再設定しなければならない。
このような作業を人的作業にて行うことは、効率的ではなく、対象システムが増大するほど影響度も大きくなる。
【００１４】
本発明の目的は、システム障害等による連携システム間の影響度を即座に把握し、システム運行スケジュールの再調整を速やかに可能とする業務連携制御装置を提供することにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明に係る業務連携制御装置は、他の情報処理システムの処理結果を引き継いで所定の業務処理を連携して実行する複数の情報処理システムにおける業務処理の連携制御を行う業務連携制御装置であって、
複数の業務処理のそれぞれの開始時刻、終了時刻、先行業務処理名、後続業務処理名から成る業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、
各業務処理を実行する情報処理システム名、処理名および処理必要時間、先行処理名、後続処理名から成る処理連携関係情報を管理者端末から受付け、前記業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成し、前記処理連携管理テーブルに登録し、再作成した連携スケジュールに従って処理を再開させる第４の手段とを備えることを特徴とする。
そして、前記第１の手段は、複数の業務処理を表す図形を表示装置画面上で時間軸に沿って配置する操作によって連携関係を定義する機能を備えていることを特徴とする。
また、前記第３の手段は、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に時間軸に沿って図形表示する機能を備えていることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、複数の情報処理システムが例えばネットワークを介して接続可能状態にある場合において、各情報処理システムにおける各処理の連携スケジュールを作成し、一元的に管理し、処理を実行させる。
そして、いずれかの情報処理システムに障害が発生した場合、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する。
これにより、影響を受けうる情報処理システムとそのシステムにおいて実行される処理、および、関連する業務を特定することが可能となり、システム障害等による連携システム間の影響度を即座に把握し、システム運行スケジュールの再調整を速やかに実施可能になる。
直接的な効果として、人的作業の効率化、間接的な効果として、システムリソースの有効活用が可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一形態を図面を参照して説明する。
図１は、本発明に係るシステム連携制御装置を使用したシステムの全体構成を示す図である。
本システムは、システム連携制御装置（１００）と、分散型情報処理システム１（１１０）と、分散型情報処理システム（１２０）と、分散型情報処理システム（１３０）と統合業務装置（１Ａ１）それらを物理的に接続するネットワーク機器（図示せず）により構成される。
図１においてシステム１の処理（１４０）からシステム３の処理（１６０）までを「１業務」と定義する。
【００１８】
システム連携制御装置（１００）は、統合業務装置（１０１）との連携インタフェースを持ち、統合業務装置（１０１）が監視対象とする各システム１〜３の障害情報、運行状態（処理状況）を元にシステムの運行スケジュールを管理するシステム運行管理手段１０１を備えている。
【００１９】
複数システムの運行スケジュールを統一的に管理制御するには、各システム１（１１０）、２（１２０）、３（１３０）にて実行される処理と、それらの出力結果およびそれらのインプットデータを統合的に管理しなくてはならない。
また、これらには統合的なＩＤを割り当てる必要がある。割り当てられた統合的な処理ＩＤおよび業務ＩＤは、システム連携制御装置（１００）の記憶装置内に設けられるシステム運行管理テーブル１０４において管理される。この登録処理を行う手段は任意のものでよい。
【００２０】
システム運行管理手段（１０１）の特徴について説明する。
システム運行管理手段（１０１）は、複数業務のスケジュールと業務内連携におけるスケジュールを管理する機能を持つ。本説明において「業務内連携」とは図１に示すような業務内の処理単位の連携を指す。
まず、連続する業務の運行スケジュールの作成について説明する。
【００２１】
連続する業務の運行スケジュールについては、システム連携制御装置（１００）に設けられるスケジュールデザイナー手段（１０２）を使用し、業務の運行スケジュールを決定する。
図２にスケジュールデザイナー手段のモデル図を示す。
スケジュールデザイナー手段（１０２）は、業務運行スケジュール定義画面（２１０）をシステム連携制御装置（１００）のシステム運用管理者端末（以下、管理者端末）上に表示し、システム運用管理者が、各業務のスケジュールを決定・修正が可能であり、表示される情報は、時間を縦軸に備え、業務名称が記述されている箱型の図形の大きさがその業務に要する実行時間であることを指し、線で結ばれている業務が連携対象業務であり、それらの実行順序が見て取れる要件を満たすこととする。
スケジュールデザイナー手段（１０２）にて業務実行スケジュールおよび連携情報を登録すると、システム連携制御装置（１００）の内の記憶装置内に設けられた業務間連携管理テーブル（２Ｔ１）に情報が登録される。
図２に例示する業務間連携管理テーブル（２Ｔ１）には、業務ＩＤ、業務種別、業務前連携業務ＩＤ、業務後連携業務ＩＤ、業務開始時刻、業務終了時刻が登録されるようになっている。
【００２２】
業務スケジュールの決定後、システム運用管理者は業務内処理の連携定義を行う。
業務内の処理フローの決定は、スケジュールデザイナー手段（１０２）の図３に示す処理連携フロー定義画面（３１０）により行う。この機能にて定義された情報は、システム連携制御装置（１００）の内の記憶装置内に設けられた処理連携管理テーブル群（３Ｔ１）に反映される。
処理連携管理テーブル群（３Ｔ１）は、図３に示すように、業務構成テーブルモデル（３Ｔ３）、処理テーブルモデル（３Ｔ４）、処理連携管理テーブルモデル（３Ｔ２）で構成され、業務構成テーブルモデル（３Ｔ３）には業務ＩＤ，システムＩＤ、処理ＩＤの関係が登録される。
また、処理連携管理テーブルモデル（３Ｔ２）には、システムＩＤ、処理ＩＤＦ、処理開始時刻、処理終了時刻が登録され、処理管理テーブルモデル（３Ｔ４）には処理ＩＤ、入力処理ＩＤ、出力処理ＩＤ、必要時間、予備時間が登録される。なお、処理連携管理テーブルモデル（３Ｔ２）には、業務１の処理以外にも各システムに多数スケジューリングされているので（処理ＩＤ３ＸＸ）、各システムの運用責任者は、自システムにスケジューリングされている処理がどの業務の処理かについて、常時把握している訳ではない。
【００２３】
スケジュールデザイナー手段（１０２）によって定義された情報は、システム運行管理手段（１０１）が保持するシステム運行管理テーブル（１０２）に格納され、システム連携制御に使用される情報を構成する。
システム運行管理手段（１０１）が保持するシステム運行管理テーブル（１０２）を構成するデータの例を図４に示す。
これらのテーブル構成情報に、統合業務装置（１Ａ１）が各システムを監視しており、その運行状況の情報から得ることのできる各種情報（処理ＩＤ、トランザクションＮｏ、トランザクション結果）を反映させる。
【００２４】
決定されたスケジュール情報をもとに、システム連携制御装置（１００）は、統合業務装置（１Ａ１）に処理の実行を許可する信号を送る。
統合業務装置（１Ａ１）は、各システムの処理実行と処理結果を監視しているので、システム連携制御装置（１００）にて、各システム１（１１０）、２（１２０）、３（１３０）の処理実行制御機能を保持する必要はない。
システム連携制御装置（１００）と統合業務装置（１Ａ１）とを接続するインタフェースについては、導入されている統合業務装置（１Ａ１）のインタフェースに依存するとし、システム連携制御装置（１００）は任意のインタフェースを介して統合業務装置（１Ａ１）と連携するものとする。
【００２５】
一連の業務定義および処理定義が完了したことで、統合業務装置（１Ａ１）によって管理されている処理について、システム連携制御装置（１００）にて確認することが可能となる。
図５に本発明のシステム運行状況確認画面モデル図を示す。
システム運用管理者は、システム連携制御装置（１００）のビューア手段（１０３）にて、定義済みの業務間スケジュールおよび、業務内処理スケジュールに合わせた実行状況等を、システム運用管理者端末上に表示させ、業務連携確認画面モデル（５１０）を確認することで、現時点での運行スケジュールを確認することができる。
システム連携制御装置（１Ａ１）に接続することのできる条件を備えていれば、システム１〜３の各運用管理者が複数であっても、各システム１〜３の運用管理者のクライアント端末にて現在の実行状況および、全体スケジュールから詳細スケジュールまでを閲覧可能にすることができる。
【００２６】
業務連携確認画面モデル（５１０）においては、障害が発生している業務をシステム運用管理者に識別可能な情報を表示して警告する。もし、当該業務に関連するシステムが別々のシステム運用管理者によって管理されている場合、当該警告は関連する全てのシステム運用管理者に対してなされるものとする。
図５に例示する業務連携確認画面モデル（５１０）においては、「業務１」の箱が変色されて表示される。「業務１」の箱を拡大表示させる操作を行うと、業務内連携確認画面モデル（５２０）が表示され、その中に、異常終了したシステム名称、処理ＩＤ、エラーコードなどの詳細な状況が表示される。
業務内連携確認画面モデル（５２０）は、統合制御装置（１Ａ１）にて取得する各情報処理システム１〜３の現在実行中の処理ＩＤ、実行終了の処理ＩＤ、処理ＩＤ単位の処理結果などをシステム連携制御装置（１００）が受け取り、その情報を表示している。
図５には、業務ＩＤ、システムＩＤ、ＥＲＲＣＯＤＥ、開始時間、終了時間、トランザクションＮｏのみを表示した例を示している。
業務内連携確認画面モデル（５２０）を参照した場合、「業務１」において現在の状況が、システム１の処理ＩＤ３４０正常終了後、システム２の処理ＩＤ３５０にて異常終了し、その原因がＥＲＲＣＯＤＥ：ＥＳ０２０００１であることが確認できる。また、その後影響を与える処理としてシステム３の処理ＩＤ３６０が存在することが確認できる。
【００２７】
図５のような業務連携確認画面モデル（５１０）の状況になった場合、システム運用管理者が行うべき作業は、業務単位の再スケジューリングとシステム運行の再スケジューリングをすることである。図１において、このような場合の作業フローを提示したが、システム連携制御装置（１００）はスケジュールデザイナー手段（１０２）を用いることで、人的負荷を軽減させる。
【００２８】
システム連携制御装置（１００）が管理するシステム運行管理テーブル内には、図３に例示したように、処理の開始時刻、処理に必要とされる時間、その処理から次の処理へ移るまでの予備時間とそれら処理の集合からなる業務の開始時刻、それら処理の実行時間と予備時間を合計して算出される業務必要時間と業務全体での終了時刻を保持している。
障害が発生した場合、業務内の処理連携フローをこれらの情報から再生成する。
この処理連携フローを再生成するには、障害が発生している処理の復旧時間を見極めなくてはならない。図５のケースでは、障害はシステム２の処理３５０で発生しているので、システム２のシステム運用管理者は、処理３５０の運用関係者と連携を取って、障害回復に必要とされる時間を算定する。障害回復に必要とされる時間が決定したら、この処理のリスタート時間をスケジュールデザイナー手段（１０２）を使用してシステム連携制御装置（１００）に登録する。
この場合は、障害発生前に登録してあった処理開始時刻を処理再開可能時刻に合わせればよい。
システム連携制御装置（１００）は、対象処理のリスタート時間を基準にして、処理連携テーブル群（３Ｔ１）を再構築する。そして、再構築された処理連携テーブル群（３Ｔ１）から業務間連携テーブル（２Ｔ１）を再構築する。この情報を元に、今回適用される業務運行スケジュールを自動生成し、システム運用管理者の端末に表示する。表示された新規の業務運行スケジュールはスケジュールデザイナー手段（１０２）によって修正が可能であるので、提示されたスケジュールを修正することも可能である。
【００２９】
システム連携制御装置（１００）のアクションフローを図６に示す。
システム連携制御装置（１００）が行う機能の特徴は、統合業務装置（１Ａ１）にて管理対象となるシステムの業務と、業務を構成する処理、複数の業務からなる情報処理のスケジュールをデータとして保持し、それらのスケジュールを図表形式にて表示する機能と、図表を加工する形でスケジュールを修正できる機能と、その図表形式でのデータをテーブル情報として保存することができることである。
図６に示す一連の処理において、人的作業は、ステップ（６０６）、（６１０）の判断と（６０８）、（６１１）の図表修正のみである。それ以外の処理はシステム連携制御装置（１００）のプログラムが行うものである。
【００３０】
図６において、まず、障害が発生した業務を含む業務連携スケジュールを表示し（ステップ６０１）、さらに障害が発生した処理を含む処理連携フローを表示し（ステップ６０２）、障害発生処理の再スタート時刻の入力を待つ（ステップ６０３）。
再スタート時刻が管理者端末から入力されたならば、その再スタート時刻を基準点として、処理連携管理テーブル群（３Ｔ１）を再構築する（ステップ６０４）。
次に、再構築された処理連携管理テーブル群（３Ｔ１）から処理連携フローを再生成し、管理者端末に表示する（ステップ６０５）。
次に、再生成された処理連携フローを採用するかを障害システムの運用管理者及び後続処理のシステム運用管理者に確認させ（図５の例ではシステム２，３の運用管理者）、全てのシステム運用管理者から採用する旨の指示があったならば（ステップ６０６）、業務間連携テーブル（２Ｔ１）を再構築する（ステップ６０７）。
再生成された処理連携フローを不採用とする旨の指示がいずれかのシステム管理者から入力された場合は、
再生成された処理連携フローをシステム管理者からの指示に従って修正する（ステップ６０８）。
この後、再構築された業務間連携テーブル（２Ｔ１）から業務連携スケジュールを再生成し、管理者端末に表示する（ステップ６０９）。
そして、再生成された業務連携スケジュールを採用するかを当該業務に関連するシステム運用管理者及び後続業務に関連するシステム運用管理者に確認させ（図５の例ではシステム１，２，３の運用管理者）、全てのシステム運用管理者から採用する旨の指示があったならば（ステップ６１０）、生成された連携制御情報を統合業務装置（１Ａ１）に転送する（ステップ６１２）。
しかし、再生成された業務連携スケジュールを不採用とする旨の指示がいずれかのシステム管理者から入力された場合は、再生成された業務連携スケジュールをシステム管理者からの指示に従って修正する（ステップ６１１）。
【００３１】
システム連携制御装置（１００）のプログラム処理フローを図７に示す。
図７は、システム運用管理者が決定した再スタート時刻を基準時刻として、各種テーブルに保持している情報より、新規スケジュールを決定するプログラムの処理ステップを簡略的に示している。
まず、システム運用管理者が決定した再スタート時刻を受け付け（ステップ７０１）、処理必要時間と予備時間を保持している図４のテーブル（３Ｔ３）から取得し、合算した時間を合計時間として算出し、基準時刻（再スタート時刻）に加算し、算出された時刻をその処理の新終了時刻として決定する（ステップ７０２）。
対象処理に出力処理ＩＤとして連携すべき処理ＩＤが定義されていた場合（ステップ７０３）、新処理終了時刻がテーブル（３Ｔ２）に登録されている処理開始時刻より後であれば、それより前の時刻になるように再スタート時刻を再度入力させる（ステップ７０４）。
しかし、新終了時刻がテーブル（３Ｔ２）に登録されている開始時刻より前になる場合は、新終了時刻が求められた処理を対象として処理連携テーブル（３Ｔ１）の開始時刻と終了時刻を更新する（ステップ７０５）。
全ての業務内処理の新開始時刻が決定されたならば、処理連携管理テーブル群（３Ｔ１）に登録されたデータをもとに、新処理連携フローを生成し、管理者端末に表示する（ステップ７０６）。
この時点においてシステム管理者が人的判断にて、スケジュールの修正をする場合は（ステップ９０７）、スケジュールデザイナー手段（１０２）を使用して調整する（ステップ７０７、７０８）。
最終的に決定された処理連携スケジュールは、システム連携制御装置（１００）のメモリ上またはディスク上の領域に一次保存される（ステップ７０９）。
一次保存された処理連携スケジュールの最終処理の終了時刻が業務連携スケジュールにおける対象業務の新業務終了時刻としてメモリ上またはディスク上に一次保存される（ステップ７１０）。
【００３２】
次に、テーブル（２Ｔ１）を参照し、後連携する業務があれば（ステップ７１１）、後業務の業務開始時刻と新業務終了時刻を比較する（ステップ７１２）。新業務終了時刻が後業務の開始時刻前であれば、連携する以降の業務のスケジュール変更は発生しない。
しかし、新業務終了時刻が後業務の開始時刻以降であるならば、新業務終了時刻を基準時間として、業務構成テーブルモデル（３Ｔ３）に登録されている、その業務を構成する全ての処理に対して、ステップ９０２からステップ９１３の処理を行うことを繰り返し、業務前連携業務ＩＤの終了時刻を当業務の開始時刻として業務内処理の再計算を行い、業務間連携管理テーブル（２Ｔ１）を更新する（ステップ７１４）。
この後、業務間連携管理テーブル（２Ｔ１）によって定義されている、連携が必要となる業務の全てにおいて、システム連携制御装置（１００）のメモリ上またはディスク上にこれまでの処理によって構築された、新業務間連携管理テーブルと新処理連携管理テーブル群を一次保存する（ステップ７９１５）。
そして、それらのテーブル情報から、新業務連携スケジュールをシステム管理者端末に表示し、新業務連携スケジュールを採用するか否かの指示を待つ（ステップ７１６）。
システム運用管理者がスケジュールデザイナー手段（１０２）を使用して修正した場合は（ステップ７１７）、その修正後の各種情報を一次保存し、最終決定スケジュールが登録された時点で（ステップ７９１８）、新業務間連携テーブルを確定して登録する（ステップ７１９）。
なお、上記の実施形態において、各情報処理システムの運行状態は統合業務装置で監視しているが、システム連携制御装置で直接に監視するようにしてもよい。
【図面の簡単な説明】
【００３３】
【図１】本発明に係る業務連携制御装置を適用したシステムの実施形態を示すシステム構成図である。
【図２】スケジュールデザイナー手段によって業務運行スケジュールを定義する画面の例及び定義情報の例を示す図である。
【図３】スケジュールデザイナー手段によって処理連携関係を定義する画面の例及び定義情報の例を示す図である。
【図４】業務連携関係を定義するテーブルのデータ構成図である。
【図５】システム運行状況確認画面及び障害発生時の確認画面の例を示す図である。
【図６】障害発生時におけるシステム連携制御装置の処理を示すフローチャートである。
【図７】障害発生時において業務再開時刻を受付けた以降のシステム連携制御装置の処理を示すフローチャートである。
【図８】従来の障害発生時の各システム運用管理者の作業フロー図である。
【図９】複数の情報処理システムにて業務を実行する場合のブロック図である。
【符号の説明】
【００３４】
１００ システム連携制御装置
１０１ システム運行管理手段
１０２ スケジュールデザイナー手段
１０３ ビューア手段
１０４ システム運行管理テーブル
１１０ システム１
１２０ システム２
１３０ システム３
２Ｔ１ 業務間連携管理テーブル
３Ｔ１ 処理連携管理テーブル群
【特許請求の範囲】
【請求項１】
他の情報処理システムの処理結果を引き継いで所定の業務処理を連携して実行する複数の情報処理システムにおける業務処理の連携制御を行う業務連携制御装置であって、
複数の業務処理のそれぞれの開始時刻、終了時刻、先行業務処理名、後続業務処理名から成る業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、
各業務処理を実行する情報処理システム名、処理名および処理必要時間、先行処理名、後続処理名から成る処理連携関係情報を管理者端末から受付け、前記業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、
いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、
障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成し、前記処理連携管理テーブルに登録し、再作成した連携スケジュールに従って処理を再開させる第４の手段と
を備えることを特徴とする業務連携制御装置。
【請求項２】
前記第１の手段は、複数の業務処理を表す図形を表示装置画面上で時間軸に沿って配置する操作によって連携関係を定義する機能を備えていることを特徴とする請求項１に記載の業務連携制御装置。
【請求項３】
前記第３の手段は、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に時間軸に沿って図形表示する機能を備えていることを特徴とする請求項１または２に記載の業務連携制御装置。
【請求項１】
他の情報処理システムの処理結果を引き継いで所定の業務処理を連携して実行する複数の情報処理システムにおける業務処理の連携制御を行う業務連携制御装置であって、
複数の業務処理のそれぞれの開始時刻、終了時刻、先行業務処理名、後続業務処理名から成る業務連携関係情報を管理者端末から受付け、業務間連携管理テーブルに登録する第１の手段と、
各業務処理を実行する情報処理システム名、処理名および処理必要時間、先行処理名、後続処理名から成る処理連携関係情報を管理者端末から受付け、前記業務連携関係情報を参照して各処理の連携スケジュールを作成し、処理連携管理テーブルに登録する第２の手段と、
いずれかの情報処理システムにおける障害発生時に、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に表示する第３の手段と、
障害復旧後に、障害が発生した処理以降の処理を再開させる再開時刻を管理者端末から受付け、再開時刻を基準として障害が発生した処理以降の各処理の連携スケジュールを再作成し、前記処理連携管理テーブルに登録し、再作成した連携スケジュールに従って処理を再開させる第４の手段と
を備えることを特徴とする業務連携制御装置。
【請求項２】
前記第１の手段は、複数の業務処理を表す図形を表示装置画面上で時間軸に沿って配置する操作によって連携関係を定義する機能を備えていることを特徴とする請求項１に記載の業務連携制御装置。
【請求項３】
前記第３の手段は、障害内容および障害が発生している処理名を先行処理名および後続処理名と共に時間軸に沿って図形表示する機能を備えていることを特徴とする請求項１または２に記載の業務連携制御装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００６−２３５８３３（Ｐ２００６−２３５８３３Ａ）
【公開日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願番号】特願２００５−４７３３６（Ｐ２００５−４７３３６）
【出願日】平成１７年２月２３日（２００５．２．２３）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成１８年９月７日（２００６．９．７）
【国際特許分類】
【出願日】平成１７年２月２３日（２００５．２．２３）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]