(57)【要約】【課題】正規の処理手段の代わりに代替処理手段による処理結果を用いて後段の処理手段に指示を行った場合に、正規の処理手段とは異なる処理が実施されてしまうことを低減する。【解決手段】配送指示システム１において障害が発生すると、窓口サーバー１１が外部から受けた通知を受けることで配送指示システム１における処理を代行する代替処理サーバー３と、代替処理サーバー３から受け取った発注依頼情報を保存すると共に配送指示システム１の代わりに発注サーバー２に発注を依頼するリカバリ支援サーバー４とを、有する。配送指示システム１は、障害復旧後、代替処理サーバー３に送った通知を含めて処理を再開する。リカバリ支援サーバー４は、障害復旧後、配送指示システム１から受け取った発注依頼情報と代替処理サーバー３から受け取った発注依頼情報とを比較することで、一致しない発注依頼情報に関しては発注サーバー２に発注の修正を指示する。【選択図】図１
2020008970.tif 000002
【特許請求の範囲】
【請求項１】
入力データに対して所定の処理を行う正規の処理手段が前記所定の処理を実施できない場合に代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段と、
前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段と、
前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段と、
前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記修正指示手段が指示する修正は、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の取り消し若しくは変更、又は前記後段の処理手段に対する処理指示の追加のうち少なくとも１つであることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記修正指示手段は、前記第１取得手段が取得した処理結果にあって前記第２取得手段が取得した処理結果にない処理結果に基づく処理指示を取り消すよう指示することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記修正指示手段は、前記第１取得手段が取得した処理結果になく前記第２取得手段が取得した処理結果にある処理結果に基づく処理指示を追加するよう指示することを特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記修正指示手段は、前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果の内容が異なる処理結果に基づく処理指示を変更するよう指示することを特徴とする請求項２に記載の情報処理装置。
【請求項６】
入力データに対して所定の処理を行う正規の処理手段と、
前記正規の処理手段が前記所定の処理を実施できない場合に前記入力データに対して前記所定の処理を実施する代替処理手段と、
前記正規の処理手段が前記所定の処理を実施できない場合に前記代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段と、
前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段と、
前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段と、
前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段と、
を有することを特徴とする情報処理システム。
【請求項７】
前記正規の処理手段の状態を監視する監視手段を有し、
前記監視手段は、前記正規の処理手段が前記所定の処理を実施できない場合に前記入力データに対する前記所定の処理の実施を前記代替処理手段に指示することを特徴とする請求項６に記載の情報処理システム。
【請求項８】
前記監視手段は、前記正規の処理手段が前記所定の処理を実施できるようになった場合に前記所定の処理の実施の停止を前記代替処理手段に指示することを特徴とする請求項６に記載の情報処理システム。
【請求項９】
コンピュータを、
入力データに対して所定の処理を行う正規の処理手段が前記所定の処理を実施できない場合に代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段、
前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段、
前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段、
前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム及びプログラムに関する。
【背景技術】
【０００２】
従来から、プログラムが入力データを処理した結果を後段のプログラムに送り、後段のプログラムが前段のプログラムの処理結果を入力データとして処理することで、最終的に一連のプログラムの処理結果としてデータを出力するシステムがある。このシステムにおいて、いずれかのプログラムに障害が発生すると、障害が発生したプログラムの代替プログラムに処理させることによって出力データを出力させる技術が提案されている（例えば、特許文献１）。
【０００３】
プログラムが障害から復旧すると、プログラムは処理を再開する。これにより、再開したプログラムは、障害発生時に処理していなかったデータを処理し、後段のプログラムにデータを出力することで処理を指示する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１１９２５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、代替処理手段が正規の処理手段と同等の機能を提供できない場合、正規の処理手段による処理結果と代替処理手段による処理結果とが一致しない場合があった。
【０００６】
本発明は、正規の処理手段の代わりに代替処理手段による処理結果を用いて後段の処理手段に指示を行った場合に、正規の処理手段とは異なる処理が実施されてしまうことを低減することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る情報処理装置は、入力データに対して所定の処理を行う正規の処理手段が前記所定の処理を実施できない場合に代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段と、前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段と、前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段と、前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段と、を有することを特徴とする。
【０００８】
また、前記修正指示手段が指示する修正は、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の取り消し若しくは変更、又は前記後段の処理手段に対する処理指示の追加のうち少なくとも１つであることを特徴とする。
【０００９】
また、前記修正指示手段は、前記第１取得手段が取得した処理結果にあって前記第２取得手段が取得した処理結果にない処理結果に基づく処理指示を取り消すよう指示することを特徴とする。
【００１０】
また、前記修正指示手段は、前記第１取得手段が取得した処理結果になく前記第２取得手段が取得した処理結果にある処理結果に基づく処理指示を追加するよう指示することを特徴とする。
【００１１】
また、前記修正指示手段は、前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果の内容が異なる処理結果に基づく処理指示を変更するよう指示することを特徴とする。
【００１２】
本発明に係る情報処理システムは、入力データに対して所定の処理を行う正規の処理手段と、前記正規の処理手段が前記所定の処理を実施できない場合に前記入力データに対して前記所定の処理を実施する代替処理手段と、前記正規の処理手段が前記所定の処理を実施できない場合に前記代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段と、前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段と、前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段と、前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段と、を有することを特徴とする。
【００１３】
また、前記正規の処理手段の状態を監視する監視手段を有し、前記監視手段は、前記正規の処理手段が前記所定の処理を実施できない場合に前記入力データに対する前記所定の処理の実施を前記代替処理手段に指示することを特徴とする。
【００１４】
また、前記監視手段は、前記正規の処理手段が前記所定の処理を実施できるようになった場合に前記所定の処理の実施の停止を前記代替処理手段に指示することを特徴とする。
【００１５】
本発明に係るプログラムは、コンピュータを、入力データに対して所定の処理を行う正規の処理手段が前記所定の処理を実施できない場合に代替処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第１取得手段、前記第１取得手段が取得した処理結果に基づく処理の実施を前記正規の処理手段の後段の処理手段に指示する処理指示手段、前記所定の処理を実施できるようになった前記正規の処理手段が前記入力データに対して前記所定の処理を実施したときの処理結果を取得する第２取得手段、前記第１取得手段が取得した処理結果と前記第２取得手段が取得した処理結果との比較結果に応じて、前記処理指示手段が前記後段の処理手段に対して既にした処理指示の修正を前記後段の処理手段に指示する修正指示手段、として機能させる。
【発明の効果】
【００１６】
請求項１に記載の発明によれば、正規の処理手段の代わりに代替処理手段による処理結果を用いて後段の処理手段に指示を行った場合に、正規の処理手段とは異なる処理が実施されてしまうことを低減することができる。
【００１７】
請求項２に記載の発明によれば、後段の処理手段に対して処理の追加、変更、又は取り消しを指示することができる。
【００１８】
請求項３に記載の発明によれば、後段の処理手段に対して処理の取り消しを指示することができる。
【００１９】
請求項４に記載の発明によれば、後段の処理手段に対して処理の追加を指示することができる。
【００２０】
請求項５に記載の発明によれば、後段の処理手段に対して処理の変更を指示することができる。
【００２１】
請求項６に記載の発明によれば、正規の処理手段の代わりに代替処理手段による処理結果を用いて後段の処理手段に指示を行った場合に、正規の処理手段とは異なる処理が実施されてしまうことを低減することができる。
【００２２】
請求項７に記載の発明によれば、入力データに対する所定の処理を代替処理手段に代行させることができる。
【００２３】
請求項８に記載の発明によれば、正規の処理手段による所定の処理の実施に戻すことができる。
【００２４】
請求項９に記載の発明によれば、正規の処理手段の代わりに代替処理手段による処理結果を用いて後段の処理手段に指示を行った場合に、正規の処理手段とは異なる処理が実施されてしまうことを低減することができる。
【図面の簡単な説明】
【００２５】
【図１】本実施の形態における配送システムの全体構成の一例を示す図であり、配送システムが正常に動作しているときのデータの流れを示す図である。
【図２】本実施の形態におけるリカバリ支援サーバーを示すブロック構成図である。
【図３】本実施の形態において物流業務サーバーが発注の要否の判断に用いる情報の一例をテーブル形式にて示す図である。
【図４Ａ】本実施の形態における処理のシーケンス図である。
【図４Ｂ】図４Ａに続く処理のシーケンス図である。
【図５】本実施の形態における配送システムにおいて障害が発生したときのデータの流れを示す図である。
【図６】本実施の形態における配送システムにおいて障害から復旧した後のデータの流れを示す図である。
【発明を実施するための形態】
【００２６】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００２７】
図１は、本発明に係る情報処理システムの一形態である配送システムの全体構成の一例を示す図である。本実施の形態における配送システムは、顧客のビルや店舗等の施設からの通知に応じて物品の配送を依頼する。図１には、配送指示システム１、発注サーバー２、代替処理サーバー３及びリカバリ支援サーバー４が示されている。
【００２８】
配送指示システム１は、顧客側からの通知を受けたことに応じて物品の配送が必要となる場合、発注依頼を発注サーバー２に対して行う。配送指示システム１は、窓口サーバー１１、振分サーバー１２、物流業務サーバー１３、保守業務サーバー１４及び管理サーバー１５を有している。このうち、窓口サーバー１１、振分サーバー１２、物流業務サーバー１３及び保守業務サーバー１４はそれぞれ、正規のプログラムを実行することで正規の処理手段として機能する。そして、顧客側からの通知に応じて必要により発注サーバー２に発注を依頼する。
【００２９】
窓口サーバー１１は、顧客側からの通知を受ける窓口となるサーバーコンピュータである。本実施の形態では、顧客の施設に設置の複合機に何らかの事象が発生したことに応じて複合機若しくは顧客から何らかの通知がされてくることを想定して説明するが、窓口サーバー１１は、これらの顧客側からの通知を入力データとする窓口処理プログラムを正規のプログラムとして実行する。通知には、例えば、部品の破損、消耗品切れ等何らかの物品が必要となる事象に関する通知や、消耗品切れの発生予告等現時点では物品が必要とならない事象に関する通知等が含まれる。窓口サーバー１１は、顧客側からの通知を受信すると、受信した通知の内容を通信ログ（図示せず）に記録する。
【００３０】
振分サーバー１２は、窓口サーバー１１が受信した通知を振り分けるサーバーコンピュータである。振分サーバー１２は、窓口サーバー１１からの通知を入力データとし、通知の内容に従って通知を振り分ける振分処理プログラムを正規のプログラムとして実行する。例えば、振分サーバー１２は、エンジニアに知らせるべき通知を後段の物流業務サーバー１３に振り分け、他の種類の通知を他のサーバーに振り分ける。
【００３１】
物流業務サーバー１３は、顧客側からの通知に応じて発注を依頼するかどうかを判断するために用いられるサーバーコンピュータである。物流業務サーバー１３は、振分サーバー１２からの通知を入力データとし、発注の要否の判断処理プログラムを正規のプログラムとして実行する。
【００３２】
保守業務サーバー１４は、発注サーバー２に発注を依頼するために用いられるサーバーコンピュータである。保守業務サーバー１４は、物流業務サーバー１３が発注要と判断したときに送られてくる通知（発注依頼指示）に応じて発注依頼情報を生成し、発注サーバー２に送る発注処理プログラムを正規のプログラムとして実行する。発注依頼情報には、発注日時、物品の種別、数量、配送依頼先、配送予定日等が含まれている。発注依頼情報自体は、従前と同じでよい。
【００３３】
管理サーバー１５は、配送指示システム１に含まれている各サーバー１１〜１４の管理を行う。管理サーバー１５は、各サーバー１１〜１４の状態を監視する監視手段として機能し、例えば、発生した障害の管理、障害ログの管理、障害の発生に伴う各サーバー１１〜１４への通知等を行う。また、管理サーバー１５は、いずれかのサーバー１１〜１４が正規のプログラムによる所定の処理を実施できない場合に代替処理の実施を代替処理サーバー３に指示する。更に、管理サーバー１５は、所定の処理を実施できなかったサーバー１１〜１４が所定の処理を実施できるようになった場合に代替処理の実施の停止を代替処理サーバー３に指示する。
【００３４】
発注サーバー２は、発注依頼を受けると、発注依頼により指示された依頼先に物品の配送を依頼する。発注サーバー２は、配送指示システム１の保守業務サーバー１４からの発注依頼を入力データとし、指示された依頼先に物品の配送を依頼する配送依頼プログラムを実行する。発注サーバー２が実行する配送依頼プログラムも正規のプログラムであり、発注サーバー２は正規の処理手段として機能する。また、配送指示システム１において障害が発生しているときには、リカバリ支援サーバー４からの発注依頼を入力データとして配送依頼プログラムを実行する。
【００３５】
本実施の形態では、正規の処理手段として複数のサーバー１１〜１４を配送指示システム１に設けている。ただ、発注サーバー２は、配送指示システム１から入力データを受け取るので、発注サーバー２からしてみれば、配送指示システム１全体が前段に位置する１つの正規の処理手段に相当するともいえる。換言すると、配送指示システム１からしてみれば、発注サーバー２は、後段に位置する正規の処理手段となる。
【００３６】
なお、発注サーバー２の所定の配送依頼先として、部品の配送業務を行う物流センターや客先にて部品交換等の作業を行うエンジニアが所在する事業所等が該当する。
【００３７】
代替処理サーバー３は、配送指示システム１において正規の処理手段が機能せず所定の処理を実施できない場合に配送指示システム１に代わって所定の処理を実施し、発注サーバー２に発注を依頼するサーバーコンピュータである。例えば、代替処理サーバー３は、配送指示システム１における正規の処理手段（サーバー１１〜１４）に代わって所定の代替プログラムを実行することで所定の処理を実施する代替処理手段として機能する。仮に振分サーバー１２において障害が発生すると、代替処理サーバー３は、振分サーバー１２、更に振分サーバー１２の後段の物流業務サーバー１３及び保守業務サーバー１４に代わって所定の処理を実施する。また、物流業務サーバー１３において障害が発生すると、代替処理サーバー３は、物流業務サーバー１３、更に物流業務サーバー１３の後段の保守業務サーバー１４に代わって所定の処理を実施する。
【００３８】
代替処理サーバー３は、前述した窓口処理プログラム、振分処理プログラム、判断処理プログラム及び発注処理プログラムの各代替プログラムを搭載しているので、各サーバー１１〜１４に代わって所定の処理を実施できる。ただ、詳細は後述するが、代替プログラムを実行することで行われる代替処理は、正規のプログラムと完全同一な機能を提供できるとは限らず、正規のプログラムが提供する機能の一部を有するに留まる。
【００３９】
前述した「所定の処理を実施できない場合」には、いずれかのサーバー１１〜１４に障害が発生して稼働不能な状態である場合に限らず、メンテナンス等障害以外の理由で稼働できない場合、あるいは高負荷等により正常な稼働が困難な状態である場合などを含む。
【００４０】
リカバリ支援サーバー４は、配送指示システム１において正規の処理手段として機能するいずれかのサーバー１１〜１４が所定の処理を実施できない場合に配送指示システム１のリカバリを支援するために用いられるサーバーコンピュータである。
【００４１】
本実施の形態におけるリカバリ支援サーバー４は、前述した各サーバー１１〜１５，２，３と同様、従前から存在する汎用的なハードウェア構成で実現できる。すなわち、リカバリ支援サーバー４は、ＣＰＵ、ＲＯＭ、記憶手段としてのＲＡＭ及びハードディスクドライブ（ＨＤＤ）、ユーザインタフェース、他のサーバーコンピュータと通信を行う通信手段としてのネットワークインタフェースを内部バスに接続して構成される。ユーザインタフェースは、マウスやキーボード等の入力手段及びディスプレイ等の表示手段を有する。あるいは、入力手段及び表示手段を兼用するタッチパネル等により形成してもよい。
【００４２】
図２は、本実施の形態におけるリカバリ支援サーバー４を示すブロック構成図である。本実施の形態におけるリカバリ支援サーバー４は、代替データ取得部４１、処理指示部４２、正規データ取得部４３、修正指示部４４及び代替データ記憶部４５を有している。なお、本実施の形態の説明に用いない構成要素については図から省略している。
【００４３】
代替データ取得部４１は、第１取得手段として機能し、代替処理サーバー３における処理結果を取得する。前述したように、代替処理サーバー３は、配送指示システム１におけるいずれかのサーバー１１〜１４が所定の処理を実施できない場合に所定の処理を代行するので、本実施の形態の場合、処理結果として発注依頼情報を取得する。
【００４４】
処理指示部４２は、処理指示手段として機能し、代替データ取得部４１が取得した処理結果（発注依頼情報）を受け取ると、代替データ記憶部４５に保存し、その処理結果に基づき発注依頼を発注サーバー２に行うことで配送を指示する。代替データ記憶部４５に保存される発注依頼情報のデータ構成は、保守業務サーバー１４が生成する発注依頼情報と同じでよい。
【００４５】
正規データ取得部４３は、第２取得手段として機能し、所定の処理を実施できなかった配送指示システム１が所定の処理を実施できるようになった場合、配送指示システム１が処理できなかった入力データに対して所定の処理を実施したときの処理結果、すなわち配送指示システム１の保守業務サーバー１４が生成する発注依頼情報を取得する。
【００４６】
修正指示部４４は、修正指示手段として機能し、代替データ記憶部４５に保存されている発注依頼情報と、正規データ取得部４３が取得した発注依頼情報との比較結果に応じて、処理指示部４２が発注サーバー２に対して既にした処理指示の修正、すなわち発注依頼の修正を発注サーバー２に指示する。
【００４７】
代替データ記憶部４５には、代替データ取得部４１が取得し、処理指示部４２により発注サーバー２に送られた発注依頼情報が記憶される。
【００４８】
リカバリ支援サーバー４における各構成要素４１〜４４は、リカバリ支援サーバー４を形成するコンピュータと、コンピュータに搭載されたＣＰＵで動作するプログラムとの協調動作により実現される。また、代替データ記憶部４５は、リカバリ支援サーバー４に搭載されたＨＤＤにて実現される。あるいは、ＲＡＭ又は外部にある記憶手段をネットワーク経由で利用してもよい。
【００４９】
また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。
【００５０】
ここで、物流業務サーバー１３における発注の要否の判断方法について図３に示すテーブルを用いて説明する。
【００５１】
図３には、発注の要否の結果（発注する、発注しない）と当該結果を得るための条件が示されている。組合せパターンは、条件の組合せであり、例えば組合せパターンＮｏ．１に示すように、判断対象とする通知が全ての条件１〜７のうち条件１と条件５のみを満たす場合（図３において、条件を満たす場合を“○”で示す）、判断処理プログラムは、当該通知に対して発注要と判断する。なお、判断結果は「発注する」若しくは「発注しない」のいずれかであって、図３では、該当する方に“○”と記している。また、例えば組合せパターンＮｏ．７に示すように、判断対象とする通知が全ての条件１〜７のいずれも満たさない場合（図３において、条件を満たさない場合を“×”で示す）、判断処理プログラムは、当該通知に対して発注しないと判断する。
【００５２】
ところで、発注の要否を判断するための条件は、図３に示すように公開されている情報に基づく条件１〜４と、配送指示システム１内の情報に基づく条件５〜７とがある。前者の条件は、公開されている情報のみを参照すれば当該条件を満たすかどうかを判断できる条件である。つまり、前者の条件の判定に参照される情報は、配送指示システム１にとって秘匿性（セキュリティ性）のない情報であって配送指示システム１の外部に位置する代替処理サーバー３でも参照可能な情報である。これに対し、後者の条件は、配送指示システム１の内部のサーバー１１〜１５のみが参照可能な情報（少なくとも物流業務サーバー１３が参照可能な情報）を参照してはじめて当該条件を満たすかどうかを判断できる条件である。つまり、後者の条件の判定に参照される情報の少なくとも１つは、配送指示システム１にとって秘匿性（セキュリティ性）のある情報であり、配送指示システム１の外部に位置する代替処理サーバー３が参照できない情報である。
【００５３】
なお、図３に示した条件の数、組合せパターン及びその数は一例であって、この数やパターンに制限されるものではない。また、本実施の形態では、説明の便宜上、条件をテーブル形式にて示したが、判断処理プログラムを、必ずしもテーブルを参照せずに発注の要否を判断できるように作成してもよい。
【００５４】
次に、本実施の形態における動作について説明する。まず、正規の処理手段が所定の処理を実施できる通常状態の動作について図１及び図４Ａ、図４Ｂを用いて説明する。
【００５５】
図１では、通常状態におけるデータの流れを矢印にて示している。すなわち、窓口サーバー１１は、顧客側からの通知を受信すると（ステップ１０１）、その通知の内容を通信ログに保存する窓口処理を行う（ステップ１０２）。そして、窓口サーバー１１は、受信した通知を振分サーバー１２に送る（ステップ１０３）。
【００５６】
なお、配送指示システム１において後段のサーバーに送られる通知は、通信ログに保存された通知そのものでもよいし、窓口サーバー１１が通信ログに保存する際に割り振った通知の識別情報（通知ＩＤ）でもよい。後段のサーバーに通知を送る際には通知ＩＤが付加される。配送指示システム１における各サーバー１１〜１５は、通信ログを参照でき、通知ＩＤによって所望の通知を取得できる。
【００５７】
振分サーバー１２は、窓口サーバー１１から送られてきた通知の振分処理を行う（ステップ１０４）。その通知が複合機のエンジニアに知らせるべき通知であれば、物流業務サーバー１３に送る（ステップ１０５）。
【００５８】
物流業務サーバー１３は、振分サーバー１２から送られてきた通知に基づき当該通知に応じて図３に示すテーブルの設定内容に従って発注の要否の判定処理を行う（ステップ１０６）。発注要と判断した場合は、振分サーバー１２から送られてきた通知を送ることによって発注依頼を保守業務サーバー１４に指示する（ステップ１０７）。発注不要と判断した場合は、発注依頼指示をしない。発注の要不要の判定結果を管理サーバー１５に通知して管理させるようにしてもよい。
【００５９】
保守業務サーバー１４は、物流業務サーバー１３から送られてきた通知（発注依頼指示）の内容に従って配送依頼先を特定するなどして発注依頼情報を生成する処理を行う（ステップ１０８）。そして、生成した発注依頼情報を発注サーバー２に送る（ステップ１０９）。発注依頼情報には、情報生成の元になる通知の通知ＩＤが含まれている。
【００６０】
発注サーバー２は、保守業務サーバー１４から送られてきた発注依頼情報に従って、指定された依頼先に配送を依頼する（ステップ１１０）。
【００６１】
通常時は、上記説明した処理（ステップ１０１〜１１０）が繰り返し実施される。ここで、配送指示システム１の振分サーバー１２において障害が発生したとする（ステップ１２０）。振分サーバー１２に障害が発生することで、後段の物流業務サーバー１３及び保守業務サーバー１４には、前段から通知が送られてこなくなる。このときのデータの流れを図５に示す。
【００６２】
管理サーバー１５は、配送指示システム１のエラーログを監視するなどして振分サーバー１２において障害が発生したことを検知すると、その旨を少なくとも窓口サーバー１１に通知する。
【００６３】
窓口サーバー１１は、顧客側からの通知を受信すると（ステップ１２１）、その通知の内容を通信ログに保存する窓口処理を行う（ステップ１２２）。そして、窓口サーバー１１は、受信した通知を障害発生中の振分サーバー１２の代わりに代替処理サーバー３に送る（ステップ１２３）。なお、管理サーバー１５は、代替処理の実施を代替処理サーバー３に直接指示してもよいし、上記のように窓口サーバー１１が受信した通知を代替処理サーバー３に送らせることで、これを代替処理の実施の指示としてもよい。
【００６４】
代替処理サーバー３は、窓口サーバー１１から送られてきた通知を受けると代替処理を実施する（ステップ１２４）。ここでは、代替処理サーバー３は、窓口サーバー１１から通知を受けているので、振分サーバー１２にて障害が発生したことと、振分サーバー１２に加えて振分サーバー１２の後段の物流業務サーバー１３及び保守業務サーバー１４で実施されるべき処理をも合わせて代行する必要があることを認識する。すなわち、代替処理サーバー３は、振分処理プログラム、判断処理プログラム及び発注処理プログラムの各代替プログラムを実行することで代替処理を実施することになる。代替処理の内容は、正規のプログラムの実行内容と同じなので説明を省略する。ただ、判断処理プログラムの代替プログラムは、図３に示すテーブルを参照できたとしても、配送指示システム１内の情報に基づく条件５〜７の検証に参照すべき情報は参照することができず、公開されている情報に基づく条件１〜４のみで発注の要否を判断することになる。従って、図３に示す設定例によると、組合せパターンＮｏ．３とＮｏ．４に該当する通知を受けた場合、代替処理サーバー３は、発注要と判断すべきところを発注不要と誤った判断をしてしまうことになる。
【００６５】
代替処理サーバー３は、これ以外にも発注不要と判断すべきところを発注要と誤って判断したり、あるいは発注処理プログラムの代替プログラムが発注数量を誤って算出したりするなど、代替処理サーバー３における代替プログラムは、機能が制限されていることから、正規のプログラムとは異なる処理を実施することで異なる処理結果を得る場合がある。
【００６６】
代替処理サーバー３は、以上のように代替処理を実施すると、その処理結果、すなわち発注要の場合に生成される発注依頼情報をリカバリ支援サーバー４に送る（ステップ１２５）。
【００６７】
リカバリ支援サーバー４は、代替処理サーバー３から送られてくる発注依頼情報を受け取ると、代替データ記憶部４５に保存する（ステップ１２６）。なお、代替処理サーバー３から送られてくる発注依頼情報には、通知ＩＤが含まれている。そして、発注依頼情報を発注サーバー２に送る発注処理を行うことで発注サーバー２に配送を依頼する（ステップ１２７）。
【００６８】
発注サーバー２は、リカバリ支援サーバー４から発注依頼情報が送られてくると、配送指示システム１から送られてくる場合と同様に受け取った発注依頼情報に従って、指定された依頼先に配送を依頼する（ステップ１２９）。
【００６９】
配送指示システム１において障害が発生している間は、上記説明した処理（ステップ１２１〜１２９）が繰り返し実施される。ここで、配送指示システム１の振分サーバー１２において発生した障害が復旧したとする（ステップ１３０）。振分サーバー１２が障害から復旧した後のデータの流れを図６に示す。
【００７０】
管理サーバー１５は、システムログ（エラーログ）等を監視するなどして振分サーバー１２が障害から復旧したことを検知すると、その旨を少なくとも窓口サーバー１１及び保守業務サーバー１４に通知する。
【００７１】
窓口サーバー１１は、顧客側からの通知を受信すると（ステップ１３１）、その通知の内容を通信ログに保存する窓口処理を行う（ステップ１３２）。そして、振分サーバー１２が障害から復旧したことを知らされているので、窓口サーバー１１は、受信した通知を振分サーバー１２に送る（ステップ１３３）。代替処理サーバー３では、窓口サーバー１１から通知が送られてこないため代替処理が実施されなくなる。このように、代替処理サーバー３に通知を送らないようにすることで、管理サーバー１５は、代替処理の実施の停止を暗に指示するようにしてもよいし、代替処理サーバー３に対して明示的に指示するようにしてもよい。
【００７２】
その後、振分サーバー１２は、窓口サーバー１１から通知を受けて振分処理を実施してから保守業務サーバー１４が実施する発注依頼情報の生成処理までの処理（ステップ１３３〜１３８）は、前述した通常時における処理（ステップ１０３〜１０８）と同じなので説明を省略する。
【００７３】
ところで、窓口サーバー１１が通信ログに保存して管理する通知にはそれぞれ、通知ＩＤが付加されて管理される。通知ＩＤは、窓口サーバー１１における窓口処理プログラムが処理した順番がわかるように各通知に対して付与するのが好適である。管理サーバー１５は、振分サーバー１２の障害発生時に代替処理サーバー３に送った通知の通知ＩＤのリストを窓口サーバー１１から取得している。あるいは、障害の発生から復旧するまでの間に窓口サーバー１１が取得した通知の通知ＩＤのリストを自ら得るようにしてもよい。また、通知ＩＤのリストではなく、代替処理サーバー３に送った先頭の通知ＩＤと最後の通知ＩＤ等代替処理サーバー３に代替処理させた通知の範囲がわかる情報を取得してもよい。そして、管理サーバー１５は、保守業務サーバー１４に送る振分サーバー１２の復旧通知には、代替処理サーバー３に送った通知の通知ＩＤのリストを含めている。
【００７４】
保守業務サーバー１４は、上記の通り発注依頼情報を生成するが、管理サーバー１５からの振分サーバー１２の復旧通知に含まれている全ての通知ＩＤ（代替処理サーバー３に送られた通知の通知ＩＤ）に対応する発注依頼情報を生成した後にまとめて発注サーバー２ではなくリカバリ支援サーバー４に送る（ステップ１３９）。
【００７５】
前述した配送指示システム１における障害の発生から復旧までの間に生成された発注処理が終了すると、保守業務サーバー１４は、通常処理の状態に戻り、物流業務サーバー１３から送られてくる通知に応じて生成した発注依頼情報を発注サーバー２に送る。
【００７６】
リカバリ支援サーバー４における正規データ取得部４３が、配送指示システム１の保守業務サーバー１４から送られてくる発注依頼情報を受け取ると、修正指示部４４は、その受け取った発注依頼情報に含まれているのと同じ通知ＩＤを含む発注依頼情報を代替データ記憶部４５から読み出し、比較する（ステップ１４０）。
【００７７】
ところで、前述したように、代替プログラムは、正規のプログラムが提供する機能の一部を有するに留まることからそれぞれの処理結果が異なる場合がある。すなわち、代替処理サーバー３は、物流業務サーバー１３と同じ内容の発注依頼情報が生成されている保証はない。
【００７８】
内容の異なる発注依頼情報としては、前述したように発注数量が異なっていたり、発注対象の物品が異なったりする場合が考えられる。その他にも、図３に示すテーブルを用いて説明したように、物流業務サーバー１３における正規のプログラムと代替処理サーバー３における代替プログラムとの機能（アクセス権限）の差から、代替プログラムが発注要のところを発注不要と判断をしたり、発注不要のところを発注要と判断したりする場合がある。前者の場合は発注漏れに該当する。後者の場合は無用な発注となる。
【００７９】
従って、リカバリ支援サーバー４における修正指示部４４は、同じ通知ＩＤの発注依頼情報の内容が不一致の場合、発注サーバー２に修正を指示する（ステップ１４１，１４２）。
【００８０】
具体的には、修正指示部４４は、同じ通知ＩＤの発注依頼情報が存在し、それらの内容が異なっている場合、配送指示システム１から受け取った発注依頼情報で既に送った発注依頼情報（代替処理サーバー３が生成した発注依頼情報）を変更するよう発注サーバー２に指示する。
【００８１】
また、配送指示システム１が生成した発注依頼情報と同じ通知ＩＤの発注依頼情報が代替データ記憶部４５に保存されていない場合、この場合は発注漏れに該当することになるので、修正指示部４４は、配送指示システム１が生成した発注依頼情報を送ることで発注サーバー２に配送依頼を新規に指示する。一方、代替データ記憶部４５に保存されている発注依頼情報と同じ通知ＩＤの発注依頼情報が配送指示システム１から送られてこなかった場合、この場合は無用な発注に該当することになるので、修正指示部４４は、既に送った当該発注依頼情報の取り消し、すなわち配送依頼のキャンセルを発注サーバー２に指示する。なお、リカバリ支援サーバー４における処理指示部４２が当該発注依頼情報を送信していなければ、送信しないように処理すればよく、配送依頼のキャンセルを発注サーバー２に指示する必要はない。
【００８２】
配送指示システム１が生成した発注依頼情報と代替処理サーバー３が生成した同じ通知ＩＤの発注依頼情報が一致している場合、代替処理サーバー３は、正しい発注依頼情報を生成していることになるので、当該発注依頼情報を修正指示の対象とする必要はない。
【００８３】
配送指示システム１における障害の発生から復旧までの間に生成された発注依頼情報に対する処理が終了すると、リカバリ支援サーバー４は、代替データ記憶部４５に保存されていた発注依頼情報を削除する。
【００８４】
そして、発注サーバー２は、リカバリ支援サーバー４からの修正指示を反映させて配送を依頼する（ステップ１４３）。
【００８５】
前述したように、代替プログラムにより生成される発注依頼情報は、正規のプログラムにより生成される発注依頼情報と一致するとは限らない。つまり、代替処理サーバー３における処理結果は、確度の低い処理結果となり得る。しかしながら、配送指示システム１が提供する業務を長時間停止させる訳にはいかない場合がある。配送指示システム１が提供する業務を停止させないために、システムを多重化して構築することも考えられるが，冗長化によりコストが増大する。また、本実施の形態のように、秘匿性のある情報を外部のサーバー（本実施の形態の場合、代替処理サーバー３）に提供できない場合もある。
【００８６】
そこで、本実施の形態においては、配送指示システム１において障害が発生したときには、業務の停止を回避するために確度は低くなるかもしれないが、代替処理サーバー３に代替処理を実施させるようにした。そして、障害復旧後に確度の低い処理結果（発注依頼情報）を保証するために、リカバリ支援サーバー４に発注依頼情報の正当性を検証させ、正しくない発注依頼を修正するようにした。なお、発注サーバー２が配送依頼先に配送依頼をした後でも配送依頼先で配送を実際に行っていない場合もあるので、配送の修正を電話等にて行うことも可能である。
【００８７】
上記説明では、振分サーバー１２にて障害が発生した場合を例にして説明したが、他のサーバー、すなわち物流業務サーバー１３又は保守業務サーバー１４で障害が発生した場合でも同様に処理すればよい。また、本実施の形態では、代替処理手段として代替処理サーバー３を設けて配送指示システム１における代替処理を一括して実施させるようにしたが、各サーバー１２〜１４に対応させて代替処理手段を設けてもよい。
【符号の説明】
【００８８】
１  配送指示システム、２  発注サーバー、３  代替処理サーバー、４  リカバリ支援サーバー、１１  窓口サーバー、１２  振分サーバー、１３  物流業務サーバー、１４  保守業務サーバー、１５  管理サーバー、４１  代替データ取得部、４２  処理指示部、４３  正規データ取得部、４４  修正指示部、４５  代替データ記憶部。
【図１】
2020008970.tif 000003
【図２】
2020008970.tif 000004
【図３】
2020008970.tif 000005
【図４Ａ】
2020008970.tif 000006
【図４Ｂ】
2020008970.tif 000007
【図５】
2020008970.tif 000008
【図６】
2020008970.tif 000009