(57)【要約】【課題】複数の処理モジュールを含む機能の処理に係るログの確認に係る手間を軽減させる機能を提供することを目的とする。【解決手段】複数の処理モジュールを含む機能についての一連の処理の開始から終了までに、前記機能に含まれる複数の処理モジュールのそれぞれが出力するログを、出力ログとしてまとめるまとめ手段と、前記まとめ手段によりまとめられた前記出力ログを出力する出力手段と、を有する。【選択図】図８
2017033037.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理モジュールを含む機能についての一連の処理の開始から終了までに、前記機能に含まれる複数の処理モジュールのそれぞれが出力するログを、出力ログとしてまとめるまとめ手段と、
前記まとめ手段によりまとめられた前記出力ログを出力する出力手段と、
を有するサーバー装置。
【請求項２】
前記出力手段は、前記まとめ手段によりまとめられた前記出力ログを、ログ出力設定情報で指定された条件に従って、出力する請求項１記載のサーバー装置。
【請求項３】
前記出力手段は、前記まとめ手段によりまとめられた前記出力ログのうち、エラーに関するログ以外のログを出力し、前記出力ログのうち、前記エラーに関するログを待機記憶領域に記録し、更に、エラーが発生した場合、前記待機記憶領域に記録した前記エラーに関するログを出力する請求項１又は２記載のサーバー装置。
【請求項４】
前記出力手段は、前記機能の処理に係る期間が設定された閾値を超過する場合に、エラーが発生したとして、前記待機記憶領域に記録した前記エラーに関するログを出力する請求項３記載のサーバー装置。
【請求項５】
前記出力手段は、前記機能に含まれる複数の処理モジュールの何れかに例外が発生した場合に、エラーが発生したとして、前記待機記憶領域に記録した前記エラーに関するログを出力する請求項３又は４記載のサーバー装置。
【請求項６】
前記出力手段は、更に、設定されたユーザーがログインした場合、前記待機記憶領域に記録した前記エラーに関するログを出力する請求項３乃至５何れか１項記載のサーバー装置。
【請求項７】
前記出力手段は、更に、前記機能の処理が設定された処理である場合、前記待機記憶領域に記録した前記エラーに関するログを出力する請求項３乃至６何れか１項記載のサーバー装置。
【請求項８】
前記出力手段は、更に、前記機能の処理が設定された順番で実行される場合、前記待機記憶領域に記録した前記エラーに関するログ情報を出力する請求項７記載のサーバー装置。
【請求項９】
前記出力手段は、エラーが発生した場合、前記待機記憶領域に記録した前記エラーに関するログに発生したエラーの情報を付加し、付加したエラーの情報毎に、前記エラーに関するログを出力する請求項３乃至８何れか１項記載のサーバー装置。
【請求項１０】
前記出力手段は、前記待機記憶領域に記録した前記エラーに関する出力ログを、設定されたユーザーにアクセス可能な出力先に出力し、
前記出力手段により出力された前記出力先へのリンク情報を前記設定されたユーザーに通知する通知手段を更に有する請求項３乃至９何れか１項記載のサーバー装置。
【請求項１１】
前記複数の処理モジュールを含む機能は、ＷｅｂＡＰＩである請求項１乃至１０何れか１項記載のサーバー装置。
【請求項１２】
複数の処理モジュールを含む機能についての一連の処理の開始から終了までに、前記機能に含まれる複数の処理モジュールのそれぞれが出力するログを、出力ログとしてまとめるまとめ手段と、
前記まとめ手段によりまとめられた前記出力ログを、ログ出力設定情報で指定された条件に従って、出力する出力手段と、
を有するシステム。
【請求項１３】
サーバー装置が実行する情報処理方法であって、
複数の処理モジュールを含む機能についての一連の処理の開始から終了までに、前記機能に含まれる複数の処理モジュールのそれぞれが出力するログを、出力ログとしてまとめるまとめステップと、
前記まとめステップでまとめられた前記出力ログを、ログ出力設定情報で指定された条件に従って、出力する出力ステップと、
を含む情報処理方法。
【請求項１４】
コンピュータを、請求項１乃至１１何れか１項記載のサーバー装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー装置、システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
Ｗｅｂブラウザーのようなクライアントに対して、ＲＥＳＴ  ＡＰＩ等のＷｅｂＡＰＩを提供するサービスがある。ＲＥＳＴ  ＡＰＩとは、Ｗｅｂシステムを外部から利用するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）で、ＲＥＳＴと呼ばれる設計原則に従って実装されたものである。
サービスが提供するＷｅｂＡＰＩは、一般に、オープンソースソフトウェア（ＯＳＳ）を含む複数の処理モジュール群から構成されるように実装される。また、サービスは、多くのクライアントからの要求（ＷｅｂＡＰＩ呼び出し）を受けて動作するため、各々のＷｅｂＡＰＩに相当する処理モジュール群を、マルチスレッドにより、並行して動作させる。
【０００３】
マルチスレッドによる並行動作を行う各処理モジュールは、パフォーマンス解析、アクセス解析、エラー時のエラー原因調査等のため、ログを出力する。
また、あるユーザーがサービスに対してＷｅｂＡＰＩのコールを行った場合、コールされたＷｅｂＡＰＩの処理開始から終了までの一連の処理毎（処理スレッド毎）に、複数の処理モジュールがコールされることになる。
従来、特許文献１のように、エラー発生時の適切なログ出力を行うロギングシステムが提案されている。特許文献１のロギングシステムは、メソッドの入力値や内部状態によってエラーが発生するような場合においても、適切なログの出力条件を設定して詳細なログを出力することが可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−７５９６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ユーザーは、ＷｅｂＡＰＩ等の複数の処理モジュールを含む機能についての処理開始から終了までの期間を取得する場合、機能の処理開始から終了までの一連の処理（処理スレッド）について、機能の各処理モジュールの出力したログを確認する必要がある。
また、ユーザーは、機能の処理が途中で失敗した場合、エラー解析等のため、機能の複数の処理モジュールについて、各処理モジュールの出力したログを確認する必要がある。
従来、機能の処理モジュールのそれぞれは、個別にログを出力する。そのため、ユーザーは、機能の処理に関するログを確認する場合、処理モジュール毎に個別に出力されたログを一つ一つ確認する必要があり、煩雑な手間を要するという問題があった。また、特許文献１の技術は、適切なログの出力条件を設定する技術であり、この問題を解決するものではなかった。
そこで、本発明は、複数の処理モジュールを含む機能の処理に係るログの確認に係る手間を軽減させる機能を提供することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明のサーバー装置は、複数の処理モジュールを含む機能についての一連の処理の開始から終了までに、前記機能に含まれる複数の処理モジュールのそれぞれが出力するログを、出力ログとしてまとめるまとめ手段と、前記まとめ手段によりまとめられた前記出力ログを出力する出力手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、複数の処理モジュールを含む機能の処理に係るログの確認に係る手間を軽減させる機能を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】ログ出力システムのシステム構成の一例を示す図である。
【図２】クライアントＰＣのハードウェア構成等の一例を示す図である。
【図３】ログ出力システムのシステム構成要素の機能構成の一例を示す図である。
【図４】ＷｅｂＡＰＩサーバーモジュールの処理におけるスレッドモデルの一例を示す図である。
【図５】従来のＷｅｂＡＰＩ処理の概要を示す図である。
【図６】従来のＷｅｂＡＰＩ処理の一例を示すフローチャートである。
【図７】ＭｏｄｕｌｅＡのログ出力処理の一例を示すフローチャートである。
【図８】ＷｅｂＡＰＩ処理の概要を示す図である。
【図９】ＷｅｂＡＰＩ処理の一例を示すフローチャートである。
【図１０】ログ出力処理の一例を示す図である。
【図１１】ＷｅｂＡＰＩの処理の概要を示す図である。
【図１２】ＷｅｂＡＰＩの処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
本実施形態では、インターネット上で帳票データを生成する帳票サービスと、インターネット等のネットワーク上のデータを取得して印刷する印刷サービスと、が図１で後述するＷｅｂＡＰＩサーバー３００に実装されている。ＷｅｂＡＰＩとは、コンピュータプログラムの提供する機能を外部の別のプログラムから呼び出して利用するためのＡＰＩで、ＨＴＴＰ等のＷｅｂの技術を用いて構築されている。ＷｅｂＡＰＩで機能を公開しているサーバーは、インターネット等を通じてＨＴＴＰリクエストが送信されると、処理結果をＨＴＴＰレスポンスとして返信する。送受信されるデータの形式は、ＡＰＩによって様々だが、ＸＭＬ、ＨＴＭＬ、ＪＳＯＮ、各種の画像ファイル形式等が用いられる。
以下では、帳票サービスや印刷サービスのようにインターネット等のネットワーク上で機能を提供しているサービスを、リソースサービスとする。また、本実施形態では、例えばネットワーク上の画像形成装置にインストールされた印刷アプリケーション及び帳票アプリケーション等がリソースサービスを利用する。
以下では、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションとする。リソースサービスは、帳票サービス、印刷サービスには限られない。また、リソースサービス連携アプリケーションは、帳票アプリケーション、印刷アプリケーションに限られない。
本実施形態では、ログ出力システムは、権限の移譲について、ＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報が利用される。
【００１１】
図１は、ログ出力システムのシステム構成の一例を示す図である。
ログ出力システムは、クライアントＰＣ２００、ＷｅｂＡＰＩサーバー３００を含む。ＷＡＮ１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋであり、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は、ＷｅｂＡＰＩサーバー３００が接続されているＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。ＬＡＮ１０２は、クライアントＰＣ２００が接続されているＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。
クライアントＰＣ２００、ＷｅｂＡＰＩサーバー３００は、ＷＡＮ１００とＬＡＮ１０１とＬＡＮ１０２とを介して、相互に接続されている。
【００１２】
クライアントＰＣ２００は、ユーザーによる操作用のＰＣ等の情報処理装置である。クライアントＰＣ２００は、Ｗｅｂブラウザーや、ＷｅｂＡＰＩを呼び出すクライアントアプリケーション等を含む。クライアントＰＣ２００は、クライアントＰＣ２００の入力装置を介したユーザーの操作に基づいて、Ｗｅｂブラウザーやクライアントアプリケーション等を介して、ＷｅｂＡＰＩサーバー３００にアクセスし、ＷｅｂＡＰＩを利用する。ＷｅｂＡＰＩサーバー３００から提供されるＷｅｂＡＰＩには、ＲＥＳＴ（ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ）ＡＰＩ等がある。ＲＥＳＴＡＰＩとは、ＲＥＳＴの設計原則に従って実装されたＡＰＩである。
ＷｅｂＡＰＩサーバー３００は、クライアントＰＣ２００からのＷｅｂＡＰＩのリクエストに応じて、各種サービスを提供するサーバーコンピューター等の情報処理装置である。ＷｅｂＡＰＩサーバー３００が提供するサービスは、例えば、印刷サービスや帳票サービス等である。
クライアントＰＣ２００とＷｅｂＡＰＩサーバー３００とは、それぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよいし、同一の情報処理装置上に構成されていてもよい。
【００１３】
図２は、クライアントＰＣ２００のハードウェア構成の一例を示す図である。
クライアントＰＣ２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、キーボードコントローラ（ＫＢＣ）２０５、ＣＲＴコントローラ（ＣＲＴＣ）２０６、ディスクコントローラ（ＤＫＣ）２０７、ネットワークカード（ＮＣ）２１２を含む。クライアントＰＣ２００のハードウェア構成要素は、システムバス２０４を介して、相互に接続されている。
ＣＰＵ２０１は、クライアントＰＣ２００の処理を制御する中央演算装置である。ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶されたプログラム、又は、外部メモリー２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ＯＳは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳとする。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する記憶装置である。ＲＯＭ２０３は、プログラムや各種設定データ、各種閾値等を記憶する記憶装置である。ＫＢＣ２０５は、キーボード（ＫＢ）２０９やマウス等のポインティングデバイスからの入力を制御するコントローラである。ＣＲＴＣ２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御するコントローラである。
【００１４】
ＤＫＣ２０７は、各種データを記憶するハードディスク（ＨＤ）やフレキシブルディスク等である外部メモリー２１１に対するデータアクセスを制御するコントローラである。クライアントＰＣ２００は、ＮＣ２１２を介して、ネットワークに接続し、ネットワークに接続された他の機器との通信を制御する。
後述の全ての説明において、特に断りのない限り、クライアントＰＣ２００の処理を実行するハードウェア上の主体は、ＣＰＵ２０１である。また、クライアントＰＣ２００の処理を実行するソフトウェア上の主体は、クライアントＰＣ２００に含まれるアプリケーションである。
ＫＢ２０９は、クライアントＰＣへ２００の入力処理に利用されるキーボード等の入力装置である。ＣＲＴ２１０は、クライアントＰＣ２００から出力された映像を表示する為のＣＲＴディスプレイである。外部メモリー２１１は、クライアントＰＣ２００が実行するプログラム、各種設定データ、各種閾値等を記憶する。
ＣＰＵ２０１が、ＲＯＭ２０３のプログラムＲＯＭ又は外部メモリー２１１に記憶されたプログラムに基づき処理を実行することによって、図３（ａ）のクライアントＰＣ２００の機能及びクライアントＰＣ２００の処理が実現される。
【００１５】
ＷｅｂＡＰＩサーバー３００のハードウェア構成は、クライアントＰＣ２００と同様である。
後述の全ての説明において、特に断りのない限り、ＷｅｂＡＰＩサーバー３００の処理を実行するハードウェア上の主体は、ＷｅｂＡＰＩサーバー３００のＣＰＵである。また、ＷｅｂＡＰＩサーバー３００の処理を実行するソフトウェア上の主体は、ＷｅｂＡＰＩサーバー３００に含まれるアプリケーションである。
ＷｅｂＡＰＩサーバー３００のＣＰＵが、ＷｅｂＡＰＩサーバー３００のプログラムＲＯＭ又はＷｅｂＡＰＩサーバー３００の外部メモリーに記憶されたプログラムに基づき処理を実行することによって、以下のようになる。即ち、図３（ｂ）のＷｅｂＡＰＩサーバー３００の機能及び図６、７、９、１０、１２のフローチャートの処理が実現される。
【００１６】
図３は、ログ出力システムのシステム構成要素の機能構成の一例を示す図である。
図３（ａ）は、クライアントＰＣ２００の機能構成の一例を示す図である。
クライアントＰＣ２００は、ＯＳ２２０、Ｗｅｂブラウザー２３０を含む。
ＯＳ２２０は、クライアントＰＣ２００のＯＳであり、リアルタイムＯＳであってもよいし、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳであってもよい。
Ｗｅｂブラウザー２３０は、ＷＷＷを利用するためのユーザーエージェントとして機能する。
【００１７】
図３（ｂ）は、ＷｅｂＡＰＩサーバー３００の機能構成の一例を示す図である。
ＷｅｂＡＰＩサーバー３００は、ＷｅｂＡＰＩサーバーモジュール３１０、ソフトウェアライブラリモジュール３２０、Ｌｏｇｇｅｒ３３０を含む。
ＷｅｂＡＰＩサーバーモジュール３１０は、図８等で後述するＷｅｂＡＰＩフレームワーク、フレームワークログ出力設定情報を含む。
ソフトウェアライブラリモジュール３２０は、ＷｅｂＡＰＩ機能を実現するためのモジュール群である。ソフトウェアライブラリモジュール３２０は、例えば、ＯＡｕｔｈ認証ライブラリ、帳票フォーマット作成ライブラリ、印刷データ変換ライブラリを含む。また、ソフトウェアライブラリモジュール３２０は、図５で後述するＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３を含む。
Ｌｏｇｇｅｒ３３０は、ＷｅｂＡＰＩの一連の処理毎のログを取得する。Ｌｏｇｇｅｒ３３０は、図５で後述するＬｏｇｇｅｒＡ５１１、ＬｏｇｇｅｒＢ５２１、ＬｏｇｇｅｒＣ５３１、図８で後述する共通Ｌｏｇｇｅｒ８０３を含む。
【００１８】
図４は、ＷｅｂＡＰＩサーバーモジュール３１０の処理におけるスレッドモデルの一例を示す図である。
ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｍａｉｎスレッド４１１において、クライアントＰＣ２００からのＨＴＴＰプロトコルによる認証要求、印刷要求といったＷｅｂＡＰＩリクエストを受信し、Ｗｏｒｋｅｒスレッド４１２、４２２、４３２に処理を渡す。
ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｗｏｒｋｅｒスレッド４１２、４２２、４３２において、Ｍａｉｎスレッド４１１からＨＴＴＰプロトコルの処理を渡され、ＨＴＴＰコネクションを管理し、クライアントＰＣ２００からのＨＴＴＰリクエストを受信する。そして、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｗｏｒｋｅｒスレッド４１２、４２２、４３２において、ＨＴＴＰコネクション毎にＰｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３において受信したＨＴＴＰリクエストに対応する処理をそれぞれ依頼する。そして、ＷｅｂＡＰＩサーバー３００のＣＰＵは、処理の依頼と併せて、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３に、処理を渡す。
【００１９】
ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３において、それぞれＷｏｒｋｅｒスレッド４１２、４２２、４３２から受信したクライアントＰＣ２００からのＨＴＴＰリクエストに対応する処理を行う。そして、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３において、それぞれＷｏｒｋｅｒスレッド４１２、４２２、４３２、及び、Ｍａｉｎスレッド４１１を経由して、以下の処理を行う。即ち、ＷｅｂＡＰＩサーバー３００のＣＰＵは、処理の結果をＨＴＴＰレスポンスとしてクライアントＰＣ２００に送信する。
本実施形態では、クライアントＰＣ２００からＷｅｂＡＰＩサーバー３００への一つのＨＴＴＰリクエストは、一つのＷｅｂＡＰＩ呼び出しに対応する。例えば、クライアントＰＣ２００は、クライアント情報取得のためのＷｅｂＡＰＩであるｇｅｔｃｌｉｅｎｔｉｎｆｏの呼び出しとして、以下のＨＴＴＰリクエスト１をＷｅｂＡＰＩサーバー３００に送信する。
（ＨＴＴＰリクエスト１）
ＰＯＳＴ  ／ｉｎｖｏｋｅｒ／ｖ１／ｇｅｔｃｌｉｅｎｔｉｎｆｏ  ＨＴＴＰ／１．１
Ｈｏｓｔ：  ｓｅｒｖｅｒ．ｅｘａｍｐｌｅ．ｃｏｍ
Ａｕｔｈｏｒｉｚａｔｉｏｎ：  Ｂａｓｉｃ  ｃｚＺＣａＧＲＳａ３Ｆ０ＭｚｐｎＷＤＦｍＱｍＦ０Ｍ２ＪＷ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ；ｃｈａｒｓｅｔ＝ＵＴＦ−８
【００２０】
ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｍａｉｎスレッド４１１において、ＨＴＴＰポートを監視し、ＨＴＴＰリクエスト１を受信したらＷｏｒｋｅｒスレッド４１２にＨＴＴＰコネクションと共に処理を渡す。ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｗｏｒｋｅｒスレッド４１２において、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３にＨＴＴＰリクエスト１を渡して処理を渡す。ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、ＨＴＴＰリクエスト１を解釈し、ＨＴＴＰリクエスト１に対応する処理を行い、以下のようなＨＴＴＰレスポンス１を、クライアントＰＣ２００に返す。
（ＨＴＴＰレスポンス１）
ＨＴＴＰ／１．１  ２００  ＯＫ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ；ｃｈａｒｓｅｔ＝ＵＴＦ−８
Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：  ｎｏ−ｓｔｏｒｅ
Ｐｒａｇｍａ：  ｎｏ−ｃａｃｈｅ
｛
"ｄｅｆａｕｌｔ＿ｌａｎｇｕａｇｅ＿ｃｏｄｅ"："ｊａ"，
"ｍｅｔａｄａｔａ＿ｌｉｓｔ"：［
｛
"ｌａｎｇｕａｇｅ＿ｃｏｄｅ"："ｊａ"，
"ｃｌｉｅｎｔ＿ｎａｍｅ"："￥ｕ３０Ｃ６￥ｕ３０Ｂ９￥ｕ３０Ｃ８￥ｕ３０Ｃ７￥ｕ３０ＦＣ￥ｕ３０ＢＦ"，
"ｃｌｉｅｎｔ＿ｄｅｓｃｒｉｐｔｉｏｎ"："￥ｕ３０Ｃ６￥ｕ３０Ｂ９￥ｕ３０Ｃ８￥ｒ￥ｎ￥ｕ３０Ｃ７￥ｕ３０ＦＣ￥ｕ３０ＢＦ"，
"ｉｃｏｎ＿ｉｄ"："００１"
｝，
｛
"ｌａｎｇｕａｇｅ＿ｃｏｄｅ"："ｅｎ"，
"ｃｌｉｅｎｔ＿ｎａｍｅ"："ＹＹＹＹＹＹＹＹＹ"，
"ｃｌｉｅｎｔ＿ｄｅｓｃｒｉｐｔｉｏｎ"："ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ"，
"ｉｃｏｎ＿ｉｄ"："００２"
｝
］，
"ｒｅｄｉｒｅｃｔ＿ｕｒｌ＿ｌｉｓｔ"：  ［"ｈｔｔｐ：／／ｗｗｗ．ＸＸＸＸＸＸＸＸＸ．ｊｐ"，  "ｈｔｔｐ：／／ｗｗｗ．ＹＹＹＹＹＹＹＹＹ．ｊｐ"］
｝
【００２１】
ＨＴＴＰレスポンス１は、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３からＷｏｒｋｅｒスレッド４１２を介してクライアントＰＣ２００に返される。
Ｍａｉｎスレッド４１１、Ｗｏｒｋｅｒスレッド４１２、４２２、４３２、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３は、ＷｅｂＡＰＩサーバーモジュール３１０の起動時に生成される。また、Ｗｏｒｋｅｒスレッド４１２、４２２、４３２やＰｒｏｃｅｓｓｉｎｇスレッド４１３、４２３、４３３は、クライアントＰＣ２００からのアクセス毎にＭａｉｎスレッド４１１により順次生成されることとしてもよい。図４の例では、Ｗｏｒｋｅｒスレッド、Ｐｒｏｃｅｓｓｉｎｇスレッドは、三つとしたが、ＷｅｂＡＰＩサーバー３００のＣＰＵは、は、処理負荷に応じて、Ｗｏｒｋｅｒスレッド、Ｐｒｏｃｅｓｓｉｎｇスレッドの数を動的に変更してもよい。
【００２２】
以下、図５、図６、図７を用いて、従来のＷｅｂＡＰＩの処理について説明する。図５は、従来のＷｅｂ  ＡＰＩ処理の概要を示す図である。ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３は、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３の一連の処理を行う各々独立した異なるソフトウェアモジュールである。ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、ＷｅｂＡＰＩの処理の過程でＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３を順次呼び出し、処理を行う。
図６は、従来のＷｅｂＡＰＩ処理の一例を示すフローチャートである。図５、図６の例では、ＷｅｂＡＰＩサーバー３００のＣＰＵは、ＨＴＴＰリクエスト１に対応する処理をＰｒｏｃｅｓｓｉｎｇスレッド４１３において、実行することとする。
【００２３】
Ｓ６０１において、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、ＨＴＴＰリクエスト１を解釈し、認証ライブラリモジュールをＭｏｄｕｌｅＡ３２１として呼び出し、認証処理を行う。
Ｓ６０２において、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｓ６０１で認証に成功した場合、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、以下の処理を行う。即ち、ＷｅｂＡＰＩサーバー３００のＣＰＵは、ＤＢアクセスモジュールをＭｏｄｕｌｅＢ３２２として呼び出し、認証情報に紐付くクライアント情報を取得する処理を行う。クライアント情報には、言語コード、クライアント名称、クライアント説明、アイコンＩＤ等が含まれる。
Ｓ６０３において、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、データフォーマット整形モジュールをＭｏｄｕｌｅＣ３２３として呼び出すことで、以下の処理を行う。即ち、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｓ６０２で取得したクライアント情報に基づいて、ＨＴＴＰレスポンス１を生成する。そして、ＷｅｂＡＰＩサーバー３００のＣＰＵは、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において、生成したＨＴＴＰレスポンス１をクライアントＰＣ２００に返す。
【００２４】
ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３は、各々異なる独立したソフトウェアライブラリで、各々が独自にログ出力ライブラリ、ログ出力設定情報を持つ。このようなソフトウェア構成は、独自開発のソフトウェアモジュール、第三者から購入されたソフトウェアモジュール、オープンソースのソフトウェアモジュール等が混在して用いられるような場合に起こり得る。
ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３のログ出力ライブラリは、それぞれＬｏｇｇｅｒＡ５１１、ＬｏｇｇｅｒＢ５２１、ＬｏｇｇｅｒＣ５３１である。また、ＬｏｇｇｅｒＡ５１１、ＬｏｇｇｅｒＢ５２１、ＬｏｇｇｅｒＣ５３１のログ出力設定情報は、それぞれＳｅｔｔｉｎｇＡ５１２、ＳｅｔｔｉｎｇＢ５２２、ＳｅｔｔｉｎｇＣ５３２である。ＳｅｔｔｉｎｇＡ５１２、ＳｅｔｔｉｎｇＢ５２２、ＳｅｔｔｉｎｇＣ５３２は、それぞれＬｏｇｇｅｒＡ５１１、ＬｏｇｇｅｒＢ５２１、ＬｏｇｇｅｒＣ５３１によるログの出力処理に対する条件を指定する情報である。
ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３にそれぞれ対応するログ出力モジュールは、ＯｕｔｐｕｔＭｏｄｕｌｅＡ５１３、ＯｕｔｐｕｔＭｏｄｕｌｅＢ５２３、ＯｕｔｐｕｔＭｏｄｕｌｅＣ５３３である。ＯｕｔｐｕｔＭｏｄｕｌｅＡ５１３、ＯｕｔｐｕｔＭｏｄｕｌｅＢ５２３、ＯｕｔｐｕｔＭｏｄｕｌｅＣ５３３は、それぞれＳｅｔｔｉｎｇＡ５１２、ＳｅｔｔｉｎｇＢ５２２、ＳｅｔｔｉｎｇＣ５３２に基づいてログ出力を行う。
【００２５】
ＯｕｔｐｕｔＭｏｄｕｌｅＡ５１３により出力されるログ出力ファイルは、Ｌｏｇ＿ＭｏｄｕｌｅＡ．ｌｏｇ５１４である。ＯｕｔｐｕｔＭｏｄｕｌｅＢ５２３により出力されるログ出力ファイルは、Ｌｏｇ＿ＭｏｄｕｌｅＢ．ｌｏｇ５２４である。ＯｕｔｐｕｔＭｏｄｕｌｅＣ５３３により出力されるログ出力ファイルは、Ｌｏｇ＿ＭｏｄｕｌｅＣ．ｌｏｇ５３４である。
Ｌｏｇ＿ＭｏｄｕｌｅＡ．ｌｏｇ５１４、Ｌｏｇ＿ＭｏｄｕｌｅＢ．ｌｏｇ５２４、Ｌｏｇ＿ＭｏｄｕｌｅＣ．ｌｏｇ５３４は、それぞれ単一のファイルであってもよいし、複数のファイルであってもよい。例えば、ＬｏｇｇｅｒＡ５１１がＬｏｇ４Ｊライブラリ（ＯＳＳ）である場合、ＳｅｔｔｉｎｇＡ５１２は、以下の例のようになる。
（ＳｅｔｔｉｎｇＡ５１２の例）
＃＃＃  ｌｏｇ  ｍｅｓｓａｇｅｓ  ｔｏ  ｓｔｄｏｕｔ  ＃＃＃
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＣｏｎｓｏｌｅＡｐｐｅｎｄｅｒ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ．Ｔａｒｇｅｔ＝Ｓｙｓｔｅｍ．ｏｕｔ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ．ｌａｙｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＰａｔｔｅｒｎＬａｙｏｕｔ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ．ｌａｙｏｕｔ．ＣｏｎｖｅｒｓｉｏｎＰａｔｔｅｒｎ＝  ％−５ｐ  ［％ｔ］：  ％ｍ％ｎ
＃＃＃  ｌｏｇ  ｍｅｓｓａｇｅｓ  ｔｏ  ｆｉｌｅ  Ｌｏｇ＿ＭｏｄｕｌｅＡ．ｌｏｇ  ＃＃＃
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｉｌｅ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＦｉｌｅＡｐｐｅｎｄｅｒ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｉｌｅ．Ｆｉｌｅ＝Ｌｏｇ＿ＭｏｄｕｌｅＡ．ｌｏｇ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｉｌｅ．Ａｐｐｅｎｄ＝ｔｒｕｅ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｉｌｅ．ｌａｙｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＰａｔｔｅｒｎＬａｙｏｕｔ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｉｌｅ．ｌａｙｏｕｔ．ＣｏｎｖｅｒｓｉｏｎＰａｔｔｅｒｎ＝  ％−５ｐ  ［％ｔ］：  ％ｍ％ｎ
ｌｏｇ４ｊ．ｒｏｏｔＬｏｇｇｅｒ＝ｄｅｂｕｇ，  ｓｔｄｏｕｔ，  ｆｉｌｅ
【００２６】
認証ライブラリモジュールであるＭｏｄｕｌｅＡ３２１が上記の例のＳｅｔｔｉｎｇＡ５１２に基づいて出力するログは、以下の例のようになる。
（ＭｏｄｕｌｅＡログ出力例）
ＤＥＢＵＧ  ［ｍａｉｎ］：  Ｍｅｓｓａｇｅ  １
ＷＡＲＮ    ［ｍａｉｎ］：  Ｍｅｓｓａｇｅ  ２
ＯｕｔｐｕｔＭｏｄｕｌｅＡ５１３は、上記のＳｅｔｔｉｎｇＡ５１２の例の設定に基づいて、上記ＭｏｄｕｌｅＡログ出力例を、ＭｏｄｕｌｅＡのプロセスの標準出力と、カレントディレクトリのＬｏｇ＿ＭｏｄｕｌｅＡ．ｌｏｇファイルに出力する。
【００２７】
ＬｏｇｇｅｒＢ５２１がＡｐａｃｈｅ  Ｃｏｍｍｏｎｓ  Ｌｏｇｇｉｎｇライブラリ（ＯＳＳ）である場合、ＳｅｔｔｉｎｇＢ５２２は、以下の例のようになる。
（ＳｅｔｔｉｎｇＢ５２２の例）
ＳｅｔｔｉｎｇＢ５２２は、以下の二つのファイルから構成される。
１．ｃｏｍｍｏｎｓ−ｌｏｇｇｉｎｇ．ｐｒｏｐｅｒｔｉｅｓファイル
ｏｒｇ．ａｐａｃｈｅ．ｃｏｍｍｏｎｓ．ｌｏｇｇｉｎｇ．Ｌｏｇ＝ｏｒｇ．ａｐａｃｈｅ．ｃｏｍｍｏｎｓ．ｌｏｇｇｉｎｇ．ｉｍｐｌ．Ｌｏｇ４ＪＬｏｇｇｅｒ
２．ｌｏｇ４ｊ．ｐｒｏｐｅｒｔｉｅｓファイル
＃  ｉｎｉｔｉａｌｉｚｅ  ｒｏｏｔ  ｌｏｇｇｅｒ  ｗｉｔｈ  ｌｅｖｅｌ  ＥＲＲＯＲ  ｆｏｒ  ｓｔｄｏｕｔ  ａｎｄ  ｆｏｕｔ
ｌｏｇ４ｊ．ｒｏｏｔＬｏｇｇｅｒ＝ＥＲＲＯＲ，ｓｔｄｏｕｔ，ｆｏｕｔ
＃  ｓｅｔ  ｔｈｅ  ｌｏｇ  ｌｅｖｅｌ  ｆｏｒ  ｔｈｅｓｅ  ｃｏｍｐｏｎｅｎｔｓ
ｌｏｇ４ｊ．ｌｏｇｇｅｒ．ｃｏｍ．ｅｎｄｅｃａ＝ＤＥＢＵＧ
ｌｏｇ４ｊ．ｌｏｇｇｅｒ．ｃｏｍ．ｅｎｄｅｃａ．ｅｉｄｉ．ｗｅｂ．ｍｅｔｒｉｃｓ＝ＤＥＢＵＧ
＃  ａｄｄ  ａ  ＣｏｎｓｏｌｅＡｐｐｅｎｄｅｒ  ｔｏ  ｔｈｅ  ｌｏｇｇｅｒ  ｓｔｄｏｕｔ  ｔｏ  ｗｒｉｔｅ  ｔｏ  ｔｈｅ  ｃｏｎｓｏｌｅ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＣｏｎｓｏｌｅＡｐｐｅｎｄｅｒ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ．ｌａｙｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＰａｔｔｅｒｎＬａｙｏｕｔ
＃  ｕｓｅ  ａ  ｓｉｍｐｌｅ  ｍｅｓｓａｇｅ  ｆｏｒｍａｔ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｓｔｄｏｕｔ．ｌａｙｏｕｔ．ＣｏｎｖｅｒｓｉｏｎＰａｔｔｅｒｎ＝％ｄ  ％５ｐ  ％ｃ｛１｝  −  ％ｍ％ｎ
＃  ａｄｄ  ａ  ＦｉｌｅＡｐｐｅｎｄｅｒ  ｔｏ  ｔｈｅ  ｌｏｇｇｅｒ  ｆｏｕｔ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＦｉｌｅＡｐｐｅｎｄｅｒ
＃  ｃｒｅａｔｅ  ａ  ｌｏｇ  ｆｉｌｅ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｏｕｔ．Ｆｉｌｅ＝／ｖａｒ／ｔｍｐ／Ｌｏｇ＿ＭｏｄｕｌｅＢ．ｌｏｇ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｏｕｔ．ｌａｙｏｕｔ＝ｏｒｇ．ａｐａｃｈｅ．ｌｏｇ４ｊ．ＰａｔｔｅｒｎＬａｙｏｕｔ
＃  ｕｓｅ  ａ  ｍｏｒｅ  ｄｅｔａｉｌｅｄ  ｍｅｓｓａｇｅ  ｐａｔｔｅｒｎ
ｌｏｇ４ｊ．ａｐｐｅｎｄｅｒ．ｆｏｕｔ．ｌａｙｏｕｔ．ＣｏｎｖｅｒｓｉｏｎＰａｔｔｅｒｎ＝％ｄ  ％５ｐ  ％ｃ｛１｝  −  ％ｍ％ｎ
【００２８】
ＤＢアクセスライブラリモジュールであるＭｏｄｕｌｅＢ３２２が上記の例のＳｅｔｔｉｎｇＢ５２２に基づいて、出力するログは、例えば以下のようになる。
（ＭｏｄｕｌｅＢログ出力例）
２０１５／０６／０４  ２１：１３：２２  ＦＡＴＡＬ  ＭｏｄｕｌｅＢ  −  ｆａｔａｌ  ｍｅｓｓａｇｅ
２０１５／０６／０４  ２１：１３：２３  ＦＡＴＡＬ  ＭｏｄｕｌｅＢ  −  ｅｒｒｏｒ  ｍｅｓｓａｇｅ
２０１５／０６／０４  ２１：１３：２３  ＷＡＲＮ  ＭｏｄｕｌｅＢ  −  ｗａｒｎ  ｍｅｓｓａｇｅ
２０１５／０６／０４  ２１：１３：２３  ＩＮＦＯ  ＭｏｄｕｌｅＢ  −  ｉｎｆｏ  ｍｅｓｓａｇｅ
ＯｕｔｐｕｔＭｏｄｕｌｅＢ５２３は、上記の例のＳｅｔｔｉｎｇＢ５２２に基づいて、上記ＭｏｄｕｌｅＢログ出力例を、ＭｏｄｕｌｅＢのプロセスの標準出力と、／ｖａｒ／ｔｍｐディレクトリのＬｏｇ＿ＭｏｄｕｌｅＢ．ｌｏｇファイルに出力する。
【００２９】
ＬｏｇｇｅｒＣ５３１がＪａｖａ（登録商標）のライブラリの一つＪａｖａ  Ｕｔｉｌ  Ｌｏｇｇｉｎｇライブラリである場合、ＳｅｔｔｉｎｇＣ５３２は、以下の例のようになる。
（ＳｅｔｔｉｎｇＣ５３２の例）
＃  ｄｅｆａｕｌｔ  ｆｉｌｅ  ｏｕｔｐｕｔ  ｉｓ  ｉｎ  ｕｓｅｒ'ｓ  ｈｏｍｅ  
ｄｉｒｅｃｔｏｒｙ．
ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ．ＦｉｌｅＨａｎｄｌｅｒ．ｐａｔｔｅｒｎ  ＝  Ｌｏｇ＿ＭｏｄｕｌｅＣ．ｌｏｇ
ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ．ＦｉｌｅＨａｎｄｌｅｒ．ｌｉｍｉｔ  ＝  ５００００
ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ．ＦｉｌｅＨａｎｄｌｅｒ．ｃｏｕｎｔ  ＝  １
ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ．ＦｉｌｅＨａｎｄｌｅｒ．ｆｏｒｍａｔｔｅｒ  ＝  ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ．ＸＭＬＦｏｒｍａｔｔｅｒ
【００３０】
データフォーマット整形ライブラリモジュールであるＭｏｄｕｌｅＣ３２３が上記の例のＳｅｔｔｉｎｇＣ５３２に基づいて、出力するログは、例えば以下のようになる。
（ＭｏｄｕｌｅＣログ出力例）
＜ｒｅｃｏｒｄ＞
＜ｄａｔｅ＞２０１５−０６−０４Ｔ０７：１２：１３＜／ｄａｔｅ＞
＜ｍｉｌｌｉｓ＞１３４４６５３３９３３１９＜／ｍｉｌｌｉｓ＞
＜ｓｅｑｕｅｎｃｅ＞８８７＜／ｓｅｑｕｅｎｃｅ＞
＜ｌｏｇｇｅｒ＞ｃｏｍ．ｅｘａｍｐｌｅ．ＬｏｇｇｅｒＣ＜／ｌｏｇｇｅｒ＞
＜ｌｅｖｅｌ＞ＩＮＦＯ＜／ｌｅｖｅｌ＞
＜ｃｌａｓｓ＞ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＣ＜／ｃｌａｓｓ＞
＜ｍｅｔｈｏｄ＞ｍａｉｎ＜／ｍｅｔｈｏｄ＞
＜ｔｈｒｅａｄ＞１＜／ｔｈｒｅａｄ＞
＜ｍｅｓｓａｇｅ＞Ｍｅｓｓａｇｅｓ＜／ｍｅｓｓａｇｅ＞
＜／ｒｅｃｏｒｄ＞
ＯｕｔｐｕｔＭｏｄｕｌｅＣ５３３は、上記の例のＳｅｔｔｉｎｇＣ５３２に基づいて、上記ＭｏｄｕｌｅＣログ出力例を、ＭｏｄｕｌｅＣのプロセスの標準出力に出力する。また、ＯｕｔｐｕｔＭｏｄｕｌｅＣ５３３は、上記ＭｏｄｕｌｅＣログ出力例を、ＭｏｄｕｌｅＣを実行したユーザーのホームディレクトリのＬｏｇ＿ＭｏｄｕｌｅＣ．ｌｏｇファイルに出力する。
【００３１】
図７は、ＭｏｄｕｌｅＡ３２１のログ出力処理の一例を示すフローチャートである。
Ｓ７０１において、ＭｏｄｕｌｅＡ３２１は、ログ出力設定情報であるＳｅｔｔｉｎｇＡ５１２を読み込み、ログ出力オブジェクトであるＬｏｇｇｅｒＡ５１１を生成する。
Ｓ７０２において、ＭｏｄｕｌｅＡ３２１は、各種認証処理を実行する。
Ｓ７０３において、ＭｏｄｕｌｅＡ３２１は、Ｓ７０１で生成したＬｏｇｇｅｒＡ５１１を用いてログ出力を行う。
ＭｏｄｕｌｅＡ３２１のログ出力処理に対応するソースコードは、例えば以下のようになる。
（ソースコードの例）
ｓｔａｔｉｃ  Ｌｏｇｇｅｒ  ｌｏｇ  ＝  Ｌｏｇｇｅｒ．ｇｅｔＬｏｇｇｅｒ（ＭｏｄｕｌｅＡ．ｃｌａｓｓ）；
：
ｌｏｇ．ｄｅｂｕｇ（"Ｍｅｓｓａｇｅ  １"）；
ｌｏｇ．ｗａｒｎ（"Ｍｅｓｓａｇｅ  ２"）；
：
ＭｏｄｕｌｅＡ３２１は、上記の例のソースコードに対応する処理を実行することで、上記ＭｏｄｕｌｅＡログ出力例のログを出力する。ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３は、ＭｏｄｕｌｅＡ３２１と同様の処理でログ出力を行う。
【００３２】
以下、図８、図９、図１０を用いて、本実施形態でのＷｅｂＡＰＩ処理におけるログ出力処理について説明する。
図８は、本実施形態におけるＷｅｂＡＰＩ処理の概要を示す図である。
図８における、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、ＭｏｄｕｌｅＡ３２１、ＬｏｇｇｅｒＡ５１１、ＳｅｔｔｉｎｇＡ５１２、ＭｏｄｕｌｅＢ３２２、ＬｏｇｇｅｒＢ５２１、ＳｅｔｔｉｎｇＢ５２２は、図５と同様である。また、図８における、ＭｏｄｕｌｅＣ３２３、ＬｏｇｇｅｒＣ５３１、ＳｅｔｔｉｎｇＣ５３２についても、図５と同様である。
フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１は、ＨｏｏｋＭｏｄｕｌｅＡ８０４、ＨｏｏｋＭｏｄｕｌｅＢ８０５、ＨｏｏｋＭｏｄｕｌｅＣ８０６から出力されたログを一つのログとして出力する処理に対して条件を指定する共通ログ出力設定情報である。ＡＰＩフレームワーク８０２は、ＷｅｂＡＰＩサーバーモジュール３１０に含まれるフレームワークであり、本実施形態のＷｅｂＡＰＩ処理を行う。共通Ｌｏｇｇｅｒ８０３は、ＨｏｏｋＭｏｄｕｌｅＡ８０４、ＨｏｏｋＭｏｄｕｌｅＢ８０５、ＨｏｏｋＭｏｄｕｌｅＣ８０６が取得したログを一つの出力ログとして出力するログ出力ライブラリである。
ＨｏｏｋＭｏｄｕｌｅＡ８０４は、ＭｏｄｕｌｅＡ３２１からのログを、共通Ｌｏｇｇｅｒ８０３に送信するログ出力ブリッジライブラリである。ＨｏｏｋＭｏｄｕｌｅＢ８０５は、ＭｏｄｕｌｅＢ３２２からのログを、共通Ｌｏｇｇｅｒ８０３に送信するログ出力ブリッジライブラリである。ＨｏｏｋＭｏｄｕｌｅＣ８０６は、ＭｏｄｕｌｅＣ３２３からのログを、共通Ｌｏｇｇｅｒ８０３に送信するログ出力ブリッジライブラリである。ログ出力ファイル８０７は、共通Ｌｏｇｇｅｒ８０３が出力するログ情報を記録するファイルである。
【００３３】
図９は、本実施形態におけるＷｅｂＡＰＩ処理の一例を示すフローチャートである。
Ｓ９０１において、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３の共通ログ出力設定情報であるフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１を読み込む。
Ｓ９０２において、ＡＰＩフレームワーク８０２は、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３の開始時刻であるＷｅｂＡＰＩ処理開始時刻を、ＷｅｂＡＰＩサーバー３００のＲＡＭ、ＲＯＭ等に記録する。
Ｓ９０３において、ＡＰＩフレームワーク８０２は、図６と同様のＷｅｂＡＰＩ処理を行う。
【００３４】
Ｓ９０４において、ＡＰＩフレームワーク８０２は、ＨｏｏｋＭｏｄｕｌｅＡ８０４、ＨｏｏｋＭｏｄｕｌｅＢ８０５、ＨｏｏｋＭｏｄｕｌｅＣ８０６からログを取得する。そして、ＡＰＩフレームワーク８０２は、フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、取得したログをＡＰＩフレームワーク８０２の共通ログとして出力する。Ｓ９０４の処理の詳細は、図１０で後述する。
Ｓ９０５において、ＡＰＩフレームワーク８０２は、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３において行われた一連のＡＰＩ処理の終了時刻であるＷｅｂＡＰＩ処理終了時刻を、ＷｅｂＡＰＩサーバー３００のＲＡＭ、ＲＯＭ等に記録する。
【００３５】
図１０は、ログ出力処理の一例を示すフローチャートである。図１０は、Ｓ９０４の処理の詳細を示す。
Ｓ１００１において、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＡ３２１のログ出力を取り込む。より具体的には、ＡＰＩフレームワーク８０２は、ＨｏｏｋＭｏｄｕｌｅＡ８０４であるｌｏｇ４ｊ−ｏｖｅｒ−ｓｌｆ４ｊ．ＸＸＸ．ｊａｒ（ＯＳＳ）（ｌｏｇ４ｊ  →  ｓｌｆ４ｊに処理を移譲するライブラリ）を用い、以下の処理を行う。即ち、ＡＰＩフレームワーク８０２は、ＬｏｇｇｅｒＡ５１１（Ｌｏｇ４Ｊ（ＯＳＳ））の出力を、共通のＬｏｇｇｅｒ（ＳＬＦ４Ｊ（ＯＳＳ））に移譲することによってログ出力を共通Ｌｏｇｇｅｒ８０３に取り込む。
【００３６】
Ｓ１００２において、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＢ３２２のログ出力を取り込む。より具体的には、ＡＰＩフレームワーク８０２は、ＨｏｏｋＭｏｄｕｌｅＢ８０５であるｊｃｌ−ｏｖｅｒ−ｓｌｆ４ｊ．ＸＸＸ．ｊａｒ（ＯＳＳ）（ｃｏｍｍｏｎｓ−ｌｏｇｇｉｎｇ  →  ｓｌｆ４ｊに処理を移譲するライブラリ）を用い、以下の処理を行う。ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＢ３２２の使用するロガー（Ａｐａｃｈｅ  Ｃｏｍｍｏｎｓ  Ｌｏｇｇｉｎｇ（ＯＳＳ））の出力を共通のロガー（ＳＬＦ４Ｊ（ＯＳＳ））に移譲することによってログ出力を共通Ｌｏｇｇｅｒ８０３に取り込む。
Ｓ１００３において、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＣ３２３のログ出力を取り込む。より具体的には、ＡＰＩフレームワーク８０２は、ＨｏｏｋＭｏｄｕｌｅＣ８０６であるｊｕｌ−ｔｏ−ｓｌｆ４ｊ．ＸＸＸ．ｊａｒ（ＯＳＳ）（ｊａｖａ．ｕｔｉｌ．ｌｏｇｇｉｎｇ  →  ｓｌｆ４ｊに処理を移譲するライブラリ）を用い、以下の処理を行う。ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＣ３２３の使用するロガー（Ｊａｖａ  Ｕｔｉｌ  Ｌｏｇｇｉｎｇ）の出力を共通のロガー（ＳＬＦ４Ｊ（ＯＳＳ））に移譲することによってログ出力を共通Ｌｏｇｇｅｒ８０３に取り込む。
【００３７】
本実施形態では、共通Ｌｏｇｇｅｒ８０３は、ＳＬＦ４Ｊ（ＯＳＳ）とｌｏｇｂａｃｋ（ＯＳＳ）とから構成されるＬｏｇｇｅｒで、以下の例のようなフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、ログ出力ファイル８０７に対してログ出力を行う。
（フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１の例）
＜ｃｏｎｆｉｇｕｒａｔｉｏｎ＞
＜ａｐｐｅｎｄｅｒ  ｎａｍｅ＝"ＣＯＭＭＯＮＬＯＧＦＩＬＥ"  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｏｒｅ．ｒｏｌｌｉｎｇ．ＲｏｌｌｉｎｇＦｉｌｅＡｐｐｅｎｄｅｒ"＞
＜ｆｉｌｅ＞Ｌｏｇ＿Ｍｏｄｕｌｅｓ＿％ｄ｛ｙｙｙｙ−ＭＭ−ｄｄ｝．ｌｏｇ＜／ｆｉｌｅ＞
＜ｅｎｃｏｄｅｒ＞
＜ｐａｔｔｅｒｎ＞％ｄ｛ｙｙｙｙ／ＭＭ／ｄｄ  ＨＨ：ｍｍ：ｓｓ．ＳＳＳ｝  ％Ｘ｛ｃｏｍｍｏｎｌｏｇｌｅｖｅｌ  ｝［％ｔｈｒｅａｄ］  ％ｌｏｇｇｅｒ｛１０｝  −  ％ｍｓｇ％ｎ＜／ｐａｔｔｅｒｎ＞
＜／ｅｎｃｏｄｅｒ＞
＜／ａｐｐｅｎｄｅｒ＞
＜ａｐｐｅｎｄｅｒ  ｎａｍｅ＝"ＳＴＤＯＵＴ"  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｏｒｅ．ＣｏｎｓｏｌｅＡｐｐｅｎｄｅｒ"＞
＜ｅｎｃｏｄｅｒ＞
＜ｐａｔｔｅｒｎ＞％ｄ｛ｙｙｙｙ／ＭＭ／ｄｄ  ＨＨ：ｍｍ：ｓｓ．ＳＳＳ｝  ％Ｘ｛ｃｏｍｍｏｎｌｏｇｌｅｖｅｌ  ｝［％ｔｈｒｅａｄ］  ％ｌｏｇｇｅｒ｛１０｝  −  ％ｍｓｇ％ｎ＜／ｐａｔｔｅｒｎ＞
＜／ｅｎｃｏｄｅｒ＞
＜／ａｐｐｅｎｄｅｒ＞
＜ｒｏｏｔ  ｌｅｖｅｌ＝"ｄｅｂｕｇ"＞
＜ａｐｐｅｎｄｅｒ−ｒｅｆ  ｒｅｆ＝"ＣＯＭＭＯＮＬＯＧＦＩＬＥ"  ／＞
＜ａｐｐｅｎｄｅｒ−ｒｅｆ  ｒｅｆ＝"ＳＴＤＯＵＴ"  ／＞
＜／ｒｏｏｔ＞
＜／ｃｏｎｆｉｇｕｒａｔｉｏｎ＞
【００３８】
従来、複数の処理モジュールから構成されるＷｅｂＡＰＩの処理において、ＷｅｂＡＰＩに含まれる各処理モジュールは、それぞれ独自の形式でログを出力する。
ＷｅｂブラウザーのようなクライアントにＷｅｂＡＰＩを提供するサービスにおいて、ＷｅｂＡＰＩの内部の処理モジュールとして、ＯＳＳの処理モジュールや第三者が作成した処理モジュールが利用される場合がある。その場合、ＷｅｂＡＰＩの内部の処理モジュールは、ＡＰＩ  Ｆｒａｍｅｗｏｒｋ  のログ出力ポリシー（経過時間、他Ｍｏｄｕｌｅの例外等）に従わず、独自のログ出力形式のログを出力することがある。
共通Ｌｏｇｇｅｒ８０３は、フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、ログ出力ファイル８０７に対してログ出力を行うことで、以下のような効果を奏することができる。即ち、共通Ｌｏｇｇｅｒ８０３は、ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３からそれぞれ独自の出力設定で出力されたログを同一の出力設定で出力することができる。ログの出力設定には、ログ出力レベル設定、ファイルシステム、電子メール等へのログ出力先の設定、プレーンテキスト、ＨＴＭＬ、ＪＳＯＮ等のログ出力形式設定、サイズや日時等のログローテーション規則設定等がある。
【００３９】
Ｓ１００４において、共通Ｌｏｇｇｅｒ８０３は、上記の例のフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、Ｓ１００１〜Ｓ１００３で取り込んだログのログ出力レベルを設定する。
Ｓ１００５において、共通Ｌｏｇｇｅｒ８０３は、以下の例のようなログを、ログ出力ファイル８０７に出力する。ログ出力ファイル８０７は、一つのファイルであってもよいし、設定された数（例えば二つ）のファイルであってもよい。
（ログ出力例）
２０１５／０６／０５  ０１：０３：３２．４６０  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＡ  −    Ｍｅｓｓａｇｅ  １
２０１５／０６／０５  ０１：０３：３２．４７３  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＡ  −    Ｍｅｓｓａｇｅ  ２
２０１５／０６／０５  ０１：０３：３２．４７９  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＢ  −    ｆａｔａｌ  ｍｅｓｓａｇｅ
２０１５／０６／０５  ０１：０３：３２．４８０  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＢ  −    ｅｒｒｏｒ  ｍｅｓｓａｇｅ
２０１５／０６／０５  ０１：０３：３２．４８１  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＢ  −    ｗａｒｎ  ｍｅｓｓａｇｅ
２０１５／０６／０５  ０１：０３：３２．４８９  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＢ  −    ｉｎｆｏ  ｍｅｓｓａｇｅ
２０１５／０６／０５  ０１：０３：３２．４９１  ＤＥＢＵＧ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＣ  −    Ｍｅｓｓａｇｅｓ
本実施形態では、共通Ｌｏｇｇｅｒ８０３は、上記の例のようなログを、出力ログとして、ファイルに出力することとしたが、上記の例のようなログをコンソールに出力してもよいし、メール等でネットワークに出力することとしてもよい。
【００４０】
以上、本実施形態の処理により、ＷｅｂＡＰＩサーバー３００は、それぞれ独自のログ出力を行うＷｅｂＡＰＩに含まれる複数の処理モジュールが出力するログを、同一の出力設定で、まとめてログ出力ファイルに出力することができる。それにより、ユーザーは、出力されたログ出力ファイルの内容を確認すればよく、ＷｅｂＡＰＩの処理モジュールそれぞれの出力ログを確認する必要がなくなる。即ち、ＷｅｂＡＰＩサーバー３００は、ユーザーによるＷｅｂＡＰＩのログの確認に係る手間を軽減させることができる。
また、ユーザーには、ＷｅｂＡＰＩの処理開始から終了までの処理時間を知りたい場合やＷｅｂＡＰＩの処理が途中で失敗した際に複数の処理モジュールの一連の処理のどこまで成功してどこで失敗したかを知りたい場合がある。しかし、従来、ＷｅｂＡＰＩに含まれる処理モジュールは、処理に失敗した場合のみ、ＯｕｔｐｕｔＭｏｄｕｌｅを介して、ログを出力することがある。その場合、ユーザーは、ＷｅｂＡＰＩの処理モジュールを得ることができなかった。そこで、本実施形態の処理により、ユーザーは、ＷｅｂＡＰＩの何れかの処理モジュールの処理が失敗した場合でも、ＷｅｂＡＰＩの全ての処理モジュールのログを取得することができる。
また、ＷｅｂＡＰＩサーバー３００は、複数のＷｅｂＡＰＩを並行して動作させることもできる。その場合、従来では、動作中の各ＷｅｂＡＰＩに含まれる処理モジュールは、それぞれ独自のログを出力する。そのため、ユーザーは、ログの確認に更に煩雑な手間を要することとなる。本実施形態の処理により、ＷｅｂＡＰＩサーバー３００は、並行して動作しているＷｅｂＡＰＩのそれぞれについて、内部の処理モジュールのログをＷｅｂＡＰＩ毎にまとめて出力することができる。それにより、ユーザーは、複数のＷｅｂＡＰＩが並行して動作している場合でも、それぞれのＷｅｂＡＰＩのログの確認に係る手間を軽減することができる。
【００４１】
＜実施形態２＞
実施形態１では、ＷｅｂＡＰＩサーバー３００は、ＷｅｂＡＰＩの処理開始から終了までの一連の処理毎（処理スレッド毎）の処理モジュールのログ出力について、処理スレッド単位で、まとめてログ出力することとした。しかし、ＷｅｂＡＰＩサーバー３００は、エラーや処理遅延の発生を想定して、複数モジュールから構成されるＷｅｂ  ＡＰＩ処理のログとして、エラーや処理時間遅延が発生していない場合にも確認を要するログの数よりも多くのログを出力する可能性がある。
エラー等が発生していない場合には確認を要せず、エラー等が発生した場合に確認を要するログには、例えば、各処理メソッドの引数や戻り値のパラメーター、ＤＢ問合せのためのＳＱＬ式、ＤＢ問い合わせの結果等のログがある。これらのログは、エラー発生時やＷｅｂＡＰＩ処理遅延時には必要となるが、通常処理時には、ログ出力の必要がない。エラーが発生した場合にのみ確認を要するログが全て出力されることで出力されるログの総量が増大する。出力されるログ量の増大は、保存領域の圧迫、ログ検索時の手間の増加等の、システムの運用、メンテナンスへの負の影響となる。エラー等が発生していない場合には確認を要せず、エラー等が発生した場合に確認を要するログは、以下では、異常系ログとする。通常の処理に関わるログのようにエラー等が発生していない場合にも確認を要するログは、以下では、通常系ログとする。異常系ログは、エラーに関するログの一例である。
そこで、本実施形態では、ログ量の増大に対応し、かつエラー発生時やＷｅｂＡＰＩ処理遅延時には必要となるログを出力可能な方法を説明する。
本実施形態のログ出力システムのシステム構成は、実施形態１と同様である。本実施形態のクライアントＰＣ２００のハードウェア構成、機能構成は、実施形態１と同様である。本実施形態のＷｅｂＡＰＩサーバー３００のハードウェア構成、機能構成は、実施形態１と同様である。
【００４２】
図１１は、本実施形態のＷｅｂＡＰＩ処理の概要を示す図である。
図１１の、Ｐｒｏｃｅｓｓｉｎｇスレッド４１３、ＭｏｄｕｌｅＡ３２１、ＬｏｇｇｅｒＡ５１１、ＳｅｔｔｉｎｇＡ５１２、ＨｏｏｋＭｏｄｕｌｅＡ８０４は、図８と同様である。また、図１１の、ＭｏｄｕｌｅＢ３２２、ＬｏｇｇｅｒＢ５２１、ＳｅｔｔｉｎｇＢ５２２、ＨｏｏｋＭｏｄｕｌｅＢ８０５、ＭｏｄｕｌｅＣ３２３、ＬｏｇｇｅｒＣ５３１、ＳｅｔｔｉｎｇＣ５３２、ＨｏｏｋＭｏｄｕｌｅＣ８０６も、図８と同様である。更に、図１１のフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１、ＡＰＩフレームワーク８０２も、図８と同様である。
【００４３】
図１２は、本実施形態におけるＷｅｂＡＰＩ処理の一例を示すフローチャートである。
Ｓ１２０１、Ｓ１２０２、Ｓ１２０４の処理は、それぞれＳ９０１、Ｓ９０２、Ｓ９０５と同様である。
Ｓ１２０３において、ＡＰＩフレームワーク８０２は、図６のＷｅｂＡＰＩ処理を行う。実施形態１と異なり、本実施形態において、Ｓ１２０３のＷｅｂＡＰＩ処理中での、異常系ログの出力処理に対応するソースコードは、例えば、以下の例のようになる。
（異常系ログ出力処理のソースコード例）
ｓｔａｔｉｃ  Ｌｏｇｇｅｒ  ｌｏｇ  ＝  Ｌｏｇｇｅｒ．ｇｅｔＬｏｇｇｅｒ（ＭｏｄｕｌｅＡ．ｃｌａｓｓ）；
ｔｒｙ  ｛
；
／／  Ｓｏｍｅ  ｐｒｏｃｅｓｓｉｎｇ…
：
｝  ｃａｔｃｈ（Ｅｘｃｅｐｔｉｏｎ）  ｛
ｌｏｇ．ｉｎｃｉｄｅｎｔ（"Ａｎ  Ｕｎｅｘｐｅｃｔｅｄ  ｅｘｃｅｐｔｉｏｎ  ｈａｓ  ｏｃｃｕｒｒｅｄ．"）；
｝
上記の例のソースコード中の、ｌｏｇ．ｉｎｃｉｄｅｎｔ（"Ａｎ  Ｕｎｅｘｐｅｃｔｅｄ  ｅｘｃｅｐｔｉｏｎ  ｈａｓ  ｏｃｃｕｒｒｅｄ"）に対応する異常系ログ出力処理は、通常のログ出力処理と異なり、以下のようになる。即ち、異常系ログ出力処理は、ＡＰＩフレームワーク８０２がメモリー１１０１上の文字列バッファに、異常系ログを記録する処理である。メモリー１１０１上の文字列バッファは、異常系ログの待機記憶領域の一例である。
Ｓ１２０３のＷｅｂＡＰＩ処理中における異常系ログ出力処理は、上記のようにＡＰＩフレームワーク８０２のメモリー１１０１上の文字列バッファに出力することを表す。メモリー１１０１上の文字列バッファは、例外やＷｅｂＡＰＩ処理時間超過がＡＰＩフレームワーク８０２により検出されなければ、ファイル出力されずに、Ｓ１２０７で消去される。
【００４４】
Ｓ１２０５において、ＡＰＩフレームワーク８０２は、Ｓ１２０３のＷｅｂＡＰＩ処理にて例外が発生したか否かを判定する。本実施形態では、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＡ３２１、ＭｏｄｕｌｅＢ３２２、ＭｏｄｕｌｅＣ３２３、から出力されたログに基づいて、例外が発生したか否かを判定する。例えば、ＡＰＩフレームワーク８０２は、ＭｏｄｕｌｅＡ３２１から例外の発生を示すログを取得した場合、Ｓ１２０３のＷｅｂＡＰＩ処理において例外が発生したと判定する。
ＡＰＩフレームワーク８０２は、Ｓ１２０３のＷｅｂＡＰＩ処理にて例外が発生したと判定した場合、Ｓ１２０９の処理に進み、Ｓ１２０３のＷｅｂＡＰＩ処理にて例外が発生し邸内と判定した場合、Ｓ１２０６の処理に進む。
【００４５】
Ｓ１２０６において、ＡＰＩフレームワーク８０２は、Ｓ１２０２で記録したＷｅｂＡＰＩ処理開始時刻と、Ｓ１２０４で記録したＷｅｂＡＰＩ処理終了時刻と、からＷｅｂＡＰＩの処理に要した期間を取得する。例えば、ＡＰＩフレームワーク８０２は、Ｓ１２０２で記録したＷｅｂＡＰＩ処理開始時刻と、Ｓ１２０４で記録したＷｅｂＡＰＩ処理終了時刻と、の間の期間をＷｅｂＡＰＩの処理に要した期間として取得する。そして、ＡＰＩフレームワーク８０２は、取得した期間が設定された閾値を超過したか否かを判定する。ＡＰＩフレームワーク８０２は、取得した期間が設定された閾値を超過したと判定した場合、Ｓ１２０９の処理に進み、取得した期間が設定された閾値を超過していないと判定した場合、Ｓ１２０７の処理に進む。
Ｓ１２０７において、ＡＰＩフレームワーク８０２は、Ｓ１２０３でメモリー１１０１上の文字列バッファに記録された異常系ログを消去する。
Ｓ１２０８において、ＡＰＩフレームワーク８０２は、パフォーマンス監視用のログ等異常系ログ以外のログ（通常系ログ）を、実施形態１と同様に、ログ出力ファイル８０７に対して出力する。
Ｓ１２０９において、共通Ｌｏｇｇｅｒ８０３は、異常系ログを出力する。即ち、共通Ｌｏｇｇｅｒ８０３は、フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、Ｓ１２０３でメモリー１１０１上の文字列バッファに記録した異常系ログをまとめて一つの異常系ログファイル１１０２に出力する。共通Ｌｏｇｇｅｒ８０３は、Ｓ１２０９の処理を終了後、Ｓ１２０７の処理に進む。本実施形態では、共通Ｌｏｇｇｅｒ８０３は、上記の例のようなログを、ファイルに出力することとしたが、異常系ログをコンソールに出力してもよいし、メール等でネットワークに出力することとしてもよい。
【００４６】
本実施形態では、共通Ｌｏｇｇｅｒ８０３は、例外発生した場合及びＷｅｂＡＰＩ処理時間超過した場合に、Ｓ１２０９で異常系ログをファイル出力している。しかし、共通Ｌｏｇｇｅｒ８０３は、特定のイベント、例えば管理者ユーザー等特定のユーザーのログインが発生した場合に、異常系ログをファイル出力してもよい。それにより、異常系ログを確認する必要のあるユーザーは、ログイン後、すぐに異常系ログにアクセスすることができる。
共通Ｌｏｇｇｅｒ８０３は、特定のＷｅｂＡＰＩが呼ばれた場合、異常系ログをファイル出力してもよい。また、共通Ｌｏｇｇｅｒ８０３は、特定の順番でＷｅｂＡＰＩが呼ばれた場合、異常系ログをファイル出力してもよい。それにより、共通Ｌｏｇｇｅｒ８０３は、解析を要する特定のＡＰＩについての異常系ログを、ユーザーに手間をかけさせることなく、ユーザーに提供できる。
共通Ｌｏｇｇｅｒ８０３は、フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、Ｓ１２０３でメモリー１１０１上の文字列バッファに記録した異常系ログを、設定されたユーザーによってアクセス可能な異常系ログファイル１１０２に出力してもよい。そして、共通Ｌｏｇｇｅｒ８０３は、異常系ログファイル１１０２へのリンク情報を、ログ監視システムのインシデント通知等として、設定されたユーザーに通知することとしてもよい。それにより、ユーザーは、エラー等が発生した場合、より容易に異常系ログを確認することができるようになる。
【００４７】
共通Ｌｏｇｇｅｒ８０３は、ＡＰＩの処理期間について処理期間の上限を示す設定された閾値に基づいて、ＡＰＩの処理機関が閾値を超えた場合、処理遅延が発生したとみなす。そして、共通Ｌｏｇｇｅｒ８０３は、処理遅延が発生した場合、メモリー１１０１に出力していた異常系ログを、まとめて一つの異常系ログファイル１１０２に出力する。
また、共通Ｌｏｇｇｅｒ８０３は、複数モジュールに跨るＷｅｂＡＰＩ処理において、何れかのモジュールにおいて例外の発生を検知した場合、エラーが発生したとみなす。そして、共通Ｌｏｇｇｅｒ８０３は、例外の発生を検知した場合、メモリー１１０１に記録していた異常系ログを、まとめて一つの異常系ログファイル１１０２に出力する。共通Ｌｏｇｇｅｒ８０３は、メモリー１１０１に記録していた異常系ログを、設定された数（例えば二つ）の異常系ログファイル１１０２に出力することとしてもよい。
【００４８】
共通Ｌｏｇｇｅｒ８０３は、メモリー１１０１に記録されている異常系ログを、以下の例のようなフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、異常系ログファイル１１０２に出力する。
（フレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１の例）
＜ｃｏｎｆｉｇｕｒａｔｉｏｎ＞
＜ａｐｐｅｎｄｅｒ  ｎａｍｅ＝"ＩＮＣＩＤＥＮＴＬＯＧＦＩＬＥ"  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｏｒｅ．ＦｉｌｅＡｐｐｅｎｄｅｒ"＞
＜ｆｉｌｅ＞Ｌｏｇ＿Ｉｎｃｉｄｅｎｔ．ｌｏｇ＜／ｆｉｌｅ＞
＜ｆｉｌｔｅｒ  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｌａｓｓｉｃ．ｆｉｌｔｅｒ．ＬｅｖｅｌＦｉｌｔｅｒ"＞
＜ｌｅｖｅｌ＞ＥＲＲＯＲ＜／ｌｅｖｅｌ＞
＜ｏｎＭａｔｃｈ＞ＡＣＣＥＰＴ＜／ｏｎＭａｔｃｈ＞
＜ｏｎＭｉｓｍａｔｃｈ＞ＤＥＮＹ＜／ｏｎＭｉｓｍａｔｃｈ＞
＜／ｆｉｌｔｅｒ＞
＜ｅｎｃｏｄｅｒ＞
＜ｐａｔｔｅｒｎ＞％ｄ｛ｙｙｙｙ／ＭＭ／ｄｄ  ＨＨ：ｍｍ：ｓｓ．ＳＳＳ｝  ％Ｘ｛ｃｏｍｍｏｎｌｏｇｌｅｖｅｌ  ｝［％ｔｈｒｅａｄ］  ％ｌｏｇｇｅｒ｛１０｝  −  ％ｍｓｇ％ｎ＜／ｐａｔｔｅｒｎ＞
＜／ｅｎｃｏｄｅｒ＞
＜／ａｐｐｅｎｄｅｒ＞
＜ａｐｐｅｎｄｅｒ  ｎａｍｅ＝"ＣＯＭＭＯＮＬＯＧＦＩＬＥ"  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｏｒｅ．ｒｏｌｌｉｎｇ．ＲｏｌｌｉｎｇＦｉｌｅＡｐｐｅｎｄｅｒ"＞
＜ｆｉｌｅ＞Ｌｏｇ＿Ｍｏｄｕｌｅｓ＿％ｄ｛ｙｙｙｙ−ＭＭ−ｄｄ｝．ｌｏｇ＜／ｆｉｌｅ＞
＜ｅｎｃｏｄｅｒ＞
＜ｐａｔｔｅｒｎ＞％ｄ｛ｙｙｙｙ／ＭＭ／ｄｄ  ＨＨ：ｍｍ：ｓｓ．ＳＳＳ｝  ％Ｘ｛ｃｏｍｍｏｎｌｏｇｌｅｖｅｌ  ｝［％ｔｈｒｅａｄ］  ％ｌｏｇｇｅｒ｛１０｝  −  ％ｍｓｇ％ｎ＜／ｐａｔｔｅｒｎ＞
＜／ｅｎｃｏｄｅｒ＞
＜／ａｐｐｅｎｄｅｒ＞
＜ａｐｐｅｎｄｅｒ  ｎａｍｅ＝"ＳＴＤＯＵＴ"  ｃｌａｓｓ＝"ｃｈ．ｑｏｓ．ｌｏｇｂａｃｋ．ｃｏｒｅ．ＣｏｎｓｏｌｅＡｐｐｅｎｄｅｒ"＞
＜ｅｎｃｏｄｅｒ＞
＜ｐａｔｔｅｒｎ＞％ｄ｛ｙｙｙｙ／ＭＭ／ｄｄ  ＨＨ：ｍｍ：ｓｓ．ＳＳＳ｝  ％Ｘ｛ｃｏｍｍｏｎｌｏｇｌｅｖｅｌ  ｝［％ｔｈｒｅａｄ］  ％ｌｏｇｇｅｒ｛１０｝  −  ％ｍｓｇ％ｎ＜／ｐａｔｔｅｒｎ＞
＜／ｅｎｃｏｄｅｒ＞
＜／ａｐｐｅｎｄｅｒ＞
＜ｒｏｏｔ  ｌｅｖｅｌ＝"ｄｅｂｕｇ"＞
＜ａｐｐｅｎｄｅｒ−ｒｅｆ  ｒｅｆ＝"ＩＮＣＩＤＥＮＴＬＯＧＦＩＬＥ"  ／＞
＜ａｐｐｅｎｄｅｒ−ｒｅｆ  ｒｅｆ＝"ＣＯＭＭＯＮＬＯＧＦＩＬＥ"  ／＞
＜ａｐｐｅｎｄｅｒ−ｒｅｆ  ｒｅｆ＝"ＳＴＤＯＵＴ"  ／＞
＜／ｒｏｏｔ＞
＜／ｃｏｎｆｉｇｕｒａｔｉｏｎ＞
共通Ｌｏｇｇｅｒ８０３は、Ｓ１２０９で、上記の例のフレームワークＬｏｇＳｅｔｔｉｎｇｓ８０１に基づいて、ログ出力レベルをＥＲＲＯＲに設定して、以下の例のようなログを出力する。
（異常系ログ出力例）
２０１５／０６／０５  ０１：０３：３２．４６０  ＥＲＲＯＲ  ［ｍａｉｎ］  ｃｏｍ．ｅｘａｍｐｌｅ．ＭｏｄｕｌｅＡ  −    Ａｎ  Ｕｎｅｘｐｅｃｔｅｄ  ｅｘｃｅｐｔｉｏｎ  ｈａｓ  ｏｃｃｕｒｒｅｄ．
【００４９】
ＡＰＩフレームワーク８０２は、エラー等が発生した場合、メモリー１１０１に記録された異常系ログに、発生したエラー等の要因の情報を付加してもよい。そして、共通Ｌｏｇｇｅｒ８０３は、メモリー１１０１に記録された異常系ログを、発生したエラー等の要因に応じたファイルに出力することとしてもよい。
それにより、ＡＰＩフレームワーク８０２は、異常系ログを、発生したエラー等の要因の情報毎にまとめることができる。そして、ユーザーは、発生したエラー等毎に、ログを確認することが容易になる。
【００５０】
以上、本実施形態の処理では、ＡＰＩフレームワーク８０２は、ＷｅｂＡＰＩ処理等の一連の処理について、エラー等が発生していない場合、複数モジュールに跨る異常系のログを一つにまとめてメモリー１１０１に出力する。そして、共通Ｌｏｇｇｅｒ８０３は、エラー等が発生した場合、メモリー１１０１に記録していた異常系ログを、まとめて一つの異常系ログファイル１１０２に出力する。
本実施形態の処理により、ＷｅｂＡＰＩサーバー３００は、出力されるログ量の増大による、保存領域の圧迫、ログ検索時の手間の増加等の、システムの運用、メンテナンスへの負の影響を軽減することができる。また、ＡＰＩフレームワーク８０２は、ログファイルを個別に分けず一連の処理毎にまとめて出力することで、エラーが発生した際等において、ユーザーによる異常系ログの確認の手間を軽減できる。
【００５１】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００５２】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではない。
例えば、上述したＷｅｂＡＰＩサーバー３００の機能構成の一部又は全てをハードウェアとしてＷｅｂＡＰＩサーバー３００に実装してもよい。
【符号の説明】
【００５３】
２００  クライアントＰＣ、３００  ＷｅｂＡＰＩサーバー、３１０  ＷｅｂＡＰＩサーバーモジュール
【図１】
2017033037.tif 000003
【図２】
2017033037.tif 000004
【図３】
2017033037.tif 000005
【図４】
2017033037.tif 000006
【図５】
2017033037.tif 000007
【図６】
2017033037.tif 000008
【図７】
2017033037.tif 000009
【図８】
2017033037.tif 000010
【図９】
2017033037.tif 000011
【図１０】
2017033037.tif 000012
【図１１】
2017033037.tif 000013
【図１２】
2017033037.tif 000014