JP2021197588A

JP2021197588A - Information processing device and program

Info

Publication number: JP2021197588A
Application number: JP2020101134A
Authority: JP
Inventors: 博行江口; Hiroyuki Eguchi
Original assignee: Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2020-06-10
Filing date: 2020-06-10
Publication date: 2021-12-27

Abstract

To suppress a load on a system compared to a case where a health check is executed even during use by a user of a cloud service.SOLUTION: An information processing device that provides a service to relay the use of a cloud service by a terminal operated by a user has a processor. The processor monitors the processing status of an accepted request and does not issue a health check request while there is a request that is still being processed.SELECTED DRAWING: Figure 7

Description

本発明は、情報処理装置及びプログラムに関する。 The present invention relates to an information processing apparatus and a program.

今日、インターネット経由で様々なウェブサービスの利用が可能である。例えばユーザのデータに予め定めた処理を加えるサービスやユーザのデータを記憶するサービスがある。以下では、インターネット上で提供されるサービスをクラウド型のサービス（以下「クラウドサービス」という）という。
障害によりクラウドサービスが停止すると、クラウドサービスを利用するユーザの活動に影響が及ぶ。そこで、クラウドサービスにおける障害の発生の有無を検知する仕組みがある。この仕組は、ヘルスチェックと呼ばれる。ヘルスチェックの頻度が高いほど、障害を事前に検知する精度が高くなる一方、通信に使用するシステム（以下「通信システム」という）に加わる負荷も高くなる。そこで、通信システムの負荷の変化に応じてヘルスチェックを実行する間隔を能動的に制御する方法や負荷が比較的少ない時間帯にヘルスチェックの実行を計画する方法がある。 Today, various web services are available via the Internet. For example, there are services that add predetermined processing to user data and services that store user data. In the following, services provided on the Internet will be referred to as cloud-type services (hereinafter referred to as "cloud services").
If the cloud service is stopped due to a failure, the activities of users who use the cloud service will be affected. Therefore, there is a mechanism to detect the presence or absence of a failure in the cloud service. This mechanism is called a health check. The higher the frequency of health checks, the higher the accuracy of detecting failures in advance, while the higher the load on the system used for communication (hereinafter referred to as "communication system"). Therefore, there are a method of actively controlling the interval at which the health check is executed according to a change in the load of the communication system, and a method of planning the execution of the health check during a time when the load is relatively light.

特開２００９−１１７９１５号公報Japanese Unexamined Patent Publication No. 2009-117915

しかし、ユーザによりクラウドサービスが利用できていれば、ヘルスチェックを実行しなくてもクラウドサービスが動作していることは分かる。また、通信システムの負荷が比較的少ない時間帯にヘルスチェックの実行を計画する場合でも、現実にヘルスチェックを実行する場面では通信システムの負荷が高いことも起こり得る。 However, if the cloud service is available to the user, it can be seen that the cloud service is operating without performing a health check. Further, even when the health check is planned to be executed during the time when the load of the communication system is relatively light, the load of the communication system may be high when the health check is actually executed.

本発明は、クラウドサービスのユーザによる使用中もヘルチェックが実行される場合に比して、システムに対する負荷を抑制することを目的とする。 An object of the present invention is to reduce the load on the system as compared with the case where the hell check is executed even while the cloud service is being used by the user.

請求項１に記載の発明は、ユーザが操作する端末によるクラウドサービスの利用を中継するサービスを提供する情報処理装置はプロセッサを有し、前記プロセッサは、受け付けたリクエストに関する処理の状態を監視し、処理が継続している前記リクエストがある間、ヘルスチェックのリクエストを発行しない情報処理装置である。
請求項２に記載の発明は、前記プロセッサは、ユーザが操作する前記端末で発行された前記リクエストの処理が完了するまで、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置である。
請求項３に記載の発明は、前記プロセッサは、前記リクエストに関する処理がいずれも完了した後、前記ヘルスチェックのリクエストの発行を許可する、請求項２に記載の情報処理装置である。
請求項４に記載の発明は、前記プロセッサは、前記クラウドサービスの障害の発生を監視し、当該障害の発生が確認された場合、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置である。
請求項５に記載の発明は、前記プロセッサは、プラグインサービスのログを通じ、前記障害の発生を監視する、請求項４に記載の情報処理装置である。
請求項６に記載の発明は、前記プロセッサは、前記障害の復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項４に記載の情報処理装置である。
請求項７に記載の発明は、前記プロセッサは、前記クラウドサービスの障害からの復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項１に記載の情報処理装置である。
請求項８に記載の発明は、前記プロセッサは、前記クラウドサービスの停止を、ユーザが操作する前記端末に通知する、請求項４に記載の情報処理装置である。
請求項９に記載の発明は、前記プロセッサは、前記クラウドサービスの復旧を、ユーザが操作する前記端末に通知する、請求項４又は８に記載の情報処理装置である。
請求項１０に記載の発明は、コンピュータに、受け付けたリクエストに関する処理の状態を監視する機能と、処理が継続している前記リクエストがある間、ヘルスチェックのリクエストを発行しない機能とを実現させるプログラムである。 According to the first aspect of the present invention, the information processing apparatus for providing a service for relaying the use of the cloud service by the terminal operated by the user has a processor, and the processor monitors the state of processing related to the received request. It is an information processing device that does not issue a health check request while there is the request for which processing is continuing.
The information processing apparatus according to claim 1, wherein the processor does not issue the health check request until the processing of the request issued by the terminal operated by the user is completed. Is.
The invention according to claim 3 is the information processing apparatus according to claim 2, wherein the processor permits the issuance of the health check request after all the processes related to the request are completed.
The information according to claim 1, wherein the processor monitors the occurrence of a failure of the cloud service and does not issue the health check request when the occurrence of the failure is confirmed. It is a processing device.
The invention according to claim 5 is the information processing apparatus according to claim 4, wherein the processor monitors the occurrence of the failure through the log of the plug-in service.
The invention according to claim 6 is the information processing apparatus according to claim 4, wherein the processor permits the issuance of the health check request when the recovery of the failure is confirmed.
The invention according to claim 7 is the information processing apparatus according to claim 1, wherein the processor permits the issuance of the health check request when recovery from the failure of the cloud service is confirmed.
The invention according to claim 8 is the information processing apparatus according to claim 4, wherein the processor notifies the terminal operated by the user of the stop of the cloud service.
The invention according to claim 9 is the information processing apparatus according to claim 4 or 8, wherein the processor notifies the terminal operated by the user of the restoration of the cloud service.
The invention according to claim 10 is a program that realizes a function of monitoring the processing status of a received request and a function of not issuing a health check request while the processing is continuing. Is.

請求項１記載の発明によれば、クラウドサービスのユーザによる使用中もヘルチェックを実行する場合に比して、システムに対する負荷を抑制できる。
請求項２記載の発明によれば、ユーザの端末からのリクエストの進捗により、システムの負荷を増やすこと無く、クラウドサーバの状態を把握できる。
請求項３記載の発明によれば、システムの負荷を抑制しながらヘルスチェックを実行できる。
請求項４記載の発明によれば、不要なヘルスチェックの実行を抑制できる。
請求項５記載の発明によれば、ヘルスチェックを実行することなく、クラウドサービスの状態を監視できる。
請求項６記載の発明によれば、クラウドサービスが復旧するのを待ってヘルスチェックを再開できる。
請求項７記載の発明によれば、クラウドサービスが復旧するのを待ってヘルスチェックを再開できる。
請求項８記載の発明によれば、ユーザの操作を抑制してシステムの負荷の抑制できる。
請求項９記載の発明によれば、ユーザによる操作の再開を可能にできる。
請求項１０記載の発明によれば、クラウドサービスのユーザによる使用中もヘルチェックを実行する場合に比して、システムに対する負荷を抑制できる。 According to the first aspect of the present invention, the load on the system can be suppressed as compared with the case where the hell check is executed even during use by the user of the cloud service.
According to the second aspect of the present invention, the state of the cloud server can be grasped without increasing the load on the system by the progress of the request from the user's terminal.
According to the invention of claim 3, the health check can be executed while suppressing the load on the system.
According to the invention of claim 4, it is possible to suppress the execution of unnecessary health checks.
According to the invention of claim 5, the state of the cloud service can be monitored without executing the health check.
According to the invention of claim 6, the health check can be restarted after waiting for the cloud service to be restored.
According to the invention of claim 7, the health check can be restarted after the cloud service is restored.
According to the invention of claim 8, it is possible to suppress the operation of the user and suppress the load on the system.
According to the invention of claim 9, it is possible for the user to resume the operation.
According to the tenth aspect of the present invention, the load on the system can be suppressed as compared with the case where the hell check is executed even during use by the user of the cloud service.

実施の形態１で想定するクラウドシステムの構成例を示す図である。It is a figure which shows the configuration example of the cloud system assumed in Embodiment 1. FIG. 中継サーバの構成例を説明する図である。It is a figure explaining the configuration example of a relay server. 実施の形態１で使用する中継サーバの機能構成の一例を説明する図である。It is a figure explaining an example of the functional structure of the relay server used in Embodiment 1. FIG. リクエスト状態管理部が管理するリクエストの状態を説明する図である。It is a figure explaining the state of the request managed by the request state management part. 端末からリクエストが与えられた場合における中継サーバの処理動作の一例を説明する図である。It is a figure explaining an example of the processing operation of a relay server when a request is given from a terminal. リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。It is a figure explaining the transition of the state of the request managed by the request state management part. ヘルスチェックのためのリクエストが発行される場合における中継サーバの処理動作の一例を説明する図である。It is a figure explaining an example of the processing operation of a relay server when a request for a health check is issued. リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。It is a figure explaining the transition of the state of the request managed by the request state management part. 実施の形態２で使用する中継サーバの機能構成の一例を説明する図である。It is a figure explaining an example of the functional structure of the relay server used in Embodiment 2. FIG. クラウドサービスに障害が発生した場合における中継サーバの処理動作の一例を説明する図である。It is a figure explaining an example of the processing operation of a relay server when a failure occurs in a cloud service. リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。It is a figure explaining the transition of the state of the request managed by the request state management part. 実施の形態３で使用する端末と中継サーバの機能構成の一例を説明する図である。It is a figure explaining an example of the functional structure of the terminal and the relay server used in Embodiment 3. FIG. プラグインサービス状態保持部に保持されている状態の例を説明する図である。It is a figure explaining the example of the state held in the plug-in service state holding part. 端末からプラグインサービスの状態が問い合わされた場合における中継サーバの処理動作の一例を説明する図である。It is a figure explaining an example of the processing operation of a relay server when the state of a plug-in service is inquired from a terminal. プラグインサービスの状態を示す画面の表示例を示す図である。It is a figure which shows the display example of the screen which shows the state of a plug-in service. プラグインサービスの状態を示す他の画面の表示例を示す図である。It is a figure which shows the display example of another screen which shows the state of a plug-in service. 画像形成装置の表示部に対するユーザの操作の例を説明する図である。It is a figure explaining the example of the user operation with respect to the display part of an image forming apparatus. ユーザが選択したフォーマットＡへの文字データへの変換を実行できない場合に代替フォーマットへの変換を提示する画面の例を示す図である。It is a figure which shows the example of the screen which presents the conversion to an alternative format when the conversion to the character data to the format A selected by the user cannot be performed.

以下、添付図面を参照して、実施の形態について詳細に説明する。
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１で想定するクラウドシステム１の構成例を示す図である。
クラウドシステム１は、クラウドネットワーク１０と、ユーザが操作する端末２０と、クラウドサービスを提供するクラウドサーバ３０と、端末２０とクラウドサーバ３０の間で通信を中継する中継サーバ４０とで構成されている。中継サーバ４０は、情報処理装置の一例である。
クラウドネットワーク１０は、例えばインターネットやＶＰＮ（＝Virtual Private Network）であり、専用線でもよい。 Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.
<Embodiment 1>
<System configuration>
FIG. 1 is a diagram showing a configuration example of the cloud system 1 assumed in the first embodiment.
The cloud system 1 is composed of a cloud network 10, a terminal 20 operated by a user, a cloud server 30 that provides a cloud service, and a relay server 40 that relays communication between the terminal 20 and the cloud server 30. .. The relay server 40 is an example of an information processing device.
The cloud network 10 is, for example, the Internet or a VPN (= Virtual Private Network), and may be a dedicated line.

ユーザが操作する端末２０は、クラウドサーバ３０との連携により、様々なサービスをユーザに提供する。図１では、端末２０の例として、画像形成装置２０Ａとノート型のコンピュータ２０Ｂを表している。もっとも、端末２０は、通信機能を有し、クラウドサービスを活用して機能の拡張が可能な機器であればよい。端末２０は、例えばスマートフォン、タブレット型のコンピュータ、コネクティッドカー、ＩｏＴ（＝Internet of Things）家電、スマート家電でもよい。
本実施の形態で使用する画像形成装置２０Ａは、印刷、コピー、ファックス、スキャナ等の複数の機能を有している。この種の画像形成装置２０Ａは、複合機とも呼ばれる。 The terminal 20 operated by the user provides various services to the user in cooperation with the cloud server 30. In FIG. 1, as an example of the terminal 20, an image forming apparatus 20A and a notebook computer 20B are shown. However, the terminal 20 may be a device having a communication function and capable of expanding the function by utilizing a cloud service. The terminal 20 may be, for example, a smartphone, a tablet-type computer, a connected car, an IoT (= Internet of Things) home appliance, or a smart home appliance.
The image forming apparatus 20A used in the present embodiment has a plurality of functions such as printing, copying, faxing, and scanning. This type of image forming apparatus 20A is also called a multifunction device.

クラウドサーバ３０は、クラウドサービスを提供するサーバであり、本実施の形態の場合、サービス毎に用意される。クラウドサービスには、例えばグループウェア、バックオフィス、オンラインストレージ、ＯＣＲ（＝Optical Character Recognition）処理、データのフォーマット変換がある。本実施の形態では、データをストレージに記憶するサービスをストレージ型といい、データを処理するサービスや外部と接続するサービスを業務型という。 The cloud server 30 is a server that provides a cloud service, and in the case of the present embodiment, the cloud server 30 is prepared for each service. Cloud services include, for example, groupware, back office, online storage, OCR (= Optical Character Recognition) processing, and data format conversion. In the present embodiment, the service for storing data in the storage is referred to as a storage type, and the service for processing data and the service for connecting to the outside are referred to as a business type.

図１には、クラウドサーバ３０の例として、業務型のクラウドサービスを提供するクラウドサーバ３０Ａ（以下「業務型のクラウドサーバ３０Ａ」という）とストレージ型のクラウドサービスを提供するクラウドサーバ３０Ｂ（以下「ストレージ型のクラウドサーバ３０Ｂ」という）を表している。
業務型のクラウドサーバ３０Ａは、例えば端末２０から受信した文書データを処理して返却するサービスを提供する。ストレージ型のクラウドサーバ３０Ｂは、端末２０から受信した文書データを予め確保された領域に記憶する。なお、クラウドシステム１で扱うデータは文書データに限らない。 FIG. 1 shows, as an example of the cloud server 30, a cloud server 30A that provides a business-type cloud service (hereinafter referred to as “business-type cloud server 30A”) and a cloud server 30B that provides a storage-type cloud service (hereinafter ““ business-type cloud server 30A ”). It represents a storage type cloud server 30B ”).
The business-type cloud server 30A provides, for example, a service of processing and returning document data received from a terminal 20. The storage type cloud server 30B stores the document data received from the terminal 20 in a predetermined area. The data handled by the cloud system 1 is not limited to document data.

中継サーバ４０は、端末２０から入力されたリクエストに応じて１つ又は複数のクラウドサーバ３０にアクセスし、リクエストに応じた処理の結果を端末２０に通知する。本実施の形態における中継サーバ４０は、クラウドサーバ３０における障害の有無を検知するヘルスチェックを実行する。
図２は、中継サーバ４０の構成例を説明する図である。中継サーバ４０は、装置全体の動作を制御する制御ユニット４１と、データを記憶する記憶装置４２と、入出力ポート４３と、通信装置４４とを有している。なお、制御ユニット４１と他の処理部は、信号線やバスを用いて相互に接続されている。 The relay server 40 accesses one or more cloud servers 30 in response to a request input from the terminal 20, and notifies the terminal 20 of the result of processing in response to the request. The relay server 40 in the present embodiment executes a health check for detecting the presence or absence of a failure in the cloud server 30.
FIG. 2 is a diagram illustrating a configuration example of the relay server 40. The relay server 40 has a control unit 41 that controls the operation of the entire device, a storage device 42 that stores data, an input / output port 43, and a communication device 44. The control unit 41 and other processing units are connected to each other by using a signal line or a bus.

制御ユニット４１は、ＣＰＵ（＝Central Processing Unit）４１Ａと、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）と、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）とを有している。制御ユニット４１は、いわゆるコンピュータとして機能する。ＣＰＵ４１Ａは、プロセッサの一例である。
記憶装置４２は、例えば半導体メモリやハードディスク装置により構成される。記憶装置４２には、オペレーティングシステムやヘルスチェックに関するプログラムも記憶されている。 The control unit 41 includes a CPU (= Central Processing Unit) 41A, a ROM (= Read Only Memory) in which a BIOS (= Basic Input Output System) and the like are stored, and a RAM (= Random Access Memory) used as a work area. have. The control unit 41 functions as a so-called computer. The CPU 41A is an example of a processor.
The storage device 42 is composed of, for example, a semiconductor memory or a hard disk device. The storage device 42 also stores programs related to the operating system and health check.

図３は、実施の形態１で使用する中継サーバ４０の機能構成の一例を説明する図である。図３に示す機能は、ＣＰＵ４１Ａによるプログラムの実行を通じて実現される。
中継サーバ４０は、コアサービス４１０と、タスク定義モジュール４２０と、プラグインサービス４３０と、キュー４４０と、リクエスト状態管理部４５０と、ヘルスチェックリクエスト発行部４６０として機能する。
コアサービス４１０は、外部とのデータの受け渡しを実行するサブ機能で構成される。図３の場合、コアサービス４１０は、ユーザが操作する端末２０と通信するタスクサービス４１０Ａと、業務型のクラウドサーバ３０Ａと通信するＡＰＩ（＝Application Programming Interface）デリゲートサービス４１０Ｂと、ストレージ型のクラウドサーバ３０Ｂと通信するＣＭＩＳ（＝Content Management Interoperability Services）ゲートウェイサービス４１０Ｃとを有している。 FIG. 3 is a diagram illustrating an example of the functional configuration of the relay server 40 used in the first embodiment. The function shown in FIG. 3 is realized through the execution of the program by the CPU 41A.
The relay server 40 functions as a core service 410, a task definition module 420, a plug-in service 430, a queue 440, a request status management unit 450, and a health check request issuing unit 460.
The core service 410 is composed of sub-functions that execute data exchange with the outside. In the case of FIG. 3, the core service 410 includes a task service 410A that communicates with the terminal 20 operated by the user, an API (= Application Programming Interface) gateway service 410B that communicates with the business-type cloud server 30A, and a storage-type cloud server. It has a CMIS (= Content Management Interoperability Services) gateway service 410C that communicates with 30B.

タスクサービス４１０Ａは、端末２０から受け付けたリクエストやヘルスチェックリクエスト発行部４６０から受け付けたリクエストに基づいて、タスク定義モジュール４２０のイベント処理モジュール４２０Ａを起動する処理、タスク定義モジュール４２０との連携によりプラグインを呼び出すリクエストを出力する処理、クラウドサービスから返却された文書データを端末２０に返信する処理、リクエスト状態管理部４５０にリクエストの発行や終了を通知する処理等を実行する。
タスクサービス４１０Ａは、イベント処理モジュール４２０Ａを起動する場合、タスク定義をイベント処理モジュール４２０Ａに与える。タスク定義は、プラグイン又は複数のプラグインの組み合わせにより実現される作業を定義する情報である。 The task service 410A is a plug-in that activates the event processing module 420A of the task definition module 420 based on the request received from the terminal 20 or the request received from the health check request issuing unit 460, and cooperates with the task definition module 420. It executes a process of outputting a request to call, a process of returning the document data returned from the cloud service to the terminal 20, a process of notifying the request status management unit 450 of the issuance or termination of the request, and the like.
When the task service 410A starts the event processing module 420A, the task service 410A gives the task definition to the event processing module 420A. A task definition is information that defines a work realized by a plug-in or a combination of a plurality of plug-ins.

ＡＰＩデリゲートサービス４１０Ｂは、業務型プラグインサービス４３０Ａから読み出したプラグインを用い、業務型のクラウドサーバ３０Ａと通信する処理等を実行する。
ＣＭＩＳゲートウェイサービス４１０Ｃは、ストレージ型プラグインサービス４３０Ｂから読み出したプラグインを用い、ストレージ型のクラウドサーバ３０Ｂと通信する処理等を実行する。
タスク定義モジュール４２０は、イベント処理モジュール４２０Ａと、タスク定義ライブラリ４２０Ｂで構成される。イベント処理モジュール４２０Ａは、タスク定義に関連するプラグインのライブラリを、タスク定義ライブラリ４２０Ｂから読み出す。 The API delegate service 410B uses the plug-in read from the business-type plug-in service 430A to execute a process of communicating with the business-type cloud server 30A.
The CMIS gateway service 410C uses the plug-in read from the storage type plug-in service 430B to execute a process of communicating with the storage type cloud server 30B.
The task definition module 420 includes an event processing module 420A and a task definition library 420B. The event processing module 420A reads the library of the plug-in related to the task definition from the task definition library 420B.

図３に示すプラグインサービス４３０は、業務型プラグインサービス４３０Ａとストレージ型プラグインサービス４３０Ｂで構成される。
業務型プラグインサービス４３０Ａは、業務型のサービス毎に用意され、文書処理プラグイン４３０Ａ１と、プラグインライブラリ４３０Ａ２とで構成される。
ストレージ型プラグインサービス４３０Ｂは、ストレージ型のサービス毎に用意され、ストレージ登録プラグイン４３０Ｂ１と、プラグインライブラリ４３０Ｂ２で構成される。
キュー４４０は、タスクサービス４１０Ａから出力されたプラグインを呼び出すリクエストを格納する記憶領域である。 The plug-in service 430 shown in FIG. 3 is composed of a business-type plug-in service 430A and a storage-type plug-in service 430B.
The business-type plug-in service 430A is prepared for each business-type service, and is composed of a document processing plug-in 430A1 and a plug-in library 430A2.
The storage type plug-in service 430B is prepared for each storage type service, and is composed of a storage registration plug-in 430B1 and a plug-in library 430B2.
The queue 440 is a storage area for storing a request for calling a plug-in output from the task service 410A.

リクエスト状態管理部４５０は、ユーザが操作する端末２０やヘルスチェックリクエスト発行部４６０から受け付けたリクエストの処理の状態を管理する機能と、管理の対象であるリクエストの状態を変更する機能と、リクエストの状態に応じ、ヘルスチェックリクエスト発行部４６０に対してヘルスチェックのためのリクエストの発行を依頼する機能とを有している。
本実施の形態の場合、リクエスト状態管理部４５０は、処理中のリクエストが継続している場合は、ヘルスチェックのためのリクエストを発行しない。 The request status management unit 450 has a function of managing the processing status of the request received from the terminal 20 operated by the user and the health check request issuing unit 460, a function of changing the status of the request to be managed, and a request. It has a function of requesting the health check request issuing unit 460 to issue a request for health check according to the state.
In the case of this embodiment, the request status management unit 450 does not issue a request for health check if the request being processed continues.

換言すると、ユーザが操作する端末２０から受け付けたリクエストが処理中の場合やヘルスチェックのためのリクエストが処理中の場合、リクエスト状態管理部４５０は、それらの処理が完了するまで、ヘルスチェックのための新たなリクエストを発行しない。
本実施の形態におけるリクエスト状態管理部４５０がヘルスチェックのためのリクエストを発行するのは、処理中のリクエストがない場合に限られる。
ヘルスチェックリクエスト発行部４６０は、リクエスト状態管理部４５０から依頼があった場合に、ヘルスチェックのためのリクエストを発行してタスクサービス４１０Ａに与える。 In other words, if the request received from the terminal 20 operated by the user is being processed or the request for health check is being processed, the request status management unit 450 is for health check until those processes are completed. Do not issue new requests for.
The request state management unit 450 in the present embodiment issues a request for health check only when there is no request being processed.
When the request status management unit 450 requests, the health check request issuing unit 460 issues a request for health check and gives it to the task service 410A.

図４は、リクエスト状態管理部４５０が管理するリクエストの状態を説明する図である。
本実施の形態の場合、リクエストの状態は、新規、待機中、処理中、完了、失敗の５つである。
新規は、ユーザが操作する端末２０又はヘルスチェックリクエスト発行部４６０から発行された新たなリクエストが登録された状態をいう。
待機中は、プラグインが処理待ちで待機している状態をいう。
処理中は、プラグインが処理を行っている状態をいう。
完了は、プラグインが処理を完了した状態をいう。
失敗は、プラグインの処理がエラーにより失敗した状態をいう。 FIG. 4 is a diagram illustrating a request state managed by the request state management unit 450.
In the case of this embodiment, there are five request states: new, waiting, processing, completed, and failed.
The new state means a state in which a new request issued from the terminal 20 operated by the user or the health check request issuing unit 460 is registered.
Waiting means that the plug-in is waiting for processing.
During processing, it means that the plug-in is processing.
Completion means that the plug-in has completed the process.
Failure means that the processing of the plug-in has failed due to an error.

前述したように、リクエストがない場合、又は、全てのリクエストが完了した場合に、リクエスト状態管理部４５０は、ヘルスチェックリクエスト発行部４６０に対してリクエストの発行を依頼する。一方、リクエストが新規、待機中、処理中、失敗の状態の場合に、リクエスト状態管理部４５０は、ヘルスチェックリクエスト発行部４６０に対してリクエストの発行を依頼しない。
リクエストの状態が新規、待機中、処理中、失敗の場合は、リクエストの処理が継続している状態の一例である。 As described above, when there is no request or when all the requests are completed, the request status management unit 450 requests the health check request issuing unit 460 to issue the request. On the other hand, when the request is in a new, waiting, processing, or failing state, the request state management unit 450 does not request the health check request issuing unit 460 to issue the request.
When the status of the request is new, waiting, processing, or failure, it is an example of the state in which the processing of the request is continuing.

＜処理動作＞
図５は、端末２０からリクエストが与えられた場合における中継サーバ４０の処理動作の一例を説明する図である。
図５で説明する処理動作は、端末２０からタスクサービス４１０Ａに対し、リクエストの通知が与えられることで開始される。
リクエストを受け付けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、新規のリクエストの発行を通知する。
通知を受け付けたリクエスト状態管理部４５０は、リクエストの状態を更新して「新規」とする。
この後、タスクサービス４１０Ａは、キュー４４０にリクエストを格納する。 <Processing operation>
FIG. 5 is a diagram illustrating an example of a processing operation of the relay server 40 when a request is given from the terminal 20.
The processing operation described with reference to FIG. 5 is started when the terminal 20 gives a request notification to the task service 410A.
The task service 410A that has received the request notifies the request status management unit 450 that a new request is issued.
The request status management unit 450 that has received the notification updates the status of the request to make it "new".
After that, the task service 410A stores the request in the queue 440.

プラグインサービス４３０は、キュー４４０にアクセスし、格納されているリクエストを取得する。その後、プラグインサービス４３０は、リクエストの処理を開始し、リクエスト状態管理部４５０に対し、リクエストの状態の更新を通知する。これにより、リクエスト状態管理部４５０による状態の管理は、「新規」から「処理中」に変更される。
やがて、リクエストの処理が終了すると、プラグインサービス４３０は、タスクサービス４１０Ａに対し、リクエストの処理の完了を通知する。なお、業務型のプラグインサービスの場合は、処理済みのデータ又は結果もタスクサービス４１０Ａに通知される。 The plug-in service 430 accesses the queue 440 and acquires the stored request. After that, the plug-in service 430 starts processing the request and notifies the request status management unit 450 of the update of the request status. As a result, the status management by the request status management unit 450 is changed from "new" to "processing".
Eventually, when the processing of the request is completed, the plug-in service 430 notifies the task service 410A of the completion of the processing of the request. In the case of a business-type plug-in service, the processed data or result is also notified to the task service 410A.

通知を受けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、リクエストの処理の完了を通知する。
通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「完了」とする。
図６は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。リクエストの状態は、リクエストＩＤ（＝IDentification）と紐付けて管理される。図６の場合、リクエストＩＤは、「REQ00001」で管理されている。図６の場合、状態は「新規」→「処理中」→「完了」に変化する。 Upon receiving the notification, the task service 410A notifies the request status management unit 450 that the processing of the request is completed.
Upon receiving the notification, the request status management unit 450 updates the status of the request and sets it as "completed".
FIG. 6 is a diagram illustrating a transition of the request state managed by the request state management unit 450. The state of the request is managed in association with the request ID (= IDentification). In the case of FIG. 6, the request ID is managed by "REQ00001". In the case of FIG. 6, the state changes from “new” → “processing” → “completed”.

図７は、ヘルスチェックのためのリクエストが発行される場合における中継サーバ４０の処理動作の一例を説明する図である。
図７で説明する処理動作は、リクエスト状態管理部４５０が、予め定めた状態を検知することで開始される。具体的には、リクエストが無い、又は、全て完了している場合、リクエスト状態管理部４５０が、ヘルスチェックリクエスト発行部４６０に対し、リクエストの発行の依頼を通知する。
通知を受けたヘルスチェックリクエスト発行部４６０は、タスクサービス４１０Ａに対し、ヘルスチェックのリクエストの発行を通知する。 FIG. 7 is a diagram illustrating an example of the processing operation of the relay server 40 when a request for health check is issued.
The processing operation described with reference to FIG. 7 is started when the request state management unit 450 detects a predetermined state. Specifically, when there is no request or all are completed, the request status management unit 450 notifies the health check request issuing unit 460 of the request for issuing the request.
Upon receiving the notification, the health check request issuing unit 460 notifies the task service 410A of the issuance of the health check request.

リクエストの発行の通知を受け付けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、新規のリクエストの発行を通知する。
通知を受け付けたリクエスト状態管理部４５０は、リクエストの状態を更新して「新規」とする。
この後、タスクサービス４１０Ａは、キュー４４０にリクエストを格納する。
プラグインサービス４３０は、キュー４４０にアクセスし、格納されているリクエストを取得する。その後、プラグインサービス４３０は、リクエストの処理を開始し、リクエスト状態管理部４５０に対し、リクエストの状態の更新を通知する。これにより、リクエスト状態管理部４５０による状態の管理は、「新規」から「処理中」に変更される。ヘルスチェックのためのリクエストは、クラウドサービスの動作の状態を確認することを目的とするので、処理自体は簡易である。 Upon receiving the notification of the issuance of the request, the task service 410A notifies the request status management unit 450 of the issuance of a new request.
The request status management unit 450 that has received the notification updates the status of the request to make it "new".
After that, the task service 410A stores the request in the queue 440.
The plug-in service 430 accesses the queue 440 and acquires the stored request. After that, the plug-in service 430 starts processing the request and notifies the request status management unit 450 of the update of the request status. As a result, the status management by the request status management unit 450 is changed from "new" to "processing". Since the request for health check is intended to confirm the operation status of the cloud service, the processing itself is simple.

やがて、リクエストの処理が終了すると、プラグインサービス４３０は、タスクサービス４１０Ａに対し、リクエストの処理の完了を通知する。
通知を受けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、リクエストの処理の完了を通知する。
通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「完了」とする。
図８は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。図８の場合、リクエストＩＤは、「REQ00002」で管理されている。
図８の場合、「REQ00002」のリクエストは、「REQ00001」のリクエストが完了した後に発行される。このため、「REQ00002」の状態が「新規」として登録されたときには、「REQ00001」の状態が既に「完了」になっている。その後の「REQ00002」の状態の変化は、「REQ00001」の状態の変化と同じである。 Eventually, when the processing of the request is completed, the plug-in service 430 notifies the task service 410A of the completion of the processing of the request.
Upon receiving the notification, the task service 410A notifies the request status management unit 450 that the processing of the request is completed.
Upon receiving the notification, the request status management unit 450 updates the status of the request and sets it as "completed".
FIG. 8 is a diagram illustrating a transition of the request state managed by the request state management unit 450. In the case of FIG. 8, the request ID is managed by "REQ00002".
In the case of FIG. 8, the request of "REQ00002" is issued after the request of "REQ00001" is completed. Therefore, when the state of "REQ00002" is registered as "new", the state of "REQ00001" is already "completed". Subsequent changes in the state of "REQ00002" are the same as changes in the state of "REQ00001".

＜実施の形態２＞
実施の形態２の場合にも、実施の形態１で説明したクラウドシステム１（図１参照）を想定する。
図９は、実施の形態２で使用する中継サーバ４０の機能構成の一例を説明する図である。図９には、図３との対応部分に対応する符号を付して示している。
本実施の形態で使用する中継サーバ４０は、障害管理部４７０を有する点で実施の形態１と相違する。
本実施の形態における障害管理部４７０には、プラグインサービス４３０のログから障害の発生を検知する機能と、プラグインサービス４３０のログから障害からの復旧を検知する機能と、障害の発生をリクエスト状態管理部４５０に通知する機能と、障害からの復旧をリクエスト状態管理部４５０に通知する機能とが設けられている。 <Embodiment 2>
Also in the case of the second embodiment, the cloud system 1 (see FIG. 1) described in the first embodiment is assumed.
FIG. 9 is a diagram illustrating an example of the functional configuration of the relay server 40 used in the second embodiment. FIG. 9 is shown with reference numerals corresponding to the portions corresponding to those in FIG.
The relay server 40 used in the present embodiment is different from the first embodiment in that it has a fault management unit 470.
The failure management unit 470 in the present embodiment is requested to have a function of detecting the occurrence of a failure from the log of the plug-in service 430, a function of detecting recovery from the failure from the log of the plug-in service 430, and a request for the occurrence of a failure. It is provided with a function of notifying the status management unit 450 and a function of notifying the request status management unit 450 of recovery from a failure.

図１０は、クラウドサービスに障害が発生した場合における中継サーバ４０の処理動作の一例を説明する図である。
図１０で説明する処理動作は、プラグインサービス４３０のログを通じてリクエストの処理に障害が発生したことを検知した障害管理部４７０が、リクエスト状態管理部４５０に対し、障害の発生を通知が与えることで開始される。通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「失敗」とする。
やがて、プラグインサービス４３０のログを通じてリクエストの処理が復旧したことを検知すると、障害管理部４７０は、リクエスト状態管理部４５０に対し、障害からの復旧を通知する。通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「処理中」とする。 FIG. 10 is a diagram illustrating an example of processing operation of the relay server 40 when a failure occurs in the cloud service.
In the processing operation described with reference to FIG. 10, the failure management unit 470, which detects that a failure has occurred in request processing through the log of the plug-in service 430, notifies the request status management unit 450 of the occurrence of the failure. It starts with. Upon receiving the notification, the request status management unit 450 updates the status of the request and sets it as "failure".
Eventually, when it is detected through the log of the plug-in service 430 that the processing of the request has been restored, the failure management unit 470 notifies the request status management unit 450 of the recovery from the failure. Upon receiving the notification, the request status management unit 450 updates the status of the request and sets it as "processing".

図１１は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。
図１１の場合、「REQ00002」で管理されるリクエストの処理中に、リクエストを処理しているクラウドサービスに障害が発生している。このため、「REQ00002」の状態が「処理中」から「失敗」に変化している。なお、障害からの復旧が確認された後は、「REQ00002」の状態が「失敗」から「処理中」に戻っている。
この後、「REQ00002」の処理が完了すると、「REQ00002」の状態は、「完了」に変化する。 FIG. 11 is a diagram illustrating a transition of the request state managed by the request state management unit 450.
In the case of FIG. 11, a failure has occurred in the cloud service processing the request during the processing of the request managed by "REQ00002". Therefore, the state of "REQ00002" has changed from "processing" to "failure". After the recovery from the failure is confirmed, the status of "REQ00002" returns from "failure" to "processing".
After that, when the processing of "REQ00002" is completed, the state of "REQ00002" changes to "completed".

＜実施の形態３＞
実施の形態３の場合にも、実施の形態１で説明したクラウドシステム１（図１参照）を想定する。
図１２は、実施の形態３で使用する端末２０と中継サーバ４０の機能構成の一例を説明する図である。図１２には、図９との対応部分に対応する符号を付して示している。
本実施の形態の場合、ユーザが操作する端末２０には、自装置からプラグインサービス４３０の状態を問い合わせるプラグインサービス状態確認部２１０と、プラグインサービス４３０の状態を表示部に表示するプラグインサービス状態表示部２２０とが設けられている。 <Embodiment 3>
Also in the case of the third embodiment, the cloud system 1 (see FIG. 1) described in the first embodiment is assumed.
FIG. 12 is a diagram illustrating an example of the functional configuration of the terminal 20 and the relay server 40 used in the third embodiment. In FIG. 12, reference numerals corresponding to the portions corresponding to those in FIG. 9 are added.
In the case of the present embodiment, the terminal 20 operated by the user has a plug-in service status confirmation unit 210 that inquires about the status of the plug-in service 430 from its own device and a plug-in that displays the status of the plug-in service 430 on the display unit. A service status display unit 220 is provided.

プラグインサービス状態確認部２１０は、操作画面上でプラグインサービスの状態の確認を求める操作を受け付けた場合、中継サーバ４０に対して、プラグインサービスの状態の問い合わせを実行する。この問い合わせは、クラウドサービスに対してデータの処理を求めるリクエストではないので、タスクサービス４１０Ａには送信されない。
本実施の形態の場合、プラグインサービス状態表示部２２０は、問い合わせに対する応答として、プラグインサービスの現在の状態を表示する。なお、リクエスト状態管理部４５０が、ユーザからの問い合わせとは無関係に、プラグインサービスの現在の状態をプラグインサービス状態表示部２２０に表示させてもよい。 When the plug-in service status confirmation unit 210 receives an operation requesting confirmation of the plug-in service status on the operation screen, the plug-in service status confirmation unit 210 executes an inquiry of the plug-in service status to the relay server 40. Since this inquiry is not a request for the cloud service to process data, it is not sent to the task service 410A.
In the case of the present embodiment, the plug-in service status display unit 220 displays the current status of the plug-in service as a response to the inquiry. The request status management unit 450 may display the current status of the plug-in service on the plug-in service status display unit 220 regardless of the inquiry from the user.

本実施の形態で使用する中継サーバ４０には、実施の形態２の機能構成に加え、プラグインサービス状態保持部４８０と、プラグインサービス状態受付部４９０と、プラグインサービス状態通知部５００とが設けられている。
プラグインサービス状態保持部４８０は、障害管理部４７０より通知されたプラグインサービス４３０の状態を保持する。
プラグインサービス状態受付部４９０は、端末２０からプラグインサービス４３０の状態の問い合わせを受け付ける。プラグインサービス状態受付部４９０は、問い合わせを受け付けた場合、プラグインサービス状態保持部４８０に保持されている状態を読み出し、プラグインサービス状態通知部５００に通知する。
プラグインサービス状態通知部５００は、プラグインサービス状態受付部４９０から与えられたプラグインサービスの状態を端末２０に通知する。 In addition to the functional configuration of the second embodiment, the relay server 40 used in the present embodiment includes a plug-in service status holding unit 480, a plug-in service status receiving unit 490, and a plug-in service status notification unit 500. It is provided.
The plug-in service state holding unit 480 holds the state of the plug-in service 430 notified by the failure management unit 470.
The plug-in service status reception unit 490 receives an inquiry about the status of the plug-in service 430 from the terminal 20. When the plug-in service status reception unit 490 receives an inquiry, the plug-in service status reception unit 490 reads the status held in the plug-in service status holding unit 480 and notifies the plug-in service status notification unit 500.
The plug-in service status notification unit 500 notifies the terminal 20 of the status of the plug-in service given by the plug-in service status reception unit 490.

図１３は、プラグインサービス状態保持部４８０に保持されている状態の例を説明する図である。
図１３の場合、３つのプラグインサービスの状態が保持されている。図１３の場合、プラグインサービスの「PLGSVC001」と「PLGSVC002」の状態は「活性」であり、プラグインサービスの「PLGSVC003」の状態は「非活性」である。
図１４は、端末２０からプラグインサービスの状態が問い合わされた場合における中継サーバ４０の処理動作の一例を説明する図である。
図１４に説明する処理動作は、端末２０（図１参照）のプラグインサービス状態確認部２１０が、プラグインサービス状態受付部４９０に対し、プラグインサービス４３０（図１２参照）の状態を問い合わせることで開始される。前述したように、問い合わせは、ユーザが端末２０を通じて指示した場合に送信される。 FIG. 13 is a diagram illustrating an example of a state held in the plug-in service state holding unit 480.
In the case of FIG. 13, the states of the three plug-in services are maintained. In the case of FIG. 13, the state of the plug-in service "PLGSVC001" and "PLGSVC002" is "active", and the state of the plug-in service "PLGSVC003" is "inactive".
FIG. 14 is a diagram illustrating an example of a processing operation of the relay server 40 when the state of the plug-in service is inquired from the terminal 20.
In the processing operation described with reference to FIG. 14, the plug-in service status confirmation unit 210 of the terminal 20 (see FIG. 1) inquires of the plug-in service status reception unit 490 about the status of the plug-in service 430 (see FIG. 12). It starts with. As described above, the inquiry is transmitted when the user instructs through the terminal 20.

プラグインサービス状態受付部４９０は、プラグインサービス４３０の状態の問い合わせを受信すると、プラグインサービス状態保持部４８０に対し、プラグインサービス４３０が利用可能かを問い合わせる。問い合わせは、特定のプラグインサービス４３０を指定せずに行ってもよいが、特定のプラグインサービス４３０を指定して行ってもよい。例えば端末２０で実行されている機能に関連するプラグインサービス４３０を指定する。指定は、プラグインサービス状態確認部２１０が行ってもよいし、プラグインサービス状態受付部４９０が行ってもよい。
プラグインサービス状態保持部４８０は、保持している状態をプラグインサービス状態受付部４９０に戻す。図１４の場合、「非活性」との情報がプラグインサービス状態受付部４９０に戻される。 Upon receiving the inquiry about the status of the plug-in service 430, the plug-in service status reception unit 490 inquires the plug-in service status holding unit 480 whether the plug-in service 430 is available. The inquiry may be made without specifying a specific plug-in service 430, but may be made by designating a specific plug-in service 430. For example, the plug-in service 430 related to the function executed by the terminal 20 is specified. The designation may be made by the plug-in service status confirmation unit 210 or by the plug-in service status reception unit 490.
The plug-in service state holding unit 480 returns the holding state to the plug-in service state receiving unit 490. In the case of FIG. 14, the information of "inactive" is returned to the plug-in service status reception unit 490.

次に、プラグインサービス状態受付部４９０は、プラグインサービス状態通知部５００に対し、プラグインサービス４３０の状態の通知を依頼する。
依頼を受け付けたプラグインサービス状態通知部５００は、プラグインサービス状態表示部２２０に対し、プラグインサービス４３０の状態を通知する。
この後、プラグインサービス状態表示部２２０は、表示部にプラグインサービス４３０の状態を表示する。
図１５は、プラグインサービス４３０の状態を示す画面２３０の表示例を示す図である。図１５に示す画面２３０は、プラグインサービス４３０（図１２参照）の状態を問い合わせた端末２０（図１参照）の表示部２００Ａに表示される。図１５に示す画面２３０は、ＸＸＸサービスが停止していることを示している。
図１６は、プラグインサービス４３０の状態を示す他の画面２４０の表示例を示す図である。図１６に示す画面２４０は、停止していたＸＸＸサービスが復旧した直後に表示される。 Next, the plug-in service status reception unit 490 requests the plug-in service status notification unit 500 to notify the status of the plug-in service 430.
The plug-in service status notification unit 500 that has received the request notifies the plug-in service status display unit 220 of the status of the plug-in service 430.
After that, the plug-in service status display unit 220 displays the status of the plug-in service 430 on the display unit.
FIG. 15 is a diagram showing a display example of the screen 230 showing the state of the plug-in service 430. The screen 230 shown in FIG. 15 is displayed on the display unit 200A of the terminal 20 (see FIG. 1) inquiring about the status of the plug-in service 430 (see FIG. 12). The screen 230 shown in FIG. 15 indicates that the XXX service is stopped.
FIG. 16 is a diagram showing a display example of another screen 240 showing the state of the plug-in service 430. The screen 240 shown in FIG. 16 is displayed immediately after the stopped XXX service is restored.

なお、プラグインサービス状態受付部４９０には、プラグインサービス４３０の状態が非活性の場合に、ユーザからの問い合わせがなくてもユーザにより選択された処理を実行するプラグインサービス４３０に障害が検知されると、代替が可能な他のサービスを端末２０に通知する機能を設けてもよい。
図１７は、画像形成装置２０Ａ（図１参照）の表示部２００Ａに対するユーザの操作の例を説明する図である。（Ａ）は画像形成装置２０Ａで読み取った原稿の画像データのＯＣＲ処理を選択した状態を示し、（Ｂ）はＯＣＲ処理後の文字データをフォーマットＡで記憶する状態を示す。
なお、ＯＣＲ処理は、業務型のクラウドサーバ３０Ａで実行され、フォーマットＡによる文字データの記憶は、ストレージ型のクラウドサーバ３０Ｂで実行される。図１７では、ＯＣＲ処理が選択された状態とフォーマットＡへの変換が選択された状態を破線で囲んで示している。 In the plug-in service status reception unit 490, when the status of the plug-in service 430 is inactive, a failure is detected in the plug-in service 430 that executes the process selected by the user even if there is no inquiry from the user. Then, a function of notifying the terminal 20 of another service that can be substituted may be provided.
FIG. 17 is a diagram illustrating an example of a user's operation on the display unit 200A of the image forming apparatus 20A (see FIG. 1). (A) shows a state in which the OCR processing of the image data of the original image read by the image forming apparatus 20A is selected, and (B) shows a state in which the character data after the OCR processing is stored in the format A.
The OCR process is executed by the business-type cloud server 30A, and the storage of character data in the format A is executed by the storage-type cloud server 30B. In FIG. 17, a state in which OCR processing is selected and a state in which conversion to format A is selected are shown by being surrounded by a broken line.

図１８は、ユーザが選択したフォーマットＡへの文字データへの変換を実行できない場合に代替フォーマットへの変換を提示する画面２７０の例を示す図である。
図１８の場合、画面２７０には、「ただいま、サーバの障害によりフォーマットＡへの変換ができません。代替機能として、フォーマットＢへの変換は可能です。フォーマットＢに変換し、処理を継続しますか？」と表示されており、「はい」か「いいえ」の選択が可能である。
フォーマットＡは、例えばＰＤＦ（＝Portable Document Format）であり、フォーマットＢは、例えばDocuWorks（登録商標）である。 FIG. 18 is a diagram showing an example of a screen 270 that presents conversion to an alternative format when conversion to character data to format A selected by the user cannot be performed.
In the case of FIG. 18, on the screen 270, "Currently, conversion to format A is not possible due to a server failure. Conversion to format B is possible as an alternative function. Do you want to convert to format B and continue processing? "?" Is displayed, and "Yes" or "No" can be selected.
Format A is, for example, PDF (= Portable Document Format), and format B is, for example, DocuWorks®.

なお、図１８に示す画面２７０を表示しても、ユーザによる代替機能の選択がいつまで経っても入力されない状況も考えられる。例えば原稿のスキャンの実行を画像形成装置２０Ａに指示した後に、ユーザが画像形成装置２０Ａから離れた場合である。
予め定めた時間が経過してもユーザによる選択が入力されない場合に備えた機能として、プラグインサービス状態表示部２２０に、予め登録されているユーザのメールアドレスに対して他のフォーマットへの変換を実行するかを問い合わせる機能を設けてもよい。
ユーザからの選択を受け付ける前に障害が復旧した場合、クラウドサービスの処理が再開される。 Even if the screen 270 shown in FIG. 18 is displayed, it is conceivable that the user does not input the alternative function for a long time. For example, this is a case where the user leaves the image forming apparatus 20A after instructing the image forming apparatus 20A to execute scanning of the original.
As a function in case the user's selection is not input even after the predetermined time has elapsed, the plug-in service status display unit 220 converts the pre-registered user's e-mail address into another format. A function for inquiring whether to execute may be provided.
If the failure recovers before accepting the user's selection, the cloud service processing will resume.

＜他の実施の形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。 <Other embodiments>
Although the embodiments of the present invention have been described above, the technical scope of the present invention is not limited to the scope described in the above-described embodiments. It is clear from the description of the claims that the above-mentioned embodiments with various modifications or improvements are also included in the technical scope of the present invention.

例えば前述の実施の形態では、端末２０の例として、印刷、コピー、ファックス、スキャナ等の複数の機能を備える画像形成装置２０Ａを想定したが、印刷の専用機やスキャナの専用機でもよい。また、端末２０は、画像形成装置２０Ａのように、用紙等の記録媒体に画像を形成する装置ではなく、例えば３次元データを用いて立体像を形成する３次元プリンタでもよい。 For example, in the above-described embodiment, as an example of the terminal 20, an image forming apparatus 20A having a plurality of functions such as printing, copying, faxing, and a scanner is assumed, but a dedicated printing machine or a dedicated scanner may be used. Further, the terminal 20 may be a three-dimensional printer that forms a stereoscopic image using, for example, three-dimensional data, instead of a device that forms an image on a recording medium such as paper as in the image forming apparatus 20A.

また、前述の実施の形態におけるプロセッサは、広義的な意味でのプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ等）の他、専用的なプロセッサ（例えばＧＰＵ、ＡＳＩＣ（＝Application Specific Integrated Circuit）、ＦＰＧＡ、プログラム論理デバイス等）を含む。
また、前述した各実施の形態におけるプロセッサの動作は、１つのプロセッサが単独で実行してもよいが、物理的に離れた位置に存在する複数のプロセッサが協働して実行してもよい。また、プロセッサにおける各動作の実行の順序は、前述した各実施の形態に記載した順序のみに限定されるものでなく、個別に変更してもよい。 Further, the processor in the above-described embodiment refers to a processor in a broad sense, and in addition to a general-purpose processor (for example, CPU), a dedicated processor (for example, GPU, ASIC (= Application Specific Integrated Circuit)). FPGA, program logic device, etc.) is included.
Further, the operation of the processor in each of the above-described embodiments may be executed by one processor alone, or may be executed by a plurality of processors existing at physically separated positions in cooperation with each other. Further, the order of execution of each operation in the processor is not limited to the order described in each of the above-described embodiments, and may be changed individually.

１…クラウドシステム、１０…クラウドネットワーク、２０…端末、２０Ａ…画像形成装置、２０Ｂ…ノート型のコンピュータ、３０…クラウドサーバ、３０Ａ…業務型のクラウドサーバ、３０Ｂ…ストレージ型のクラウドサーバ、４０…中継サーバ、４１…制御ユニット、４１Ａ…ＣＰＵ、４２…記憶装置、４３…入出力ポート、４４…通信装置、４１０…コアサービス、４２０…タスク定義モジュール、４３０…プラグインサービス、４４０…キュー、４５０…リクエスト状態管理部、４６０…ヘルスチェックリクエスト発行部 1 ... cloud system, 10 ... cloud network, 20 ... terminal, 20A ... image forming device, 20B ... notebook computer, 30 ... cloud server, 30A ... business type cloud server, 30B ... storage type cloud server, 40 ... Relay server, 41 ... control unit, 41A ... CPU, 42 ... storage device, 43 ... input / output port, 44 ... communication device, 410 ... core service, 420 ... task definition module, 430 ... plug-in service, 440 ... queue, 450 … Request status management department, 460… Health check request issuing department

Claims

An information processing device that provides a service that relays the use of cloud services by a terminal operated by a user has a processor and has a processor.
The processor
Monitor the processing status of the received request and monitor it.
An information processing device that does not issue a health check request while there is the request whose processing is continuing.

The information processing device according to claim 1, wherein the processor does not issue the health check request until the processing of the request issued by the terminal operated by the user is completed.

The information processing device according to claim 2, wherein the processor permits the issuance of the health check request after all the processes related to the request are completed.

The information processing device according to claim 1, wherein the processor monitors the occurrence of a failure of the cloud service, and does not issue the health check request when the occurrence of the failure is confirmed.

The information processing device according to claim 4, wherein the processor monitors the occurrence of the failure through the log of the plug-in service.

The information processing device according to claim 4, wherein the processor permits the issuance of the health check request when the recovery of the failure is confirmed.

The information processing device according to claim 1, wherein the processor permits the issuance of the health check request when recovery from the failure of the cloud service is confirmed.

The information processing device according to claim 4, wherein the processor notifies the terminal operated by the user of the stop of the cloud service.

The information processing device according to claim 4 or 8, wherein the processor notifies the terminal operated by the user of the restoration of the cloud service.

On the computer
A function to monitor the processing status of received requests and
A program that realizes a function that does not issue a health check request while there is the request whose processing is continuing.