JP5738133B2 - 縮退処理装置、縮退処理システム、縮退処理装置の縮退処理方法および縮退処理プログラム - Google Patents

Description

本発明は、例えば、障害発生時に縮退の業務処理を行う縮退処理装置、縮退処理システム、縮退処理装置の縮退処理方法および縮退処理プログラムに関するものである。

情報システムには、システムに障害が発生した場合にＢＣＰ（Ｂｕｓｉｎｅｓｓ Ｃｏｎｔｉｎｕｉｔｙ Ｐｌａｎ）などに従って必要最低限の業務を継続させるため、システムの構成を切替えて必要最低限の業務を継続させるフェイルソフト（業務縮退）という要件がある。

従来、アプリケーションの障害を検知すると、再配置ポリシーや最適配置ポリシーの設定に従い、障害を検知したアプリケーションと同一のアプリケーションを別の計算機に移動していた。

しかし、アプリケーションを別計算機に移動する際に、障害を検知したアプリケーションを別のアプリケーションに置き換えることができない。このため、アプリケーションの機能の一部を障害に応じて変更して業務縮退することができない。

また、障害を検知したときに処理中だった業務データに対する業務処理を途中から継続することができない。このため、処理中だった業務データに対する業務処理は最初やり直さなければいけない。

特開２００５−１００３８７号公報

本発明は、例えば、障害が発生した場合、複数の業務処理で構成される業務フローを少なくとも一部の業務処理が異なる縮退フローに変更できるようにすることを目的とする。

本発明の縮退処理装置は、
複数の業務処理で構成される特定の業務フローの業務処理毎に、当該業務処理で障害が発生した場合に前記特定の業務フローの代わりに実行する業務フローを縮退フローとして特定する縮退フロー情報を記憶する縮退フロー情報記憶部と、
前記特定の業務フローを実行する業務フロー実行部と、
前記特定の業務フローのいずれかの業務処理で障害が発生した場合、障害が発生した業務処理に対応する縮退フロー情報を前記縮退フロー情報記憶部から取得する縮退フロー情報取得部とを備え、
前記業務フロー実行部は、前記縮退フロー情報取得部によって取得された縮退フロー情報によって特定される縮退フローを前記特定の業務フローの代わりに実行する。

本発明によれば、例えば、障害が発生した場合、複数の業務処理で構成される業務フローを少なくとも一部の業務処理が異なる縮退フローに変更することができる。これにより、業務フローの処理を縮退フローに従って継続することができる。

実施の形態１における分散システム１００の概要図。 実施の形態１における計算機２００の機能構成図。 実施の形態１における業務フローＰｎの一例を示す図。 実施の形態１における障害ルール対応表２９１の一例を示す図。 実施の形態１における縮退フローＰｘの一例を示す図。 実施の形態１における分散システム１００のサービス構成変更方法を示すフローチャート。 実施の形態１における計算機２００のハードウェア資源の一例を示す図。 実施の形態２における計算機２００の機能構成図。 実施の形態２における障害ルール対応表２９１の一例を示す図。 実施の形態２における業務フローＰｎの一例を示す図。 実施の形態２におけるチェックポイントデータ１２９による業務データ（タスク変数）の回復の流れを示す図。 実施の形態２における分散システム１００のサービス構成変更方法を示すフローチャート。 実施の形態３（実施例１）における障害ルール対応表２９１と縮退フローＰ０とを示す図。 実施の形態３（実施例２）における障害ルール対応表２９１と縮退フローＰ０とを示す図。 実施の形態３（実施例３）における障害ルール対応表２９１とルックアップテーブル２９４と縮退フローＰ０’とを示す図。 実施の形態３（実施例４）のおける障害ルール対応表２９１と縮退フローＰ０’とを示す図。

実施の形態１．
特定の業務フローを構成する業務処理で障害が発生した場合に、特定の業務フローの代わりに特定の業務フローと異なる業務処理を含んだ縮退フローを実行して業務データを処理する形態について説明する。

図１は、実施の形態１における分散システム１００の概要図である。
実施の形態１における分散システム１００の概要について、図１に基づいて説明する。

分散システム１００（縮退処理システムの一例）は、計算機２００Ａと計算機２００Ｂ（それぞれ、縮退処理装置の一例）と通信サーバ１１０とを備える。

計算機２００Ａと計算機２００Ｂと通信サーバ１１０とは、インターネットやローカルエリアネットワーク（ＬＡＮ）などのネットワークを介して通信を行う。

計算機２００Ａと計算機２００Ｂとは、業務フロー定義ファイル２９２に定義された業務フローに従って業務データを連携して処理する。業務フロー定義ファイル２９２の内容は計算機２００Ａと計算機２００Ｂとで同じである。
業務フローは、処理順が決められた複数の業務処理から構成される。

業務フローを構成するいずれかの業務処理で障害が発生した場合、計算機２００Ａと計算機２００Ｂとは、後述する障害ルール対応表２９１に基づいて障害に対応する縮退フローを選択し、選択した縮退フローに従って業務データを処理する。障害ルール対応表２９１の内容は計算機２００Ａと計算機２００Ｂとで同じである。
縮退フローは、障害が発生した場合に障害が発生していない正常時の業務フローの代わりに実行する障害時の業務フローである。

例えば、計算機２００Ｂと通信サーバ１１０との間で通信障害が発生した場合、正常時の業務フローを構成する複数の業務処理のうち計算機２００Ｂと通信サーバ１１０との間で通信を行う必要がある業務処理が障害となる。以下、障害が発生した業務処理を「障害処理」という。
この場合、計算機２００Ｂは障害処理を示す障害イベントを計算機２００Ａに通知し、計算機２００Ａと計算機２００Ｂとは障害処理の代替となる業務処理（代替処理）を含んだ縮退フローを選択し、選択した縮退フローに従って業務データを処理する。

但し、分散システム１００は、３台以上の計算機２００が連携したシステムであっても構わないし、計算機２００の台数が１台であるシステムであっても構わない。
また、分散システム１００は、計算機２００および通信サーバ１１０以外の装置を備えても構わないし、通信サーバ１１０を備えなくても構わない。

図２は、実施の形態１における計算機２００の機能構成図である。
実施の形態１における計算機２００の機能構成について、図２に基づいて説明する。

計算機２００（縮退処理装置の一例）は、複数の業務アプリ実行部２１０と、障害監視部２２０、障害ルール解釈部２３０と、トークン切替部２４０と、データマッピング部２４１とサービス制御部２５０と、計算機間連携部２６０と、計算機記憶部２９０とを備える。

計算機記憶部２９０（縮退フロー情報記憶部の一例）は、計算機２００で使用するデータやプログラムを記憶する。
障害ルール対応表２９１、業務フロー定義ファイル２９２、マップアプリ２９３、業務アプリ２９８、トークン２９９は、計算機記憶部２９０に記憶されるデータまたはプログラムの一例である。

障害ルール対応表２９１（縮退フロー情報の一例）は、複数の業務処理で構成される特定の業務フロー（正常時の業務フロー）の業務処理毎に縮退フロー情報を示すデータである。縮退フロー情報は、当該業務処理で障害が発生した場合に前記特定の業務フローの代わりに実行する業務フロー（異常時の業務フロー）を縮退フローとして特定する情報である。
例えば、障害ルール対応表２９１は、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に縮退フロー情報を示す。
障害ルール対応表２９１は、さらに、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に業務データの変換方法を特定するデータ変換情報（マップアプリ２９３を特定する情報）を示す。

業務フロー定義ファイル２９２は、複数の業務フロー（縮退フローを含む）を定義したデータであって、業務フロー毎に業務フローを構成する複数の業務処理を特定する業務フロー定義（縮退フロー定義の一例）を含んだデータである。

マップアプリ２９３は、業務データのデータ形式やデータ値を変換する変換方法のアルゴリズムを表すプログラムである。
マップアプリ２９３は、特定の業務データを入力し、入力した業務データを所定の変換方法で変換し、変換した業務データを出力する。

業務アプリ２９８は、業務処理のアルゴリズムを表すプログラムである。
業務アプリ２９８は、業務データを入力し、入力した業務データを所定の処理方法（業務処理）に従って処理し、処理した業務データを出力する。
但し、障害が発生した場合、業務アプリ２９８は、発生した障害の情報を出力する。

トークン２９９は、業務データを含んだデータである。業務データは１つ又は複数のデータを含んだデータである。以下、業務データに含まれるデータを「個別データ」という。
例えば、トークン２９９は、業務データの他に、業務データを処理する業務フローを識別する情報や、業務データを処理する（または直前に処理した）業務処理を識別する情報、実行する（または直前に実行した）処理ステップのステップ番号などの処理情報を含む。

業務アプリ実行部２１０は、所定の業務アプリ２９８を実行して所定の業務処理で業務データを処理する。

サービス制御部２５０（業務フロー実行部の一例）は、複数の業務アプリ実行部２１０を制御して特定の業務フロー（正常時の業務フロー）を実行する。
つまり、サービス制御部２５０は、特定の業務フローを構成する複数の業務処理に対応する複数の業務アプリ実行部２１０（業務アプリ２９８）を実行する。

障害ルール解釈部２３０（縮退フロー情報取得部の一例）は、特定の業務フローのいずれかの業務処理で障害が発生した場合、障害が発生した業務処理に対応する縮退フロー情報を障害ルール対応表２９１から取得する。
障害ルール解釈部２３０は、さらに、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理（障害処理）との組み合わせに対応する縮退フロー情報を業務データの縮退フロー情報として障害ルール対応表２９１から取得する。
障害ルール解釈部２３０は、さらに、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応するデータ変換情報を業務データのデータ変換情報として障害ルール対応表２９１から取得する。

データマッピング部２４１（業務データ変換部の一例）は、前記障害の発生時に処理されていた業務データ毎に業務データのデータ変換情報によって特定される変換方法に従って業務データを変換する。
つまり、データマッピング部２４１は、業務データのデータ変換情報によって特定されるマップアプリ２９３を実行して業務データを変換する。

サービス制御部２５０は、特定の業務フローのいずれかの業務処理で障害が発生した場合、障害ルール解釈部２３０によって取得された縮退フロー情報によって特定される縮退フローを特定の業務フローの代わりに実行する。
つまり、サービス制御部２５０は、縮退フローを構成する複数の業務処理に対応する複数の業務アプリ実行部２１０（業務アプリ２９８）を実行する。

例えば、サービス制御部２５０は、以下のように縮退フローに従って業務データを処理する。
サービス制御部２５０は、障害の発生時に処理されていた業務データ毎に業務データの縮退フロー情報によって特定される縮退フローに従って業務データを処理する。
サービス制御部２５０は、データマッピング部２４１によって変換された業務データを処理する。

障害監視部２２０は、業務処理の障害が発生したか否かを監視する。
例えば、障害監視部２２０は、業務アプリ２９８の出力が障害情報である場合に業務処理の障害が発生したことを検出する。
また、障害監視部２２０は、他の計算機２００から障害イベントが通知された場合に他の計算機２００の業務処理で障害が発生したことを検出する。

トークン切替部２４０は、業務処理の障害が発生した場合に縮退フローに合わせてトークン２９９の処理情報を更新する。

計算機間連携部２６０は、他の計算機２００と通信を行う。
例えば、計算機間連携部２６０は、業務データや障害イベントを他の計算機２００と通信する。

以下、特定の業務フロー（正常時の業務フロー）を単に「業務フロー」といい、「Ｐｎ」で記す。また、縮退フロー（異常時の業務フロー）を「Ｐｘ」（ｘは整数）で記す。
業務フローＰｎまたは縮退フローＰｘを構成する業務処理または業務処理に対応する業務アプリ２９８を小文字のアルファベット「ａ，ｂ，ｃ，・・・」で記す。
業務アプリ＊（＊は小文字のアルファベット）を実行する業務アプリ実行部２１０を「（＊）」で記す。

図３は、実施の形態１における業務フローＰｎの一例を示す図である。
実施の形態１における業務フローＰｎの一例について、図３に基づいて説明する。但し、実施の形態１における業務フローＰｎは図３に示す業務フローに限られるものではない。

業務フローＰｎは５つの業務アプリａ，ｂ，ｃ，ｄ，ｅで構成され、業務アプリ２９８の処理順は「ａ→ｂ→ｃ→ｄ→ｅ」である。
また、業務アプリａ，ｅ，ｄは計算機２００Ａで実行され、業務アプリｂ，ｃは計算機２００Ｂで実行される。

業務フローＰｎを定義した業務フロー定義は、業務フロー定義ファイル２９２に予め設定する。
また、業務フローＰｎを定義した業務フロー定義は、各計算機２００Ａ・Ｂの所定の記憶領域に予め記憶する。以下、業務フローＰｎの業務フロー定義が予め記憶される記憶領域を「フロー定義領域」という。

１つまたは複数のトークン２９９（業務データ）が発生した場合、計算機２００Ａのサービス制御部２５０は、フロー定義領域に記憶された業務フロー定義に従って以下のように動作する。
サービス制御部２５０は、最初の業務アプリａを実行するために業務アプリ実行部（ａ）（タスク、プロセスともいう）を起動し、起動した業務アプリ実行部（ａ）にトークン２９９を入力する。
業務アプリ実行部（ａ）は、業務アプリａを実行してトークン２９９に含まれる業務データを処理し、処理した業務データを含めたトークン２９９を出力する。
サービス制御部２５０は、業務アプリ実行部（ａ）を停止し、業務アプリ実行部（ａ）から出力されたトークン２９９を計算機間連携部２６０を介して計算機２００Ｂへ送信する。

計算機２００Ｂのサービス制御部２５０は、計算機間連携部２６０を介してトークン２９９を受信する。
サービス制御部２５０は、フロー定義領域に記憶された業務フロー定義に従って以下のように動作する。
サービス制御部２５０は、次の業務アプリｂを実行するために業務アプリ実行部（ｂ）を起動し、受信したトークン２９９を業務アプリ実行部（ｂ）に入力する。
業務アプリ実行部（ｂ）は、業務アプリｂを実行して業務データを処理し、処理した業務データを含めたトークン２９９を出力する。
サービス制御部２５０は、業務アプリ実行部（ｂ）を停止し、次の業務アプリｃを実行するために業務アプリ実行部（ｃ）を起動し、業務アプリ実行部（ｂ）から出力されたトークン２９９を業務アプリ実行部（ｃ）に入力する。
業務アプリ実行部（ｃ）は、業務アプリｃを実行して業務データを処理し、処理した業務データを含めたトークン２９９を出力する。
サービス制御部２５０は、業務アプリ実行部（ｃ）を停止し、業務アプリ実行部（ｃ）から出力されたトークン２９９を計算機間連携部２６０を介して計算機２００Ａへ送信する。

計算機２００Ａのサービス制御部２５０は、計算機間連携部２６０を介してトークン２９９を受信する。
サービス制御部２５０は、フロー定義領域に記憶された業務フロー定義に従って以下のように動作する。
サービス制御部２５０は、次の業務アプリｄを実行するために業務アプリ実行部（ｄ）を起動し、受信したトークン２９９を業務アプリ実行部（ｄ）に入力する。
業務アプリ実行部（ｄ）は、業務アプリｄを実行して業務データを処理し、処理した業務データを含めたトークン２９９を出力する。
サービス制御部２５０は、業務アプリ実行部（ｄ）を停止し、最後の業務アプリｅを実行するために業務アプリ実行部（ｅ）を起動し、業務アプリ実行部（ｄ）から出力されたトークン２９９を業務アプリ実行部（ｅ）に入力する。
業務アプリ実行部（ｅ）は、業務アプリｅを実行して業務データを処理し、処理した業務データを含めたトークン２９９を出力する。
サービス制御部２５０は、業務アプリ実行部（ｅ）を停止する。

図４は、実施の形態１における障害ルール対応表２９１の一例を示す図である。
実施の形態１における障害ルール対応表２９１の一例について、図４に基づいて説明する。但し、実施の形態１における障害ルール対応表２９１は図４に示す障害ルール対応表２９１に限られるものではない。

障害ルール対応表２９１は、データ項目として「切替前位置」「障害」「（切替後）フロー」「（切替後）位置」「収集対象」「マップアプリ」を有する。

「切替前位置」は、“新規”または業務アプリのアプリ名（“ａ”，“ｂ”，“ｃ”，・・・）を示す。

「障害」は、障害内容を識別する障害名を示す。以下、業務アプリ＊（＊は小文字のアルファベット）で発生した障害の障害名を「Ｅ＊」で記す。例えば、障害名Ｅｂは業務アプリｂで発生した障害を識別する。

「（切替後）フロー」（縮退フロー情報の一例）は、縮退フローを識別するフロー名Ｐｘを示す。

「（切替後）位置」は、縮退フローを構成する業務アプリ２９８のうち最初に実行する業務アプリ＊を識別するアプリ名（処理名）「＊」を示す。

「収集対象」は、マップアプリ２９３に入力する業務データを示す。以下、業務アプリ＊で処理した業務データを「Ｄ＊」で記す。

「マップアプリ」（データ変換情報の一例）は、マップアプリ２９３を識別するアプリ名を示す。以下、マップアプリ２９３を「Ｍ＃」（＃は小文字のアルファベット）で記す。
例えば、マップアプリＭｃは、業務データＤｂと業務データＤｃとを入力し、入力した業務データＤｂ，Ｄｃを所定の変換処理で変換し、変換して得られた業務データを縮退フローＰ２の業務アプリｂ’で処理する業務データとして出力する。

図５は、実施の形態１における縮退フローＰｘの一例を示す図である。
実施の形態１における縮退フローＰｘの一例について、図５に基づいて説明する。但し、実施の形態１における縮退フローＰｘは図５に示す縮退フローＰｘに限られるものではない。

各縮退フローＰｘを定義した業務フロー定義（縮退フロー定義）は、業務フロー定義ファイル２９２に予め設定する。

ここで、業務フローＰｎの業務アプリｂで障害が発生したものとする。
この場合、新たな業務データまたは業務アプリａで実行されていた業務データを処理するための縮退フローとして図４の障害ルール対応表２９１に基づいて縮退フローＰ１が選択される。切替前位置「新規」「ａ」と障害「Ｅｂ」とに対応する（切替後）フローが「Ｐ１」だからである。

同様に、業務アプリｂ，ｃで実行されていた業務データを処理するための縮退フローとして縮退フローＰ２が選択される。
また、業務アプリｄで実行されていた業務データを処理するための縮退フローとして縮退フローＰ３が選択され、業務アプリｅで実行されていた業務データを処理するための縮退フローとして縮退フローＰ４が選択される。

例えば、障害が発生した業務アプリｂは業務データを通信サーバ１１０へ送信する処理であり、業務アプリｂの次に実行される業務アプリｃは業務データを送信したことを示すフラグを所定のデータベースに設定する処理である。

縮退フローＰ１は、業務処理ｂを含まず、業務アプリｃの代わりに業務アプリｃ’を含む。業務アプリｃ’は、処理した業務データを送信できなかったことを示すフラグをデータベースに設定する処理である。いずれの業務処理も計算機Ａで実行される。
縮退フローＰ２は、業務アプリａを含まず、業務アプリｂ，ｃの代わりに業務アプリｂ’を含む。業務アプリｂ’は、業務データ自体に障害が発生しているかもしれないため、処理する業務データを復元するリカバリ処理と処理した業務データを送信できなかったことを示すフラグをデータベースに設定する処理とを含んだ処理である。業務アプリｂ’は計算機Ｂで実行され、業務アプリｄ，ｅは計算機Ａで実行される。
縮退フローＰ３は業務アプリａ−ｃを含まずに業務アプリｄ’を含み、縮退フローＰ４は業務アプリａ−ｄを含まずに業務アプリｄ’を含む。業務アプリｄ’は、処理する業務データが障害の影響を受けていない業務データであることを示すフラグをデータベースに設定する処理である。いずれの業務処理も計算機Ａで実行される。
但し、各業務処理は、上記の処理以外の処理であっても構わない。

図６は、実施の形態１における分散システム１００のサービス構成変更方法を示すフローチャートである。
実施の形態１における分散システム１００のサービス構成変更方法（縮退処理方法の一例）について、図６に基づいて説明する。

各計算機２００Ａ・Ｂは、以下に説明する処理をＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や通信機器などのハードウェア資源を用いて実行する。

Ｓ１１０において、計算機２００Ａの障害監視部２２０は、計算機２００Ａを監視し、計算機２００Ａで実行されている業務アプリ２９８の障害の発生を検出する。
計算機２００Ｂの障害監視部２２０は、計算機２００Ｂを監視し、計算機２００Ｂで実行されている業務アプリ２９８の障害の発生を検出する。
例えば、業務アプリ２９８の障害が発生した場合、障害が発生した業務アプリ２９８を実行していた業務アプリ実行部２１０は、障害が発生した業務アプリ２９８を特定する障害名を含んだ障害情報を出力する。障害監視部２２０は、業務アプリ実行部２１０から障害情報が出力されるか否かを監視し、障害の発生を示す情報として障害情報を検出する。

ここで、計算機２００Ｂの業務アプリ２９８（例えば、図５の業務処理ｂ）で障害が発生し、計算機２００Ｂの障害監視部２２０が障害の発生を検出したものとする。
Ｓ１１０の後、Ｓ１２０に進む。

Ｓ１２０において、計算機２００Ｂの障害監視部２２０は、障害が発生した業務アプリ２９８を特定する障害名などの障害情報を含んだデータを障害の発生を示す「障害イベント」として生成する。
計算機２００Ｂの計算機間連携部２６０は、障害監視部２２０によって生成された障害イベントを計算機２００Ａへ送信する。
計算機２００Ａの計算機間連携部２６０は、計算機２００Ｂから送信された障害イベントを受信する。
Ｓ１２０の後、Ｓ１３０に進む。

Ｓ１３０において、業務アプリ２９８を実行中の各業務アプリ実行部２１０が処理中のトークン２９９に対する業務処理を終了した場合、各計算機２００Ａ・Ｂのサービス制御部２５０は、各業務アプリ実行部２１０を停止する。
但し、サービス制御部２５０は、次の業務アプリ２９８を実行するための業務アプリ実行部２１０を実行しない。
つまり、サービス制御部２５０は、各トークン２９９に対して業務フローＰｎの実行を停止する。
Ｓ１３０の後、Ｓ１４０に進む。

Ｓ１４０において、計算機２００Ｂの障害ルール解釈部２３０は、障害監視部２２０によって検出された障害情報に含まれる障害名（Ｓ１１０参照）に対応する縮退情報を障害ルール対応表２９１から取得する。
計算機２００Ａの障害ルール解釈部２３０は、障害イベント（Ｓ１２０参照）に含まれる障害名に対応する縮退情報を障害ルール対応表２９１から取得する。

例えば、障害名が「Ｅｂ」である場合、各計算機２００Ａ・Ｂの障害ルール解釈部２３０は、図４に示した障害ルール対応表２９１から切替前位置「新規」の縮退情報として（切替後）フロー「Ｐ１」、（切替後）位置「ａ」を取得する。
さらに、各障害ルール解釈部２３０は、切替前位置「ａ」の縮退情報として（切替後）フロー「Ｐ１」、（切替後）位置「ｃ’」、収集対象「Ｄａ」、マップアプリ「Ｍａ」を取得する。
同様に、各障害ルール解釈部２３０は、切替前位置「ｂ」「ｃ」「ｄ」「ｅ」の縮退情報を取得する。

Ｓ１４０の後、Ｓ１５０に進む。

Ｓ１５０において、各計算機２００Ａ・Ｂのトークン切替部２４０は、業務フローＰｎを構成する各業務アプリ２９８で処理されていたトークン２９９を収集する。
例えば、各計算機２００Ａ・Ｂのトークン切替部２４０は、他方の計算機２００の業務アプリ２９８で処理されていたトークン２９９を計算機間連携部２６０を介して収集する。
Ｓ１５０の後、Ｓ１６０に進む。

Ｓ１６０において、各計算機２００Ａ・Ｂの障害ルール解釈部２３０は、収集されたトークン２９９毎にトークン２９９の縮退情報を障害ルール対応表２９１から取得する。
トークン２９９の縮退情報は、障害発生時にトークン２９９を処理していた業務アプリ２９８と障害が発生した業務アプリ２９８とに対応する障害ルール対応表２９１のデータである。
例えば、障害発生時にトークン２９９を処理していた業務アプリ２９８が「ａ」であり、障害が発生した業務アプリ２９８が「ｂ」である場合、（切替前）位置「ａ」と障害「Ｅｂ」とに対応するデータ（Ｐ１，ｃ’，Ｄａ，Ｍａ）がトークン２９９の縮退情報である（図４参照）。

各計算機２００Ａ・Ｂのトークン切替部２４０は、収集したトークン２９９毎にトークン２９９の処理情報を縮退情報に基づいて更新する。

例えば、各計算機２００Ａ・Ｂのトークン切替部２４０は、業務アプリａで処理されていたトークン２９９の処理情報（フロー名、アプリ名など）をトークン２９９の縮退情報に基づいて以下のように更新する。
トークン切替部２４０は、トークン２９９のフロー名「Ｐｎ」をトークン２９９の縮退情報に含まれる（切替後）フロー「Ｐ１」に更新する。
トークン切替部２４０は、トークン２９９のアプリ名「ａ」をトークン２９９の縮退情報に含まれる（切替後）位置「ｃ’」に更新する。

各計算機２００Ａ・Ｂのデータマッピング部２４１は、収集されたトークン２９９毎にトークン２９９の業務データをトークン２９９の縮退情報に基づいて変換する。

例えば、各計算機２００のトークン切替部２４０は、業務アプリ「ａ」で処理されていたトークン２９９の業務データ「Ｄａ」をトークン２９９の縮退情報で特定されるマップアプリ「Ｍａ」を実行して変換する。

Ｓ１６０の後、Ｓ１７０に進む。

Ｓ１７０において、各計算機２００Ａ・Ｂのサービス制御部２５０は、フロー定義領域に記憶されている業務フローＰｎの業務フロー定義をＳ１４０で取得された縮退情報に基づいて縮退フローの業務フロー定義に更新する。以下、縮退フローの業務フロー定義を「縮退フロー定義」という。

例えば、切替前位置「新規」「ａ」の縮退フローのフロー名が「Ｐ１」であり、切替前位置「ｂ」「ｃ」の縮退フローのフロー名が「Ｐ２」であり、切替前位置「ｄ」の縮退フローのフロー名が「Ｐ３」であり、切替前位置「ｅ」の縮退フローのフロー名が「Ｐ４」であるものとする。
この場合、各計算機２００Ａ・Ｂのサービス制御部２５０は、縮退フロー「Ｐ１」「Ｐ２」「Ｐ３」「Ｐ４」それぞれの縮退フロー定義を業務フロー定義ファイル２９２から取得する。サービス制御部２５０は、フロー定義領域に記憶されている業務フローＰｎの業務フロー定義を４つの縮退フロー定義（Ｐ１、Ｐ２、Ｐ３、Ｐ４）に更新する。

Ｓ１７０の後、Ｓ１８０に進む。

Ｓ１８０において、各計算機２００Ａ・Ｂのサービス制御部２５０は、フロー定義領域に記憶されている各縮退フロー定義に従って各業務アプリ実行部２１０を起動し、縮退フローの実行を開始する。

例えば、サービス制御部２５０は、以下のように動作する。
サービス制御部２５０は、Ｓ１６０で更新されたトークン２９９毎に、トークン２９９に含まれるフロー名を参照し、参照したフロー名で識別される縮退フローをトークン２９９を処理する縮退フローとして判定する。
サービス制御部２５０は、トークン２９９に含まれるアプリ名を参照し、参照したアプリ名で識別される業務アプリ２９８を実行するために業務アプリ実行部２１０を起動し、起動した業務アプリ実行部２１０にトークン２９９を入力する。
以後、サービス制御部２５０は、判定した縮退フローの処理順に従って業務アプリ実行部２１０を起動してトークン２９９を縮退フローで処理する。

ここで、「トークン２９９」は、障害発生時に同じ業務アプリ実行部２１０によって処理されていた「複数のトークン２９９」に置き換えてもよい。

縮退フローの実行方法は、業務フローの実行方法（図３の説明を参照）と同様である。

Ｓ１８０により、サービス構成変更方法の処理は終了する。
以上により、業務フローの業務処理で障害が発生した場合、分散システム１００は、業務フローで実行していたトークン２９９および新たな業務フローを縮退フローによって処理することができる。

図７は、実施の形態１における計算機２００のハードウェア資源の一例を示す図である。
図７において、計算機２００（コンピュータの一例）は、ＣＰＵ９０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。ＣＰＵ９０１は、バス９０２を介してＲＯＭ９０３、ＲＡＭ９０４、通信装置９０５、ディスプレイ９１１（表示装置）、キーボード９１２、マウス９１３、ドライブ装置９１４、磁気ディスク装置９２０などのハードウェアデバイスと接続され、これらのハードウェアデバイスを制御する。ドライブ装置９１４は、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などの記憶媒体を読み書きする装置である。
ＲＯＭ９０３、ＲＡＭ９０４、磁気ディスク装置９２０およびドライブ装置９１４は記憶装置の一例である。キーボード９１２およびマウス９１３は入力装置の一例である。ディスプレイ装置９１１は出力装置の一例である。

通信装置９０５は、有線または無線で、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネット、電話回線などの通信網に接続している。
通信装置９０５は、入力装置または出力装置の一例である。

磁気ディスク装置９２０には、ＯＳ９２１（オペレーティングシステム）、プログラム群９２２、ファイル群９２３が記憶されている。

プログラム群９２２には、実施の形態において「〜部」として説明する機能を実行するプログラムが含まれる。プログラム（例えば、縮退処理プログラム）は、ＣＰＵ９０１により読み出され実行される。すなわち、プログラムは、「〜部」としてコンピュータを機能させるものであり、また「〜部」の手順や方法をコンピュータに実行させるものである。

ファイル群９２３には、実施の形態において説明する「〜部」で使用される各種データ（入力、出力、判定結果、計算結果、処理結果など）が含まれる。

実施の形態において構成図およびフローチャートに含まれている矢印は主としてデータや信号の入出力を示す。
フローチャートなどに基づいて説明する実施の形態の処理はＣＰＵ９０１や記憶装置や通信装置などのハードウェアを用いて実行される。

実施の形態において「〜部」として説明するものは「〜回路」、「〜装置」、「〜機器」であってもよく、また「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ファームウェア、ソフトウェア、ハードウェアまたはこれらの組み合わせのいずれで実装されても構わない。

実施の形態１において、例えば、以下のような効果を奏する分散システム１００について説明した。

分散システム１００は、正常時の業務フローを縮退時の業務フローに置き換えることにより、業務フローから一部の業務処理（サービス）を削除したり、業務フローを構成する業務処理を変更したりすることができる。
分散システム１００は、障害発生時に実行していた業務処理に応じて縮退時の業務フローを選択し、業務データを縮退時の業務フロー用のデータに変換する。これにより、分散システム１００は、正常時の業務フローで処理されていた処理中の業務データを縮退時の業務フローで引き続き処理することができる。

実施の形態１において、分散システム１００は、ＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）ミドルウェアやＢＰＭ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ）ミドルウェアなどのサービス実行基盤を用いて業務縮退を実現するシステムとして構成することができる。
サービス実行基盤は、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）における基本ミドルウェアである。計算機２００の業務アプリ２９８やその他の機能はサービス実行基盤上で実行される。サービス実行基盤に処理要求があると、業務フロー定義に従った処理順で業務アプリ２９８が起動され、最後に要求元へ結果が返される。

実施の形態２．
業務フローの所定の業務処理が終了したときに業務データを保存し、その後の業務処理で障害が発生した場合に保存した業務データを用いた縮退フローを実行する形態について説明する。
以下、実施の形態１と異なる事項について主に説明する。説明を省略する事項については実施の形態１と同様である。

図８は、実施の形態２における計算機２００の機能構成図である。
実施の形態２における計算機２００の機能構成について、図８に基づいて説明する。

計算機２００は、実施の形態１で説明したデータマッピング部２４１の代わりに、チェックポイント保存部２４２とチェックポイント回復部２４３とを備える。

チェックポイント保存部２４２は、特定の業務フローを構成する複数の業務処理のうちチェックポイントとして予め定められる業務処理の実行が終了したときにチェックポイントで処理された業務データをチェックポイントＤＢ１２０（ＤＢ：データベース）に保存する。以下、チェックポイントで処理された業務データを含んだデータを「チェックポイントデータ１２９」という。

チェックポイント回復部２４３は、特定の業務フローを構成するいずれかの業務処理で障害が発生した場合、チェックポイントＤＢ１２０からチェックポイントデータ１２９を取得する。

サービス制御部２５０は、チェックポイント回復部２４３によって取得されたチェックポイントデータ１２９に含まれる業務データを業務アプリ実行部２１０によって処理する。

チェックポイントＤＢ１２０（所定のチェックポイント保存装置の一例）は、チェックポイントデータ１２９を保存する記憶装置である。
チェックポイントＤＢ１２０は、各計算機２００Ａ・Ｂからアクセスされる。

以下、業務データを設定する変数を「タスク変数」という。
トークン２９９には業務データの代わりにタスク変数の変数名が含まれ、チェックポイントデータ１２９にはタスク変数名に対応付けてタスク変数に設定された変数値（業務データ）が含まれる。

計算機２００は、タスク変数ＡＰＩ（アプリケーションインタフェース）を備える（図示省略）。
トークン２９９が発生した場合、タスク変数ＡＰＩは、タスク変数定義に基づいてトークン毎にタスク変数を生成する。つまり、タスク変数はトークン毎に管理される。タスク変数定義はタスク変数の変数名やデータ型を設定したデータであり、計算機記憶部２９０に予め記憶する（図示省略）。

図９は、実施の形態２における障害ルール対応表２９１の一例を示す図である。
図８、図９に示すように、実施の形態２ではマップアプリ２９３は不要である。但し、実施の形態１と同様にマップアプリ２９３を用いても構わない。

図１０は、実施の形態２における業務フローＰｎの一例を示す図である。
図１０に示すように、業務フローＰｎを構成する業務アプリａ−ｅのうち業務アプリｂがチェックポイントである。
したがって、業務アプリｂの実行終了時に業務アプリｂで処理されたトークン２９９がチェックポイントデータ１２９としてチェックポイントＤＢ１２０に記憶される。
業務アプリｂがチェックポイントであることは、業務フローＰｎの業務フロー定義に予め設定する。

また、業務アプリｃで障害が発生したときに業務アプリｃで処理していたトークン２９９の処理を継続するための縮退フローを「Ｐ３」とする。
縮退フローＰ３は、計算機２００Ａで業務アプリ２９８を「ｂ’→ｄ→ｅ」の順で実行する処理手順である。

図１１は、実施の形態２におけるチェックポイントデータ１２９による業務データ（タスク変数）の回復の流れを示す図である。
実施の形態２におけるチェックポイントデータ１２９による業務データ（タスク変数）の回復の流れについて、図１１に基づいて説明する。

図１０に示した業務フローＰｎに従って、まず、計算機２００Ａの業務アプリ実行部２１０が業務アプリａを実行する。業務アプリａを実行後のタスク変数Ｖａｒ１（文字列）の値は“ａａａ”であり、タスク変数Ｖａｒ２（整数）の値は“２０”である。各タスク変数の値はトークン２９９毎に設けるメモリ内の記憶領域に設定される。以下、トークン２９９毎に設ける記憶領域を「タスク領域２０１」という。

計算機２００Ａと計算機２００Ｂとは、トークン２９９の他にタスク領域２０１の各タスク変数を通信し、互いにタスク領域２０１の同期をとる。
つまり、計算機２００Ｂは計算機２００Ａによって処理されたタスク変数に対して処理を行い、計算機２００Ａは計算機２００Ｂによって処理されたタスク変数に対して処理を行う。

次に、計算機２００Ｂの業務アプリ実行部２１０が業務アプリｂを実行する。業務アプリｂを実行後のタスク変数Ｖａｒ１の値は“ｂｂ”であり、タスク変数Ｖａｒ２の値は“１０”である。
計算機２００Ｂのチェックポイント保存部２４２は、業務アプリｂを実行後のタスク変数Ｖａｒ“ｂｂ”とタスク変数Ｖａｒ２“１０”をチェックポイントＤＢ１２０にチェックポイントデータ１２９として記憶する。

次に、計算機２００Ｂの業務アプリ実行部２１０が業務アプリｃを実行する。ここで、業務アプリｃに障害が発生したものとする。

各計算機Ａ・Ｂのチェックポイント回復部２４３は、チェックポイントＤＢ１２０からチェックポイントデータ１２９を取得し、取得したチェックポイントデータ１２９に含まれるタスク変数Ｖａｒ１“ｂｂ”とタスク変数Ｖａｒ２“１０”とをタスク領域２０１に設定する。これにより、タスク領域２０１は、業務アプリｂを実行後の状態に回復する。

以後、縮退フローＰ３に従って、計算機２００Ａの各業務アプリ実行部２１０が業務アプリｂ’，ｄ，ｅを実行して回復後のタスク領域２０１のタスク変数を処理する。

図１２は、実施の形態２における分散システム１００のサービス構成変更方法を示すフローチャートである。
実施の形態２における分散システム１００のサービス構成変更方法について、図１２に基づいて説明する。

ここで、チェックポイントである業務アプリ２９８の実行が終了した場合、当該業務アプリ２９８を実行した計算機２００のチェックポイント保存部２４２は、チェックポイントＤＢ１２０にチェックポイントデータ１２９を保存しているものとする。
つまり、チェックポイント保存部２４２は、当該業務アプリ２９８で処理されたトークン２９９の各タスク変数をチェックポイントデータ１２９としてタスク領域２０１からチェックポイントＤＢ１２０に退避する。

サービス構成変更方法の処理は、実施の形態１（図６参照）で説明したＳ１６０の代わりに、Ｓ１６１を含む。

その他の処理（Ｓ１１０−Ｓ１５０、Ｓ１７０、Ｓ１８０）は実施の形態１と同様である。

Ｓ１６１において、各計算機２００Ａ・Ｂのトークン切替部２４０は、収集したトークン２９９毎にトークン２９９の処理情報を縮退情報（Ｓ１４０参照）に基づいて更新する。更新方法は、実施の形態１のＳ１６０と同様である。

さらに、各計算機２００Ａ・Ｂのチェックポイント回復部２４３は、チェックポイントＤＢ１２０からチェックポイントデータ１２９を取得する。
チェックポイント回復部２４３は、収集されたトークン２９９毎にチェックポイントデータ１２９でタスク領域２０１のタスク変数を回復する（図１１参照）。

これにより、分散システム１００は、回復後のタスク変数に対して縮退フローに従って業務処理を継続することができる。

必要に応じて、各業務アプリ２９８に実施の形態１で説明したマップアプリ２９３の機能を設けてもよい。この場合、各業務アプリ２９８はタスク変数を変換し、変換後のタスク変数を処理する。

実施の形態２において、例えば、以下のような効果を奏する分散システム１００について説明した。
分散システム１００は、チェックポイント回復機能によって業務データ（タスク変数）を自動的に回復することにより、障害発生時に各計算機２００からトークン２９９を収集する必要が無い。また、縮退フローを回復後の業務データに対応したものにすれば、分散システム１００は業務データを回復するため、マップアプリ２９３によって業務データを変換する必要が無い。つまり、マップアプリ２９３を開発が不要になる。

実施の形態３．
１つの縮退フロー定義で複数の縮退フローを表す形態について説明する。
以下、実施の形態１、２と異なる事項について主に説明する。説明を省略する事項については実施の形態１、２と同様である。

＜実施例１＞
計算機２００の機能構成は、実施の形態１（図２参照）と同様である。

但し、障害ルール対応表２９１は、特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に縮退フローを構成する複数の業務処理のうち実行不要な業務処理をスキップ処理として特定するスキップ処理情報（後述する「（切替後）スキップ」）を含む。
障害ルール解釈部２３０は、障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応するスキップ処理情報を業務データのスキップ処理情報として障害ルール対応表２９１から取得する。
サービス制御部２５０は、障害の発生時に処理されていた業務データ毎に業務データの縮退フローに基づいて業務データを処理する。例えば、サービス制御部２５０は、業務データの縮退フローを構成する複数の業務処理のうち業務データのスキップ処理情報によって特定されるスキップ処理を除いた残りの業務処理で業務データを処理する。

図１３は、実施の形態３（実施例１）における障害ルール対応表２９１と縮退フローＰ０とを示す図である。
実施の形態３（実施例１）における障害ルール対応表２９１と縮退フローＰ０とについて、図１３に基づいて説明する。

障害ルール対応表２９１は、実施の形態１（図４参照）で説明した項目に加えて、「（切替後）スキップ」を有する。

「（切替後）スキップ」は、縮退フローＰ０を構成する業務アプリ２９８のうち実行しない業務アプリ２９８のアプリ名を示す。

例えば、縮退フローＰ０が「ａ→ｂ→ｃ’→ｄ→ｅ」であり、（切替後）スキップが「ｂ，ｄ」である場合、サービス制御部２５０は、縮退フローＰ０から業務アプリｂ，ｄを除外して縮退フローＰ０’「ａ→ｃ’→ｅ」を生成し、生成した縮退フローＰ０’を実行する。

＜実施例２＞
計算機２００の機能構成は、実施の形態１（図２参照）と同様である。

但し、業務フロー定義ファイル２９２は、少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義を含む。縮退フロー定義は、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す。
障害ルール対応表２９１は、特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎にフローラベル（後述する「（切替後）ラベル」）を含む。
障害ルール解釈部２３０は、障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応するフローラベルを業務データのフローラベルとして障害ルール対応表２９１から取得する。
サービス制御部２５０は、障害の発生時に処理されていた業務データ毎に共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する。

図１４は、実施の形態３（実施例２）における障害ルール対応表２９１と縮退フローＰ０とを示す図である。
実施の形態３（実施例２）における障害ルール対応表２９１と縮退フローＰ０とについて、図１４に基づいて説明する。

縮退フローＰ０は、ラベル「Ｌａ」で識別される個別処理「ａ→ｂ」と、ラベル「Ｌｂ」で識別される個別処理「ａ→ｆ」と、ラベル「Ｌｃ」で識別される個別処理「ａ→ｇ」と、全てのラベルで共通する共通処理「ｃ’→ｄ→ｅ」とで構成される。
つまり、縮退フローＰ０の縮退フロー定義は個別処理と共通処理とを組み合わせた３つの縮退フローを表す。３つの縮退フローは、ラベル「Ｌａ」で識別される縮退フロー「ａ→ｂ→ｃ’→ｄ→ｅ」、ラベル「Ｌｂ」で識別される縮退フロー「ａ→ｆ→ｃ’→ｄ→ｅ」、ラベル「Ｌｃ」で識別される縮退フロー「ａ→ｇ→ｃ’→ｄ→ｅ」である。

障害ルール対応表２９１は、実施の形態１（図４参照）で説明した項目に加えて、「（切替後）ラベル」を有する。

「（切替後）ラベル」は、縮退フローＰ０の縮退フロー定義に含まれる３つの縮退フローから選択する縮退フローを識別するラベル名を示す。

例えば、（切替後）ラベルが「Ｌａ」である場合、サービス制御部２５０は、縮退フローＰ０からラベル「Ｌａ」で識別される縮退フローを選択して縮退フローＰ０’「ａ→ｂ→ｃ’→ｄ→ｅ」を生成し、生成した縮退フローＰ０’を実行する。

＜実施例３＞
計算機２００の機能構成は、実施の形態１（図２参照）と同様である。

但し、業務フロー定義ファイル２９２は、少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義を含む。縮退フロー定義は、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す。
計算機記憶部２９０（ルックアップテーブル記憶部の一例）は、特定の業務データに設定されるデータ値と特定のフローラベルとを対応付けたルックアップテーブル２９４を記憶する。
障害ルール対応表２９１は、特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に所定の個別データを識別するデータ名（後述する「（切替後）タスク変数」）を含む。
障害ルール解釈部２３０は、障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応するデータ名を業務データの個別データ名として障害ルール対応表２９１から取得する。
サービス制御部２５０（フローラベル取得部の一例）は、障害の発生時に処理されていた業務データ毎に業務データの個別データ名によって識別される個別データのデータ値を判定する。サービス制御部２５０は、判定したデータ値に対応するフローラベルを業務データのフローラベルとしてルックアップテーブル２９４から取得する。
サービス制御部２５０は、障害の発生時に処理していた業務データ毎に共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する。

図１５は、実施の形態３（実施例３）における障害ルール対応表２９１とルックアップテーブル２９４と縮退フローＰ０’とを示す図である。
実施の形態３（実施例３）における障害ルール対応表２９１とルックアップテーブル２９４と縮退フローＰ０’とについて、図１５に基づいて説明する。

縮退フローＰ０（図示省略）の縮退フロー定義は、実施例２と同じく、複数（３つ）の縮退フローを含む（図１４参照）。

障害ルール対応表２９１は、実施の形態１（図４参照）で説明した項目に加えて、「（切替後）タスク変数」を有する。

「（切替後）タスク変数」は、トークン２９９に含まれる特定のタスク変数を識別する変数名を示す。

ルックアップテーブル２９４は、「タスク変数」「変数値」「ラベル」を対応付けたデータである。

「タスク変数」は、トークン２９９に含まれる特定のタスク変数を識別する変数名を示す。
「変数値」は、タスク変数の値を示す。
「ラベル」は、縮退フローＰ０の縮退フロー定義に含まれる３つの縮退フローから選択する縮退フローを識別するラベル名を示す。

例えば、（切替後）タスク変数が「Ｄａ」であり、タスク変数Ｄａの変数値が「ｘ」である場合、サービス制御部２５０は、タスク変数「Ｄａ」と変数値「ｘ」とに対応するラベル名「Ｌａ」をマップアプリ２９３から取得する。
サービス制御部２５０は、縮退フローＰ０（図１４参照）からラベル名「Ｌａ」で識別される縮退フローを選択して縮退フローＰ０’「ａ→ｂ→ｃ’→ｄ→ｅ」を生成し、生成した縮退フローＰ０’を実行する。

＜実施例４＞
計算機２００の機能構成は、実施の形態１（図２参照）と同様である。

但し、業務フロー定義ファイル２９２は、少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義を含む。縮退フロー定義は、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す。
計算機記憶部２９０は、特定の業務データに設定されるデータ値を入力して入力したデータ値に予め対応付けられたフローラベルを出力するラベル決定スクリプト２９５（フローラベル出力プログラムの一例）を記憶する。
障害ルール対応表２９１は、特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に所定の個別データを識別するデータ名（後述する「（切替後）タスク変数」）を含む。
障害ルール解釈部２３０は、障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応するデータ名を業務データの個別データ名として障害ルール対応表２９１から取得する。
サービス制御部２５０（フローラベル出力部の一例）は、障害の発生時に処理されていた業務データ毎に業務データの個別データ名によって識別される個別データのデータ値を判定する。サービス制御部２５０は、判定したデータ値に対応するフローラベルを業務データのフローラベルとしてラベル決定スクリプト２９５を実行して取得する。
サービス制御部２５０は、障害の発生時に処理していた業務データ毎に共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する。

図１６は、実施の形態３（実施例４）のおける障害ルール対応表２９１と縮退フローＰ０’とを示す図である。
実施の形態３（実施例４）のおける障害ルール対応表２９１と縮退フローＰ０’とについて、図１６に基づいて説明する。

縮退フローＰ０（図示省略）の縮退フロー定義は、実施例２と同じく、複数（３つ）の縮退フローを含む（図１４参照）。

障害ルール対応表２９１は、実施の形態１（図４参照）で説明した項目に加えて、「（切替後）タスク変数」を有する。

「（切替後）タスク変数」は、トークン２９９に含まれる特定のタスク変数を識別する変数名を示す。

ラベル決定スクリプト２９５は、タスク変数の変数名と変数値とを入力し、入力したタスク変数の変数名と変数値とに対応する所定のラベル名を出力するプログラムである。

例えば、（切替後）タスク変数が「Ｄａ」であり、タスク変数Ｄａの変数値が「ｘ」である場合、サービス制御部２５０は、タスク変数「Ｄａ」と変数値「ｘ」とをラベル決定スクリプト２９５の入力としてラベル決定スクリプト２９５を実行する。
ラベル決定スクリプト２９５からラベル名「Ｌａ」が出力された場合、サービス制御部２５０は、縮退フローＰ０（図１４参照）からラベル名「Ｌａ」で識別される縮退フローを選択して縮退フローＰ０’「ａ→ｂ→ｃ’→ｄ→ｅ」を生成し、生成した縮退フローＰ０’を実行する。

実施例１から実施例４を組み合わせても構わない。
例えば、障害ルール対応表２９１の「切替前位置」や「障害」に応じて適用する実施例が異なってもよい。
つまり、縮退前位置「新規」の縮退フローは実施例１と同様に（切替後）スキップに従って決定し、縮退前位置「ａ」の縮退フローは実施例２と同様に（切替後）ラベルに従って決定してもよい。縮退前位置「ｂ」の縮退フローは実施例３と同様に（切替後）タスク変数とマップアプリ２９３とに従って決定し、縮退前位置「ｃ」の縮退フローは実施例４と同様に（切替後）タスク変数とラベル決定スクリプト２９５とに従って決定してもよい。

実施例１と実施例２−４を組み合わせても構わない。
つまり、実施例２−４のいずれかと同様にラベル名を判定し、実施例１と同様に（切替後）スキップを判定し、ラベル名で識別される縮退フローから（切替後）スキップで識別される業務アプリ２９８を削除してもよい。

実施の形態３におけるサービス構成変更方法の処理は、実施の形態１と同様である（図６参照）。
但し、Ｓ１７０において、サービス制御部２５０は、トークン２９９毎に実施例１−４（または組み合わせの実施例）の処理を実行してトークン２９９の縮退フローを決定する。サービス制御部２５０は、決定した各縮退フローの縮退フロー定義をフロー定義領域に設定する。
Ｓ１８０において、サービス制御部２５０は、トークン２９９毎にトークン２９９の縮退フローに従ってトークン２９９を処理する。

但し、実施の形態２（図１２参照）と同様にサービス構成方法の処理を実行しても構わない。つまり、実施の形態２と同様にチェックポイントの保存・回復を行っても構わない。

実施の形態３において、例えば、以下のような効果を奏する分散システム１００について説明した。
分散システム１００は、１つの縮退フロー定義で複数の縮退フローを表す。これにより、縮退フロー毎に縮退フロー定義を生成する必要がなくなる。つまり、縮退フロー定義の数を減らし、縮退フロー定義を生成するための作業量を減らすことができる。

１００ 分散システム、１１０ 通信サーバ、１２０ チェックポイントＤＢ、１２９ チェックポイントデータ、２００ 計算機、２０１ タスク領域、２１０ 業務アプリ実行部、２２０ 障害監視部、２３０ 障害ルール解釈部、２４０ トークン切替部、２４１ データマッピング部、２４２ チェックポイント保存部、２４３ チェックポイント回復部、２５０ サービス制御部、２６０ 計算機間連携部、２９０ 計算機記憶部、２９１ 障害ルール対応表、２９２ 業務フロー定義ファイル、２９３ マップアプリ、２９４ ルックアップテーブル、２９５ ラベル決定スクリプト、２９８ 業務アプリ、２９９ トークン、９０１ ＣＰＵ、９０２ バス、９０３ ＲＯＭ、９０４ ＲＡＭ、９０５ 通信装置、９１１ ディスプレイ装置、９１２ キーボード、９１３ マウス、９１４ ドライブ装置、９２０ 磁気ディスク装置、９２１ ＯＳ、９２２ プログラム群、９２３ ファイル群。

Claims (9)

1. 処理順を有する複数の業務処理で構成される特定の業務フローの複数の業務処理を組み合わせた業務処理の組み合わせ毎に、当該業務処理で障害が発生した場合に前記特定の業務フローの代わりに実行する業務フローを縮退フローとして特定する縮退フロー情報と、業務データの変換方法を特定するデータ変換情報とを記憶する縮退フロー情報記憶部と、
   前記特定の業務フローを実行して業務データを処理する業務フロー実行部と、
   前記特定の業務フローのいずれかの業務処理で障害が発生した場合、障害の発生時に処理されていた業務データ毎に、業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応する縮退フロー情報とデータ変換情報とを前記縮退フロー情報記憶部から取得する縮退フロー情報取得部と、
   前記障害の発生時に処理されていた業務データ毎に、前記縮退フロー情報取得部によって取得されたデータ変換情報によって特定される変換方法に従って業務データを変換する業務データ変換部とを備え、
   前記業務フロー実行部は、障害の発生時に処理していた業務データ毎に、前記縮退フロー情報取得部によって取得された縮退フロー情報によって特定される縮退フローを前記特定の業務フローの代わりに実行して、前記業務データ変換部によって変換された業務データを処理する
   ことを特徴とする縮退処理装置。
2. 前記縮退処理装置は、前記特定の業務フローを構成する複数の業務処理のうちチェックポイントとして予め定められる業務処理の実行が終了したときに前記チェックポイントで処理された業務データを所定のチェックポイント保存装置に保存するチェックポイント保存部を備え、
   前記業務フロー実行部は、前記チェックポイント保存部に保存された業務データを処理する
   ことを特徴とする請求項１記載の縮退処理装置。
3. 前記縮退処理装置は、縮退フロー毎に縮退フローを構成する複数の業務処理を特定する縮退フロー定義を記憶する縮退フロー定義記憶部を備え、
   前記縮退フロー情報記憶部は、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に縮退フローを構成する複数の業務処理のうち実行不要な業務処理をスキップ処理として特定するスキップ処理情報を記憶し、
   前記縮退フロー情報取得部は、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と前記障害が発生した業務処理との組み合わせに対応するスキップ処理情報を業務データのスキップ処理情報として前記縮退フロー情報記憶部から取得し、
   前記業務フロー実行部は、前記障害の発生時に処理していた業務データ毎に業務データの縮退フローを構成する複数の業務処理のうち業務データのスキップ処理情報によって特定されるスキップ処理を除いた残りの業務処理で業務データを処理する
   ことを特徴とする請求項１または請求項２に記載の縮退処理装置。
4. 前記縮退処理装置は、少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義であって、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す縮退フロー定義を記憶する縮退フロー定義記憶部を備え、
   前記縮退フロー情報記憶部は、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎にフローラベルを記憶し、
   前記縮退フロー情報取得部は、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と前記障害が発生した業務処理との組み合わせに対応するフローラベルを業務データのフローラベルとして前記縮退フロー情報記憶部から取得し、
   前記業務フロー実行部は、前記障害の発生時に処理していた業務データ毎に前記共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の縮退処理装置。
5. 業務データは、複数の個別データを含み、
   前記縮退処理装置は、
   少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義であって、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す縮退フロー定義を記憶する縮退フロー定義記憶部と、
   特定の業務データに設定されるデータ値と特定のフローラベルとを対応付けたルックアップテーブルを記憶するルックアップテーブル記憶部と、
   特定のデータ値に対応するフローラベルを前記ルックアップテーブルから取得するフローラベル取得部とを備え、
   前記縮退フロー情報記憶部は、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に所定の個別データを識別するデータ名を記憶し、
   前記縮退フロー情報取得部は、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と前記障害が発生した業務処理との組み合わせに対応するデータ名を業務データの個別データ名として前記縮退フロー情報記憶部から取得し、
   前記フローラベル取得部は、前記障害の発生時に処理されていた業務データ毎に業務データの個別データ名によって識別される個別データのデータ値を判定し、判定したデータ値に対応するフローラベルを業務データのフローラベルとして前記ルックアップテーブルから取得し、
   前記業務フロー実行部は、前記障害の発生時に処理していた業務データ毎に前記共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の縮退処理装置。
6. 業務データは、複数の個別データを含み、
   前記縮退処理装置は、
   少なくとも一部の業務処理が共通する複数の縮退フローを定義した縮退フロー定義であって、複数の縮退フローに共通する業務処理を共通処理として示し、縮退フロー毎に縮退フローを識別するフローラベルに対応付けて他の縮退フローと共通しない業務処理を個別処理として示す縮退フロー定義を記憶する縮退フロー定義記憶部と、
   特定の業務データに設定されるデータ値を入力して入力したデータ値に予め対応付けられたフローラベルを出力するフローラベル出力プログラムを記憶するプログラム記憶部と、
   前記フローラベル出力プログラムを実行して特定のデータ値に対応するフローラベルを取得するフローラベル取得部とを備え、
   前記縮退フロー情報記憶部は、前記特定の業務フローを構成する複数の業務処理を組み合わせた業務処理の組み合わせ毎に所定の個別データを識別するデータ名を記憶し、
   前記縮退フロー情報取得部は、前記障害の発生時に処理されていた業務データ毎に業務データを処理していた業務処理と前記障害が発生した業務処理との組み合わせに対応するデータ名を業務データの個別データ名として前記縮退フロー情報記憶部から取得し、
   前記フローラベル取得部は、前記障害の発生時に処理されていた業務データ毎に業務データの個別データ名によって識別される個別データのデータ値を判定し、判定したデータ値に対応するフローラベルを業務データのフローラベルとして前記フローラベル出力プログラムを実行して取得し、
   前記業務フロー実行部は、前記障害の発生時に処理していた業務データ毎に前記共通処理と業務データのフローラベルに対応する個別処理とによって業務データを処理する
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の縮退処理装置。
7. 請求項１から請求項６のいずれか一項に記載の複数の縮退処理装置を有し、
   第一の縮退処理装置は、前記特定の業務フローを構成する少なくともいずれかの業務処理を実行し、
   第二の縮退処理装置は、前記特定の業務フローを構成する複数の業務処理のうち前記第一の縮退処理装置によって実行される業務処理以外の残りの業務処理を実行する
   ことを特徴とする縮退処理システム。
8. 処理順を有する複数の業務処理で構成される特定の業務フローの複数の業務処理を組み合わせた業務処理の組み合わせ毎に、当該業務処理で障害が発生した場合に前記特定の業務フローの代わりに実行する業務フローを縮退フローとして特定する縮退フロー情報と、業務データの変換方法を特定するデータ変換情報とを記憶する縮退フロー情報記憶部を備える縮退処理装置の縮退処理方法であって、
   縮退フロー情報取得部は、前記特定の業務フローのいずれかの業務処理で障害が発生した場合、障害の発生時に処理されていた業務データ毎に、業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応する縮退フロー情報とデータ変換情報とを前記縮退フロー情報記憶部から取得し、
   業務データ変換部は、前記障害の発生時に処理されていた業務データ毎に、前記縮退フロー情報取得部によって取得されたデータ変換情報によって特定される変換方法に従って業務データを変換し、
   業務フロー実行部は、障害の発生時に処理していた業務データ毎に、前記縮退フロー情報取得部によって取得された縮退フロー情報によって特定される縮退フローを前記特定の業務フローの代わりに実行して、前記業務データ変換部によって変換された業務データを処理する
   ことを特徴とする縮退処理装置の縮退処理方法。
9. 処理順を有する複数の業務処理で構成される特定の業務フローの複数の業務処理を組み合わせた業務処理の組み合わせ毎に、当該業務処理で障害が発生した場合に前記特定の業務フローの代わりに実行する業務フローを縮退フローとして特定する縮退フロー情報と、業務データの変換方法を特定するデータ変換情報とを記憶する縮退フロー情報記憶部を備える縮退処理装置を機能させる縮退処理プログラムであって、
   前記特定の業務フローのいずれかの業務処理で障害が発生した場合、障害の発生時に処理されていた業務データ毎に、業務データを処理していた業務処理と障害が発生した業務処理との組み合わせに対応する縮退フロー情報とデータ変換情報とを前記縮退フロー情報記憶部から取得する縮退フロー情報取得部と、
   前記障害の発生時に処理されていた業務データ毎に、前記縮退フロー情報取得部によって取得されたデータ変換情報によって特定される変換方法に従って業務データを変換する業務データ変換部と、
   障害の発生時に処理していた業務データ毎に、前記縮退フロー情報取得部によって取得された縮退フロー情報によって特定される縮退フローを前記特定の業務フローの代わりに実行して、前記業務データ変換部によって変換された業務データを処理する業務フロー実行部として縮退処理装置を機能させる
   ことを特徴とする縮退処理プログラム。

Images