(57)【要約】【課題】処理中に何らかの異常が発生した場合には自動的に電子メールが消去されるようにして、人の手を介する面倒な電子メールの取消処理を不要とすることができる。【解決手段】トランザクションを開始させるためのトランザクション宣言受信部３０と、指定された宛先に送信するための電子メールを順次受信するメール送信依頼受信部３１と、電子メールをトランザクションごとに一時的に蓄積するメール記憶部３５と、トランザクションを終了させるためのコミット宣言受信部３２と、コミットされたときに、メール記憶部３５に蓄積された電子メールを送信するメール送信部３８と、トランザクションの開始から終了前までの間に異常が発生した場合に、メール記憶部３５に記憶された電子メールをすべて一括して破棄するロールバック宣言受信部とを備えている。【選択図】図３
2007193667.tif 000002
【特許請求の範囲】
【請求項１】
トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信手段と、
前記トランザクション宣言受信手段が受信した前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信手段と、
受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶手段と、
前記トランザクションの終了を宣言するコミット宣言信号を受信するコミット宣言受信手段と、
前記コミット宣言受信手段が受信した前記コミット宣言信号に基づいて、前記電子メール記憶手段に蓄積された前記電子メールを指定された前記宛先に送信する電子メール送信手段と
を備えたことを特徴とするトランザクション管理システム。
【請求項２】
前記トランザクションの取消を宣言するロールバック宣言信号を受信するロールバック宣言受信手段と、
前記ロールバック宣言受信手段が受信した前記ロールバック宣言信号に基づいて、前記電子メール記憶手段に蓄積された前記電子メールを破棄する電子メール破棄手段と
をさらに備えたことを特徴とする請求項１に記載のトランザクション管理システム。
【請求項３】
トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信手段と、
前記トランザクション宣言受信手段が受信した前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信手段と、
受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶手段と、
前記トランザクションの取消を宣言するロールバック宣言信号を受信するロールバック宣言受信手段と、
前記ロールバック宣言受信手段が受信した前記ロールバック宣言信号に基づいて、前記電子メール記憶手段に蓄積された前記電子メールを破棄する電子メール破棄手段と
を備えたことを特徴とするトランザクション管理システム。
【請求項４】
トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信ステップと、
前記トランザクション宣言受信ステップにおいて受信された前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信ステップと、
受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶ステップと、
前記トランザクションの終了を宣言するコミット宣言信号を受信するコミット宣言受信ステップと、
前記コミット宣言受信ステップにおいて受信された前記コミット宣言信号に基づいて、前記電子メール記憶ステップにおいて蓄積された前記電子メールを指定された前記宛先に送信する電子メール送信ステップと
を備えたトランザクション管理プログラム。
【請求項５】
前記トランザクションの取消を宣言するロールバック宣言信号を受信するロールバック宣言受信ステップと、
前記ロールバック宣言受信ステップにおいて受信された前記ロールバック宣言信号に基づいて、前記電子メール記憶ステップにおいて蓄積された前記電子メールを破棄する電子メール破棄ステップと
を備えたことを特徴とする請求項４に記載のトランザクション管理プログラム。
【請求項６】
トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信ステップと、
前記トランザクション宣言受信ステップにおいて受信された前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信ステップと、
受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶ステップと、
前記トランザクションの取消を宣言するロールバック宣言信号を受信するロールバック宣言受信ステップと、
前記ロールバック宣言受信ステップにおいて受信された前記ロールバック宣言信号に基づいて、前記電子メール記憶ステップにおいて蓄積された前記電子メールを破棄する電子メール破棄ステップと
を備えたトランザクション管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はトランザクション管理システムおよびトランザクション管理プログラムに関する。
【背景技術】
【０００２】
現在、広く利用されている電子メールには“電子メールの登録”という電子メールの送信を保留しておく概念がなく、“電子メールの送信”のみが提供されている。つまり、“電子メールの登録”という概念が無いために、トランザクション管理という概念が存在しない。このような現状の電子メールを用いた受注処理システムの構成を図７に示す。
“注文登録”はトランザクションを開始し、顧客情報や商品情報を注文情報としてデータベースに登録する。
“在庫管理”は注文された商品の在庫が有るか無いかを確認し、有る場合にはデータベースに消費する商品の情報を登録し、在庫情報を更新する。在庫が無い場合には、在庫の管理業務を行う在庫部門に商品の補充依頼を電子メールにて通知する。
“配送管理”は配送依頼を商品の配送業務を行う配送部門に電子メールにて通知し、“配送管理”の処理で電子メールは配送部門宛に送信される。
“受注通知”は、顧客に注文が受注された旨を通知する電子メールが顧客宛に送信される。そしてトランザクションがコミット（終了）され受注処理が完了する。
【０００３】
この従来の受注処理システムにおいて、“受注通知”の処理中など、電子メールを送信する処理が完了した後に何らかの異常が発生した場合、その受注処理の取消処理にてトランザクションをロールバックすることで、データベースに登録した内容は取り消すことができるが、電子メールはトランザクションのコミットに関わらず、送信されてしまうので、取り消すことはできない。すなわち、電子メールの送信は、トランザクション管理されていないため、送信された電子メールを取り消すキャンセルの電子メールの送信など、電子メールの取消処理が別途必要となってしまうという問題点があった。
【０００４】
なお、電子メールを即座に送信せずに、自動送信を行う日時の指定を行うことが可能なシステムも提案されている（例えば、特許文献１参照）。
【０００５】
【特許文献１】特開２０００−６９０７４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記の図７に示した従来のシステムにおいては、上述したように、電子メールの送信はトランザクション管理されていないため、各処理での電子メールの送信依頼によって、実際に電子メールが各宛先に送信される。そのため、万一、何らかの異常が発生した場合にも、いったん送信されてしまった電子メールを取り消すことは出来ないので、問題が発生した場合には、送信された電子メールが無効であることを知らせるための電子メールを別途追って送信する必要があり、その場合には送信側では取消用の電子メールの作成および送信処理が必要となり、受信側でも当該メールの内容の確認と、それに基づくデータの書き換え処理などが必要となって、送信側も受信側も人の手を介して取消処理を行う必要があり、作業者の負荷が多く、面倒であるという問題点があった。
【０００７】
さらに、人の手を介して取消処理を行うため、取消漏れや間違い等のトラブルが発生する可能性があるという問題点があった。
【０００８】
上記の特許文献１のシステムにおいては、送信日時を指定することができるので、指定された日時になる前に何かの異常が発生した場合には、送信予定の電子メールの送信を中止することは可能であるが、送信後には送信された電子メールを取り消すことは出来ないので、図７のシステムと同様に、送信側と受信側の両方で人の手を介して取消処理を行わなければならず、面倒であるという問題点があった。
【０００９】
この発明はかかる問題点を解決するためになされたものであり、処理中に何らかの異常が発生した場合には自動的に電子メールが消去されるようにして、人の手を介する面倒な電子メールの取消処理を不要とするトランザクション管理システムおよびトランザクション管理プログラムを得ることを目的としている。
【課題を解決するための手段】
【００１０】
この発明は、トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信手段と、前記トランザクション宣言受信手段が受信した前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信手段と、受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶手段と、前記トランザクションの終了を宣言するコミット宣言信号を受信するコミット宣言受信手段と、前記コミット宣言受信手段が受信した前記コミット宣言信号に基づいて、前記電子メール記憶手段に蓄積された前記電子メールを指定された前記宛先に送信する電子メール送信手段とを備えたことを特徴とするトランザクション管理システムである。
【発明の効果】
【００１１】
この発明は、トランザクションの開始を宣言するトランザクション宣言信号を受信するトランザクション宣言受信手段と、前記トランザクション宣言受信手段が受信した前記トランザクション宣言信号に基づいて、指定された宛先に送信するための電子メールを受信する電子メール送信依頼受信手段と、受信した前記電子メールをトランザクションごとに蓄積する電子メール記憶手段と、前記トランザクションの終了を宣言するコミット宣言信号を受信するコミット宣言受信手段と、前記コミット宣言受信手段が受信した前記コミット宣言信号に基づいて、前記電子メール記憶手段に蓄積された前記電子メールを指定された前記宛先に送信する電子メール送信手段とを備えたことを特徴とするトランザクション管理システムであるので、処理中に何らかの異常が発生した場合には自動的に電子メールが消去されるようにして、人の手を介する面倒な電子メールの取消処理を不要とすることができるので、効率よく、トランザクション管理および電子メール送信管理を行うことができる。
【発明を実施するための最良の形態】
【００１２】
実施の形態１．
文具などの商品を通信販売する会社に受注処理システムがあり、この受注処理システムは、情報を管理するデータベースと本発明のトランザクション管理システムとで構成されている。本発明のトランザクション管理システム（以下、マネージャとする。）は、電子メールの送信にトランザクション管理を提供する機構を持ち、電子メールの送信はマネージャを介して行う。マネージャでは、受注処理中に送信された電子メールを一旦、送信トレイ（以後、メッセージキューとする）に登録する。メッセージキューはトランザクション単位で管理しており、トランザクションをコミットすることで、メッセージキューに登録された電子メールを送信する。この受注処理システムの構成を図１に示す。
【００１３】
図１において、受注処理システムは、顧客からの注文情報を登録する注文登録部１による“注文登録”、注文商品の在庫管理を行う在庫管理部２による“在庫管理”、注文商品の配送を手配する配送管理部３による“配送管理”、注文を受注したことを顧客７に通知する受注通知部４による“受注通知”（符号４）の４処理で構成されており、“注文登録”から“受注通知”までの４処理を１トランザクションとして処理する。
注文登録部１による“注文登録”では、まず始めに受注処理を開始する為にトランザクションの開始を行う。次に、顧客７の氏名、住所、電話番号などの顧客情報と、商品名、個数などの商品情報を注文情報としてデータベース５に登録する。
在庫管理部２による“在庫管理”では、注文された商品の在庫の有無を確認し、在庫が有る場合はデータベース５に消費する商品の情報を登録し、在庫情報を更新する。在庫が無い場合は、在庫の管理業務を行う在庫部門８に商品の補充依頼を電子メールにて通知するため、在庫部門８宛の電子メールを送信し、マネージャ６のメッセージキュー３６に登録する。
配送管理部３による“配送管理”では、商品の配送業務を行う配送部門９への配送依頼を電子メールにて通知するため、配送部門９宛の電子メールを送信し、マネージャ６のメッセージキュー３６に登録する。
受注通知部４による“受注通知”では、注文が受注された旨を顧客７に電子メールにて通知するため、顧客７宛の電子メールを送信するため、マネージャ６のメッセージキュー３６に登録する。そして、最後に受注処理を完了する為にトランザクションをコミットし、受注処理を終了する。このトランザクションのコミットにより、データベースに登録した注文情報の登録や在庫情報の更新はデータベース上で確定され、マネージャのメッセージキューに登録されている電子メールは各宛先、すなわち、顧客７、在庫部門８および配送部門９に送信される。
本発明においては、このような電子メールの送信を伴う処理を含む受注処理システムなどに、マネージャを導入することで、電子メールの送信にトランザクション管理を持たせることができる。これにより、処理中で何らかの異常が発生した場合においても、トランザクションのコミット以前では電子メールが宛先に送信されないため、送信されてしまった電子メールに対する取消処理（キャンセルの電子メール送信）などが不要となる。また、メッセージキューに登録した送信予定の電子メールの削除は、トランザクションをロールバックすることにより自動的に消去されるため、削除処理を必要としない。
【００１４】
図２は、本発明のトランザクション管理システムの構成を示した図である。図２に示すように、マネージャ６内には、外部との通信を行うマネージャインターフェース１０と、電子メールの送信依頼を受信するクライアント（センダ）１１と、送信依頼された電子メールを一時的に蓄積するサーバ（プロバイダ）１２と、蓄積された電子メールを各宛先に送信するためにメールサーバ１４に出力するクライアント（レシーバ）１３とが設けられている。
【００１５】
図３に、マネージャ６に設けられたクライアント（センダ）１１、サーバ（プロバイダ）１２、クライアント（レシーバ）１３の内部構成を詳細に示す。
【００１６】
クライアント（センダ）１１には、トランザクション宣言受信部３０と、メール送信依頼受信部３１と、コミット宣言受信部３２と、ロールバック宣言受信部３３とが設けられている。
トランザクション宣言受信部３０は、注文管理部１から送信されてきてマネージャインタフェース１０により受信されたトランザクションを開始するためのトランザクション宣言信号を受信する。
メール送信依頼受信部３１は、注文管理部１、在庫管理部２、配送管理部３、受注通知部４から送信されてきてマネージャインタフェース１０により受信された宛先に送信されるべき電子メールを受信する。
コミット宣言受信部３２は、受注通知部４から送信されてきてマネージャインタフェース１０により受信されたトランザクションを終了するためのコミット宣言信号を受信する。
ロールバック宣言受信部３３は、何らかの異常が発生したときに、注文管理部１、在庫管理部２、配送管理部３、あるいは、受注通知部４から送信されてきてマネージャインタフェース１０により受信されたトランザクションをロールバックするためのロールバック宣言信号を受信する。
【００１７】
サーバ（プロバイダ）１２には、メール記憶部３５が設けられており、メール記憶部３５内には、トランザクションに１対１に対応して、トランザクションの個数と同数の複数のメッセージキュー３６が設けられている。
メッセージキュー３６は、メール送信依頼受信部３１を介して送信されてくる電子メールを各トランザクション毎に一時的に蓄積する。
【００１８】
クライアント（レシーバ）１３には、メール送信部３８が設けられている。
メール送信部３８は、コミット宣言受信部３２から出力されるコミット宣言信号を受信したときに、メッセージキュー３６に貯えられた電子メールを読み出して、メールサーバ１４を介して各宛先に送信する。
【００１９】
次に、本実施の形態に係るトランザクション管理システムの動作について説明する。図４は、本実施の形態に係るトランザクション管理システムの処理の流れを示した図である。図５および図６に示した例を基に、図４により動作について説明する。図５は異常が発生せずに正常に処理される場合を示している。この場合には、まず、図４に示すように、ステップＳ１では、注文登録部１が、まず始めに受注処理を開始する為に、トランザクションの開始を行うためのトランザクション宣言信号を出力する。当該信号をトランザクション宣言受信部３０がマネージャーインターフェース１０を介して受信し、セッションをオープンにする。この後の処理において、当該セッションはオープンの状態を継続し、トランザクションがコミットされるときに、セッションもクローズされる。これにより、各処理で生成された電子メールは、トランザクションごとに、セッションにより接続された所定のメッセージキュー３６に蓄積される。次に、注文登録部１が、顧客７の氏名、住所、電話番号などの顧客情報と、商品名、個数などの商品情報を注文情報としてデータベース５に登録する。次に、ステップＳ２で、注文登録部１が、ここまでの処理のなかで何らかの異常が発生していないか否かを判定する。この場合には、異常は発生していないので、ステップＳ３に進む。ステップＳ３では、在庫管理部２が、注文された商品の在庫の有無を確認し、在庫が有る場合はデータベース５に消費する商品の情報を登録し、在庫情報を更新する。在庫が無い場合は、在庫の管理業務を行う在庫部門８に商品の補充依頼を電子メールにて通知するため、在庫部門８宛の電子メールを送信する。メール送信受信部３１がマネージャーインターフェース１０を介してこれを受信し、メッセージキュー３６に登録する。次に、ステップＳ４で、在庫管理部２が、ここまでの処理のなかで何らかの異常が発生していないか否かを判定する。この場合には、異常は発生していないので、ステップＳ５に進む。ステップＳ５では、配送管理部３が、商品の配送業務を行う配送部門９への配送依頼を電子メールにて通知するため、配送部門９宛の電子メールを送信する。メール送信受信部３１がこれをマネージャーインターフェース１０を介して受信し、メッセージキュー３６に登録する。次に、ステップＳ６で、配送管理部３が、ここまでの処理のなかで何らかの異常が発生していないか否かを判定する。この場合には、異常は発生していないので、ステップＳ７に進む。ステップＳ７では、受注通知部４が、注文が受注された旨を顧客７に電子メールにて通知するため、顧客７宛の電子メールを送信する。メール送信受信部３１がこれをマネージャーインターフェース１０を介して受信し、メッセージキュー３６に登録する。次に、ステップＳ８で、受注通知部４が、ここまでの処理のなかで何らかの異常が発生していないか否かを判定する。この場合には、異常は発生していないので、ステップＳ９に進む。ステップＳ９では、受注処理を完了する為にトランザクションをコミットするためのコミット宣言信号を受注通知部４が送信する。コミット宣言受信部３２がこれをマネージャーインターフェース１０を介して受信し、セッションをクローズして、受注処理を終了する。次に、このトランザクションのコミットにより、データベース５に登録した注文情報の登録や在庫情報の更新はデータベース５上で確定され、メッセージキュー３６に登録されている電子メールは、メール送信部３８により読み出され、各宛先、すなわち、顧客７、在庫部門８および配送部門９に、それぞれ、メールサーバ１４を介して送信される。
【００２０】
一方、図６の例においては、配送管理部３による“配送管理”処理の途中もしくは後で何らかの異常が発生した場合を例に挙げている。この場合には、図４のステップＳ１〜Ｓ５までの処理は上記の説明と同じであるが、ステップＳ６の処理において、配送管理部３が異常が発生していると判定し、異常を通知するための異常通知信号を送信する。次に、ステップＳ１０において、ロールバック宣言受信部３３が、マネージャーインターフェース１０を介して、当該異常通知信号を受信して、トランザクションのロールバックを行う。すなわち、ステップＳ１、Ｓ３、Ｓ５の処理で作成し、メッセージキュー３６に蓄積されている電子メールをすべて一括して破棄（削除）する。このように、異常発生により、その時点でトランザクションをロールバックすることにより蓄積された電子メールはすべて消去され破棄される。
【００２１】
このように、本実施の形態においては、メッセージキュー３６に登録された不特定数の電子メールは、各処理の段階で送信してしまわずに、メッセージキュー３６に一時的に蓄積し、トランザクションがコミットされた段階で、はじめて、各宛先に送信されるようにしたので、処理の途中で何らかの異常が発生した場合には、それまでに蓄積した電子メールをすべて一括して破棄することができるので、従来のように、人の手を介して送信した電子メールを無効にする為の取消処理を行う必要がなくなり、効率よく、かつ、確実に、受注処理を行うことができる。また、従来においては人の手を介して取消をおこなっていたため、間違いが発生して、取消漏れが発生する可能性があったが、本実施の形態においては、異常が発生したトランザクションに関する電子メールを自動的に一斉に破棄するように構成されているので、取消漏れが発生する等のトラブルを確実に防ぐことができる。また、人の手を介さないので、人手もかからず、コストを削減することができる。
【００２２】
実施の形態２．
上記の実施の形態１においては、トランザクション開始からコミットまでの間、ずっとセッションがオープンされている場合を例に挙げて説明したが、その場合に限らず、例えば、注文管理部１、在庫管理部２、配送管理部３、受注通知部４での各処理ごとに、セッションのオープンおよびクローズを行うようにしてもよい。
【００２３】
その場合には、注文登録部１は、現在いずれのトランザクションでも使用されていない空きの状態のメッセージキューを検索し、それに対するセッションをオープンして処理を行う。このときに、検索したメッセージキューのアドレスもしくはセッションのＩＤ（識別番号）等の接続先を指定するための情報を記憶する。次に、在庫管理部３は、記憶された情報を用いて、注文登録部１が検索したメッセージキューに接続されているセッションを指定して、それをオープンさせ、処理を行う。処理終了後に、当該セッションをクローズする。配送管理部３および受注通知部４も同様に、記憶された情報を用いて、セッションを指定してオープンさせ、処理後に当該セッションをクローズする。他の動作については実施の形態１と同じであるため、ここでは説明を省略する。
【００２４】
以上のように、本実施の形態においても、実施の形態１と同様の効果が得られるとともに、さらに、不要なときはセッションをクローズするようにしたので、セキュリティ性が向上する。
【００２５】
実施の形態３．
上記の実施の形態２においては、接続先を指定する例について説明したが、その場合に限らず、各メッセージキューはトランザクション毎に用意されるので、接続先の情報ではなく、トランザクションＩＤを記憶しておき、注文管理部１、在庫管理部２、配送管理部３、受注通知部４での各処理ごとに、トランザクションＩＤを用いてメッセージキューを検索して、当該メッセージキューに電子メールを蓄積するようにしてもよい。
【００２６】
以上のように、本実施の形態においても、実施の形態１と同様の効果が得られるとともに、さらに、トランザクションＩＤを用いてメッセージキューを検索するようにしたので、電子メールが他のトランザクションの電子メールと混乱してしまうというようなトラブルを防ぐことができる。
【図面の簡単な説明】
【００２７】
【図１】この発明の実施の形態１に係る受注処理システムの構成を示した構成図である。
【図２】この発明の実施の形態１に係るトランザクション管理システム（マネージャ）の構成を示した構成図である。
【図３】この発明の実施の形態１に係るトランザクション管理システム（マネージャ）の構成を詳細に示した構成図である。
【図４】この発明の実施の形態１に係る受注処理システムの処理の流れを示した流れ図である。
【図５】この発明の実施の形態１に係る受注処理システムの処理の流れの一例を示した説明図である。
【図６】この発明の実施の形態１に係る受注処理システムの処理の流れの他の例を示した説明図である。
【図７】従来の電子メールを用いた受注処理システムの構成を示した構成図である。
【符号の説明】
【００２８】
１  注文登録部、２  在庫管理部、３  配送管理部、４  受注通知部、５  データベース、６  マネージャ（トランザクション管理システム）、７  顧客、８  在庫部門、９  配送部門、１０  マネージャインタフェース、１１  クライアント（センダ）、１２  サーバ（プロバイダ）、１３  クライアント（レシーバ）、１４  メールサーバ、３０  トランザクション宣言受信部、３１  メール送信依頼受信部、３２  コミット宣言受信部、３３  ロールバック宣言受信部、３５  メール記憶部、３６  メッセージキュー、３８  メール送信部。
【図１】
2007193667.tif 000003
【図２】
2007193667.tif 000004
【図３】
2007193667.tif 000005
【図４】
2007193667.tif 000006
【図５】
2007193667.tif 000007
【図６】
2007193667.tif 000008
【図７】
2007193667.tif 000009