(57)【要約】【課題】電子商取引において顧客の利便性を向上させる。【解決手段】データ保持部３０は、各業務プロセスを実行することにより発生する負荷の大きさをプロセス負荷として保持する。データ処理部５０は、定期的に電子商取引装置１００で発生している負荷を装置負荷として取得する。ユーザインタフェース処理部１０は、ローンの申込み情報を複数の顧客端末３０４から受信する。データ処理部５０は、データ保持部３０を参照して、複数の申込み情報に基づき実行すべき業務プロセスの中から、装置負荷とプロセス負荷とに基づき、実行対象の業務プロセスを決定して実行する。ユーザインタフェース処理部１０が取引結果要求を受信すると、データ処理部５０は業務プロセスの処理結果を取得して、ユーザインタフェース処理部１０を介して、当該処理結果を顧客端末３０４または社員端末３００に送信する。【選択図】図２
2009134471.tif 000002
【特許請求の範囲】
【請求項１】
所定の電子商取引サービスを顧客に提供するために、前記所定の電子商取引を実現する一連の業務プロセスを有する装置であって、
各業務プロセスと、各業務プロセス実行により発生する負荷の大きさを示すプロセス負荷とが対応づけられた個別負荷情報を保持する個別負荷情報保持部と、
当該装置で発生している負荷の大きさを装置負荷として取得する装置負荷取得部と、
複数の顧客の端末から前記電子商取引を要求する申込み情報を受信する申込み情報受信部と、
業務プロセスの実行に許容される負荷の大きさを示す許容負荷を前記取得された装置負荷に応じて決定し、前記個別負荷情報を参照して、複数の前記申込み情報に基づき実行すべき業務プロセスの中から、前記許容負荷以下のプロセス負荷に対応づけられている業務プロセスを実行対象として決定する実行プロセス決定部と、
前記実行対象として決定された業務プロセスを実行する業務プロセス実行部と、
特定の申込み情報に基づく電子商取引の結果を要求する取引結果要求を所定のユーザの端末から受信したとき、前記特定の申込み情報に対応づけられた一連の業務プロセスの実行結果を前記ユーザの端末に送信する取引結果通知部と、
を備えることを特徴とする電子商取引装置。
【請求項２】
前記実行プロセス決定部は、前記取引結果通知部により取引結果要求が受信され、前記一連の業務プロセスのいずれかが未実行であるとき、前記取得された装置負荷にかかわらず、前記未実行の業務プロセスを実行対象として決定することを特徴とする請求項１に記載の電子商取引装置。
【請求項３】
データベースに対するトランザクションを制御するトランザクション制御部をさらに備え、
前記業務プロセス実行部は、データベースに対するトランザクション処理を含む複数の業務プロセスを実行し、
前記トランザクション制御部は、前記複数の業務プロセスによるトランザクション処理を一度に確定し、または一度に取り消すことを特徴とする請求項１または２に記載の電子商取引装置。
【請求項４】
前記トランザクション制御部は、前記データベースに対するトランザクション処理が取り消されたときに前記データベースを当該トランザクション処理前の状態に回復するための情報を保持する領域の使用量に応じて、トランザクション処理を確定し、または取り消すことを特徴とする請求項３に記載の電子商取引装置。
【請求項５】
前記業務プロセス実行部は、所定の申込み情報に対する処理であって、所定のデータベースに対する第１のトランザクション処理を含む新規の業務プロセスを実行して、前記第１のトランザクション処理の結果を取得し、
前記トランザクション制御部は、前記所定のデータベースにおける前記第１のトランザクション処理を取り消し、
前記業務プロセス実行部は、前記所定の申込み情報に対する処理であって、前記所定のデータベースに対する第２のトランザクション処理を含む従来の業務プロセスを実行して、前記第２のトランザクション処理の結果を取得し、前記第１および第２のトランザクション処理の比較結果を出力することを特徴とする請求項３に記載の電子商取引装置。
【請求項６】
所定の電子商取引サービスを顧客に提供するために、前記所定の電子商取引を実現する一連の業務プロセスを有する装置に、
各業務プロセスと、各業務プロセス実行により発生する負荷の大きさを示すプロセス負荷とが対応づけられた個別負荷情報を保持する機能と、
当該装置で発生している負荷の大きさを装置負荷として取得する機能と、
複数の顧客の端末から前記電子商取引を要求する申込み情報を受信する機能と、
業務プロセスの実行に許容される負荷の大きさを示す許容負荷を前記取得された装置負荷に応じて決定し、前記個別負荷情報を参照して、複数の前記申込み情報に基づき実行すべき業務プロセスの中から、前記許容負荷以下のプロセス負荷に対応づけられている業務プロセスを実行対象として決定する機能と、
前記実行対象として決定された業務プロセスを実行する機能と、
特定の申込み情報に基づく電子商取引の結果を要求する取引結果要求を所定のユーザの端末から受信したとき、前記特定の申込み情報に対応づけられた一連の業務プロセスの実行結果を前記ユーザの端末に送信する機能と、
を実現させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電子商取引技術に関する。
【背景技術】
【０００２】
近年、コンピュータの普及とネットワーク技術の進展にともない、ネットワークを介した電子情報の交換が盛んになっている。商取引の多くも、ネットワークを介したいわゆる電子商取引に移行しつつあり、最近ではインターネット上にさまざまな電子商取引サイトが開設されている。
【特許文献１】特開平１１−２５０１５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
電子商取引を申込む旨の申込み情報を顧客から受け付けた電子商取引装置は、通常、複数の業務プロセスを様々な業務処理装置に実行させることにより、電子商取引サービスを提供する。本明細書における「業務プロセス」は、「与信確認」や「経理処理」等、電子商取引を実現するための各業務を実行するソフトウェアモジュールを意味する。各業務プロセスの中には、その処理において多くのハードウェアリソースを使用するものもり、また、少ないハードウェアリソースしか使用しないものもある。多くのハードウェアリソースを使用する業務プロセスは、夜間にバッチ処理で実行されることが多い。
【０００４】
しかし、電子商取引サイトに対する顧客のアクセスは２４時間発生し得る。このときに、バッチ処理が実行されていると、ハードウェアリソースが逼迫するため、顧客へのレスポンスに時間がかかり、また、バッチ処理の時間帯にはそもそも顧客からのアクセスを受け付けない電子商取引サイトもある。その結果、顧客の利便性を低下させてしまう。
【０００５】
このような背景から、日中・夜間の区別無く、使用可能なハードウェアリソースに応じて、実行可能な業務プロセスを随時実行させることに本発明者は想到した。これにより、使用されるハードウェアリソースを平準化でき、顧客からのアクセスを常時受け付けることが可能となり、顧客の利便性を向上できると本発明者は考えた。
【０００６】
本発明は、本発明者の上記着目に基づいて完成された発明であり、その主たる目的は、電子商取引において顧客の利便性を向上させる技術を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の電子商取引装置は、所定の電子商取引サービスを顧客に提供するために、所定の電子商取引を実現する一連の業務プロセスを有する装置であって、各業務プロセスと、各業務プロセス実行により発生する負荷の大きさを示すプロセス負荷とが対応づけられた個別負荷情報を保持する個別負荷情報保持部と、当該装置で発生している負荷の大きさを装置負荷として取得する装置負荷取得部と、複数の顧客の端末から電子商取引を要求する申込み情報を受信する申込み情報受信部と、業務プロセスの実行に許容される負荷の大きさを示す許容負荷を取得された装置負荷に応じて決定し、個別負荷情報を参照して、複数の申込み情報に基づき実行すべき業務プロセスの中から、許容負荷以下のプロセス負荷に対応づけられている業務プロセスを実行対象として決定する実行プロセス決定部と、実行対象として決定された業務プロセスを実行する業務プロセス実行部と、特定の申込み情報に基づく電子商取引の結果を要求する取引結果要求を所定のユーザの端末から受信したとき、特定の申込み情報に対応づけられた一連の業務プロセスの実行結果をユーザの端末に送信する取引結果通知部と、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、電子商取引において顧客の利便性を向上できる。
【発明を実施するための最良の形態】
【００１０】
本発明の実施の形態について説明する前に、まず、本発明の概要について説明する。
現在の典型的なシステム運用では、ＣＰＵやメモリ等のハードウェアリソースの使用量が比較的少ない業務プロセスは、日中帯にオンライン処理で実行され、ハードウェアリソースの使用量が比較的多い業務プロセスは、夜間帯にバッチ処理で実行されている。このため、バッチ処理を実行する夜間帯はハードウェアリソースが逼迫するため、オンラインでのアクセスが停止されることが多い。
【００１１】
しかし、顧客からの注文等を受け付ける電子商取引サイトにおいては、顧客からのアクセスを２４時間受け付ける必要があり、バッチ処理の時間を確保するのが難しくなっている。また、顧客へのサービス提供の迅速化が要求されており、従来は夜間帯のバッチ処理で実行されていた業務プロセスも、可能な限り日中帯に実行されることが求められている。
【００１２】
この課題に対処する従来の方法は、多くのハードウェアリソースを備えるコンピュータを導入することであった。しかし、これには多大なコストを要し、また、業務処理量が少ないときにはハードウェアリソースの多くが遊休資産となってしまう。本発明者は、日中・夜間の区別無く、使用可能なハードウェアリソースに応じて、実行可能な業務プロセスを随時実行することで、バッチ処理による弊害の解消と、サービス提供の迅速化とを少ないコストで実現できると想到した。以下、実施の形態を説明する。
【００１３】
図１は、本実施の形態における電子商取引システム５００のハードウェア構成図である。
以下の説明において、電子商取引システム５００は、顧客によるローン申込みから、当該申込みを処理した結果の出力までを実現するシステムであるとして説明する。通信ネットワーク３０２は、ＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネット等を含む通信網である。電子商取引システム５００において、電子商取引装置１００は、インターネットを介して、複数の顧客端末３０４ａ、３０４ｂ、・・・３０４ｃ（以下、単に「顧客端末３０４」と呼ぶ）と接続されている。また、電子商取引装置１００は、ＬＡＮを介して、データベースサーバ２００と、複数の社員端末３００ａ、３００ｂ、・・・、３００ｃ（以下、単に「社員端末３００」と呼ぶ。）とに接続されている。
【００１４】
電子商取引装置１００は、ウェブサーバとしての機能を有し、顧客端末３０４にウェブページを送信する。このウェブページにより、顧客が電子商取引装置１００にアクセスするためのユーザインタフェースが提供される。顧客端末３０４および社員端末３００は、ウェブブラウザを搭載した一般的なウェブ端末である。
【００１５】
顧客は、顧客端末３０４を操作し、ウェブページを介して、ローン申込み情報を入力する。電子商取引装置１００は、顧客端末３０４からローン申込み情報を受信して、ローンの申込み情報に対する各種の処理を実行する。また、電子商取引装置１００は、各種の処理の結果をデータベースサーバ２００に記録する。
【００１６】
図２は、電子商取引装置１００の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００１７】
電子商取引装置１００は、ユーザインタフェース処理部１０と、データ保持部３０と、データ処理部５０とを有する。
ユーザインタフェース処理部１０は、顧客や社員とのユーザインタフェース処理を担当する。データ保持部３０は、各種データを保持するための記憶領域である。データ処理部５０は、ユーザインタフェース処理部１０やデータ保持部３０から取得されたデータをもとにして各種のデータ処理を実行する。データ処理部５０は、ユーザインタフェース処理部１０とデータ保持部３０との間のインタフェースの役割も果たす。
【００１８】
ここで、電子商取引装置１００における処理の概要を説明する。データ保持部３０は、各業務プロセスを実行することにより発生する負荷の大きさをプロセス負荷として保持する。データ処理部５０は、定期的に電子商取引装置１００で発生している負荷を装置負荷として取得する。ユーザインタフェース処理部１０は、ローンの申込み情報を複数の顧客端末３０４から受信する。データ処理部５０は、データ保持部３０を参照して、複数の申込み情報に基づき実行すべき業務プロセスの中から、装置負荷とプロセス負荷とに基づき、実行対象の業務プロセスを決定して実行する。ユーザインタフェース処理部１０が取引結果要求を受信すると、データ処理部５０は業務プロセスの処理結果を取得して、ユーザインタフェース処理部１０を介して、当該処理結果を社員端末３００または顧客端末３０４に送信する。
【００１９】
ユーザインタフェース処理部１０：
ユーザインタフェース処理部１０は、申込み情報受信部１２と、確認情報送信部１４と、取引結果要求受信部１６と、取引結果送信部１８とを含む。
【００２０】
申込み情報受信部１２は、顧客端末３０４から送信された顧客の「ローン申込み情報」を受信する。確認情報送信部１４は、顧客から受け付けたローン申込み情報に基づき決定された貸付額等を含む確認情報を顧客端末３０４に通知する。例えば、電子メールの送信により通知してもよい。取引結果要求受信部１６は、特定のローン申込み情報に基づき実行された一連の業務プロセスの実行結果を要求する「取引結果要求」を社員端末３００または顧客端末３０４から受信する。取引結果送信部１８は、取引結果要求への応答として、特定のローン申込み情報に基づき実行された一連の業務プロセスの実行結果を社員端末３００または顧客端末３０４に送信する。
【００２１】
データ保持部３０：
データ保持部３０は、個別プロセス情報保持部３２と、許容負荷情報保持部３４と、実行順序情報保持部３６とを含む。
【００２２】
個別プロセス情報保持部３２は、電子商取引装置１００が顧客に提供する電子商取引サービスを実現する各業務プロセスの情報を記憶する。図３は、個別プロセス情報保持部３２のデータ構造を示す。業務プロセス欄１０２は、電子商取引サービス「ローン申込み」において実行される業務プロセスを記録する。同図では、取引履歴等から顧客の信用力を判定する「与信確認」、顧客に貸し付ける金額を決定する「貸付額決定」、顧客に貸付額等の確認情報を送信する「確認情報送信」、社内の経理システム等にアクセスする「経理処理」の４プロセスを示している。プロセス順序欄１０４は、業務プロセスの実行順序を記録する。同図では、「与信確認」、「貸付額決定」、「確認情報送信」、「経理処理」の順に業務プロセスが実行されることを示している。本実施の形態では、これら４つの業務プロセスは順次実行されるものとする。
【００２３】
プロセス負荷欄１０６は、各業務プロセスを実行した際に電子商取引装置１００において発生する負荷の大きさ（以下、「プロセス負荷」と呼ぶ。）を記録する。本実施の形態の説明における「負荷の大きさ」とは、典型的には、ハードウェアリソースの使用量を示し、例えば、ＣＰＵ使用時間、メモリ使用量、磁気記憶装置への入出力時間等を示す。同図では、「大」「中」「小」で示しているが、これは、ＣＰＵ使用時間等を所定の評価関数で抽象化したものである。例えば、ＣＰＵ使用時間が第１の閾値以上である場合にはプロセス負荷を「中」とし、ＣＰＵ使用時間が第２の閾値以上である場合にはプロセス負荷を「大」としてもよい。なお、この閾値は、電子商取引装置１００を保持する企業の経験に基づき設定されてもよく、実験により適切な値を算出して設定されてもよい。また、プロセス負荷欄１０６には、ＣＰＵ使用時間やメモリ使用量そのものが保持されてもよい。図２に戻る。
【００２４】
許容負荷情報保持部３４は、電子商取引装置１００において発生している負荷の大きさ（以下、「装置負荷」と呼ぶ。）と、各装置負荷の状況において業務プロセスの実行に許容される負荷の大きさ（以下、「許容負荷」と呼ぶ。）との対応関係を記憶する。図４は、装置負荷と許容負荷との対応関係を模式的に示す。同図では、縦軸に電子商取引装置１００のＣＰＵ使用率を示し、横軸にメモリ使用率を示している。許容負荷情報保持部３４は、図４で示した対応関係を表形式で保持してもよく、ＣＰＵ使用率・メモリ使用率を入力とし、許容負荷を出力とする関数として保持してもよい。
【００２５】
図４の領域１１２は、ＣＰＵ使用率およびメモリ使用率が比較的低い領域であり、このときには、プロセス負荷「大」「中」「小」いずれの業務プロセスの実行も許容される。領域１１６は、ＣＰＵ使用率またはメモリ使用率が比較的高い領域であり、このときには、プロセス負荷「小」の業務プロセスのみ実行が許容される。領域１１４における装置負荷は、領域１１２と領域１１６との中間であり、このときには、プロセス負荷「中」および「小」の業務プロセスの実行が許容される。また、各領域の境界値については、電子商取引装置１００を保持する企業の経験に基づき設定されてもよく、実験により適切な値を算出して設定されてもよい。なお、装置負荷として、ＣＰＵ使用率やメモリ使用率以外にも、例えば、磁気記憶装置アクセス時間や、所定のアプリケーションを実行した際の実行時間を領域判定のパラメータとしてもよい。図２に戻る。
【００２６】
実行順序情報保持部３６は、顧客からの申込み情報に基づき、電子商取引装置１００において実行すべき業務プロセスの実行順序（以下、「実行順序情報」と呼ぶ。）を記憶する。図５は、実行順序情報の構造を示す。実行順序欄１２２は、各業務プロセスの実行順序を記録する。実行プロセス欄１２４は、実行すべき各業務プロセスを記録する。申込み情報欄１２６は、各業務プロセスが対応づけられた申込み情報を特定するための識別情報（以下、「申込みＩＤ」と呼ぶ。）を記録する。
【００２７】
図５の各行の記録を以下「レコード」と呼ぶ。同図において、レコード１３２から１３８は、申込みＩＤ「１０１」の申込み情報に基づき実行される業務プロセスを示している。同様に、レコード１４０から１４６は申込みＩＤ「１０２」の申込み情報に、レコード１４８から１５４は申込みＩＤ「１０３」の申込み情報に対応づけられている。実行フラグ欄１２８は、各業務プロセスの実行状況を示す。実行フラグ欄１２８には、各業務プロセスの実行状況として、業務プロセスが未実行であることを示す「未実行」、実行予定であることを示す「実行予定」、実行中であることを示す「実行中」、実行が完了したことを示す「実行済」のいずれかが記録される。なお、業務プロセスの実行が完了した場合には、「実行済」が記録される代わりに、当該業務プロセスのレコードが削除されてもよい。図２に戻る。
【００２８】
データ処理部５０：
データ処理部５０は、装置負荷取得部５２と、実行順序情報更新部５４と、実行プロセス決定部５６と、業務プロセス実行部５８と、トランザクション制御部６０と、ＤＢ記録情報取得部６２と、ＤＢ記録情報比較部６４とを含む。
【００２９】
装置負荷取得部５２は、ＯＳ（Operating System）が備えるＡＰＩ（Application Program Interface）を呼び出し、またはコマンドを実行することで、電子商取引装置１００にて発生している装置負荷を取得する。例えば、「vmstat」コマンドを実行することにより、ＣＰＵ使用率やメモリ使用率等を取得する。また、所定のアプリケーションを実行して、当該アプリケーション実行終了までの時間を取得してもよい。
【００３０】
実行順序情報更新部５４は、実行順序情報保持部３６に保持された実行順序情報を更新する。ローン申込み情報が受け付けられたとき、実行順序情報更新部５４は、当該ローン申込み情報に基づき実行すべき業務プロセス、つまり図３で示した４つの業務プロセスを実行すべき業務プロセスとして追加する。例えば、図５の実行順序が１２まで設定されているとき、新たに申込みＩＤ「１０４」の申込み情報が受け付けられると、申込みＩＤ「１０４」・実行フラグ「未実行」に対応づけた４つの業務プロセスを実行順序１３から１６のレコードとして記録する。
【００３１】
実行プロセス決定部５６は、許容負荷情報保持部３４を参照して、装置負荷取得部５２により取得された装置負荷において許容される許容負荷を特定する。次に、個別プロセス情報保持部３２を参照して、当該許容負荷以下のプロセス負荷を有する業務プロセスを実行対象として決定する。つまり、許容負荷が「中」であるときには、プロセス負荷が「中」または「小」の業務プロセスを実行対象とする。実行プロセス決定部５６は、実行対象の決定にあたり、実行順序情報保持部３６に記録された実行順序にしたがうが、その決定方法の例として以下２つのパターンを示す。
【００３２】
１．直列実行型
直列実行型は、申込み情報が受け付けられた順に、各業務プロセスを実行し、実行順序の追い越しは行わない。図５の実行順序情報の場合、常に実行順序の昇順に各業務プロセスを実行する。例えば、装置負荷が図４の領域１１２であるとき、つまり許容負荷が「大」であるとき、実行プロセス決定部５６は、レコード１３４の業務プロセスを実行予定として、実行順序情報更新部５４に実行順序情報を更新させる。図６は、図５の実行順序情報が更新された状態を示す。また、装置負荷が図４の領域１１４または１１６であるとき、つまり許容負荷が「中」または「小」であるとき、実行プロセス決定部５６は、レコード１３４の業務プロセスを実行予定にせず、その結果、実行順序情報は図５の状態が維持される。直列実行型は、「与信確認」や「貸付額決定」等の各業務プロセスを実行する際に、申込み情報間で使用リソースの競合が発生するなど、申込み情報間に依存関係があり、申込み情報を受付順に順次実行すべき場合に有効である。
【００３３】
なお、実行プロセス決定部５６は、申込み情報に基づき実行すべき業務プロセスのうち、特定の業務プロセスのみ順次実行させてもよい。例えば、業務プロセス「与信確認」は、各申込みとも並行して実施し、業務プロセス「貸付額決定」については、先に受け付けられた申込み情報の順に業務プロセスが実行させてもよい。特定の業務プロセス、例えば「貸付額決定」で大きな待ち時間が発生する場合や、特定の業務プロセスを実行する際に、申込み情報間で使用リソースの競合が発生する場合などに有効である。
【００３４】
２．追い越し実行型
追い越し実行型は、原則として、申込み情報が受け付けられた順に、各業務プロセスを実行するが、装置負荷の状況によっては、実行順序が遅い業務プロセスを先に実行する。例えば、図５の実行順序情報において、装置負荷が図４の領域１１２であるときには上述した直列実行型と同様である。装置負荷が図４の領域１１４であるとき、実行プロセス決定部５６は、申込みＩＤ「１０２」に対応づけられたレコード１４０の業務プロセスを実行予定とする。図７は、図５の実行順序情報が更新された状態を示す。
【００３５】
なお、図５の実行順序情報において、装置負荷が図４の領域１１６であるとき、実行プロセス決定部５６は、いずれのレコードの業務プロセスも実行予定にせず、その結果、実行順序情報は図５の状態が維持される。プロセス負荷が「小」の業務プロセス「確認情報送信」は実行可能であるが、同一の申込み情報において各業務プロセスは順次実行される必要があり、「確認情報送信」の前の業務プロセスである「貸付額決定」がいずれの申込み情報についても実行されていないからである。
【００３６】
図７の実行順序情報の状態から、さらに、レコード１４０が実行中になっても、装置負荷が図４の領域１１２または１１４であるとき、実行プロセス決定部５６は、申込みＩＤ「１０３」に対応づけられたレコード１４８の業務プロセスを実行予定とする。図８は、図７の実行順序情報が更新された状態を示す。追い越し実行型は、直列実行型に比べ、申込み情報間に依存関係がない場合に、使用可能なハードウェアリソースをより効率的に使用できる点で有効である。
【００３７】
また、実行プロセス決定部５６は、一旦実行予定にした業務プロセスであっても、当該業務プロセスのプロセス負荷が次に取得された装置負荷に対応する許容負荷よりも大きいときには、当該業務プロセスの実行フラグ欄１２８を「未実行」に戻す。すなわち、実行プロセス決定部５６は、許容負荷とプロセス負荷との次の比較により、図６において実行予定にしたレコード１３４を、図５の状態に戻す。
【００３８】
なお、実行プロセス決定部５６は、複数の業務プロセスを実行予定にしてもよい。例えば、図５の実行順序情報において、装置負荷が図４の領域１１２のとき、レコード１３４・１４０・１４８の実行フラグ欄１２８を同時に「実行予定」としてもよい。また、図５の実行順序情報において、装置負荷が図４の領域１１４のとき、レコード１４０・１４８の実行フラグ欄１２８を同時に「実行予定」としてもよい。
【００３９】
この場合、１つ目の業務プロセスにおけるプロセス負荷と比較する許容負荷を特定するとき、実行プロセス決定部５６は、上述したように、装置負荷取得部５２により取得された装置負荷に基づき許容負荷を特定する。２つめの業務プロセスに対する許容負荷を特定するとき、実行プロセス決定部５６は、先の装置負荷に１つ目の業務プロセスの実行により発生するプロセス負荷を加えた想定装置負荷に基づき許容負荷を特定する。例えば、装置負荷としてＣＰＵ使用率が取得され、プロセス負荷としてＣＰＵ使用時間が保持されているときには、１つ目の業務プロセスのＣＰＵ使用時間からＣＰＵ使用率の増加分を算出する。続いて、この増加分を装置負荷のＣＰＵ使用率に加算することにより想定装置負荷を算出し、当該想定装置負荷に基づき許容負荷を特定する。
【００４０】
さらにまた、実行プロセス決定部５６は、後述するＤＢ記録情報取得部６２から特定の申込み情報、具体的には申込みＩＤを指定した「業務プロセス実行要求」を受け付ける。業務プロセス実行要求を受け付けたとき、実行プロセス決定部５６は、指定された申込み情報に対応づけられた業務プロセスの中で未実行の状態の業務プロセスを実行対象として決定する。すなわち、実行順序情報更新部５４に当該業務プロセスの実行フラグ欄１２８を「実行予定」に更新させる。なお、業務プロセス実行要求を契機に実行対象を決定する際には、装置負荷および業務プロセスの実行順序にかかわらず実行対象を決定する。
【００４１】
業務プロセス実行部５８は、実行順序情報保持部３６を参照して、実行順序情報において実行フラグ欄１２８が「実行予定」に設定された業務プロセスを実行する。また、業務プロセス実行部５８は、「与信確認」等の各業務プロセスを実行する際に、データベースサーバ２００に対しトランザクション処理を行う。例えば、各業務プロセスの実行結果をデータベースサーバ２００に記録する。
【００４２】
業務プロセス実行部５８は、実行順序情報から「実行予定」の業務プロセスを検出したとき、実行順序情報更新部５４に、当該業務プロセスの実行フラグ欄１２８を「実行中」に更新させる。当該業務プロセスの実行が完了すると、実行順序情報更新部５４に、当該実行フラグ欄１２８を「実行済」に更新させる。なお、業務プロセス実行部５８は、「実行済」に更新させる代わりに、実行順序情報更新部５４に、実行が完了した業務プロセスのレコード自体を削除させてもよい。これにより、「実行予定」に設定された業務プロセスを検索する際の効率を向上できる。図２に戻る。
【００４３】
トランザクション制御部６０は、データベースサーバ２００に対するトランザクションを一元的に制御する。業務プロセス実行部５８による業務プロセス実行では、データベースサーバ２００へのデータの挿入・更新・削除等のトランザクション処理が実施されるが、コミットやロールバック等のトランザクション制御は実施されない。トランザクション制御部６０は、業務プロセス実行部５８がデータベースサーバ２００に対しトランザクション処理を実施したセッションを引き継いで、当該セッションの範囲で一元的にコミットまたはロールバックを発行する。
【００４４】
例えば、業務プロセス実行部５８によりデータベースサーバ２００に対する複数のトランザクション処理が実行された後、トランザクション制御部６０は、業務プロセス実行部５８からデータベースサーバ２００に対するセッションオブジェクトを取得する。続いて、このセッションオブジェクトが備えるトランザクション制御のＡＰＩを呼び出すことにより、一元的に、コミットまたはロールバックを発行する。
【００４５】
また、トランザクション制御部６０は、データベースサーバ２００が備える所定の記憶領域の使用量に応じて、データベースサーバ２００に対しコミットまたはロールバックを発行する。この記憶領域は、データベースサーバ２００に対するトランザクション処理がロールバックされたときにデータベースサーバ２００のデータを当該トランザクション処理前の状態に回復するための情報を保持する領域（以下、「回復情報保持領域」と呼ぶ。）である。回復情報保持領域は、例えば、ＯＲＡＣＬＥ（登録商標）データベースにおけるＵＮＤＯセグメントまたはロールバックセグメントに相当する。
【００４６】
具体的に、トランザクション制御部６０は、データベースサーバ２００で稼働しているデータベースインスタンスの状態を管理するテーブル、例えばデータディクショナリテーブルまたはデータディクショナリビューを定期的に検索して、回復情報保持領域の使用量または使用率を取得する。取得した使用量または使用率が所定の閾値以上であるとき、トランザクション制御部６０は、コミットまたはロールバックを発行する。これにより、回復情報保持領域の使用量および使用率を低減させる。
【００４７】
ＤＢ記録情報取得部６２は、実行順序情報保持部３６を参照して、取引結果要求により指定された申込み情報に対応づけられた一連の業務プロセスが実行済か否かを確認する。当該一連の業務プロセスの実行フラグ欄１２８がいずれも実行済であるとき、ＤＢ記録情報取得部６２は、それらの業務プロセスの実行結果をデータベースサーバ２００から取得して、取引結果送信部１８に通知する。
【００４８】
ＤＢ記録情報取得部６２は、当該一連の業務プロセスの実行フラグ欄１２８がいずれかが未実行であるときには、未実行の業務プロセスを実行させるために、実行プロセス決定部５６に対して上述した業務プロセス実行要求を発行する。続いて、当該一連の業務プロセスが実行済か否かを再度確認して、いずれも実行済であれば、実行結果をデータベースサーバ２００から取得する。また、ＤＢ記録情報取得部６２は、業務プロセスの実行結果を複数取得したとき、後述するＤＢ記録情報比較部６４に当該複数の実行結果を比較させるための「実行結果比較要求」を発行する。
【００４９】
ＤＢ記録情報比較部６４は、実行結果比較要求を受け付けると、ＤＢ記録情報取得部６２において複数取得された業務プロセスの実行結果を比較し、その比較結果、例えば実行結果間の差分を出力する。実行結果の比較は、文字列マッチングにより差分を抽出してもよく、「diff」コマンドにより実行結果のファイルを比較してもよい。また、比較結果の出力は、比較結果をファイルに出力してもよく、取引結果送信部１８に通知してもよい。
【００５０】
以下、電子商取引装置１００における処理の流れを図９のフローチャートを用いて説明する。図９（ａ）は、ローン申込み情報の受け付けにおける一連の処理を示すフローチャートである。申込み情報受信部１２は、顧客端末３０４から申込み情報を受信する（Ｓ２）。実行順序情報更新部５４は、申込み情報に基づき、実行順序情報に実行すべき業務プロセスを追加する（Ｓ４）。
【００５１】
図９（ｂ）は、装置負荷を取得する一連の処理を示すフローチャートである。装置負荷取得部５２は、電子商取引装置１００における装置負荷を定期的に取得する（Ｓ１０）。電子商取引装置の電子商取引サービスが終了するとき（Ｓ１２のＹ）、この一連の処理は終了する。電子商取引サービスが継続するとき（Ｓ１２のＮ）、所定時間経過後、Ｓ１０の処理に戻る。
【００５２】
図９（ｃ）は、業務プロセスを実行する一連の処理を示すフローチャートである。実行プロセス決定部５６は、装置負荷に対応づけられた許容負荷と各プロセス負荷とに基づき、実行順序情報の業務プロセスの中から、実行対象の業務プロセスを決定する（Ｓ２０）。実行対象の業務プロセスがなければ（Ｓ２２のＮ）、所定の時間経過後、Ｓ２０の処理に戻る。実行対象の業務プロセスがあるとき（Ｓ２２のＹ）、業務プロセス実行処理が行われる（Ｓ２４）。電子商取引装置の電子商取引サービスが終了するとき（Ｓ２６のＹ）、この一連の処理は終了する。電子商取引サービスが継続するとき（Ｓ２６のＮ）、Ｓ２０の処理に戻る。
【００５３】
図９（ｄ）は、図９（ｃ）の業務プロセス実行処理の詳細を示すフローチャートである。業務プロセス実行部５８は、実行対象の業務プロセスを実行する（Ｓ３０）。データベースサーバ２００の回復情報保持領域の使用量が所定の閾値以上のとき（Ｓ３２のＹ）、トランザクション制御部６０は、データベースサーバ２００に対しコミットを発行する（Ｓ３４）。回復情報保持領域の使用量が所定の閾値未満のとき（Ｓ３２のＮ）、Ｓ３４の処理はスキップされる。
【００５４】
図９（ｅ）は、取引結果要求の受け付けにおける一連の処理を示すフローチャートである。取引結果要求受信部１６は、特定の申込み情報を指定した取引結果要求を社員端末３００または顧客端末３０４から受信する（Ｓ４０）。当該申込み情報に対応づけられた業務プロセスのいずれかが未実行であるとき（Ｓ４２のＮ）、ＤＢ記録情報取得部６２は、実行プロセス決定部５６に業務プロセス実行要求を発行する。実行プロセス決定部５６は、当該申込み情報に対応づけられた未実行の業務プロセスを実行対象として決定し（Ｓ４４）、図９（ｄ）で既述した業務プロセス実行処理が行われる（Ｓ４６）。当該申込み情報に対応づけられた業務プロセスのいずれも実行済であるとき（Ｓ４２のＹ）、Ｓ４４およびＳ４６の処理はスキップされる。ＤＢ記録情報取得部６２は、データベースサーバ２００から業務プロセスの実行結果を取得する（Ｓ４８）。取引結果送信部１８は、取得された実行結果を社員端末３００または顧客端末３０４に送信する（Ｓ５０）。
【００５５】
図９（ｆ）は、並行テストにおける一連の処理を示すフローチャートである。並行テストとは、変更後の業務プロセスと変更前の業務プロセスとを一連の処理で実行して比較結果を取得するテストのことである。この並行テストによって、業務プロセスの変更に伴うテストが容易となる。次にフローチャートを説明する。
【００５６】
申込み情報受信部１２は、社員端末３００からテスト用の申込み情報を受信する（Ｓ６０）。業務プロセス実行部５８は、変更後の業務プロセスを実行する（Ｓ６２）。ＤＢ記録情報取得部６２は、変更後の業務プロセスの実行結果、言い換えればデータベースサーバ２００に対するトランザクション処理の結果をデータベースサーバ２００から取得する（Ｓ６４）。トランザクション制御部６０は、データベースサーバ２００にロールバックを発行することで、変更後の業務プロセスによるトランザクション処理を取り消す（Ｓ６６）。
【００５７】
続いて、業務プロセス実行部５８は、変更前の業務プロセスを実行する（Ｓ６８）。ＤＢ記録情報取得部６２は、変更前の業務プロセスの実行結果をデータベースサーバ２００から取得する（Ｓ７０）。ＤＢ記録情報比較部６４は、ＤＢ記録情報取得部６２から実行結果比較要求を受け付けて、変更前後の業務プロセスの実行結果を比較し、比較結果を出力する（Ｓ７２）。なお、並行テストにおける実行順序情報更新部５４および実行プロセス決定部５６の動作に制限はなく、実行順序情報における業務プロセスの実行フラグ欄１２８を実行予定に設定すればよい。通常のローン申込み情報を受け付けたときと同様の処理でもよく、実行順序情報更新部５４が最初から実行予定に設定してもよい。
【００５８】
本実施の形態によれば、電子商取引装置１００で使用可能なハードウェアリソースに応じて、実施可能な業務プロセスを随時実行でき、電子商取引装置１００で使用されるハードウェアリソースを平準化できる。これにより、従来のように多くのハードウェアリソースを使用する業務プロセスは夜間にバッチ処理として実行するというシステム運用を解消できる。したがって、バッチ処理の間、顧客のアクセスに対し応答時間が長くなり、または、そもそも顧客がアクセスできなかったというバッチ処理の問題を解消でき、顧客の利便性を向上できる。また、業務プロセスが随時に実行されることで、顧客や社員等のユーザは翌日まで待たされることなく、申込みの結果を早期に確認でき、ユーザの利便性を向上できる。
【００５９】
また、本実施の形態によれば、刻々と変化するハードウェアリソースの使用状況に応じて、業務プロセスの実行量を動的に変化させられる。これにより、オンライン処理、例えば、申込みの受け付け処理や問い合わせの受け付け処理等に対する応答時間を良好なレベルに維持しながら、バックグラウンドでは先に受け付けた申込みに紐づく業務プロセスを随時実行できる。また、装置が備えるハードウェアリソースの有効活用を実現することで、ハードウェアリソースの量を低減でき、装置の導入コストを低減できる。
【００６０】
さらに、本実施の形態によれば、複数の業務プロセスを原則的には受付順に実行しながらも、ユーザの要求がある場合には、要求された業務プロセスを優先して実行できる。これにより、申込みの結果を早く知りたいユーザからのアクセスに対し、当該申込みに紐づく業務プロセスの実行結果を通知できる。これにより、ユーザの利便性をさらに向上できる。
【００６１】
さらにまた、本実施の形態によれば、トランザクション処理を行う業務プロセスとは別にトランザクション制御部６０が一元的にトランザクションを制御する。これにより、多くのハードウェアリソースを使用するトランザクション制御処理を集約し、その数を低減することで、一連の業務処理で使用されるハードウェアリソースを低減できる。
【００６２】
さらにまた、本実施の形態によれば、データベースサーバの回復情報保持領域の使用量に基づきトランザクションを制御する。データベースサーバの回復情報保持領域が満杯になるとデータベースの機能により自動で拡張されるが、その拡張処理には多くのハードウェアリソースが必要となる。本実施の形態によれば、回復情報保持領域の使用量に基づき、適切なタイミングでトランザクション制御処理ができる。これにより、トランザクション制御処理の回数を抑制しつつ、回復情報保持領域の拡張処理を回避できることで、使用されるハードウェアリソースを低減できる。
【００６３】
さらにまた、本実施の形態によれば、並行テストの実現により、業務プロセスの変更に伴うテストを容易化して、迅速な業務プロセスの変更を実現する。つまり、ユーザは一度テスト用申込み情報を入力すれば、同一のデータベースを使用して変更前後の業務プロセスが実行され、各実行結果の比較情報を取得できる。ユーザは、この比較情報の内容が変更前後の業務プロセスの仕様に合致するかを判断することで、変更後の業務プロセスの正常性を容易に確認できる。これにより、顧客の要望を迅速に電子商取引サービスに反映でき、顧客の利便性を向上できる。これは、顧客の要望等に応じ、業務プロセスの変更が頻繁に発生する電子商取引装置１００において重要な効果である。
【００６４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６５】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６６】
第１の変形例について説明する。トランザクション制御部６０は、一のデータベースセッションを使用して複数の業務プロセスを実行する際に、いずれかの業務プロセスの実行でエラーが発生した場合であっても常にコミットを発行してもよい。業務プロセス実行部５８は、業務プロセス実行においてエラーが発生した場合、当該業務プロセスの処理結果を記録するレコードにエラーの発生を示すエラーフラグを設定する。ＤＢ記録情報取得部６２によりエラーフラグが設定された業務プロセスの処理結果が取得されると、取引結果送信部１８は、エラーが発生した旨を社員端末３００または顧客端末３０４に送信する。
【００６７】
第１の変形例によれば、複数の業務プロセスにおけるトランザクション処理を一つのコミットで制御できるとともに、業務プロセス実行でエラーが発生した場合でも、全てのトランザクション処理を取り消すことなく、エラーが発生した業務プロセスについてのみ個別に対応できる。業務プロセス実行に成功したものについては再実行が不要となり、トランザクション制御の回数、具体的にはコミットの発行回数がさらに少なくなることで、電子商取引装置１００の装置負荷を低減できる。
【００６８】
第２の変形例について説明する。申込み情報受信部１２により、既に実行中の電子商取引に対する追加情報が受信されたとき、業務プロセス実行部５８は、当該電子商取引で使用しているデータベースセッションを使用して追加情報に基づく業務プロセス実行をしてもよい。データベースセッションは、追加情報で指定された申込みＩＤにより特定される。例えば、図５の実行順序情報において、申込みＩＤ「１０１」を指定した追加情報が受信されたとき、業務プロセス実行部５８は、申込みＩＤ「１０１」の各業務プロセスで使用されているデータベースセッションを使用して、当該追加情報に基づき業務プロセスを実行する。
【００６９】
第２の変形例によれば、トランザクションが確定されるまで、データベースサーバ２００に記録された業務プロセスの実行結果を参照できない弊害を解消できる。言い換えれば、トランザクション制御部６０によりトランザクションの制御が一元化され、コミット等の発行回数が減少し、トランザクションの確定まで時間がかかることにより発生しうる弊害を解消できる。具体的には、業務プロセスのトランザクションが未確定であっても、同一の申込みＩＤを指定する追加情報を処理する際に、当該業務プロセスの実行結果を参照可能となり、その実行結果と整合性を維持して、追加情報に基づき業務プロセスを実行できる。また、先に実行された業務プロセスのトランザクション確定を待つことなく、追加情報に基づき業務プロセスを実行できることで、迅速な電子商取引を実現する。
【００７０】
第３の変形例について説明する。本実施の形態では、電子商取引装置１００が業務プロセスを実行したが、業務プロセスを実行する実行装置は複数設置されてもよい。このとき、許容負荷情報保持部３４は、各実行装置の装置負荷と許容負荷との対応関係を記憶する。装置負荷取得部５２は、各実行装置の装置負荷を取得する。実行プロセス決定部５６は、装置負荷から特定される各実行装置の許容負荷に応じて、複数の実行装置の中から業務プロセスの実行主体を決定する。すなわち、本発明の技術思想は、業務プロセスの実行装置が複数ある場合についても適用できる。
【図面の簡単な説明】
【００７１】
【図１】本実施の形態における電子商取引システムのハードウェア構成図である。
【図２】電子商取引装置の機能構成を示すブロック図である。
【図３】個別プロセス情報保持部のデータ構造を示す図である。
【図４】装置負荷と許容負荷との対応関係を模式的に示す図である。
【図５】実行順序情報の構造を示す図である。
【図６】図５の実行順序情報が更新された状態を示す図である。
【図７】図５の実行順序情報が更新された状態を示す図である。
【図８】図７の実行順序情報が更新された状態を示す図である。
【図９（ａ）】ローン申込み情報の受け付けにおける一連の処理を示すフローチャートである。
【図９（ｂ）】装置負荷を取得する一連の処理を示すフローチャートである。
【図９（ｃ）】業務プロセスを実行する一連の処理を示すフローチャートである。
【図９（ｄ）】図９（ｃ）の業務プロセス実行処理の詳細を示すフローチャートである。
【図９（ｅ）】取引結果要求の受け付けにおける一連の処理を示すフローチャートである。
【図９（ｆ）】並行テストにおける一連の処理を示すフローチャートである。
【符号の説明】
【００７２】
１０  ユーザインタフェース処理部、１２  申込み情報受信部、１４  確認情報送信部、１６  取引結果要求受信部、１８  取引結果送信部、３０  データ保持部、３２  個別プロセス情報保持部、３４  許容負荷情報保持部、３６  実行順序情報保持部、５０  データ処理部、５２  装置負荷取得部、５４  実行順序情報更新部、５６  実行プロセス決定部、５８  業務プロセス実行部、６０  トランザクション制御部、６２  ＤＢ記録情報取得部、６４  ＤＢ記録情報比較部、１００  電子商取引装置、１０２  業務プロセス欄、１０４  プロセス順序欄、１０６  プロセス負荷欄、１２２  実行順序欄、１２４  実行プロセス欄、１２６  申込み情報欄、１２８  実行フラグ欄、２００  データベースサーバ、３００  社員端末、３０２  通信ネットワーク、３０４  顧客端末、５００  電子商取引システム。
【図１】
2009134471.tif 000003
【図２】
2009134471.tif 000004
【図３】
2009134471.tif 000005
【図４】
2009134471.tif 000006
【図５】
2009134471.tif 000007
【図６】
2009134471.tif 000008
【図７】
2009134471.tif 000009
【図８】
2009134471.tif 000010
【図９（ａ）】
2009134471.tif 000011
【図９（ｂ）】
2009134471.tif 000012
【図９（ｃ）】
2009134471.tif 000013
【図９（ｄ）】
2009134471.tif 000014
【図９（ｅ）】
2009134471.tif 000015
【図９（ｆ）】
2009134471.tif 000016