JP7302181B2 - 情報処理システム及び情報処理方法 - Google Patents

Description

本発明は、情報処理システム及び情報処理方法に関する。

今日において、例えばＭＦＰ（Multi-Function Peripheral）等の画像形成装置を含む企業内ネットワークで、インターネット上のサービス（クラウドサービス）を利用可能とする情報処理システムが知られている。具体的には、この情報処理システムにより、例えば画像形成装置でスキャンして得られた文書をインターネット上のサーバ装置にアップロードすることが可能となっている。また、インターネット上のサーバ装置に格納されている文書を画像形成装置で指定して印刷することが可能となっている。

しかし、インターネット上のサービスは、企業内ネットワークとは別のネットワークで提供されるサービスである。このため、システム利用者が上述のようにインターネット上のサービスを利用する場合に、インターネット上のサービスが停止している場合もある。このため、サービス状況の通知は重要である。

特許文献１（特開２０１５－０６９６２５号公報）に、利用者にサービスの提供状況を的確に通知可能なインターネット上のサービスを提供する画像処理システムが開示されている。この画像処理システムの場合、ＭＦＰから、インターネット上のサービス提供サーバ装置に対するアクセス要求を受け付けた際に、サービス提供サーバ装置から取得した状態情報に基づいてＭＦＰを介して通知を行う。この通知の際、仲介サーバ装置は、ＭＦＰの表示パネルを介して通知を行う通知形態及びその他の通知形態を、ＭＦＰの機能に応じて切り替えて通知する。

しかし、特許文献１の画像処理システムは、サービス提供サーバ装置が不意にダウンした場合、サービス提供サーバ装置から仲介サーバ装置に対して正常に状態情報を送信することが困難となる。このため、利用者に対して、サービス提供サーバ装置がダウンした状態であることを、ＭＦＰを介して通知困難となる問題がある。

本発明は、上述の課題に鑑みてなされたものであり、インターネット等の外部ネットワーク上でサービスを提供しているサーバ装置の状態を、高確率で取得して通知可能とした情報処理システム及び情報処理方法の提供を目的とする。

上述した課題を解決し、目的を達成するために、本発明は、情報処理装置に要求されたネットワークサービスを、アプリケーション情報に基づき、サービス提供サーバ装置を介して提供する情報処理システムであって、ＵＲＬを前記アプリケーション情報と関連付けて記憶する記憶手段と、
前記情報処理装置から前記サービス提供サーバ装置に対するサービス要求を受け付けた際に、前記サービス要求に対応する前記アプリケーション情報に関連するＵＲＬに基づいて、前記サービス提供サーバ装置の状態を示す状態情報を取得して前記情報処理装置に送信する管理手段と、を備える。

本発明によれば、インターネット等の外部ネットワーク上でサービスを提供しているサーバ装置の状態を、高確率で取得して通知可能とすることができるという効果を奏する。

図１は、実施の形態の情報処理システムの動作概要を説明するための模式図である。 図２は、第１の実施の形態の情報処理システムのシステム構成図である。 図３は、アプリ情報のデータ定義の一例を示す図である。 図４は、アプリ情報のレイアウト情報の一例を示す図である。 図５は、アプリ情報の処理内容情報の処理の順番の記述例を示す図である。 図６は、ファイル処理部の共通Ｉ／Ｆ及び固有Ｉ／Ｆの記述例を示す図である。 図７は、データ処理部の共通Ｉ／Ｆ及び固有Ｉ／Ｆの記述例を示す図である。 図８は、第１の実施の形態の情報処理システムにおいて、外部サービス部のサービス提供部及びドキュメントサービス部のＯＣＲ部により、ＯＣＲサービスが提供されている様子を示す図である。 図９は、エラーメッセージの表示動作の流れを示すシーケンス図である。 図１０は、ワークフローアプリの設定画面の一例を示す図である。 図１１は、アプリ情報の一例を示す図である。 図１２は、サービス状態提供部から取得された状態情報の一例を示す図である。 図１３は、サービス状態提供部から取得されたエラーメッセージの表示例を示す図である。 図１４は、サービス状態提供部が、日本語及び英語のメッセージを、アプリ管理部２１に返信した例を示す図である。 図１５は、サービス提供部のステータス情報の記述例を示す図である。 図１６は、エラーメッセージが表示された後は、「戻る」のボタンを操作することで、アプリ一覧の表示画面に戻ることしか選択肢が無い不都合を説明するための図である。 図１７は、デバイスの表示部にメッセージと共に、「ＯＫ」のボタンが表示された例を示す図である。 図１８は、一時保存されたジョブの一覧を示す図である。 図１９は、一時保存されたジョブのパラメータの一例を示す図である。 図２０は、第５の実施の形態の情報処理システムにおいて、ワークフローアプリの設定画面に表示される、エラー時にアプリケーションの予約実行を許可するか否かを指定（選択）するためのチェックボックスを示す図である。 図２１は、第５の実施の形態の情報処理システムのアプリ情報の一例を示す図である。 図２２は、第５の実施の形態の情報処理システムのデバイスに表示される予約実行指定ボタンを示す図である。 図２３は、第６の実施の形態の情報処理システムにおいて、ワークフローアプリの設定画面に表示される、エラー時にアプリケーションの強制実行を許可するか否かを指定（選択）するためのチェックボックスを示す図である。 図２４は、第６の実施の形態の情報処理システムのアプリ情報の一例を示す図である。 図２５は、第６の実施の形態の情報処理システムのデバイスに表示される強制実行指定ボタンを示す図である。 図２６は、第７の実施の形態の情報処理システムのシステム構成図である。

（概要）
まず、図１は、実施の形態の情報処理システムの動作概要を説明するための模式図である。実施の形態の情報処理システムの場合、デバイス１、サービス提供プラットフォーム２及び外部サービス部３を有している。

デバイス１は、情報処理装置の一例であり、例えばＬＡＮ（Local Area Network）等の内部ネットワークに接続されると共に、インターネット等の外部ネットワークを介してサービス提供プラットフォーム２に接続されている。外部サービス部３は、所定のワークフローサービスを提供するサーバ装置であるサービス提供部４と、サービス提供サーバ装置の一例であるサービス提供部４のサービス状態を、デバイス１を介して利用者に提供するサーバ装置であるサービス状態提供部５を有している。

このような実施の形態の情報処理システムにおいて、サービス提供プラットフォーム２は、デバイス１からアプリ情報の取得要求を受信すると（ステップＳ１）、取得要求されたアプリ情報に予め登録されている、サービス提供部４の状態の問い合わせ先となるサービス状態提供部５のＵＲＬ（Uniform Resource Locator）に対して、サービス提供部４の状態の問い合わせを行う（ステップＳ２）。

サービス状態提供部５は、この状態の問い合わせに対応して、サービス提供部４の状態を示す応答を行う（ステップＳ３）。図１の応答例は、現在、サービス提供部４が停止（サーバダウン＝エラー）しているため、例えば「現在サービス停止中です。復旧予定は明日の０９：００です。」等のエラーメッセージの応答例である。このような応答例である状態情報レスポンスは、取得要求されたアプリ情報と共にデバイス１に送信される。デバイス１は、表示部１ａに、この状態情報レスポンスを表示する。

このような実施の形態の情報処理システムは、外部ネットワーク上の外部サービス部３に、予め決められたＡＰＩ（Application Program Interface）となるサービス状態提供部５を設ける。これにより、ワークフローサービス等を行うサービス提供部４から、必要に応じて、予め決められた取得形態でサービス提供部４の状態情報を取得してデバイス１に通知できる。

外部サービス部３に、予め決められたＡＰＩとなるサービス状態提供部５を設けることで、サービス提供プラットフォーム２からの呼び出し形態を共通の呼び出し形態とすることができ、様々な用途に対応可能とすることができる（汎用性の向上を図ることができる）。また、サービス提供プラットフォーム２は、ワークフローの実行前に、例えば印刷用又はスキャン用等の用途を認識することができる。このため、ワークフローの実行前に、サービス提供部４の状態情報を取得することで、ワークフローを実行可能な状態であるか否かを、ワークフローの実行前に、ユーザに通知することができる。

［第１の実施の形態］
以下、添付図面を参照して、第１の実施の形態の情報処理システムを詳細に説明する。

（システム構成）
図２は、第１の実施の形態の情報処理システムのシステム構成図である。この図２に示すように、第１の実施の形態の情報処理システムは、デバイス１、サービス提供プラットフォーム２及び外部サービス部３を有している。

デバイス１は、例えば情報処理システムを利用するクライアント端末装置である。デバイス１は、Ｗｅｂブラウザ（ブラウザ）１０を有している。デバイス１としては、例えば複合機（ＭＦＰ：Multifunction Peripheral）、コピー装置、印刷装置又はスキャナ装置等の画像形成装置を用いることができる。

外部サービス部３は、クラウドストレージサービス等の所定のサービスを提供するサービス提供部４と、共通のインタフェース定義とされたサービス状態提供部５を有する。サービス状態提供部５は、サービス提供部４の稼働状況の影響されることなく、独立に動作可能となっている。

サービス提供プラットフォーム２は、入出力サービス部１１、アプリ情報（アプリケーションプログラム：アプリケーション情報の一例）１２、外部サービス連携部１３及びドキュメントサービス部１４を有している。

入出力サービス部１１は、アプリ管理部２１、Ｉ／Ｏロジック処理部２２、データＡＰＩブロック２３及びサブフロー生成部２４を有している。アプリ管理部２１は、管理サーバ装置の一例であり、アプリ情報１２の画面定義及び処理内容等を、各アプリ情報の識別番号（ＩＤ）に関連付けて管理する。Ｉ／Ｏロジック処理部２２は、アプリ情報１２の「処理内容」に基づいて、ドキュメントサービス部１４又は外部サービス連携部１３の処理を実行する。データＡＰＩ部２３は、外部サービス連携部１３のデータ処理部４２を介して、外部サービス部３のフォルダ一覧又はファイル一覧等の情報を取得する。

アプリ情報１２は、画面定義３１、処理内容情報３４及び状態ＡＰＩ情報３５を有している。画面定義３１は、ユーザが利用するデバイス１の表示部に表示するデータのデータ定義３２及びそのレイアウト情報３３を有している。処理内容としては、例えばドキュメントサービス又は外部サービス連携部１３の処理形態を示す情報が記載されている。

外部サービス連携部１３は、ファイル処理部４１及びデータ処理部４２を有している。ファイル処理部４１は、共通インタフェース（共通Ｉ／Ｆ）４５及び固有Ｉ／Ｆ４６を有している。また、データ処理部４２も、共通インタフェース（共通Ｉ／Ｆ）４７及び固有Ｉ／Ｆ４８を有している。ファイル処理部４１は、外部サービス部３に対するファイルの入出力に関連する処理を行う。データ処理部４２は、データの取得及び書き込み等の処理を行う。このような外部サービス連携部１３は、外部サービス毎に用意される。このため、外部サービス連携部１３を増やしていくことで、連携先を増やしていくことができる。

ドキュメントサービス部１４は、ドキュメントを処理するサービス群であって、ＯＣＲ（Optical Character Recognition）処理を行うＯＣＲ部５１、及び例えばファイルのフォーマット変換及び画像のサイズ変換等を行うファイル変換部５２を有している。

（アプリ情報の構成）
アプリ情報１２は、上述のようにデータ定義３２及びレイアウト情報３３を含む画面定義３２を有している。データ定義３２には、「データＩＤ」、「扱うデータ名称（ｋｅｙ）：処理に対するパラメータになる」及び「表現する形式」が含まれており、これらを組とする配列で表現される。種類は、画面を構成する要素であり、ＨＴＭＬのフォーム要素と同じであり、例えば「ｉｎｐｕｔ＿ｔｅｘｔ」、「ｔｅｘｔａｒｅａ」、「ｓｅｌｅｃｔ」、「ｒａｄｉｏ」等となる。また、データ元としては、データを保持するＵＲＬを指定する。固定であれば、直接データを記述してもよい。

図３に、データ定義３２の一例を示す。この図３の例は、
ｄａｔａ＿ｉｄ→１、
ｄａｔａ＿ｋｅｙ→ｓｔｏｒａｇｅ＿ｆｉｌｅｎａｍｅ
ｆｏｒｍａｔ→ｉｎｐｕｔ＿ｔｅｘｔ
ｄａｔａ＿ｓｏｕｒｃｅ→ｎｕｌｌ（空白）
の例である。

また、図３に示すデータ定義３２の他の例は、
ｄａｔａ＿ｉｄ→２，
ｄａｔａ＿ｋｅｙ→ｓｔｏｒａｇｅ＿ｔａｒｇｅｔｆｏｌｄｅｒ
ｆｏｒｍａｔ→ｓｅｌｅｃｔ
ｄａｔａ＿ｓｏｕｒｃｅ→http://sample.○○○.xxx/service-a/folders
の例である。

次に、アプリ情報１２の画面定義３１のレイアウト情報３３は、データ定義３２のデータＩＤとそれらを表示する位置情報を有する。レイアウト情報３３は、「データＩＤ」、「表示名称」及び「位置情報」を組として表現する。位置情報としては、座標を用いてもよいし、上から順番を指定する形式でもよい。また、デバイス１側が、Ｗｅｂブラウザ１０ではなく、クライアントアプリケーションである場合又は複雑な画面を構成する場合は、このレイアウト情報は存在せず、デバイス１側又はＵＩ生成過程でデータ定義３２の解釈を行う場合もある。

図４に、レイアウト情報３３の一例を示す。この図４の例は、
ｄａｔａ＿ｉｄ→１、
ｄｉｓｐｌａｙ＿ｎａｍｅ→ファイル名
ｌａｙｏｕｔ
ｏｒｄｅｒ→１
の例である。

また、図４に示すレイアウト情報３３の他の例は、
ｄａｔａ＿ｉｄ→２，
ｄｉｓｐｌａｙ＿ｎａｍｅ→配信先
ｌａｙｏｕｔ
ｏｒｄｅｒ→２
の例である。

次に、アプリ情報１２の処理内容情報３４としては、各種の外部サービス連携部１３又はドキュメントサービスの利用順番が記述される。各種処理は、「コンポーネント名称」、「処理」及び「オプションパラメータ」で構成される。例えば、「ストレージサービスＡのフォルダｓａｍｐｌｅｆｏｌｄｅｒへファイル名ｔｅｓｔ．ｐｄｆでファイルを送信する」との処理内容情報３４は、「storage:send_to_folder?type=service-a&targetfolder=samplefolder&filename=test.pdf」のように記述される。

処理の順番としては、以下のように記載される。
開始：ファイルのインプット
１：ＯＣＲ
２：サービスＡ：配信

具体的には、図５に例示するように、
Ｆｒｏｍ→ｆｉｌｅ：ｉｎｐｕｔ
ｔｏ→ｐｒｏｃｅｓｓ：ｏｃｒ
ｔｏ→ｓｔｏｒａｇｅ：ｓｅｎｄ＿ｔｏ＿ｆｏｌｄｅｒ？ｔｙｐｅ＝ｓｅｒｖｉｃｅ－ａ＆ｔａｒｇｅｔ＝ｓａｍｐｌｅｆｏｌｄｅｒ
との順で記載される。

（外部サービス連携部の構成）
次に、外部サービス連携部１３の構成を説明する。外部サービス連携部１３は、外部サービス部３に対して、例えばファイルの送信及びファイルの取得等のファイル関連の処理を行うファイル処理部４１を有している。また、外部サービス連携部１３は、外部サービス部３に対して、フォルダ一覧を取得する等の、ファイル以外のテキストで表現できるデータ処理を行うデータ処理部４２を有している。

ファイル処理部４１は、共通Ｉ／Ｆ４５及び固有Ｉ／Ｆ４６を有しており、データ処理部４２も、共通Ｉ／Ｆ４７及び固有Ｉ／Ｆ４８を有している。このようにＩ／Ｆを分けることで、例えば様々な連携サービスへファイルを配信可能なアプリケーションを実現する場合に、ファイル処理部４１及びデータ処理部４２の共通Ｉ／Ｆ４５，４７を利用することで、全てにおいて同じ作法で実現可能となる。また、特定の連携先サービスの機能を広く活用した、連携先サービスに特化したアプリケーションを作成する場合、固有Ｉ／Ｆ４６，４８までを活用することで実現することができる。

すなわち、ファイル処理４１の共通Ｉ／Ｆ４５及びデータ処理部４２の共通Ｉ／Ｆ４７は、ファイルを扱うサービスにおいて、共通に利用できる。ファイル処理４１の共通Ｉ／Ｆ４５は、例えば「フォルダにファイルを送る」又は「ファイルを取得する」等の処理に利用できる。また、データ処理部４２の共通Ｉ／Ｆ４７は、例えば「ファイル一覧の取得」又は「フォルダ一覧取得」等の処理に利用できる。

ファイル処理４１の固有Ｉ／Ｆ４６及びデータ処理部４２の固有Ｉ／Ｆ４８は、連携先のサービスの機能であるが、ファイルを扱うサービスにとって共通ではない処理に利用される。すなわち、ファイル処理部４１の固有Ｉ／Ｆ４６の場合、例えば「保存されているドキュメントにファイルを付加する」等の処理に利用される。また、データ処理部４２の固有Ｉ／Ｆ４８の場合、例えば「顧客一覧情報の取得」又は「画像ファイルの一覧情報の取得」等に利用される。

ファイル処理部４１の共通Ｉ／Ｆ４５の場合、図６に示すように、「／ｓｅｒｖｉｃｅ－ａ／ｐｒｏｃｅｓｓ／ｆｉｌｅ」等のように記述する。固有Ｉ／Ｆ４６の場合、「／ｓｅｒｖｉｃｅ－ａ／ｐｒｏｃｅｓｓ／ｅｘｔｅｎｓｉｏｎ／ａｔｔａｃｈ」の記述を、「／ｅｘｔｅｎｓｉｏｎ」以下に追加して記述する。

データ処理部４２の共通Ｉ／Ｆ４７の場合、図７に示すように、「／ｓｅｒｖｉｃｅ－ａ／ｄａｔａ／ｆｉｌｅｓ」又は「／ｓｅｒｖｉｃｅ－ａ／ｄａｔａ／ｆｏｌｄｅｒｓ」等のように記述される。また、データ処理部４２の固有Ｉ／Ｆ４８の場合、「／ｓｅｒｖｉｃｅ－ａ／ｄａｔａ／ｅｘｔｅｎｓｉｏｎ／ｉｍａｇｅｓ」の記述を「／ｅｘｔｅｎｓｉｏｎ」以下に追加して記述する。

（システム動作）
次に、第１の実施の形態の情報処理システムのシステム動作を説明する。図８は、第１の実施の形態の情報処理システムにおいて、外部サービス部３のサービス提供部４及びドキュメントサービス部１４のＯＣＲ部５１により、ＯＣＲサービスが提供されている様子を示す図である。この図８において、入出力サービス１１のアプリ管理部２１は、デバイス１から取得要求されたアプリ情報１２を取得し、アプリ情報１２の状態ＡＰＩ情報３５で示されるＵＲＬに基づいて、外部サービス部３のサービス状態提供部５にアクセスする。そして、アプリ管理部２１は、サービス状態提供部５に対して、サービス提供部４の現在の状態を示す状態情報の取得要求を行う。

サービス状態提供部５は、この取得要求に応じて、サービス提供部４の現在の状態を示す状態情報を形成し、入出力サービス１１のアプリ管理部２１に送信する。アプリ管理部２１は、サービス提供部４において、サービスの提供が可能であるか否かを、サービス状態提供部５から受信した状態情報に基づいて判別する。サービスの提供が可能であると判別した場合、アプリ管理部２１は、ドキュメントサービス部１４にサービスの提供要求を行う。これにより、ドキュメントサービス部１４及び外部サービス部３のサービス提供部４により、デバイスを介して指定されたサービスが提供される。すなわち、この例の場合は、例えばデバイス１で読み取られた画像から、文字のテキストデータを生成するＯＣＲサービスが、ＯＣＲ部５１及びサービス提供部４により提供される。

これに対して、状態情報に基づいて、例えばサービス提供部４が停止状態であり、サービスの提供が困難であると判別した場合、アプリ管理部２１は、例えば「現在サービス停止中です。復旧予定は明日の０９：００です。」等のエラーメッセージ（状態情報レスポンス）を、取得要求されたアプリ情報と共にデバイス１に送信する。デバイス１は、表示部１ａに、この状態情報レスポンスを表示する。この表示は、通知の一例である。音声通知等でもよい。

このような実施の形態の情報処理システムは、外部ネットワーク上の外部サービス部３に、予め決められたＡＰＩ（Application Program Interface）となるサービス状態提供部５を設ける。これにより、ワークフローサービス等を行うサービス提供部４から、必要に応じて、予め決められた取得形態でサービス提供部４の状態情報を取得してデバイス１に通知できる。

（エラーメッセージの表示動作）
図９は、このようなエラーメッセージの表示動作の流れを示すシーケンス図である。この図９において、まず、デバイス１は、入出力サービス１１のアプリ管理部２１に、アプリ一覧情報の取得要求を行い（ステップＳ１１）、アプリ一覧情報を取得する（ステップＳ１２）。デバイス１のＷｅｂブラウザ１０は、アプリ管理部２１から取得したアプリ一覧情報を表示部１ａに表示する。ユーザは、表示部１ａに表示されたアプリ一覧の中から所望のアプリケーションを選択操作する（ステップＳ１３）。

アプリ管理部２１は、ユーザにより選択されたアプリケーションのアプリ情報１２の画面定義３１及び状態ＡＰＩ情報３５を取得する。また、アプリ管理部２１は、外部サービス４に何らかの通知があれば、通知メッセージも取得する。

次に、アプリ管理部２１は、アプリ情報１２から取得した状態ＡＰＩ情報３５として、外部サービス部３のサービス状態提供部５のＵＲＬ（外部サービス状態情報取得用のＵＲＬ）が含まれているか否かを判別する。

ここで、アプリ情報１２に対するサービス状態提供部５のＵＲＬの入力の仕方を説明する。図１０は、ワークフローアプリの設定画面の一例を示している。このワークフローアプリの設定画面は、例えば「スキャンｔｏフロー」等のワークフローのタイプの入力欄と、英語又は日本語等の対応言語の入力欄、「ｎａｎａｎａ０５」等の表示名の入力欄を有している。また、ワークフローアプリの設定画面は、ユーザ認証の有無の選択欄、及び、ステータス取得先となるＵＲＬの入力欄を有している。

第１の実施の形態の情報処理システムの管理者等は、このステータス取得先となるＵＲＬの入力欄に対して、サービス提供部４の現在の状態を監視しているサービス状態提供部５のＵＲＬを入力する。これにより、アプリ情報１２の状態ＡＰＩ情報３５として、サービス状態提供部５のＵＲＬが登録される。図１１は、アプリ情報１２の一例を示している。この図１１に示す「ｅｘｔＳｔａｔｕｓＵｒｌ：ｈｔｔｐｓ：／／ｘｘｘｘｘ／ｓｅｒｖｉｃｅ／ｓｔａｔｕｓ」の記述が、管理者等により入力されたサービス状態提供部５のＵＲＬの一例である。

アプリ管理部２１は、アプリ情報１２に、このようなサービス状態提供部５のＵＲＬが含まれている場合、このＵＲＬに基づいてサービス状態提供部５にアクセスし（ステップＳ１４）、サービス提供部４の、現在の状態を示す状態情報を取得する（ステップＳ１５）。図１２は、サービス状態提供部５から取得された状態情報の一例を示す図である。この図１２の例は、例えば「現在サービス停止中です。復旧予定は明日の０９：００です。」とのエラーメッセージ（状態情報レスポンス）が取得された例である。

アプリ管理部２１は、このようなエラーメッセージを取得することで、サービス提供部４が、現在、停止状態であり、サービスの提供が困難であると判別することができる。この場合、アプリ管理部２１は、例えば「現在サービス停止中です。復旧予定は明日の０９：００です。」等のエラーメッセージ（状態情報レスポンス）を、取得要求されたアプリ情報と共にデバイス１に送信する。デバイス１は、図１３に例示するように、表示部１ａに対して、サービス状態提供部５から取得されたエラーメッセージを表示する。

（第１の実施の形態の効果）
以上の説明から明らかなように、第１の実施の形態の情報処理システムは、外部ネットワーク上の外部サービス部３に、予め決められたＡＰＩとなり、サービス提供部４の状態情報を取得するサービス状態提供部５を設ける。これにより、ワークフローサービス等を行うサービス提供部４から、必要に応じて、予め決められた取得形態でサービス提供部４の現在の状態を示す状態情報を取得してデバイス１に通知できる。

また、外部サービス部３に、予め決められたＡＰＩとなるサービス状態提供部５を設けることで、サービス提供プラットフォーム２からの呼び出し形態を共通の呼び出し形態とすることができ、様々な用途に対応可能とすることができる（汎用性の向上を図ることができる）。

また、サービス提供プラットフォーム２は、ワークフローの実行前に、例えば印刷用又はスキャン用等の用途を認識することができる。このため、ワークフローの実行前に、サービス提供部４の状態情報を取得することで、ワークフローを実行可能な状態であるか否かを、ワークフローの実行前に、ユーザに通知することができる。

［第２の実施の形態］
次に、第２の実施の形態の情報処理システムの説明をする。この第２の実施の形態の情報処理システムは、外部サービス部３のサービス状態提供部５が、複数の言語のメッセージをアプリ管理部２１に返信する。図１４は、サービス状態提供部５が、一例として日本語及び英語のメッセージを、アプリ管理部２１に返信した例である。この図１４の例は、例えば「現在サービス停止中です。復旧予定は明日０９：００です。」との日本語のメッセージと共に、「Ｔｈｅ ｓｅｒｖｉｃｅ ｉｓ ｃｕｒｒｅｎｔｌｙ ｓｔｏｐｐｅｄ． Ｔｈｅ ｒｅｃｏｖｅｒｙ ｐｌａｎ ｉｓ ｔｏｍｏｒｒｏｗ ０９：００．」との英語のメッセージがアプリ管理部２１に返信された例である。

アプリ管理部２１は、サービス状態提供部５から取得した複数の言語の通知のうち、デバイス１から表示言語として指定されている言語のメッセージをデバイス１に返信する。一例ではあるが、アプリ管理部２１は、デバイス１のＷｅｂブラウザ１０から送信されるリクエストに付与されているＨＴＴＰ（Hyper Text Markup Language）の「リクエストＡｃｃｅｐｔ－Ｌａｎｇｕａｇｅヘッダ」に基づいて、デバイス１から表示言語として指定されている言語を判別する。なお、ヘッダは、独自のヘッダ又はパラメータでもよい。

このような第２の実施の形態の情報処理システムは、デバイス１から指定された言語でメッセージを表示できる。このため、情報処理システムを、世界の言語に合わせて利用可能とすることができる他、上述の第１の実施の形態と同様の効果を得ることができる。

［第３の実施の形態］
次に、第３の実施の形態の情報処理システムの説明をする。この第３の実施の形態の情報処理システムは、サービス提供部４の状態情報に、上述のメッセージと共に、サービス提供部４の状態を示すステータス情報を付加した例である。

図１５は、この第３の実施の形態の情報処理システムにおける状態情報の一例である。日本語及び英語のメッセージの上に、「ｓｔａｔｅ：ｅｒｒｏｒ」とのステータス情報が付加される。この図１５の例は、サービス提供部４が、停止中（ｅｒｒｏｒ）であることを示している。

ここで、図１６に示すように、デバイス１の表示部１ａに、「現在サービス停止中です。復旧予定は明日０９：００です。」とのメッセージを表示すると共に、表示画面を一操作前の表示画面に戻す「戻る」のボタンを表示することを考える。この場合、エラーメッセージが表示された後は、「戻る」のボタンを操作することで、アプリ一覧の表示画面に戻ることしかできず、アプリケーションの実行が指定困難となる。

このため、第３の実施の形態の情報処理システムでは、アプリ管理部２１が、サービス情報提供部５から取得したサービス提供部の状態情報に対応するメッセージと共に、「ＯＫ」のボタンを、デバイス１の表示部１ａに表示制御する。図１７は、例えば「２０１８／１２／０１ １７：００～１８：００ＪＳＴの間は、メンテナンスのためサービスをご利用いただけません。」等のメッセージと共に、「ＯＫ」のボタンが、デバイス１の表示部１ａに表示された例である。

アプリ管理部２１は、メッセージで示されるサービス提供部４の状態に応じて、アプリケーションの実行を制御する。すなわち、アプリ管理部２１は、「ＯＫ」のボタンが、ユーザにより操作されると、アプリケーションを使用可能とする。これにより、エラー以外の幅広いステータスを通知可能とすることができる。また、ユーザがサービスの停止中にジョブを実行してエラーになる不都合を未然に防止できる。この他、上述の各実施の形態と同様の効果を得ることができる。

［第４の実施の形態］
次に、第４の実施の形態の情報処理システムの説明をする。この第４の実施の形態の情報処理システムは、アプリ管理部２１が、外部サービス部３がエラーの場合に、実行するジョブを一時保存する。図１８は、一時保存されたジョブの一覧を示す図である。この図１８に例示するように、各ジョブとして、ジョブＩＤ，ステータスＵＲＬ、ファイルＵＲＬ、ジョブのパラメータ、及び、保存日時の各情報が一時保存される。ステータスＵＲＬは、監視対象のサービスの状態取得ＡＰＩのＵＲＬである。ファイルＵＲＬは、ジョブで送信されたファイルをサービス内部の一時保存領域に保存したパスである。パラメータは、ジョブ実行時のパラメータである。「ｅｘｐｉｒｅｄａｔｅ」は、一時保存の保管期限である。

図１９に、一時保存されたジョブのパラメータの一例を示す。この図１９は、「オペレーション１」として、サービスキーが「××××」で、テナントＩＤが「ｔｅｎａｎｔＡ」で、ユーザＩＤが「Ｕｓｅｒ１」のパラメータの例である。また、この図１９は、「オペレーション２」として、ファイル名が「ｆｉｌｅ１．ｐｄｆ」で、フォルダＩＤが「ｒｏｏｔ」のパラメータの例である。

このようなジョブの一時保存を行うと、アプリ管理部２１は、一時保存したジョブに対応する外部サービス部３の状態を、サービス提供部５から定期的に取得して監視する。ユーザは、外部サービス部３がエラーの場合に、エラー解消後にジョブを実行するか、又は、ジョブをキャンセルするかを、デバイス１を介して事前に選択操作しており、アプリ管理部２１は、この選択情報を記憶している。アプリ管理部２１は、外部サービス部３の状態が正常に戻った際に、ユーザにより、エラー解消後にジョブを実行することが選択されている場合は、一時保存したジョブを実行制御する。これにより、外部サービス部３の状態がエラーから復旧した際に、一時的に停止していたジョブを自動的に実行可能とすることができる。

［第５の実施の形態］
次に、第５の実施の形態の情報処理システムの説明をする。この第５の実施の形態の情報処理システムは、アプリ情報１２が、予約実行の可否を示す予約実行可否情報を有している。外部サービス部３の状態がエラーの際に、アプリ管理部２１は、アプリ情報１２の予約実行可否情報により予約実行が許可されている場合に、アプリケーションを実行する。

具体的には、例えば実行する時刻等に応じて結果が変わるワークフローも存在し、ワークフロー開発者が予約実行をさせたくない場合がある。このような場合に、ワークフローのアプリケーション毎に予約実行可否を設定可能とすることで、より柔軟なワークフローアプリを作成できる。

すなわち、第５の実施の形態の情報処理システムの場合、図２０に示すように、図１０を用いて説明したワークフローアプリの設定画面に、例えば「エラー時に予約実行を許可する」との、エラー時に予約実行を許可するか否かを指定（選択）するためのチェックボックスが設けられている。一例ではあるが、このチェックボックスは、デフォルトで空白となっている。ワークフロー開発者等は、予約実行を許可する場合は、このチェックボックスにチェックを入れる入力操作を行い、予約実行を許可しない場合は、このチェックボックスを空白のままとする（チェックの入力操作は行わない）。

図２１は、第５の実施の形態の情報処理システムのアプリ情報１２の一例を示している。この第５の実施の形態の情報処理システムの場合、アプリ情報１２に、
「ｅｘｔＳｔａｔｕｓＵｒｌ：ｈｔｔｐｓ：／／ｘｘｘｘｘ／ｓｅｒｖｉｃｅ／ｓｔａｔｕｓ，
ｅｎａｂｌｅＳｃｈｅｄｕｌｅＥｘｅｃ：ｔｒｕｅ，」
との予約実行可否情報が付加される。この図２１の例は、予約実行が許可（ｔｒｕｅ）されている例である。なお、予約実行が許可されない場合は、「ｅｎａｂｌｅＳｃｈｅｄｕｌｅＥｘｅｃ：ｆａｌｓｅ」となる。

外部サービス部３の状態がエラーの際、アプリ管理部２１は、このようなアプリ情報１２の予約実行可否情報に基づいて、アプリケーションの予約実行が許可されているか否かを判別する。予約実行が許可されていると判別した場合に、図２２に示すように、上述のエラーメッセージと共に、「予約実行」を指定する予約実行指定ボタン７１をデバイス１の表示部１ａに表示制御する。そして、予約実行指定ボタン７１の操作を検出した際に、対応するアプリケーションの実行制御を行う。

ワークフローのアプリケーション毎に、予約実行の可否を設定可能であるため、より柔軟なワークフローのアプリケーションを作成することができる他、上述の各実施の形態と同様の効果を得ることができる。

［第６の実施の形態］
次に、第６の実施の形態の情報処理システムの説明をする。この第６の実施の形態の情報処理システムは、アプリ情報１２が、アプリケーションの強制実行の可否を示す強制実行可否情報を有している。外部サービス部３の状態がエラーの際に、アプリ管理部２１は、アプリ情報１２の強制実行可否情報により強制実行が許可されている場合に、アプリケーションを強制的に実行する。

すなわち、第６の実施の形態の情報処理システムの場合、図２３に示すように、図１０を用いて説明したワークフローアプリの設定画面に、例えば「エラー時に強制実行を許可する」との、エラー時に強制実行を許可するか否かを指定（選択）するためのチェックボックスが設けられている。一例ではあるが、このチェックボックスは、デフォルトで空白となっている。ワークフロー開発者等は、強制実行を許可する場合は、このチェックボックスにチェックを入れる入力操作を行い、強制実行を許可しない場合は、このチェックボックスを空白のままとする（チェックの入力操作は行わない）。

図２４は、第６の実施の形態の情報処理システムのアプリ情報１２の一例を示している。この第６の実施の形態の情報処理システムの場合、アプリ情報１２に、
「ｅｘｔＳｔａｔｕｓＵｒｌ：ｈｔｔｐｓ：／／ｘｘｘｘｘ／ｓｅｒｖｉｃｅ／ｓｔａｔｕｓ，
ｅｎａｂｌｅＦｏｒｃｅＥｘｅｃ：ｔｒｕｅ，」
との強制実行可否情報が付加される。この図２４の例は、強制実行が許可（ｔｒｕｅ）されている例である。なお、強制実行が許可されない場合は、「ｅｎａｂｌｅＳｃｈｅｄｕｌｅＥｘｅｃ：ｆａｌｓｅ」となる。

外部サービス部３の状態がエラーの際、アプリ管理部２１は、このようなアプリ情報１２の強制実行可否情報に基づいて、アプリケーションの強制実行が許可されているか否かを判別する。強制実行が許可されていると判別した場合に、図２５に示すように、上述のエラーメッセージと共に、「強制実行」を指定する強制実行指定ボタン７５をデバイス１の表示部１ａに表示制御する。そして、強制実行指定ボタン７５の操作を検出した際に、対応するアプリケーションの実行制御を行う。

ワークフローのアプリケーション毎に、強制実行の可否を設定可能であるため、より柔軟なワークフローのアプリケーションを作成することができる他、上述の各実施の形態と同様の効果を得ることができる。

［第７の実施の形態］
次に、第７の実施の形態の情報処理システムの説明をする。この第７の実施の形態の情報処理システムは、外部サービス部３に設けられていたサービス状態提供部５を、図２６に示すように外部サービス連携部１３に設けた例である。外部サービス連携部１３に設けられたサービス状態提供部５は、ファイル処理部４１及びデータ処理部４２と同様に、共通Ｉ／Ｆ６１及び固有Ｉ／Ｆ６２を有している。

外部サービス連携部１３に設けられたサービス状態提供部５は、上述と同様に、サービス提供部４の現在の状態を検出してアプリ管理部２１に通知する。これにより、ワークフローを実行可能な状態であるか否かを、ワークフローの実行前に、ユーザに通知することができる等、上述と同様の効果を得ることができる。

最後に、上述の各実施の形態は、一例として提示したものであり、本発明の範囲を限定することは意図していない。この新規な各実施の形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことも可能である。また、各実施の形態及び各実施の形態の変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ デバイス
１ａ デバイスの表示部
２ サービス提供プラットフォーム
３ 外部サービス部
４ サービス提供部
５ サービス状態提供部
１０ Ｗｅｂブラウザ
１１ 入出力サービス部
１２ アプリ情報
１３ 外部サービス連携部
１４ ドキュメントサービス部
２１ アプリ管理部
２２ Ｉ／Ｏロジック処理部
２３ データＡＰＩ部
３１ 画面定義
３２ データ定義
３３ レイアウト情報
３４ 処理内容
３５ 状態ＡＰＩ情報
４１ ファイル処理部
４２ データ処理部
４５ 共通Ｉ／Ｆ
４６ 固有Ｉ／Ｆ
４７ 共通Ｉ／Ｆ
４８ 固有Ｉ／Ｆ
５１ ＯＣＲ部
５２ ファイル変換部
７１ 予約実行指定ボタン
７５ 強制実行指定ボタン

特開２０１５－０６９６２５号公報

Claims (8)

1. 情報処理装置に要求されたネットワークサービスを、アプリケーション情報に基づき、サービス提供サーバ装置を介して提供する情報処理システムであって、
   ＵＲＬを前記アプリケーション情報と関連付けて記憶する記憶手段と、
   前記情報処理装置から前記サービス提供サーバ装置に対するサービス要求を受け付けた際に、前記サービス要求に対応する前記アプリケーション情報に関連するＵＲＬに基づいて、前記サービス提供サーバ装置の状態を示す状態情報を取得して前記情報処理装置に送信する管理手段と、を備えること
   を特徴とする情報処理システム。
2. 前記情報処理システムは、前記情報処理装置を含み、
   前記情報処理装置は、前記管理手段から受信した前記状態情報に基づく通知動作を行うこと
   を特徴とする請求項１に記載の情報処理システム。
3. 前記状態情報には、前記サービス提供サーバ装置の状態を示すステータス情報が付加され、前記情報処理システムは、前記ステータス情報に基づいて前記ネットワークサービスの実行を制御する制御手段と、を更に備えること
   を特徴とする請求項１又は請求項２に記載の情報処理システム。
4. 前記管理手段は、実行するジョブを一時的に保存し、前記状態情報で示される前記サービス提供サーバ装置の状態が、エラーから正常に戻った際に、一時的に保存していたジョブを実行すること
   を特徴とする請求項１から請求項３のうち、いずれか一項に記載の情報処理システム。
5. 前記管理手段は、前記情報処理装置を介して指定された、前記サービス提供サーバ装置の状態がエラーから正常に戻った際に、一時的に保存していたジョブを実行するか否かを示す選択情報を記憶しており、エラー解消後にジョブを実行することが選択されている場合に、一時的に保存した前記ジョブを実行制御すること
   を特徴とする請求項４に記載の情報処理システム。
6. 前記アプリケーション情報には、前記サービス提供サーバ装置の状態がエラーの際に、アプリケーションの予約実行を許可するか否かを示す予約実行可否情報が含まれており、
   前記管理手段は、前記サービス提供サーバ装置の状態がエラーの際に、前記予約実行可否情報により予約実行が許可されているアプリケーションを実行すること
   を特徴とする請求項１から請求項５のうち、いずれか一項に記載の情報処理システム。
7. 前記アプリケーション情報には、前記サービス提供サーバ装置の状態がエラーの際に、アプリケーションの強制実行を許可するか否かを示す強制実行可否情報が含まれており、
   前記管理手段は、前記サービス提供サーバ装置の状態がエラーの際に、前記強制実行可否情報により強制実行が許可されているアプリケーションを実行すること
   を特徴とする請求項１から請求項６のうち、いずれか一項に記載の情報処理システム。
8. 情報処理装置に要求されたネットワークサービスを、アプリケーション情報に基づき、サービス提供サーバ装置を介して提供する情報処理システムの情報処理方法であって、
   ＵＲＬを前記アプリケーション情報と関連付けて記憶する記憶ステップと、
   前記情報処理装置から前記サービス提供サーバ装置に対するサービス要求を受け付けた際に、前記サービス要求に対応する前記アプリケーション情報に関連するＵＲＬに基づいて、前記サービス提供サーバ装置の状態を示す状態情報を取得して前記情報処理装置に送信する送信ステップと、
   を有することを特徴とする情報処理方法。

Images