情報処理装置
【課題】各端末装置の機器種類や搭載されているＯＳ等が異なっている場合、アップロードされた各種のデータ様式に合わせて、不具合が生じたデータやエラー情報等を記録してエラー要因の解析を容易にする。
【解決手段】ＸＭＬ形式のデータを受信する受信部２１と、ＸＭＬ形式のデータが適正であるか否かを判定するとともに、送信できるか否かを判定する判定部２２とを有する。そして、ＸＭＬ形式のデータが適正でない、又は送信できないと判定されたときに、ＸＭＬ形式のデータを特定するレコードをログテーブル３１ａに格納するとともに、親要素に基づくレコードを親要素毎にレコードテーブル３１ｂに格納し、子要素に基づくレコードを親要素と対応付けて子要素毎にエレメントテーブル３１ｃに格納するテーブル格納部２３とを有する。
【解決手段】ＸＭＬ形式のデータを受信する受信部２１と、ＸＭＬ形式のデータが適正であるか否かを判定するとともに、送信できるか否かを判定する判定部２２とを有する。そして、ＸＭＬ形式のデータが適正でない、又は送信できないと判定されたときに、ＸＭＬ形式のデータを特定するレコードをログテーブル３１ａに格納するとともに、親要素に基づくレコードを親要素毎にレコードテーブル３１ｂに格納し、子要素に基づくレコードを親要素と対応付けて子要素毎にエレメントテーブル３１ｃに格納するテーブル格納部２３とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを受信して所定のインターフェースを介して送信する情報処理装置に関する。
【背景技術】
【０００２】
従来、複数のクライアントからアップロードされた情報をサーバーで受信し、受信した各情報を他のサーバーへ転送する情報処理装置がある。この情報処理装置では、他のサーバーへの転送が不具合等により実行できなかった場合、そのエラー情報を記録するようにしている。そして、エラーの要因を把握して対処した後、再度他のサーバーへ転送を実行するようにしている。例えば、特許文献１に記載されているゲートウエイサーバーでは、任意の端末装置からアップロードされたデータファイルを受信するとともに、データファイルの書式を変換して他のサーバーへ登録している。このとき、他のサーバーへの登録が実行できなかった場合、エラーログを生成するようにしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２７７５８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載されているように、複数の端末装置からアップロードされた情報をサーバーで受信する場合、各端末装置の機器種類や搭載されているＯＳ等が異なっていると、アップロードされるデータ様式も各端末装置で異なることになる。このため、他のサーバーへの転送が不具合等により実行できなかった場合、各種のデータ様式に合わせて、不具合が生じたデータやエラー情報等を記録する対応が必要になり、プログラムの開発コストや品質面において問題が生じる。
【課題を解決するための手段】
【０００５】
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
【０００６】
［適用例１］ＸＭＬ形式のデータを受信する受信部と、前記受信したＸＭＬ形式のデータが適正であるか否かを判定するとともに、前記ＸＭＬ形式のデータに基づく送信データを所定のインターフェースを介して送信できるか否かを判定する判定部と、前記受信したＸＭＬ形式のデータが適正でないと判定されたとき、又は前記送信データを送信できないと判定されたときに、前記受信したＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納するとともに、前記受信したＸＭＬ形式のデータに含まれる親子関係にある要素について、親要素に基づくレコードを前記親要素毎に第２のテーブルに格納し、子要素に基づくレコードを前記親要素と対応付けて前記子要素毎に第３のテーブルに格納するテーブル格納部と、を有することを特徴とする情報処理装置。
【０００７】
上記した情報処理装置によれば、受信したＸＭＬ形式のデータに対して、判定部が、適正であるか否かを判定し、更に送信できるか否かを判定する。そして、ＸＭＬ形式のデータが適正でないか又は送信できないと判定されてエラーのときに、テーブル格納部が、ＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納し、親要素に基づくレコードを親要素毎に第２のテーブルに格納し、子要素に基づくレコードを親要素と対応付けて子要素毎に第３のテーブルに格納する。
エラーの際、ＸＭＬ形式のデータの親要素に基づくレコードを親要素毎に格納し、子要素に基づくレコードを親要素と対応付けて子要素毎に格納する。これにより、データを送信する端末装置の機器種類や搭載されているＯＳ等が異なっている場合でも、共通のプログラムを用いて、不具合が生じたデータやエラー情報等に対してデータ処理を行い、効率的にデータを参照して利用することができる。また、共通のプログラムを用いることにより、プログラム開発のコストを抑制して品質面を向上させることができる。
【０００８】
［適用例２］前記テーブル格納部は、前記判定部における判定結果の情報を前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【０００９】
上記した情報処理装置によれば、判定結果の情報を第１のテーブルに格納することにより、この判定結果の情報に基づいてエラーの要因を把握して対処することができる。
【００１０】
［適用例３］前記テーブル格納部は、前記受信したＸＭＬ形式のデータが適正であると判定され、且つ前記送信データを送信できると判定されたときについても、前記受信したＸＭＬ形式のデータを特定するレコードを前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【００１１】
上記した情報処理装置によれば、ＸＭＬ形式のデータが適正であり送信できると判定されたとき、ＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納する。これにより、正常に送信できるＸＭＬ形式のデータの履歴を残すことができる。
【００１２】
［適用例４］前記テーブル格納部は、前記受信したＸＭＬ形式のデータを特定するレコードを、前記判定部における判定結果の情報毎に前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【００１３】
上記した情報処理装置によれば、ＸＭＬ形式のデータを特定するレコードを判定結果の情報毎に第１のテーブルに格納することにより、エラーの要因が複数の場合に容易に要因を解析することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態に係る情報処理システムの概略構成を示す図。
【図２】アプリケーションサーバーにおける機能構成を示す図。
【図３】クライアントＰＣからアップロードされるＸＭＬ形式のデータの例を示す図。
【図４】ログ情報を構成するログテーブルを示す表。
【図５】ログ情報を構成するレコードテーブルを示す表。
【図６】ログ情報を構成するエレメントテーブルを示す表。
【図７】アプリケーションサーバーに係る動作を示すフローチャート。
【図８】変形例におけるＸＭＬ形式のデータの例を示す図。
【発明を実施するための形態】
【００１５】
以下、本実施形態に係る情報処理装置の例について、図面を参照して説明する。
【００１６】
＜情報処理システムの概略構成＞
図１は、本実施形態に係る情報処理システムの概略構成を示す図である。同図に示すように、情報処理システム１０は、ファイアーウォール（ＦＷ）１１、情報処理装置としてのアプリケーションサーバー１３、管理用データベースサーバー１６、プロダクト用データベースサーバー１８等を備えている。
【００１７】
また、情報処理システム１０には、インターネット及びイントラネット等のネットワーク８０を介して複数のクライアントＰＣ５０が接続されており、各クライアントＰＣ５０には各種デバイス５１が接続されている。図１の例では、プロダクトＡ用，Ｂ用，Ｃ用の各クライアントＰＣ５０Ａ，５０Ｂ，５０Ｃが接続されており、これらのクライアントＰＣ５０Ａ，５０Ｂ，５０Ｃには、それぞれプリンター５１Ａ、プリンター５１Ｂ及びスキャナー５１Ｃが接続されている。各クライアントＰＣ５０は、それぞれに接続されているデバイス５１の情報、例えば消耗品やトラブル等に関する情報を、ＸＭＬ形式のデータに変換してネットワーク８０を介して情報処理システム１０にアップロードすることができる。
【００１８】
情報処理システム１０における各アプリケーションサーバー１３は、ファイアーウォール１１を介したＤＭＺ（非武装地帯）１２に配置されている。管理用データベースサーバー１６は、管理用データベース１７を備えて、ファイアーウォール１１を介したＳｅｃｕｒｅ（セキュアゾーン）１５に配置されている。また、プロダクト用データベースサーバー１８は、プロダクトデータベース１９を備えて、所定のインターフェースとしての情報バスＢ１０に接続されている。図１の例では、プロダクトＡ用，Ｂ用，Ｃ用の各データベースサーバー１８Ａ，１８Ｂ，１８Ｃが接続されており、これらのデータベースサーバー１８Ａ，１８Ｂ，１８Ｃは、それぞれプロダクトデータベース１９Ａ，１９Ｂ，１９Ｃを備えている。上記のように、情報処理システム１０は、ファイアーウォール１１、ＤＭＺ１２、Ｓｅｃｕｒｅ１５により、セキュリティーが確保されるようになっている。
【００１９】
アプリケーションサーバー１３は、各クライアントＰＣ５０からネットワーク８０を介してアップロードされたＸＭＬ形式のデータを受信する。そして、アップロードされたデータが適正か否かの判定、及び情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かの判定を行い、判定結果の情報等を管理用データベースサーバー１６へ送信する。また、アップロードされたＸＭＬ形式のデータが適正であり、且つプロダクト用データベースサーバー１８へ送信できると判定された場合は、アップロードされたデータに基づく送信データを、対応するプロダクト用データベースサーバー１９へ送信する。
【００２０】
管理用データベースサーバー１６は、アプリケーションサーバー１３から送信された判定結果の情報等を受信して管理用データベース１７に格納する。また、管理用データベース１７に格納された各種データの読み出しや検索等を実行する。
プロダクト用データベースサーバー１８は、アプリケーションサーバー１３から送信された送信データを受信し、プロダクトデータベース１９に格納する。また、プロダクトデータベース１９に格納されたデータの読み出しや検索等を実行する。ここで、管理用データベース１７及びプロダクトデータベース１９として、例えばリレーショナルデータベースを用いることができる。また、各プロダクトデータベース１９は、各種プロダクトの要件に合わせて構築されたデータベース構造となっている。
【００２１】
＜アプリケーションサーバーの機能構成＞
次に、アプリケーションサーバー１３における機能構成について説明する。図２は、アプリケーションサーバー１３における機能構成を示す図である。同図に示すように、アプリケーションサーバー１３は、受信部２１、判定部２２、テーブル格納部２３、プロダクトデータ格納部２４等を備えている。また、アプリケーションサーバー１３は、管理用データベースサーバー１６を介して管理用データベース１７にアクセスすることができ、各プロダクト用データベースサーバー１８を介して各プロダクトデータベース１９にアクセスすることができる。
【００２２】
受信部２１は、各クライアントＰＣ５０からネットワーク８０を介してアップロードされたＸＭＬ形式のデータを受信する。図３は、クライアントＰＣ５０からアップロードされるＸＭＬ形式のデータの例を示している。同図に示すＸＭＬ形式のデータは、”Ｈｅａｄｅｒ”要素ｈ１１０と”Ｂｏｄｙ”要素ｂ１１０の２つの部分に分かれている。最初の”Ｈｅａｄｅｒ”要素ｈ１１０の部分は、クライアントＰＣ５０からアップロードされたデータについての識別であり、次の”Ｂｏｄｙ”要素ｂ１１０の部分は、クライアントＰＣ５０からアップロードされたデータ本体である。
【００２３】
”Ｈｅａｄｅｒ”要素ｈ１１０の部分に含まれる”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１は、アップロードしたクライアントＰＣ５０のプロダクトの識別を示している。”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２は、クライアントＰＣ５０の識別を示している。”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３は、クライアントＰＣ５０に接続しているデバイス５１の識別を示している。”Ｄａｔｅ”要素ｈ１１４及び”ＬｏｃａｌＤａｔｅ”要素ｈ１１５は、クライアントＰＣ５０からアップロードした時間を示している。
一方、”Ｂｏｄｙ”要素ｂ１１０の部分は、親要素となる”Ｒｅｃｏｒｄ”要素ｂ１２０，ｂ１３０，ｂ１４０，ｂ１５０と、それぞれの子要素群ｂ１２１，ｂ１３１，ｂ１４１，ｂ１５１との親子関係にある要素で構成される。
なお、”Ｈｅａｄｅｒ”要素ｈ１１０に含まれる”ＬｏｃａｌＤａｔｅ”要素ｈ１１５の下位置の要素名に示すように、クライアントＰＣ５０において、ユーザーＩＤ及びパスワードの入力や、オプションの選択を受け付け、これらの入力値をＸＭＬ形式のデータに含めてアップデートするようにしても良い。
【００２４】
判定部２２は、クライアントＰＣ５０からアップロードされて受信部２１において受信したＸＭＬ形式のデータを解析し、ＸＭＬ形式のデータが適正であるか否かを判定する。そして、ＸＭＬ形式のデータが適正であるときに、ＸＭＬ形式のデータ又は当該データを変換したデータが送信データとして情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かを判定する。
ここで、ＸＭＬ形式のデータが適正でないと判定されるケースとして、例えば、”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１、”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２、”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３の各内容が該当しなかった場合、つまりＸＭＬ形式のデータが示すプロダクトの識別、クライアントＰＣ５０の識別及びデバイス５１の識別が、情報処理システム１０にデータとして登録されていなかった場合があげられる。また、ＸＭＬのデータ記述に誤りがあった場合にも、ＸＭＬ形式のデータが適正でないと判定される。
次に、ＸＭＬ形式のデータ等が情報バスＢ１０を介して送信できないケースとして、例えば、情報バスＢ１０に異常が発生した場合や、送信先のプロダクト用データベースサーバー１８がデータ格納できないと判断した場合等があげられる。
【００２５】
テーブル格納部２３は、判定部２２における判定結果に基づいて、管理用データベースサーバー１６を介して、各プロダクト用のログ情報３１を管理用データベース１７に格納する。なお、ログ情報３１を構成するテーブル種類及びデータ内容は、判定部２２における判定結果により異なっている。
判定部２２においてＸＭＬ形式のデータが適正でないと判定された、又は適正と判定されたときでも情報バスＢ１０を介して送信できないと判定された場合、図２の管理用データベース１７に示すように、ログ情報３１は、第１のテーブルとしてのログテーブル３１ａ、第２のテーブルとしてのレコードテーブル３１ｂ及び第３のテーブルとしてのエレメントテーブル３１ｃにより構成される。
一方、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合は、ログ情報３１は、ログテーブル３１ａのみによって構成される。
【００２６】
図４〜図６は、エラー時におけるログ情報３１を構成する各テーブルを示す表である。図４はログテーブル３１ａ、図５はレコードテーブル３１ｂ、図６はエレメントテーブル３１ｃを示している。各テーブルは、アップロード単位に、図３のＸＭＬ形式のデータに基づいて生成されて格納される。
【００２７】
図４に示すように、ログテーブル３１ａは、ｕｐｌｏａｄ＿ｉｄ、ｌｏｇ＿ｍｅｓｓａｇｅ、ｓｅｒｖｉｃｅ＿ｃｏｄｅ、ａｇｅｎｔ＿ｃｏｄｅ、ｄｅｖｉｃｅ＿ｃｏｄｅ及びｕｐｌｏａｄ＿ｄａｔｅの項目により構成され、アップロード単位に１レコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄの項目は、アップロード単位に付番するログ情報３１のＩＤがセットされる。ｌｏｇ＿ｍｅｓｓａｇｅの項目は、判定部２２における判定結果の情報がセットされる。図４の例では、「Service code TEST_SERVICE is not found」のメッセージがセットされており、これはアップロードされた”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１の内容が該当しないためにエラーであることを示している。ｓｅｒｖｉｃｅ＿ｃｏｄｅ、ａｇｅｎｔ＿ｃｏｄｅ、ｄｅｖｉｃｅ＿ｃｏｄｅ及びｕｐｌｏａｄ＿ｄａｔｅの項目は、それぞれ図３のＸＭＬ形式のデータの”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１、”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２、”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３及び”Ｄａｔｅ”要素ｈ１１４の内容がセットされる。
一方、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合は、図４に示すログテーブル３１ａのｌｏｇ＿ｍｅｓｓａｇｅに、正常に格納されたことを示すメッセージがセットされてログテーブル３１ａのみが格納される。つまり、レコードテーブル３１ｂ及びエレメントテーブル３１ｃはいずれも格納されないことになる。
【００２８】
次に、図５に示すように、レコードテーブル３１ｂは、ｕｐｌｏａｄ＿ｉｄ、ｒｅｃｏｒｄ＿ｉｄ、ｔａｂｌｅ＿ｎａｍｅの項目により構成され、親要素毎にレコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄの項目は、ログテーブル３１ａのｕｐｌｏａｄ＿ｉｄがセットされ、レコードテーブル３１ｂとログテーブル３１ａの対応付けが行われる。ｒｅｃｏｒｄ＿ｉｄの項目は、各親要素への付番がセットされる。ｔａｂｌｅ＿ｎａｍｅの項目は、図３において各親要素となる”Ｒｅｃｏｒｄ”要素ｂ１２０，ｂ１３０，ｂ１４０，ｂ１５０の各内容がセットされる。
【００２９】
次に、図６に示すように、エレメントテーブル３１ｃは、ｕｐｌｏａｄ＿ｉｄ、ｒｅｃｏｒｄ＿ｉｄ、ｅｌｅｍｅｎｔ＿ｉｄ、ｃｏｌｕｍｎ＿ｎａｍｅ、ｖａｌｕｅの項目により構成され、子要素毎にレコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄ及びｒｅｃｏｒｄ＿ｉｄは、ログテーブル３１ａのｕｐｌｏａｄ＿ｉｄ及びレコードテーブル３１ｂのｒｅｃｏｒｄ＿ｉｄがセットされ、エレメントテーブル３１ｃにおける子要素とレコードテーブル３１ｂにおける親要素との親子関係の対応付けが行われる。ｅｌｅｍｅｎｔ＿ｉｄの項目は、各親要素に属している各子要素への付番がセットされる。ｃｏｌｕｍｎ＿ｎａｍｅ及びｖａｌｕｅの項目は、図３の子要素群ｂ１２１，ｂ１３１，ｂ１４１，ｂ１５１における各子要素の要素名及び内容がセットされる。
【００３０】
プロダクトデータ格納部２４は、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合に、クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータ又は当該データを変換したデータとなる送信データを、該当するプロダクト用データベースサーバー１８へ送信して、図２に示すプロダクトデータベース１９にプロダクトデータ４１として格納する。
【００３１】
次に、アプリケーションサーバー１３に係る動作について説明する。
図７は、アプリケーションサーバー１３に係る動作を示すフローチャートである。
【００３２】
先ず、クライアントＰＣ５０は、ネットワーク８０を介してＸＭＬ形式のデータを情報処理システム１０へアップロードする（ステップＳ１１０）。そして、情報処理システム１０においてアプリケーションサーバー１３は、受信部２１により、クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータを受信する（ステップＳ１２０）。
【００３３】
次に、アプリケーションサーバー１３は、判定部２２により、ステップＳ１２０において受信したＸＭＬ形式のデータを解析してＸＭＬ形式のデータが適正であるか否かを判定し、更に情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かを判定する（ステップＳ１３０）。
【００３４】
ＸＭＬ形式のデータが適正であり、且つプロダクト用データベースサーバー１８へ送信できると判定された場合（ステップＳ１３０：Ｙｅｓ）は、テーブル格納部２３により、正常に格納されたことを示すログテーブル３１ａを管理用データベース１７に格納する（ステップＳ１４０）。そして、プロダクトデータ格納部２４により、ステップＳ１２０において受信したＸＭＬ形式のデータ又は当該データを変換したデータとなる送信データをプロダクトデータベース１９に格納し（ステップＳ１５０）、図７のフローチャートの動作を終了する。
【００３５】
他方、ステップＳ１３０においてＸＭＬ形式のデータが適正でない、又はプロダクト用データベースサーバー１８へ送信できないと判定された場合（ステップＳ１３０：Ｎｏ）は、アプリケーションサーバー１３は、テーブル格納部２３により、エラーであることを示すログテーブル３１ａを管理用データベース１７に格納する（ステップＳ１６０）。そして、管理用データベース１７に親要素で構成されるレコードテーブル３１ｂを格納し（ステップＳ１７０）、続けて子要素で構成されるエレメントテーブル３１ｃを格納して（ステップＳ１８０）、図７のフローチャートの動作を終了する。
【００３６】
上述した実施形態では、各クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータを受信してエラーの判定を行い、エラーの際には、管理用データベース１７にログテーブル３１ａ、レコードテーブル３１ｂ及びエレメントテーブル３１ｃにより構成されるログ情報３１を格納する。このとき、レコードテーブル３１ｂは親要素毎にレコードが格納され、エレメントテーブル３１ｃは子要素毎にレコードが格納されて、それぞれの親子関係の対応付けが行われる。これにより、各クライアントＰＣ５０の機器種類や搭載されているＯＳ等が異なっている場合でも、エラーの際に、各クライアントＰＣ５０に共通のプログラムでログ情報３１を生成して格納することができる。また、受信したＸＭＬ形式のデータの階層構造や要素数が様々の形式であっても、親子関係の対応付けが行われたレコードテーブル３１ｂ及びエレメントテーブル３１ｃを用いて統一様式で格納することができ、エラー要因の解析やエラーデータの復旧等に対して効率的に対応することができる。
【００３７】
（変形例１）
上述した実施形態では、各クライアントＰＣ５０から図３に示すようなＸＭＬ形式のデータを受信している。しかし、各クライアントＰＣ５０において、このＸＭＬ形式のデータに対して、図８に示すように暗号化やデジタル署名等の対応を行っても良い。この場合、判定部２２においてＸＭＬ形式のデータの署名内容が認証されなかった場合、ＸＭＬ形式のデータが適正でないと判定される。
【００３８】
（変形例２）
上述した実施形態では、ログ情報３１を構成するログテーブル３１ａについて、アップロード単位に１レコードが生成されて格納されている。しかし、判定部２２においてエラーの要因が複数生じた場合、これらのエラー要因毎にレコードを生成してログテーブル３１ａに格納するようにしても良い。エラー要因毎にレコードが生成されることにより、例えば、各エラー要因のそれぞれについて対処したり、各エラー要因をソートして分析したりすることができる。
【符号の説明】
【００３９】
１０…情報処理システム、１１…ファイアーウォール、１２…ＤＭＺ、１３…アプリケーションサーバー、１５…Ｓｅｃｕｒｅ、１６…管理用データベースサーバー、１７…管理用データベース、１８…プロダクト用データベースサーバー、１９…プロダクトデータベース、２１…受信部、２２…判定部、２３…テーブル格納部、２４…プロダクトデータ格納部、３１…ログ情報、３１ａ…ログテーブル、３１ｂ…レコードテーブル、３１ｃ…エレメントテーブル、４１…プロダクトデータ、５０…クライアントＰＣ、５１…デバイス、８０…ネットワーク、Ｂ１０…情報バス。
【技術分野】
【０００１】
本発明は、データを受信して所定のインターフェースを介して送信する情報処理装置に関する。
【背景技術】
【０００２】
従来、複数のクライアントからアップロードされた情報をサーバーで受信し、受信した各情報を他のサーバーへ転送する情報処理装置がある。この情報処理装置では、他のサーバーへの転送が不具合等により実行できなかった場合、そのエラー情報を記録するようにしている。そして、エラーの要因を把握して対処した後、再度他のサーバーへ転送を実行するようにしている。例えば、特許文献１に記載されているゲートウエイサーバーでは、任意の端末装置からアップロードされたデータファイルを受信するとともに、データファイルの書式を変換して他のサーバーへ登録している。このとき、他のサーバーへの登録が実行できなかった場合、エラーログを生成するようにしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２７７５８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載されているように、複数の端末装置からアップロードされた情報をサーバーで受信する場合、各端末装置の機器種類や搭載されているＯＳ等が異なっていると、アップロードされるデータ様式も各端末装置で異なることになる。このため、他のサーバーへの転送が不具合等により実行できなかった場合、各種のデータ様式に合わせて、不具合が生じたデータやエラー情報等を記録する対応が必要になり、プログラムの開発コストや品質面において問題が生じる。
【課題を解決するための手段】
【０００５】
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
【０００６】
［適用例１］ＸＭＬ形式のデータを受信する受信部と、前記受信したＸＭＬ形式のデータが適正であるか否かを判定するとともに、前記ＸＭＬ形式のデータに基づく送信データを所定のインターフェースを介して送信できるか否かを判定する判定部と、前記受信したＸＭＬ形式のデータが適正でないと判定されたとき、又は前記送信データを送信できないと判定されたときに、前記受信したＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納するとともに、前記受信したＸＭＬ形式のデータに含まれる親子関係にある要素について、親要素に基づくレコードを前記親要素毎に第２のテーブルに格納し、子要素に基づくレコードを前記親要素と対応付けて前記子要素毎に第３のテーブルに格納するテーブル格納部と、を有することを特徴とする情報処理装置。
【０００７】
上記した情報処理装置によれば、受信したＸＭＬ形式のデータに対して、判定部が、適正であるか否かを判定し、更に送信できるか否かを判定する。そして、ＸＭＬ形式のデータが適正でないか又は送信できないと判定されてエラーのときに、テーブル格納部が、ＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納し、親要素に基づくレコードを親要素毎に第２のテーブルに格納し、子要素に基づくレコードを親要素と対応付けて子要素毎に第３のテーブルに格納する。
エラーの際、ＸＭＬ形式のデータの親要素に基づくレコードを親要素毎に格納し、子要素に基づくレコードを親要素と対応付けて子要素毎に格納する。これにより、データを送信する端末装置の機器種類や搭載されているＯＳ等が異なっている場合でも、共通のプログラムを用いて、不具合が生じたデータやエラー情報等に対してデータ処理を行い、効率的にデータを参照して利用することができる。また、共通のプログラムを用いることにより、プログラム開発のコストを抑制して品質面を向上させることができる。
【０００８】
［適用例２］前記テーブル格納部は、前記判定部における判定結果の情報を前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【０００９】
上記した情報処理装置によれば、判定結果の情報を第１のテーブルに格納することにより、この判定結果の情報に基づいてエラーの要因を把握して対処することができる。
【００１０】
［適用例３］前記テーブル格納部は、前記受信したＸＭＬ形式のデータが適正であると判定され、且つ前記送信データを送信できると判定されたときについても、前記受信したＸＭＬ形式のデータを特定するレコードを前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【００１１】
上記した情報処理装置によれば、ＸＭＬ形式のデータが適正であり送信できると判定されたとき、ＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納する。これにより、正常に送信できるＸＭＬ形式のデータの履歴を残すことができる。
【００１２】
［適用例４］前記テーブル格納部は、前記受信したＸＭＬ形式のデータを特定するレコードを、前記判定部における判定結果の情報毎に前記第１のテーブルに格納することを特徴とする上記情報処理装置。
【００１３】
上記した情報処理装置によれば、ＸＭＬ形式のデータを特定するレコードを判定結果の情報毎に第１のテーブルに格納することにより、エラーの要因が複数の場合に容易に要因を解析することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態に係る情報処理システムの概略構成を示す図。
【図２】アプリケーションサーバーにおける機能構成を示す図。
【図３】クライアントＰＣからアップロードされるＸＭＬ形式のデータの例を示す図。
【図４】ログ情報を構成するログテーブルを示す表。
【図５】ログ情報を構成するレコードテーブルを示す表。
【図６】ログ情報を構成するエレメントテーブルを示す表。
【図７】アプリケーションサーバーに係る動作を示すフローチャート。
【図８】変形例におけるＸＭＬ形式のデータの例を示す図。
【発明を実施するための形態】
【００１５】
以下、本実施形態に係る情報処理装置の例について、図面を参照して説明する。
【００１６】
＜情報処理システムの概略構成＞
図１は、本実施形態に係る情報処理システムの概略構成を示す図である。同図に示すように、情報処理システム１０は、ファイアーウォール（ＦＷ）１１、情報処理装置としてのアプリケーションサーバー１３、管理用データベースサーバー１６、プロダクト用データベースサーバー１８等を備えている。
【００１７】
また、情報処理システム１０には、インターネット及びイントラネット等のネットワーク８０を介して複数のクライアントＰＣ５０が接続されており、各クライアントＰＣ５０には各種デバイス５１が接続されている。図１の例では、プロダクトＡ用，Ｂ用，Ｃ用の各クライアントＰＣ５０Ａ，５０Ｂ，５０Ｃが接続されており、これらのクライアントＰＣ５０Ａ，５０Ｂ，５０Ｃには、それぞれプリンター５１Ａ、プリンター５１Ｂ及びスキャナー５１Ｃが接続されている。各クライアントＰＣ５０は、それぞれに接続されているデバイス５１の情報、例えば消耗品やトラブル等に関する情報を、ＸＭＬ形式のデータに変換してネットワーク８０を介して情報処理システム１０にアップロードすることができる。
【００１８】
情報処理システム１０における各アプリケーションサーバー１３は、ファイアーウォール１１を介したＤＭＺ（非武装地帯）１２に配置されている。管理用データベースサーバー１６は、管理用データベース１７を備えて、ファイアーウォール１１を介したＳｅｃｕｒｅ（セキュアゾーン）１５に配置されている。また、プロダクト用データベースサーバー１８は、プロダクトデータベース１９を備えて、所定のインターフェースとしての情報バスＢ１０に接続されている。図１の例では、プロダクトＡ用，Ｂ用，Ｃ用の各データベースサーバー１８Ａ，１８Ｂ，１８Ｃが接続されており、これらのデータベースサーバー１８Ａ，１８Ｂ，１８Ｃは、それぞれプロダクトデータベース１９Ａ，１９Ｂ，１９Ｃを備えている。上記のように、情報処理システム１０は、ファイアーウォール１１、ＤＭＺ１２、Ｓｅｃｕｒｅ１５により、セキュリティーが確保されるようになっている。
【００１９】
アプリケーションサーバー１３は、各クライアントＰＣ５０からネットワーク８０を介してアップロードされたＸＭＬ形式のデータを受信する。そして、アップロードされたデータが適正か否かの判定、及び情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かの判定を行い、判定結果の情報等を管理用データベースサーバー１６へ送信する。また、アップロードされたＸＭＬ形式のデータが適正であり、且つプロダクト用データベースサーバー１８へ送信できると判定された場合は、アップロードされたデータに基づく送信データを、対応するプロダクト用データベースサーバー１９へ送信する。
【００２０】
管理用データベースサーバー１６は、アプリケーションサーバー１３から送信された判定結果の情報等を受信して管理用データベース１７に格納する。また、管理用データベース１７に格納された各種データの読み出しや検索等を実行する。
プロダクト用データベースサーバー１８は、アプリケーションサーバー１３から送信された送信データを受信し、プロダクトデータベース１９に格納する。また、プロダクトデータベース１９に格納されたデータの読み出しや検索等を実行する。ここで、管理用データベース１７及びプロダクトデータベース１９として、例えばリレーショナルデータベースを用いることができる。また、各プロダクトデータベース１９は、各種プロダクトの要件に合わせて構築されたデータベース構造となっている。
【００２１】
＜アプリケーションサーバーの機能構成＞
次に、アプリケーションサーバー１３における機能構成について説明する。図２は、アプリケーションサーバー１３における機能構成を示す図である。同図に示すように、アプリケーションサーバー１３は、受信部２１、判定部２２、テーブル格納部２３、プロダクトデータ格納部２４等を備えている。また、アプリケーションサーバー１３は、管理用データベースサーバー１６を介して管理用データベース１７にアクセスすることができ、各プロダクト用データベースサーバー１８を介して各プロダクトデータベース１９にアクセスすることができる。
【００２２】
受信部２１は、各クライアントＰＣ５０からネットワーク８０を介してアップロードされたＸＭＬ形式のデータを受信する。図３は、クライアントＰＣ５０からアップロードされるＸＭＬ形式のデータの例を示している。同図に示すＸＭＬ形式のデータは、”Ｈｅａｄｅｒ”要素ｈ１１０と”Ｂｏｄｙ”要素ｂ１１０の２つの部分に分かれている。最初の”Ｈｅａｄｅｒ”要素ｈ１１０の部分は、クライアントＰＣ５０からアップロードされたデータについての識別であり、次の”Ｂｏｄｙ”要素ｂ１１０の部分は、クライアントＰＣ５０からアップロードされたデータ本体である。
【００２３】
”Ｈｅａｄｅｒ”要素ｈ１１０の部分に含まれる”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１は、アップロードしたクライアントＰＣ５０のプロダクトの識別を示している。”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２は、クライアントＰＣ５０の識別を示している。”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３は、クライアントＰＣ５０に接続しているデバイス５１の識別を示している。”Ｄａｔｅ”要素ｈ１１４及び”ＬｏｃａｌＤａｔｅ”要素ｈ１１５は、クライアントＰＣ５０からアップロードした時間を示している。
一方、”Ｂｏｄｙ”要素ｂ１１０の部分は、親要素となる”Ｒｅｃｏｒｄ”要素ｂ１２０，ｂ１３０，ｂ１４０，ｂ１５０と、それぞれの子要素群ｂ１２１，ｂ１３１，ｂ１４１，ｂ１５１との親子関係にある要素で構成される。
なお、”Ｈｅａｄｅｒ”要素ｈ１１０に含まれる”ＬｏｃａｌＤａｔｅ”要素ｈ１１５の下位置の要素名に示すように、クライアントＰＣ５０において、ユーザーＩＤ及びパスワードの入力や、オプションの選択を受け付け、これらの入力値をＸＭＬ形式のデータに含めてアップデートするようにしても良い。
【００２４】
判定部２２は、クライアントＰＣ５０からアップロードされて受信部２１において受信したＸＭＬ形式のデータを解析し、ＸＭＬ形式のデータが適正であるか否かを判定する。そして、ＸＭＬ形式のデータが適正であるときに、ＸＭＬ形式のデータ又は当該データを変換したデータが送信データとして情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かを判定する。
ここで、ＸＭＬ形式のデータが適正でないと判定されるケースとして、例えば、”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１、”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２、”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３の各内容が該当しなかった場合、つまりＸＭＬ形式のデータが示すプロダクトの識別、クライアントＰＣ５０の識別及びデバイス５１の識別が、情報処理システム１０にデータとして登録されていなかった場合があげられる。また、ＸＭＬのデータ記述に誤りがあった場合にも、ＸＭＬ形式のデータが適正でないと判定される。
次に、ＸＭＬ形式のデータ等が情報バスＢ１０を介して送信できないケースとして、例えば、情報バスＢ１０に異常が発生した場合や、送信先のプロダクト用データベースサーバー１８がデータ格納できないと判断した場合等があげられる。
【００２５】
テーブル格納部２３は、判定部２２における判定結果に基づいて、管理用データベースサーバー１６を介して、各プロダクト用のログ情報３１を管理用データベース１７に格納する。なお、ログ情報３１を構成するテーブル種類及びデータ内容は、判定部２２における判定結果により異なっている。
判定部２２においてＸＭＬ形式のデータが適正でないと判定された、又は適正と判定されたときでも情報バスＢ１０を介して送信できないと判定された場合、図２の管理用データベース１７に示すように、ログ情報３１は、第１のテーブルとしてのログテーブル３１ａ、第２のテーブルとしてのレコードテーブル３１ｂ及び第３のテーブルとしてのエレメントテーブル３１ｃにより構成される。
一方、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合は、ログ情報３１は、ログテーブル３１ａのみによって構成される。
【００２６】
図４〜図６は、エラー時におけるログ情報３１を構成する各テーブルを示す表である。図４はログテーブル３１ａ、図５はレコードテーブル３１ｂ、図６はエレメントテーブル３１ｃを示している。各テーブルは、アップロード単位に、図３のＸＭＬ形式のデータに基づいて生成されて格納される。
【００２７】
図４に示すように、ログテーブル３１ａは、ｕｐｌｏａｄ＿ｉｄ、ｌｏｇ＿ｍｅｓｓａｇｅ、ｓｅｒｖｉｃｅ＿ｃｏｄｅ、ａｇｅｎｔ＿ｃｏｄｅ、ｄｅｖｉｃｅ＿ｃｏｄｅ及びｕｐｌｏａｄ＿ｄａｔｅの項目により構成され、アップロード単位に１レコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄの項目は、アップロード単位に付番するログ情報３１のＩＤがセットされる。ｌｏｇ＿ｍｅｓｓａｇｅの項目は、判定部２２における判定結果の情報がセットされる。図４の例では、「Service code TEST_SERVICE is not found」のメッセージがセットされており、これはアップロードされた”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１の内容が該当しないためにエラーであることを示している。ｓｅｒｖｉｃｅ＿ｃｏｄｅ、ａｇｅｎｔ＿ｃｏｄｅ、ｄｅｖｉｃｅ＿ｃｏｄｅ及びｕｐｌｏａｄ＿ｄａｔｅの項目は、それぞれ図３のＸＭＬ形式のデータの”ＳｅｒｖｉｃｅＣｏｄｅ”要素ｈ１１１、”ＡｇｅｎｔＣｏｄｅ”要素ｈ１１２、”ＤｅｖｉｃｅＣｏｄｅ”要素ｈ１１３及び”Ｄａｔｅ”要素ｈ１１４の内容がセットされる。
一方、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合は、図４に示すログテーブル３１ａのｌｏｇ＿ｍｅｓｓａｇｅに、正常に格納されたことを示すメッセージがセットされてログテーブル３１ａのみが格納される。つまり、レコードテーブル３１ｂ及びエレメントテーブル３１ｃはいずれも格納されないことになる。
【００２８】
次に、図５に示すように、レコードテーブル３１ｂは、ｕｐｌｏａｄ＿ｉｄ、ｒｅｃｏｒｄ＿ｉｄ、ｔａｂｌｅ＿ｎａｍｅの項目により構成され、親要素毎にレコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄの項目は、ログテーブル３１ａのｕｐｌｏａｄ＿ｉｄがセットされ、レコードテーブル３１ｂとログテーブル３１ａの対応付けが行われる。ｒｅｃｏｒｄ＿ｉｄの項目は、各親要素への付番がセットされる。ｔａｂｌｅ＿ｎａｍｅの項目は、図３において各親要素となる”Ｒｅｃｏｒｄ”要素ｂ１２０，ｂ１３０，ｂ１４０，ｂ１５０の各内容がセットされる。
【００２９】
次に、図６に示すように、エレメントテーブル３１ｃは、ｕｐｌｏａｄ＿ｉｄ、ｒｅｃｏｒｄ＿ｉｄ、ｅｌｅｍｅｎｔ＿ｉｄ、ｃｏｌｕｍｎ＿ｎａｍｅ、ｖａｌｕｅの項目により構成され、子要素毎にレコードが生成されて格納される。ｕｐｌｏａｄ＿ｉｄ及びｒｅｃｏｒｄ＿ｉｄは、ログテーブル３１ａのｕｐｌｏａｄ＿ｉｄ及びレコードテーブル３１ｂのｒｅｃｏｒｄ＿ｉｄがセットされ、エレメントテーブル３１ｃにおける子要素とレコードテーブル３１ｂにおける親要素との親子関係の対応付けが行われる。ｅｌｅｍｅｎｔ＿ｉｄの項目は、各親要素に属している各子要素への付番がセットされる。ｃｏｌｕｍｎ＿ｎａｍｅ及びｖａｌｕｅの項目は、図３の子要素群ｂ１２１，ｂ１３１，ｂ１４１，ｂ１５１における各子要素の要素名及び内容がセットされる。
【００３０】
プロダクトデータ格納部２４は、判定部２２においてＸＭＬ形式のデータが適正であり、且つ情報バスＢ１０を介して送信できると判定された場合に、クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータ又は当該データを変換したデータとなる送信データを、該当するプロダクト用データベースサーバー１８へ送信して、図２に示すプロダクトデータベース１９にプロダクトデータ４１として格納する。
【００３１】
次に、アプリケーションサーバー１３に係る動作について説明する。
図７は、アプリケーションサーバー１３に係る動作を示すフローチャートである。
【００３２】
先ず、クライアントＰＣ５０は、ネットワーク８０を介してＸＭＬ形式のデータを情報処理システム１０へアップロードする（ステップＳ１１０）。そして、情報処理システム１０においてアプリケーションサーバー１３は、受信部２１により、クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータを受信する（ステップＳ１２０）。
【００３３】
次に、アプリケーションサーバー１３は、判定部２２により、ステップＳ１２０において受信したＸＭＬ形式のデータを解析してＸＭＬ形式のデータが適正であるか否かを判定し、更に情報バスＢ１０を介してプロダクト用データベースサーバー１８へ送信できるか否かを判定する（ステップＳ１３０）。
【００３４】
ＸＭＬ形式のデータが適正であり、且つプロダクト用データベースサーバー１８へ送信できると判定された場合（ステップＳ１３０：Ｙｅｓ）は、テーブル格納部２３により、正常に格納されたことを示すログテーブル３１ａを管理用データベース１７に格納する（ステップＳ１４０）。そして、プロダクトデータ格納部２４により、ステップＳ１２０において受信したＸＭＬ形式のデータ又は当該データを変換したデータとなる送信データをプロダクトデータベース１９に格納し（ステップＳ１５０）、図７のフローチャートの動作を終了する。
【００３５】
他方、ステップＳ１３０においてＸＭＬ形式のデータが適正でない、又はプロダクト用データベースサーバー１８へ送信できないと判定された場合（ステップＳ１３０：Ｎｏ）は、アプリケーションサーバー１３は、テーブル格納部２３により、エラーであることを示すログテーブル３１ａを管理用データベース１７に格納する（ステップＳ１６０）。そして、管理用データベース１７に親要素で構成されるレコードテーブル３１ｂを格納し（ステップＳ１７０）、続けて子要素で構成されるエレメントテーブル３１ｃを格納して（ステップＳ１８０）、図７のフローチャートの動作を終了する。
【００３６】
上述した実施形態では、各クライアントＰＣ５０からアップロードされたＸＭＬ形式のデータを受信してエラーの判定を行い、エラーの際には、管理用データベース１７にログテーブル３１ａ、レコードテーブル３１ｂ及びエレメントテーブル３１ｃにより構成されるログ情報３１を格納する。このとき、レコードテーブル３１ｂは親要素毎にレコードが格納され、エレメントテーブル３１ｃは子要素毎にレコードが格納されて、それぞれの親子関係の対応付けが行われる。これにより、各クライアントＰＣ５０の機器種類や搭載されているＯＳ等が異なっている場合でも、エラーの際に、各クライアントＰＣ５０に共通のプログラムでログ情報３１を生成して格納することができる。また、受信したＸＭＬ形式のデータの階層構造や要素数が様々の形式であっても、親子関係の対応付けが行われたレコードテーブル３１ｂ及びエレメントテーブル３１ｃを用いて統一様式で格納することができ、エラー要因の解析やエラーデータの復旧等に対して効率的に対応することができる。
【００３７】
（変形例１）
上述した実施形態では、各クライアントＰＣ５０から図３に示すようなＸＭＬ形式のデータを受信している。しかし、各クライアントＰＣ５０において、このＸＭＬ形式のデータに対して、図８に示すように暗号化やデジタル署名等の対応を行っても良い。この場合、判定部２２においてＸＭＬ形式のデータの署名内容が認証されなかった場合、ＸＭＬ形式のデータが適正でないと判定される。
【００３８】
（変形例２）
上述した実施形態では、ログ情報３１を構成するログテーブル３１ａについて、アップロード単位に１レコードが生成されて格納されている。しかし、判定部２２においてエラーの要因が複数生じた場合、これらのエラー要因毎にレコードを生成してログテーブル３１ａに格納するようにしても良い。エラー要因毎にレコードが生成されることにより、例えば、各エラー要因のそれぞれについて対処したり、各エラー要因をソートして分析したりすることができる。
【符号の説明】
【００３９】
１０…情報処理システム、１１…ファイアーウォール、１２…ＤＭＺ、１３…アプリケーションサーバー、１５…Ｓｅｃｕｒｅ、１６…管理用データベースサーバー、１７…管理用データベース、１８…プロダクト用データベースサーバー、１９…プロダクトデータベース、２１…受信部、２２…判定部、２３…テーブル格納部、２４…プロダクトデータ格納部、３１…ログ情報、３１ａ…ログテーブル、３１ｂ…レコードテーブル、３１ｃ…エレメントテーブル、４１…プロダクトデータ、５０…クライアントＰＣ、５１…デバイス、８０…ネットワーク、Ｂ１０…情報バス。
【特許請求の範囲】
【請求項１】
ＸＭＬ形式のデータを受信する受信部と、
前記受信したＸＭＬ形式のデータが適正であるか否かを判定するとともに、前記ＸＭＬ形式のデータに基づく送信データを所定のインターフェースを介して送信できるか否かを判定する判定部と、
前記受信したＸＭＬ形式のデータが適正でないと判定されたとき、又は前記送信データを送信できないと判定されたときに、
前記受信したＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納するとともに、前記受信したＸＭＬ形式のデータに含まれる親子関係にある要素について、親要素に基づくレコードを前記親要素毎に第２のテーブルに格納し、子要素に基づくレコードを前記親要素と対応付けて前記子要素毎に第３のテーブルに格納するテーブル格納部と、を有することを特徴とする情報処理装置。
【請求項２】
前記テーブル格納部は、前記判定部における判定結果の情報を前記第１のテーブルに格納することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記テーブル格納部は、前記受信したＸＭＬ形式のデータが適正であると判定され、且つ前記送信データを送信できると判定されたときについても、前記受信したＸＭＬ形式のデータを特定するレコードを前記第１のテーブルに格納することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記テーブル格納部は、前記受信したＸＭＬ形式のデータを特定するレコードを、前記判定部における判定結果の情報毎に前記第１のテーブルに格納することを特徴とする請求項２又は３に記載の情報処理装置。
【請求項１】
ＸＭＬ形式のデータを受信する受信部と、
前記受信したＸＭＬ形式のデータが適正であるか否かを判定するとともに、前記ＸＭＬ形式のデータに基づく送信データを所定のインターフェースを介して送信できるか否かを判定する判定部と、
前記受信したＸＭＬ形式のデータが適正でないと判定されたとき、又は前記送信データを送信できないと判定されたときに、
前記受信したＸＭＬ形式のデータを特定するレコードを第１のテーブルに格納するとともに、前記受信したＸＭＬ形式のデータに含まれる親子関係にある要素について、親要素に基づくレコードを前記親要素毎に第２のテーブルに格納し、子要素に基づくレコードを前記親要素と対応付けて前記子要素毎に第３のテーブルに格納するテーブル格納部と、を有することを特徴とする情報処理装置。
【請求項２】
前記テーブル格納部は、前記判定部における判定結果の情報を前記第１のテーブルに格納することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記テーブル格納部は、前記受信したＸＭＬ形式のデータが適正であると判定され、且つ前記送信データを送信できると判定されたときについても、前記受信したＸＭＬ形式のデータを特定するレコードを前記第１のテーブルに格納することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記テーブル格納部は、前記受信したＸＭＬ形式のデータを特定するレコードを、前記判定部における判定結果の情報毎に前記第１のテーブルに格納することを特徴とする請求項２又は３に記載の情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１１−２２１６８２（Ｐ２０１１−２２１６８２Ａ）
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１０−８８３８７（Ｐ２０１０−８８３８７）
【出願日】平成２２年４月７日（２０１０．４．７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２２年４月７日（２０１０．４．７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
[ Back to top ]