JP2009301084A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】ユーザが画面から入力した入力情報を画面種別に依存せずに保存ができ、履歴情報を用いて入力画面を再現、処理の再実行が可能となる情報処理装置を提供する。
【解決手段】入力画面２１から情報処理装置に対して登録要求をすると、入力画面２１から情報処理装置に渡された入力情報の画面レイアウト構造を含む汎用形式に変換し、履歴情報ＤＢ６５に保存する。履歴情報を履歴照会画面２２から照会要求をすると、履歴情報ＤＢ６５に保存されている履歴情報を、登録されている入力時点の画面形式に履歴情報を変換して、ユーザが過去に入力した画面および入力情報をそのまま再現することができる。
【選択図】図５

Description

本発明は、入力項目を有する画面を有する情報システムに係り、アプリケーション種別に関わらず統一的に履歴情報を管理することができる情報処理装置および情報処理方法に関する。

近年、内部統制、個人情報保護法等により、情報セキュリティ対策が重要視されている。特に内部統制において、記録されている情報の信頼性の確保が重要である。信頼性を確保するため情報システムの利用記録、特にデータを登録・更新・削除する場合の入力履歴から、実際に入力された情報を再現することが重要である。

一方、情報システムには、各種アプリケーションが存在する。例えば、Ｗｅｂアプリケーション、リッチクライアントアプリケーション、Ｃ/Ｓ(Customer/Server)アプリケーション）が存在する。それぞれのアプリケーションは起動方法が異なる。すなわち、図４（１）に示すように、Ｗｅｂアプリケーションは、クライアントＰＣ（Personal Computer）のＷｅｂプラウザ上で実行するアプリケーションであり、処理ロジック自体は、アプリケーションサーバ上にあり、クライアントＰＣはＷｅｂプラウザによる画面描画機能のみである。図４（２）に示すように、リッチクライアントアプリケーションは、利用する都度にアプリケーションサーバからアプリケーションをダウンロードしてクライアントＰＣ上で実行するアプリケーションである。クライアントＰＣにダウンロードされたアプリケーションは、画面描画機能のみの場合と処理ロジックまでアプリケーションに含むときもある。図４（３）に示すように、Ｃ/Ｓアプリケーションは、予めアプリケーションをクライアントＰＣ上に保存し、クライアントＰＣ上で実行されるアプリケーションであり、アプリケーションに画面描画、処理ロジックの両方が保存されている。

起動されたアプリケーションは、各種方法で履歴が記録されている。特許文献１では、Ｗｅｂアプリケーションの情報の保存方法が開示されており、インターネット上のＷＷＷ（World Wide Web）サーバから取得したＷｅｂブラウザの複数ファイルを１つのファイルに集約した形で保存する形で履歴が出力される。また、特許文献２では、ＷＷＷプラウザ画面上の操作履歴を順次記録して、再生する装置が開示されている。
特開２０００-２９３４２２号公報 特開２００１-６０１７９号公報

前記情報システムは、異なるアプリケーションを運用する複数システムで構成されることが多く、一連の業務フロー中の処理が、それぞれ別の仕組みを有するシステムで実施される。このため、入力された履歴情報も、それぞれ別のフォーマット、場所に記録される。そのため、複数システムに渡る業務の操作・入力履歴を一元的に参照できないことが問題であった。

過去に入力されたデータが、監査等において履歴情報から誤りのデータが入力されていることが判明した場合、正しいデータの再登録が要求される。しかし、例えば、入力画面情報が年度末で更新され、新年度から新しい入力画面情報になっており、入力フォーマットが更新されているとすると、履歴情報を照会画面で出力した後、履歴情報のデータと入力すべき内容はほぼ同じで有るに関わらず、新しい入力画面からユーザがデータ全て再入力する必要があり入力に手間がかかる。さらに、システム個別に履歴情報が作成されるため、その履歴を参照する画面を、各画面単位で作成する必要ある。

本発明は、前記の課題を解決するための発明であって、入力項目を有する画面を持つ情報システムにおいて、アプリケーション種別に関わらず統一的に履歴情報を管理することができる情報処理装置および情報処理方法を提供することを目的とする。

前記目的を達成するために、本システムでは、（１）履歴情報を一括管理すること、（２）履歴照会画面は、入力時の入力画面をそのまま利用すること、の２つのアプローチから課題解決を行う。

情報システムにおける画面は、様々な形式を持つが、履歴の形式に画面レイアウト構造を併せ持つことにより、画面種別（Ｗｅｂ、リッチクライアント、Ｃ／Ｓ）に関わらず同一のデータベースにより管理が可能である。例えば、１つの業務を複数のシステムにて行う場合（例えば、Ｗｅｂでデータ検索しリッチクライアントで登録）にも、１種類のデータベースを参照することにより、ユーザの操作の流れを見ることができる。

本発明によれば、入力項目を有する画面を持つ情報システムにおいて、アプリケーション種別に関わらず統一的に履歴情報を管理することができる。

以下、本発明を実施するための実施形態を図面に基づいて詳細に説明する。
図１は、本実施形態の履歴管理システムの全体構成を示すブロック図である。履歴管理システムは、Ｗｅｂ／ＡＰ（アプリケーション）サーバを兼ねた履歴管理サーバ（情報処理装置）１０と複数のクライアントＰＣ２０を有し、これらがネットワーク３０を介して接続されている。なお、クライアントＰＣ２０の数は、図１に示す数に限定されない。

履歴管理サーバ１０は、出力装置１１、入力装置１２、ＣＰＵ(Central Processing Unit）１３、通信装置１４、メモリ１５、外部記憶装置１６、およびこれらを接続するバス１７から構成される。出力装置１１は、ディスプレイ等であり、履歴管理サーバ１０による処理の実行状況や実行結果等を表示する。入力装置１２は、キーボードやマウス等のコンピュータに指示を入力するための装置であり、プログラム起動等の指示を入力する。ＣＰＵ１３は、メモリ１５に格納される各種プログラムを実行する。通信装置１４は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等のネットワーク３０を介して、他の装置と各種データやコマンドを交換する。外部記憶装置１６は、履歴管理サーバ１０が処理を実行するための各種データを保存する。メモリ１５は、履歴管理サーバ１０が処理を実行する各種プログラムおよび一時的なデータを保持する。

外部記憶装置１６は、入力画面の画面定義情報等が格納される画面情報ＤＢ６１（図７、図８参照）、アクション定義情報等が格納されるアクション情報ＤＢ６２（図７、図８参照）、画面項目の表示名等が格納される画面項目情報ＤＢ６３（図７参照）、Ｗｅｂアプリケーションのプログラム等が格納されるプログラム情報ＤＢ６４、入力した履歴情報を格納する履歴情報ＤＢ６５（図６参照）、Ｗｅｂアプリケーションが格納されるＷｅｂアプリケーションＤＢ７０、およびリッチクライアントアプリケーションが格納されるリッチクライアントアプリケーションＤＢ７１を有する。

メモリ１５は、メニュー部プログラム４０、履歴管理プログラム５０を有する。メニュー部プログラム４０は、クライアントＰＣ２０からの要求により、メニュー画面を表示するプログラムである。履歴管理プログラム５０は、クライアントＰＣ２０からの要求により、入力された入力情報を履歴情報として登録、再生、再登録等を管理するプログラムである。履歴管理プログラム５０は、画面情報ＤＢ６１から画面定義を取得する画面定義取得部（画面定義取得手段）５１、要求された画面を出力する画面出力制御部５２、画面の種別を判別する画面種別判定部（画面手段判定手段）５３、入力情報に基づいて履歴情報を生成する履歴情報生成部（履歴情報生成手段）５４、生成された履歴情報をヘッダ情報と関連づけて履歴情報ＤＢ６５に登録する履歴情報出力部５５、履歴照会要求時に履歴一覧を出力する履歴一覧出力部５６、入力情報からＸＭＬ（eXtensible Markup Language）形式の変換入力情報に変換する、およびその逆変換（変換入力情報から入力情報に変換）する履歴情報変換部（履歴情報変換手段）５７、履歴情報に格納されている入力画面を再生する入力画面再生成部（入力画面生成手段）５８を有する。

ここで、本実施形態の特徴の概略を以下に示す。
従来、履歴の照会画面は、記録された履歴情報を、情報システムのユーザが判別しやすい形式に変換をして一覧表示するものはあるが、履歴データを用いて処理の再実行をしたい場合、再度、ユーザによる入力が必要となり手間がかかる場合がある。本システムによれば、履歴紹介画面を従来の項目一覧の照会に加えて、履歴を用いてユーザが入力した画面を照会画面として利用をすることで、ユーザ入力内容の直感的把握、および入力した画面を利用するため処理の再実行をすることができる。

なお、Ｗｅｂアプリケーションにおける画面のプログラムの変更が行われた場合、プログラムが上書されるため、本方式では、画面プログラムを定義情報とすることにより、プログラムそのものも履歴管理して再実行をすることができる。

（１）履歴管理サーバ１０は、異なる画面種別の入力情報をＸＭＬ形式に変換して保存する。この際、画面ＩＤ、入力日時等をヘッダ情報に、入力情報をＸＭＬ形式に変換することで、操作の流れを一元的に参照することができる。また、履歴管理サーバ１０は、クライアントＰＣ２０からの要求を判断して、履歴情報を変換、各種のアプリケーションに対応するため、クライアントアプリケーションの種別（Ｗｅｂ、リッチクライアント、Ｃ／Ｓ）の種別に関わらず同じ履歴情報ＤＢ６５で、複数種類のアプリケーションについて履歴を管理できる。
（２）履歴情報の参照画面は従来の一覧照会と、詳細情報を表示する照会画面は入力に利用した画面をそのまま利用する。これにより、入力画面へ、履歴情報と同じデータを再入力するコストが不要になり、照会画面は、各プログラムの画面を起動をするだけであるため、個別の照会画面の開発が不要となる。
（３）画面のプログラムを定義データとすることで、画面のプログラムに履歴を持たせることができる。履歴を持たせることで、履歴が作成された時点と同じ画面を描画することができる。
（４）履歴管理サーバ１０に要求（検索、登録、更新、削除）がされたタイミング（データに何らかの操作が入ったタイミング）で、履歴情報を取得する。

履歴管理システムで使用される各種アプリケーションの起動方法について、図２〜図４を参照して説明する。適宜図１を参照する。
図２は、各種アプリケーションの起動方法を示す説明図である。クライアントＰＣ２０の表示部（不図示）には、履歴管理サーバ１０のメニュー画面が表示される。Ｗｅｂアプリケーションが選択された場合、Ｗｅｂアプリケーションの起動要求がされ、履歴管理サーバ１０は、要求されたＨＴＭＬ（Hyper Text Markup Language）コンテンツを、ＷｅｂアプリケーションＤＢ７０から取り出して送信し、クライアントＰＣ２０のＷｅｂプラウザに表示する。また、リッチクライアントアプリケーションが選択された場合、リッチクライアントアプリケーションの起動要求がされ、履歴管理サーバ１０は、要求されたリッチクライアントアプリケーションを、リッチクライアントアプリケーションＤＢ７１から取り出して送信し、クライアントＰＣにダウンロードする。また、Ｃ／Ｓアプリケーションが選択された場合、予めクライアントＰＣ２０に格納されているＣ／Ｓアプリケーションの起動要求がされる。

図３は、メニュー画面からの起動例を示す説明図である。図３に示すように、メニュー
画面には、アプリケーション１、アプリケーション２、アプリケーション３、アプリケーション４等のような項目が表示されており、アプリケーションの種類により、実行形態が異なる。例えば、アプリケーション１およびアプリケーション２の場合、Ｗｅｂアプリケーションであり、履歴管理サーバ１０が要求されたＨＴＭＬコンテンツを、ＷｅｂアプリケーションＤＢ７０から取り出して送信し、クライアントＰＣ２０のＷｅｂプラウザに、Ｗｅｂアプリケーション１およびＷｅｂアプリケーション２として表示する。アプリケーション３の場合、履歴管理サーバ１０は、要求されたリッチクライアントアプリケーションを、リッチクライアントアプリケーションＤＢ７１から取り出して送信し、クライアントＰＣにダウンロードする。そして、クライアントＰＣ２０上で実行する。アプリケーション４の場合は、予めクライアントＰＣ２０に格納されているＣ／Ｓアプリケーションの起動要求がされる。

図５は、本実施形態の骨子を示す概略図である。本実施形態の履歴管理システムでは、（Ａ）履歴情報を一括管理すること、（Ｂ）履歴照会画面は、入力時の入力画面をそのまま利用すること、の２つのアプローチから課題解決を行う。このため、履歴情報を、画面の構造を持たせた形式に履歴情報を変換する。この時、画面の構造は、画面定義情報を元に画面項目に画面レイアウト構造を含め意味を持たせたＸＭＬ形式（図１０参照）で保存を行う。

各種アプリメーションにおける画面は、様々な形式を有するが、履歴の形式に画面レイアウト構造を併せ持つことにより、画面種別（Ｗｅｂアプリケーション、リッチクライアントアプリケーション、Ｃ／Ｓアプリケーション）に関わらず同一のデータベースにより管理が可能であり、例えば１つの業務を複数のシステムにて行う場合（例えば、Ｗｅｂでデータ検索し、リッチクライアントで登録）という場合にも、１種類のデータベース参照のみで、ユーザの操作の流れを見ることができる。

具体的には、図５に示すように、メニュー画面から、ひとつのアプリケーションが選択されると、（１）アプリケーションが起動し、入力画面２１がクライアントＰＣ２０の表示部に表示される。入力画面２１は、複数の入力項目（例えば、氏名番号、組織名）を有する。入力が完了し、登録指示がされると、（２）入力データが履歴情報ＤＢ６５（図１参照）に保存される。メニュー画面から履歴照会のメニューを選択されると、（３）履歴照会アプリケーションが起動し、履歴照会画面２２がクライアントＰＣ２０の表示部に表示される。履歴照会画面２２には、検索キー欄２２１に検索用語を入れてＥｎｔｅｒキーまたは、検索ボタン（不図示）が押下されると、履歴情報ＤＢ６５から検索されてこれまでの入力状態が履歴照会欄２２２に表示される。ユーザが、希望する履歴情報の再現を希望するとき、照会ボタン２２３が押下されると、（５）データ入力済みの画面が起動され、入力画面２１が再現される。

履歴照会画面２２は、記録された履歴情報をユーザが判別しやすい形式に変換して一覧表示するものである。従来、入力データの一覧は参照できるが、過去の入力画面との対応ができていなかった。このため、履歴情報を用いて処理の再実行をしたい場合、例えば、一部の入力項目のデータを修正して再入力し登録したい場合、現在表示できる入力画面を用いて、ユーザによる入力が必要となり手間がかかることがある。

本実施形態によれば、履歴紹介画面を従来の項目一覧の照会に加えて、履歴情報を用いてユーザが入力した画面を照会画面として利用をすることで、ユーザ入力内容の直感的把握、および入力した画面を利用するための処理の再実行を可能とするものである。

ただし、Ｗｅｂアプリケーションにおける画面のプログラムの変更が行われた場合、プログラムが上書きされるため、本方式では、画面プログラムを定義情報とすることにより、プログラムそのものも履歴管理して再実行を可能にするものである。

図６は、履歴情報を示す説明図である。履歴情報ＤＢ６５に格納される履歴情報には、入力画面の識別ＩＤである画面ＩＤ、ユーザのＩＤであるユーザＩＤ、入力時の日付および時刻である入力日時、アプリケーションの種別である画面種別、入力時の要求指令であるアクション情報、入力項目の入力データである入力情報を履歴情報変換部５７（図１参照）で変換された変換入力情報（図１０参照）を有する。なお、破線部分は、例えば、履歴照会画面２２（図５参照）に表示される一覧照会対象の項目である。また、変換入力情報は、画面を再生する場合に必要となる詳細照会対象の項目である。

図７は、各情報ＤＢのレイアウトを示す説明図である。図７（а）に示す画面情報ＤＢ６１に格納されるテーブルは、利用する画面のＩＤを記録する画面ＩＤ、画面定義の適用開始の日付である適用開始日付、画面定義の適用終了の日付である適用終了日時、画面定義の実体である画面定義の情報を有する。具体的には、図８を参照して説明する。

図８は、画面情報ＤＢのレイアウトを示す説明図である。画面情報ＤＢ６１には、複数の画面定義の情報を含まれている。具体的には、（１）２００６年１月１日から２００６年１２月３１日まで有効である画面定義の情報、（２）２００７年１月１日から２００７年１２月３１日まで有効である画面定義の情報、（３）２００８年１月１日から２００８年１２月３１日まで有効である画面定義の情報である。画面定義の情報は、履歴構造を持ちユーザが入力した当時の画面情報を有する。このことにより、画面の描画要求が２００７年６月１日の場合、履歴管理サーバ１０は、（２）の画面定義の情報を取得することができる。

図７に戻り、図７（ｂ）に示すアクション情報ＤＢ６２に格納されるテーブルは、利用する画面のＩＤを記録する画面ＩＤ、画面定義の適用開始の日付である適用開始日付、画面定義の適用終了の日付である適用終了日付、再実行を許可するか否かの識別子である再処理許可の識別子、アクション定義の実体であるアクション定義の情報を有する。具体的には、図９を参照して説明する。

なお、再処理許可の識別子は、例えば、再実行禁止フラグがある。再実行禁止フラグがＯＮとなっているとき、ユーザ入力再現画面２２０（図２２参照）における、アクション実行ボタン（例えば、登録ボタン）を全て非活性とする。再実行禁止フラグがＯＮとなるのは、履歴管理をしていないプログラムや、処理の再投入を意図的に禁止したい（データが壊れる可能性がある）場合に利用される。

図９は、アクション情報ＤＢのレイアウトを示す説明図である。アクション情報ＤＢ６２には、複数のアクション定義の情報を含まれている。具体的には、（１）２００６年１月１日から２００６年１２月３１日まで有効であるアクション定義の情報、（２）２００７年１月１日から２００７年１２月３１日まで有効であるアクション定義の情報、（３）２００８年１月１日から２００８年１２月３１日まで有効であるアクション定義の情報である。画面定義情報は、履歴構造を持ちユーザが入力した当時に画面情報を有する。このことにより、画面の描画要求が２００７年６月１日の場合、履歴管理サーバ１０は、（２）のアクション定義情報を取得することができる。

図７に戻り、図７（ｃ）に示す画面項目情報ＤＢ６３のテーブルは、項目のＩＤである項目ＩＤ、項目の適用開始の日付である適用開始日付、項目の適用終了の日付である適用終了日付、項目の名称である表示名称を有する。

図７（ｄ）に示す履歴情報ＤＢ６５のテーブルは、入力した画面を特定するＩＤである画面ＩＤ、入力したユーザを特定するＩＤであるユーザＩＤ、入力した日時である入力日時、ユーザが実行した処理名（例えば、検索、終了、登録）である実行処理名、画面の種別である履歴種別（例えば、Ｗｅｂ、リッチクライアント、Ｃ/Ｓ）、履歴情報変換部５７（図１参照）により変換された後の入力情報の実体である変換入力情報（図１０参照）を有する。なお、図７に示した２種類以上のテーブルを１つのテーブルに纏めて、情報ＤＢを作成することもできる。

図１０は、変換入力情報のデータ構造を示す説明図である。図１０には、ＸＭＬ本体とＸＭＬフォーマットを示す。変換入力情報は、具体的には、履歴情報変換部５７（図１参照）によりユーザ入力内容である入力情報をＸＭＬ形式で生成する。特徴としては、以下の２つがある。
特徴１：ＸＭＬ形式でタグ構造とすることで画面単位の履歴構造にできる。
特徴２：履歴情報が画面レイアウトと同じ構造を持つ。このことにより、画面の種別に関わらず、共通の構造にできる。

次に、処理フローについて、図１１〜図２２を参照して詳細に説明する。
図１１は、履歴管理システムの処理概要を示すフローチャートである。適宜図１および図５を参照して説明する。図５に示す（１）アプリケーションが起動されると、履歴管理サーバ１０は、画面情報、画面項目情報を基に画面を生成する（処理＃０）。クライアントＰＣ２０は、画面種別（Ｗｅｂ、リッチクライアント、Ｃ／Ｓ）に応じて画面を描画する。このとき、各画面の項目はキーとなる情報を有する。例えば、生成された画面が図５に示す入力画面２１であり、画面ＩＤはＧ０２である。ここでは、アプリケーションをＷｅｂアプリケーションとして、以下説明する。

ユーザが入力画面２１に必要項目を入力し登録ボタンを押下すると、クライアントＰＣ２０は、生成画面からの登録要求を送信する（処理＃１）。具体的には、クライアントＰＣ２０は、画面ＩＤ，ユーザＩＤ、ボタン押下後の処理名称（以降、アクションという。）、入力情報である画面項目キーおよび入力項目情報等を履歴管理サーバ１０へ送信する。

履歴管理サーバ１０は、受信した情報から入力情報およびアクション情報を取得する（処理＃２）。予め保存されている画面情報と画面項目情報を用いて、入力情報を変換入力情報に変換する（処理＃３）。変換入力情報に画面ＩＤ、入力日時、画面種別、ボタン種別等のヘッダ情報を付与して、履歴情報ＤＢ６５に保存する（処理＃４）。処理＃４は、図５に示す（２）入力データの保存に該当する。

図５に示す履歴照会画面２２において、検索キーに入力されてＥｎｔｅｒが押下されると、クライアントＰＣ２０は検索要求を送信し、履歴管理サーバ１０は、履歴情報の検索要求を受信する（処理＃５）。そして、検索結果をクライアントＰＣ２０に回答する。履歴照会画面２２において、照会ボタン２２３が押下されると、履歴管理サーバ１０は、照会要求を受信する（処理＃６）。照会要求に基づいて、履歴情報より照会画面を生成する（処理＃７）。図５に示す（５）データ入力済みの画面を起動し、クライアントＰＣは照会した入力画面２１を表示部に表示する。そして、ユーザが必要項目を修正して登録ボタンが押下されると、クライアントＰＣ２０は、照会画面である入力画面２１からの登録要求を送信する（処理＃８）。そして、処理＃２に戻り、再登録の処理をする。
以上が、一連の処理の流れであるが、主要な処理については、さらに詳細に説明する。

図１２は、画面生成から入力情報取得までの詳細を示すフローチャートである。図１２に示す処理＃０、処理＃１、処理＃２は、図１１の処理内容をさらに詳細に示している。履歴管理プログラム５０の画面定義取得部５１は、アプリケーションが起動されると、システム利用日付に一致する画面定義情報を、画面情報ＤＢ６１から検索して読込み（処理Ｓ０１）、画面定義取得部５１は、システム利用日付に一致する画面項目情報を、画面項目情報ＤＢ６３から読込み（処理Ｓ０２）、画面生成ロジック中で、画面出力制御部５２は、画面定義の画面情報から画面レイアウトを生成し、表示名を取得し画面を生成する（処理Ｓ０３）。具体的な処理の流れを、図１３を参照して説明する。

図１３は、画面生成ロジックの処理内容を示す説明図である。画面生成ロジックで実行される処理＃０は、画面定義取得部５１および画面出力制御部５２で実現される。符号１３１に示す画面情報は、図８に示すシステム利用日付に該当する画面定義のファイル情報である。具体的には、符号１３１から、画面ＩＤに含まれる項目数は５(koumoku_a、koumoku_b、koumoku_c、koumoku_d、koumoku_e)であり、表形式となっている項目数は３(koumoku_c、koumoku_d、koumoku_e)であることがわかる。符号１３２に示す画面項目情報は、画面に表示される実際の項目情報を示すものである。具体的には、koumoku_a、koumoku_b、koumoku_c、koumoku_d、koumoku_eは、それぞれ、項目Ａ、項目Ｂ、項目Ｃ、項目Ｄ、項目Ｅに対応している。画面生成ロジックにより、符号１３３の入力画面が生成される。また、符号１３４のアクション情報は、登録ボタン押下時の処理内容を示すものであり、図９に示すシステム利用日付に該当するアクション定義のファイル情報である。具体的には、登録アクションとして、登録チェック処理と、登録実行処理が含まれる。

本実施形態では、画面情報、アクション情報、画面項目情報は、図７に示すように、利用期間の単位（適用開始の日付から適用終了の日付までの単位）にファイルを有する。履歴管理サーバ１０は、現在のシステム利用日付に一致する各定義ファイルを選択して、画面を生成する。定義を使用しない通常のＪＳＰ（JavaServer Pages）画面の場合は、プログラム情報ＤＢ６４から、システム利用日付に該当するプログラムのファイルを取得する。なお、本実施形態の場合は、図１においてプログラムのファイルは、プログラム情報ＤＢ６４に格納しているが、画面情報の一種であるので画面情報ＤＢ６１に格納してもよい。

図１２に戻り、入力画面にデータを入力して登録ボタンが押下されると、クライアントＰＣ２０は、生成画面に入力された入力情報の登録要求を受信し（処理Ｓ１１）、クライアントＰＣ２０は、入力情報を履歴管理サーバ１０に送信する（処理Ｓ１２）。履歴管理サーバ１０は、クライアントＰＣ２０からの入力情報を受信すると（処理Ｓ２１）、システム利用日付に一致するアクション情報を読み込み（処理Ｓ２２）、入力情報を用いて、アクション情報で指定される処理を実行する（処理Ｓ２３）。具体的な処理の流れを、図１４を参照して説明する。

図１４は、データ送信ロジックの処理内容を示す説明図である。データ送信ロジックで実行される処理＃１、処理＃２は、クライアントＰＣのＣＰＵ（不図示）で実現される。符号１４１の入力画面は、図１３の符号１３３の入力画面にデータが入力された状態を示している。符号１４２は、履歴管理サーバ１０に送信される情報であり、具体的には、画面ＩＤ、入力日時、実行処理名（ボタン名）、画面種別、入力者ＩＤ、および入力情報である。入力情報には、リクエストとして各画面種別により履歴管理サーバ１０が受信できる形式に変換する。具体的には、各項目のＩＤと、実際に入力されたデータとが関連付けられている（例えば、koumoku_a＝dataＡ）。

図１５は、入力情報に基づいて履歴情報を履歴情報ＤＢへ保存するまでの詳細を示すフローチャートである。図１５に示す処理＃３、処理＃４は、図１１の処理内容をさらに詳細に示している。画面情報と入力情報を入力にして、履歴情報変換ロジックを実行する（処理Ｓ３１）。履歴情報変換ロジックで実行される処理＃３は、詳細は後記するが、画面種別判定部５３、履歴情報変換部５７、履歴情報生成部５４で実現される。履歴情報変換ロジックは、入力情報を画面情報に当てはめ、ユーザが入力していた画面定義と同じ構造を持つ形式（汎用履歴形式）に変換し（処理Ｓ３２）、変換した変換入力情報とヘッダ情報を入力にして、履歴保存ロジックを実行する（処理Ｓ３３）。そして、履歴保存ロジックは、生成された履歴情報を履歴情報ＤＢに保存する（処理＃４）。具体的な処理の流れを、図１６〜図１８を参照して説明する。

図１６は、履歴情報変換ロジックの処理を示すフローチャートである。履歴情報変換ロジックは、リクエストを汎用履歴形式に変換するロジックである。画面種別判定部５３は、画面種別を判定し（処理Ｓ１０１）、画面種別がＪＳＰの場合（処理Ｓ１０１，ＪＳＰ）、処理Ｓ１０２に進む。画面種別がＣ／Ｓの場合（処理Ｓ１０１，Ｃ／Ｓ）、Ｃ／Ｓシステム用ＸＭＬ生成の処理フロー（詳細は不図示）に進む。なお、図１６においては、他のアプリケーションの場合も同様の処理フローであるので、省略している。

履歴情報生成部５４は、受信した入力情報のデータ分を処理Ｓ１０２〜処理Ｓ１０４で繰り返す。すなわち、入力形式を判定し（処理Ｓ１０３）、単項目構造のとき（処理Ｓ１０３，単項目構造）、単項目タグを生成する（処理Ｓ１０４）。リスト構造のとき（処理Ｓ１０３，リスト構造）、開始の繰り返しタグを生成する（処理Ｓ１０５）。そして、繰り返し回数を繰り返す（処理Ｓ１０６〜処理Ｓ１０８）。履歴情報生成部５４は、入力形式を判定し（処理Ｓ１０７）、単項目構造のとき（処理Ｓ１０７，単項目構造）、単項目タグを生成する（処理Ｓ１０８）。リスト構造のとき（処理Ｓ１０７，リスト構造）、終了の繰り返しタグを生成する（処理Ｓ１０９）。そして、処理Ｓ１０２に戻る。

本実施形態の履歴変換ロジックは、判定した画面種別に応じたユーザ入力内容をＸＭＬ形式で生成する。このときＸＭＬへの変換ロジックは、（１）画面種別に関わらず同一となること、（２）元の入力情報（リクエスト）に復元ができることを実現するため、リクエストの構造を表現する統一の形式とする。ここでは、入力情報はＨａｓｈＭａｐの形式を採用し、画面の識別子である画面キー情報と、入力値を単体で持つ場合と、さらに同ＨａｓｈＭａｐが繰返し利用される場合の２種類がある。これは、画面がヘッダ形式と明細（複数）の２種類があり、２種類に対応したリクエストを生成する場合の構造である。具体的な変換方法については、さらに図１７を参照して説明する。

図１７は、履歴情報変換ロジックの処理内容を示す説明図である。図１４に示した符号１４２のクライアントから送信された情報と、符号１７１の画面定義の画面定義区分を読み取り、画面定義区分に一致するフォーマットに入力情報を変換する。変換された入力情報が符号１７２に示されている。本実施形態では、履歴管理サーバ１０に送信された入力情報を画面定義に従い、入力情報を画面レイアウト情報を有する変換入力情報に変換することが特徴である。

図１８は、履歴保存ロジックの処理内容を示す説明図である。履歴情報生成部５４は、図１７に示す符号１４２から抽出した符号１８１のヘッダ情報と、符号１７２の変換入力情報とを関連付けて履歴情報ＤＢ６５に登録する。

図１８に示すように、履歴情報には、符号１７２の変換入力情報のほかに、付与情報として、符号１８１のユーザの操作情報であるヘッダ情報が含まれる。ヘッダ情報には、画面ＩＤ、入力日時、ユーザＩＤ（不図示）、実行処理名（アクション情報）、ログ区分（画面種別）がある。付与情報を追加することで、「画面ＩＤのプログラムから」、「ｙｙｙｙ／ｍｍ／ｄｄ ｈｈ：ｍｍ ｓｓ：ｓｓ：ｓｓに」、「ユーザＩＤが」、「ＸＸＸアクション処理を」、「ログ区分の画面から」、「変換入力情報」を入力に処理をした履歴となる。

本実施形態において、履歴の取得タイミングは、ユーザから履歴管理サーバ１０に処理を投入するアクションを実施した時点（主にボタンを押下した時点）である。本実施形態では「ユーザがデータベースサーバのデータを登録、更新、削除、検索した内容の履歴を残すこと」が特徴であるため、ユーザがクライアントＰＣ２０で操作した内容は履歴として取得しない。例えば、Ｗｅｂブラウザ中に操作履歴のＳｃｒｉｐｔを埋め込むことで、「（１）画面を起動した」→「（２）項目Ｘ１に値Ｙ２を入力した」→「（３）項目Ｘ１に値Ｙ２を入力した」→「（４）ＺＺボタンを押下した」とクライアントアプリケーション側でユーザが入力した流れを記録した場合、履歴管理サーバ１０上のデータに対してデータ操作を実施しているのは実情（１）と（４）のみである。また、クライアントアプリケーションの操作情報を履歴とする場合、各クライアント別に処理を埋め込む必要があるが、本方式で示すように、アプリケーションサーバである履歴管理サーバ１０に共通の仕組みを１つ組み込めばよい。また、例えば、登録ボタンを押下した、検索ボタンを押下した等のタイミングで記録処理を行い、処理の関連性を読み取り、アクション情報付与することで履歴情報の管理を容易にしている。

本実施形態の特徴は、ユーザが画面から入力した入力情報を、画面定義を基に画面レイアウトと同様の構造に入力情報を変換することである。これにより、従来は入力情報を履歴として保存は実施されていたが、画面の種別が異なると、基の画面種別専用の履歴保存ロジック、専用データ形式をもとに変換する必要があった。また過去のデータを照会する場合には、画面種別の照会ロジックが必要であった。これに対し、本実施形態では、入力された画面種別に関わらず、共通の処理で入力情報を履歴情報として保存、保存された履歴情報の照会が可能である。また、後記するが、履歴情報に画面構造を持たせることで、ユーザが入力した画面を、再現・処理の再実行が可能である。

図１９は、履歴情報を用いた画面生成の処理を示すフローチャートである。図５に示す履歴照会画面２２の照会ボタン２２３が押下されると、入力画面再生成部５８（図１参照）が起動される。入力画面再生成部５８は、履歴情報ＤＢ６５から、画面ＩＤ、ユーザＩＤ、入力日時を基に履歴情報を読み込み（処理Ｓ１２１）、画面種別をチェックする（処理Ｓ１２２）。ここでは、例としてＷＥＢとする。履歴情報をリクエストに変換する（処理Ｓ１２３）。リクエストとは、履歴情報を、各画面種別によりサーバが受信できる形式に変換することをいう。そして、画面ＩＤに該当する画面定義を取得開始し（処理Ｓ１２４）、画面定義履歴があるか否かを判定する（処理Ｓ１２５）。画面定義履歴がある場合（処理Ｓ１２５、Ｙｅｓ）、履歴情報の入力日時に該当する画面定義（図８参照）、アクション定義（図９参照）を読込み（処理Ｓ１２７）、取得した定義で画面を再生する（処理Ｓ１２６）。処理Ｓ１２５において、画面定義履歴がない場合（処理Ｓ１２５，Ｎｏ）、プログラム情報ＤＢ６４からプログラムを取得し画面を再生する（処理Ｓ１２６）。

次に、入力画面再生成部５８は、再実行許可フラグを取得し（処理Ｓ１２８）、再実行許可されているか判定する（処理Ｓ１２９）。再実行許可されていない場合（処理Ｓ１２８，Ｎｏ）、アクション発行ボタン、入力項目をすべて禁止（利用不可）に設定し（処理Ｓ１３１）、リクエストを元に、画面ＩＤ、画面種別に該当する画面の描画要求をクライアントＰＣ１０に送信する（処理１３０）。処理Ｓ１２９において、再実行許可されている場合（処理Ｓ１２９，Ｙｅｓ）、処理Ｓ１３０に進む。具体的な処理の流れを、図２０および図２１を参照して説明する。なお、再実行許可されていない場合とは、再実行禁止フラグがＯＮのときであり、再実行許可されている場合とは、再実行禁止フラグがＯＦＦのときである。

図２０および図２１は、履歴照会ロジックの処理内容を示す説明図である。履歴照会ロジックは、入力画面再生成部５８によって実現される。図２０に示すように、入力画面再生成部５８は、履歴情報ＤＢ６５から、符号２０１のヘッダ情報、符号２０２の変換入力情報を取得する。符号２０１のヘッダ情報内の日時に該当する画面定義を、画面情報ＤＢ６１から取得する。具体的には、日時が２００７年１２月１日であるので、取得された画面定義は、符号２０３の２００７年１月１日〜２００７年１２月３１日のファイルである。

図２１に示すように、入力画面再生成部５８は、（Ａ）に示すルートによって、画面項目情報ＤＢ６３から符号２０１の日時に該当する画面項目、符号２０３の画面定義を取得する。（Ｂ）に示すルートによって、取得した画面定義に符号２０２の変換入力情報を当て込み、ユーザが入力した画面を再生成（再現）し、クライアントＰＣ２０には、表示部にユーザ入力再現画面２２０が再現される。具体的には、図２２を参照して説明する。

図２２は、登録処理の再実行の処理内容を示す説明図である。図２１で説明したユーザ入力再現画面２２０には、項目Ａ、項目Ｂ、項目Ｃ、項目Ｄ、項目Ｅに入力欄を含む画面が再現されており、過去に、ユーザが入力した入力データも再現されている。また、ここでは、アクション実行ボタンのひとつである登録ボタンは、再実行可能（再実行禁止フラグがＯＦＦ）となっている。

ユーザが再登録を行う必要があるときは、各項目の入力を変更し登録ボタンが押下された場合、履歴管理サーバ１０は、処理再実行ロジックが実行される。処理再実行ロジックは、画面種別判定部５３、履歴情報生成部５４、履歴情報出力部５５によって実現される。基本的には、図１４〜図１８に示した登録時と同様の処理を実行するので、詳細な説明は省略する。図１４と異なるのは、入力日時が、現在の入力日時ではなく、符号２１１のファイルに示す過去に登録された日時（例えば、２００７年１２月１日）をキーとして、入力当時のアクション情報ＤＢ６２に基づいてアクション定義を取得し、処理を実行することである。なお、現在の入力日時である再登録の入力日時は、過去に登録された入力日時（既登録の入力日時）と関連づけて履歴情報（図６参照）に登録することが好ましい。

本実施形態では、図５に示すように、履歴照会画面２２の照会ボタン２２３が押下されると、履歴管理サーバ１０は、履歴が記録された日に処理を実行されたとみなして、履歴が記録された日の画面定義情報を取得する。これに対し、図６に示した履歴情報に履歴管理フラグを有していてもよい。履歴管理サーバ１０の管理者により、履歴管理フラグがＯＦＦにされていると、常に最新の情報を取得することになる。また、履歴管理されていないときは、デフォルトとして、最新の情報を取得するように設定しておいてもよい。

本実施形態によれば、画面の形式（Ｗｅｂ、リッチクライアント、Ｃ／Ｓ等）に関わらず、１つの履歴情報データベースで管理ができ、複数システム間にまたがるユーザの操作履歴を把握でき、不正データの発見が容易となる。また、履歴情報が画面の構造情報を持つため入力画面を再現できる。これにより、履歴情報から誤りのデータが入力されていることが判明した場合、履歴情報から、入力画面を完全に再現して、変更が必要な最低限の項目のみ修正、処理の再実行ができ入力のコストが大幅に抑えられる。

本実施形態によれば、図５に示すように、入力画面２１から履歴管理サーバ１０に対して登録要求をすると、入力画面２１から履歴管理サーバ１０に渡された入力情報の画面レイアウト構造を含む汎用形式に変換し、履歴情報ＤＢ６５に保存する。履歴情報を照会する場合は、履歴照会画面２２から照会要求すると、履歴情報ＤＢ６５に保存されている履歴情報を、登録されている入力時点の画面形式に履歴情報を変換して、ユーザが過去に入力した画面および入力情報をそのまま再現することができる。

本実施形態の履歴管理システムの全体構成を示すブロック図である。 各種アプリケーションの起動方法を示す説明図である。 メニュー画面からの起動例を示す説明図である。 各種アプリケーションの実行形態を示す説明図である。 本実施形態の骨子を示す概略図である。 履歴情報を示す説明図である。 各情報ＤＢのレイアウトを示す説明図である。 画面情報ＤＢのレイアウトを示す説明図である。 アクション情報ＤＢのレイアウトを示す説明図である。 変換入力情報のデータ構造を示す説明図である。 履歴管理システムの処理概要を示すフローチャートである。 画面生成から入力情報取得までの詳細を示すフローチャートである。 画面生成ロジックの処理内容を示す説明図である。 データ送信ロジックの処理内容を示す説明図である。 入力情報に基づいて履歴情報を履歴情報ＤＢへ保存するまでの詳細を示すフローチャートである。 履歴情報変換ロジックの処理を示すフローチャートである。 履歴情報変換ロジックの処理内容を示す説明図である。 履歴保存ロジックの処理内容を示す説明図である。 履歴情報を用いた画面生成の処理を示すフローチャートである。 履歴照会ロジックの処理内容を示す説明図である。 履歴照会ロジックの処理内容を示す説明図である。 登録処理の再実行の処理内容を示す説明図である。

符号の説明

１０ 履歴管理サーバ（情報処理装置）
１１ 出力装置
１２ 入力装置
１３ ＣＰＵ
１４ 通信装置
１５ メモリ
１６ 外部記憶装置
１７ バス
２０ クライアントＰＣ
２１ 入力画面
２２ 履歴照会画面
３０ ネットワーク
４０ メニュー部プログラム
５０ 履歴管理プログラム
５１ 画面定義取得部（画面定義取得手段）
５２ 画面出力制御部
５３ 画面種別判定部（画面種別判定手段）
５４ 履歴情報生成部（履歴情報生成手段）
５５ 履歴情報出力部
５６ 履歴一覧出力部
５７ 履歴情報変換部（履歴情報変換手段）
５８ 入力画面再生成部（入力画面生成手段）
６１ 画面情報ＤＢ
６２ アクション情報ＤＢ
６３ 画面項目情報ＤＢ
６４ プログラム情報ＤＢ
６５ 履歴情報ＤＢ
７０ ＷｅｂアプリケーションＤＢ
７１ リッチクライアントアプリケーションＤＢ

Claims (9)

1. 入力項目を有する入力画面から入力された入力情報が登録される記憶装置を備え、登録された入力情報とともに入力された時点の入力画面を再現する情報処理装置であって、
   前記記憶装置に、前記入力画面を適用する開始日時と終了日時が定義される画面情報と、前記入力情報の入力日時と関連づけて登録される履歴情報と、を記憶しており、
   前記記憶装置に既に登録された既登録の入力日時を含む入力画面の照会要求を受理すると、前記入力画面を適用する開始日時と終了日時から前記既登録の入力日時に該当する画面情報を取得するとともに、前記既登録の入力日時の履歴情報を取得する画面定義取得手段と、
   前記取得した画面情報に、前記取得した既登録の入力日時の履歴情報を当てはめて、入力画面を再現する入力画面生成手段と、を有する
   ことを特徴とする情報処理装置。
2. 前記情報処理装置は、再現した入力画面を介して再登録の再登録要求を受理すると、前記記憶装置に記憶される前記既登録の入力日時の履歴情報に、前記再登録の入力情報を上書きし、前記再登録要求の入力日時を、前記既登録の入力日時と関連づけて前記履歴情報に登録する履歴情報生成手段を有する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記画面情報は、入力項目およびデータ値で構成される単項目と、前記単項目を複数含むことを定義される表形式定義と、から構成される画面定義を有し、
   前記入力情報を、前記画面定義で定義される画面レイアウトの構造を含む履歴情報に変換する履歴情報変換手段と、を有する
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記履歴情報は、ＸＭＬ(eXtensible Markup Language)を用いて記述されている
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記画面情報は、入力項目およびデータ値で構成される単項目と、前記単項目を複数含むことを定義される表形式定義と、から構成される画面定義を有し、
   前記入力情報には、Ｗｅｂアプリケーション、リッチクライアントアプリケーション、Ｃ/Ｓ(Customer/Server)アプリケーションであるかの画面種別情報を有し、
   前記入力情報の登録要求を受理すると、前記画面種別情報を判定する画面種別判定手段と、
   前記入力情報を、前記画面種別判定手段で判定された前記画面種別に応じた前記画面定義で定義される画面レイアウトの構造を含む変換入力情報に変換し、前記変換入力情報に画面ＩＤ、入力日時、画面種別のヘッダ情報を関連づけて前記記憶装置に登録する履歴情報変換手段と、を有する
   ことを特徴とする請求項１に記載の情報処理装置。
6. 入力項目を有する入力画面から入力された入力情報が登録される記憶装置を備え、前記記憶装置に、前記入力画面を適用する開始日時と終了日時が定義される画面情報と、前記入力情報を入力日時と関連づけて登録される履歴情報と、を記憶しており、登録された入力情報とともに入力された時点の入力画面を再現する情報処理方法であって、
   画面定義取得手段が、前記記憶装置に既に登録された既登録の入力日時を含む入力画面の照会要求を受理すると、前記入力画面を適用する開始日時と終了日時から前記既登録の入力日時に該当する入力された時点の画面情報を取得し、前記既登録の入力日時の履歴情報を取得し、
   入力画面生成手段が、前記取得した画面情報に、前記取得した既登録の入力日時の履歴情報を当てはめて、入力画面を再現する
   ことを特徴とする情報処理方法。
7. 履歴情報生成手段が、再現した入力画面を介して再登録の再登録要求を受理すると、前記既登録の入力日時の履歴情報に、前記再登録の入力情報を上書きし、前記再登録要求の入力日時を、前記既登録の入力日時と関連づけて前記履歴情報に登録する
   ことを特徴とする請求項６に記載の情報処理方法。
8. 前記画面情報は、入力項目およびデータ値で構成される単項目と、前記単項目を複数含むことを定義される表形式定義と、から構成される画面定義を有し、
   履歴情報変換手段が、前記入力情報を、前記画面定義で定義される画面レイアウトの構造を含む履歴情報に変換する
   ことを特徴とする請求項６に記載の情報処理方法。
9. 前記履歴情報は、ＸＭＬ(eXtensible Markup Language)を用いて記述されている
   ことを特徴とする請求項６に記載の情報処理方法。

Images