(57)【特許請求の範囲】
【請求項１】
第１の電子文書の申請に伴って対応する第２の電子文書を起票する伝票起票手段と、
前記第１の電子文書および、前記起票手段により起票される前記第２の電子文書の申請を受付ける申請受付手段と、
前記申請受付手段により第１の電子文書の申請を受付けた場合に、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであるか否かを判定する申請済判定手段と、
前記申請済判定手段により、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであると判定された場合には、前記第１の電子文書の申請に伴って前記伝票起票手段により新たな第２の電子文書の起票を行わずに、前記申請を受付けた第１の電子文書の申請を行う再申請抑止処理を行う再申請抑止手段と、を有し、
前記再申請抑止手段は、
前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が申請済みでないと判定された場合には、前記申請を受付けた第１の電子文書の申請および、当該第１の電子文書が申請されることに伴って前記伝票起票手段により新たに起票された前記第２の電子文書の申請を行うことを特徴とするワークフローシステム。
【請求項２】
前記第２の電子文書の初回申請時に付加される識別ＩＤであって、該第２の電子文書が起票された元となる第１の電子文書の識別ＩＤが付加された、第２の電子文書の申請を受付ける識別ＩＤ付申請受付手段を更に有し、
前記申請済判定手段は、前記識別ＩＤが付加された第２の電子文書が既に申請済みである場合に、既に申請済みであると判定することを特徴とする請求項１記載のワークフローシステム。
【請求項３】
前記第１の電子文書に対してトランザクション処理を実行するのか前記再申請抑止処理を実行するのかを設定可能な処理編集手段を更に有し、
前記処理編集手段によって設定された前記第１の電子文書の申請ごとに、トランザクション処理または再申請抑止防止処理を切り替えて実行可能なこと
を特徴とする請求項１または２記載のワークフローシステム。
【請求項４】
伝票起票手段が、第１の電子文書の申請に伴って対応する第２の電子文書を起票する伝票起票ステップと、
申請受付手段が、前記第１の電子文書および、前記起票手段により起票される前記第２の電子文書の申請を受付ける申請受付ステップと、
申請済判定手段が、前記申請受付ステップにより第１の電子文書の申請を受付けた場合に、前記伝票起票ステップによって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであるか否かを判定する申請済判定ステップと、
再申請抑止手段が、前記申請済判定ステップにより、前記伝票起票ステップによって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであると判定された場合には、前記第１の電子文書の申請に伴って前記伝票起票ステップにより新たな第２の電子文書の起票を行わずに、前記申請を受付けた第１の電子文書の申請を行う再申請抑止処理を行う再申請抑止ステップと、を有し、
前記再申請抑止ステップは、
前記伝票起票ステップによって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が申請済みでないと判定された場合には、前記申請を受付けた第１の電子文書の申請および、当該第１の電子文書が申請されることに伴って前記伝票起票ステップにより新たに起票された前記第２の電子文書の申請を行うことを特徴とするワークフローシステムの制御方法。
【請求項５】
ワークフローシステムを、
第１の電子文書の申請に伴って対応する第２の電子文書を起票する伝票起票手段と、
前記第１の電子文書および、前記起票手段により起票される前記第２の電子文書の申請を受付ける申請受付手段と、
前記申請受付手段により第１の電子文書の申請を受付けた場合に、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであるか否かを判定する申請済判定手段と、
前記申請済判定手段により、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであると判定された場合には、前記第１の電子文書の申請に伴って前記伝票起票手段により新たな第２の電子文書の起票を行わずに、前記申請を受付けた第１の電子文書の申請を行う再申請抑止処理を行う再申請抑止手段と、を有し、
前記再申請抑止手段は、
前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が申請済みでないと判定された場合には、前記申請を受付けた第１の電子文書の申請および、当該第１の電子文書が申請されることに伴って前記伝票起票手段により新たに起票された前記第２の電子文書の申請を行うことを特徴とするワークフローシステムとして機能させるためのプログラム。
【請求項６】
請求項５に記載のプログラムをコンピュータ読み取り可能に記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローシステムにおける電子文書のデータベースへのコミットの制御に関する。
【背景技術】
【０００２】
近年のワークフローシステムにおいては、同一イベント、同一タイミングで複数の帳票が作成されてワークフローシステムで回覧されるようなことが行われている。
【０００３】
例えば結婚の例を挙げると、結婚の前には、社宅申込書や住所変更届、通勤経路変更届などを作成することがあり、申請者は結婚というイベント後にも自分の判断により申請書類を起票する必要があるが、実際にはイベント後の起票を忘れたり、申請を遅れて行われたりすることが発生し、迅速な対応ができないという問題があった。
【０００４】
そこで、特許文献１では、同一イベント、同一タイミングで複数の帳票が作成されてワークフローシステムで回覧される場合、イベントによる複数の帳票間の関連をもとに起票者以降の作業担当者へ作業指示を行うことにより、作業担当者の作業負荷を軽減させ、作業効率を向上させるための発明が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−２５１００２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しなしながら、特許文献１で開示されている発明では、複数の帳票の関連をもとに帳票を管理しているので、多くの案件から関連性がある案件を探し出すことは可能であるが、各案件は、単独で処理されてしまう。例えば、ある帳票のデータベースへの書き込みの際にエラーが発生してしまった場合など、複数の関連する帳票間で、正常に書き込まれたものやエラーとなったものなど、処理結果に差がでてしまい、不具合が発生するケースがあるという問題点があった。
【０００７】
本願発明は上記問題点に鑑み、帳票をデータベースへ書き込む際、正常に書き込めなかった場合に、複数の関連する帳票間で処理結果に不具合が発生しないような仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
第１の電子文書の申請に伴って対応する第２の電子文書を起票する伝票起票手段と、
前記第１の電子文書および、前記起票手段により起票される前記第２の電子文書の申請を受付ける申請受付手段と、
前記申請受付手段により第１の電子文書の申請を受付けた場合に、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであるか否かを判定する申請済判定手段と、
【０００９】
前記申請済判定手段により、前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が既に申請済みであると判定された場合には、前記第１の電子文書の申請に伴って前記伝票起票手段により新たな第２の電子文書の起票を行わずに、前記申請を受付けた第１の電子文書の申請を行う再申請抑止処理を行う再申請抑止手段と、を有し、
前記再申請抑止手段は、
前記伝票起票手段によって前記第１の電子文書が申請されることに伴って起票される前記第２の電子文書が申請済みでないと判定された場合には、前記申請を受付けた第１の電子文書の申請および、当該第１の電子文書が申請されることに伴って前記伝票起票手段により新たに起票された前記第２の電子文書の申請を行うことを特徴とする。
【発明の効果】
【００１０】
帳票をデータベースへ書き込む際、正常に書き込めなかった場合に、複数の関連する帳票間で処理結果に不具合が発生しないワークフローシステムを提供することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【図２】図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【図４】従来のワークフローのシーケンスを示すシーケンスチャートである。
【図５】第１のモードに対応するシーケンスチャートである。
【図６】は第２のモードに対応するシーケンスチャートである。
【図７】クライアント４１０の制御フローを示すフローチャートである。
【図８】ワークフローサーバ２００の制御フローを示すフローチャートである。
【図９】本発明を適用可能なワークフローシステムの伝票画面の一例を示す図である。
【図１０】計算ボタン９１０のオブジェクト設定（編集）画面１０００である。
【図１１】通勤経路変更オブジェクトのオブジェクト編集画面１１００である。
【図１２】図１０のオブジェクト編集画面１０００によって、申請オブジェクトに設定された内容が記憶されたイメージ図である。
【図１３】ＲＤＢＭＳに記憶された内容の一例を示す図である。
【図１４】住所変更届の申請により、ＤＢに書き込まれたデータのイメージを示す図である。
【図１５】通勤経路変更届の申請により、ＤＢに書き込まれたデータのイメージを示す図である。
【発明を実施するための形態】
【００１２】
〔第１実施形態〕
以下、図面を参照して、本発明の詳細を説明する。
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。
【００１３】
実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル、各種プログラムを格納するワークフローサーバ２００を備えている。
【００１４】
これらワークフロー及び伝票設計用端末４００，ワークフロー操作用端末３００，ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。
【００１５】
ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，各種伝票情報等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。
【００１６】
ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。
【００１７】
ワークフローサーバ２００は、ワークフローシステムに関する情報（組織テーブル，役割テーブル，ユーザテーブル，ユーザ役割テーブル，配送定義情報，配送情報テーブル，閲覧権テーブル（起票者閲覧権テーブル，承認者閲覧権テーブル），各種伝票情報を格納するＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ  ＤａｔａＢａＳｅ  Ｍａｎａｇｅｍｅｎｔ  ＳｙＳｔｅｍ）２０５、ワークフロー操作用端末３００よりの要求を受け付けて要求を実行するためのＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３、ワークフロー通知機能を実現するＳＭＴＰサーバ２０４にて構成されている。
【００１８】
以下、図２を参照して、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。
【００１９】
図２は、図１に示したワークフローサーバ２００，ワークフロー操作用端末３００，ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。
【００２０】
図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク，ＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。
【００２１】
１０８は通信インタフェースで、通信ネットワーク５００への接続を可能とする。１０６は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０７は表示装置で、ＣＲＴ，ＬＣＤ等で構成される。
【００２２】
なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＨＴＴＰサーバ２０１，サーブレットエンジン２０２，ワークフロープログラム２０３，ＳＭＴＰサーバ２０４は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２３】
また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
【００２４】
さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。
【００２５】
また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１，システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。
図３は、図１に示したワークフローシステムにおける伝票の流れを示す模式図である。
【００２６】
本実施形態のワークフローシステムでは、ワークフロー操作用端末３００を用いて、図３に示すように、伝票の起票，伝票の承認／否認の手続きを、ノードと呼ばれる組織と役割で定義された担当者が行う。なお、伝票が配送されるノードをひとつに括ったものをビジネスプロセスと定義する。
【００２７】
ビジネスプロセスはその開始から終了までの間にいくつかのステップが必要となる。個々のステップでは、いくつかの手続き（起票、承認、否認、保留等）を取ることができる。
【００２８】
例えば図３で示すビジネスプロセスの場合、ノード０からノード４までの順に、社員→部長→本部長→事業本部長→社長のステップを踏み、「起票」→「承認／否認」→「承認／否認」→「承認／否認」→「承認／否認」の手続きにより構成される。
【００２９】
手続きは、個々のステップ（ノード）では、いくつかの手続きを取ることが出来る。主に前方向への手続き（申請、承認等）と、後方向への手続き（否認）に分類することができる。
このようなビジネスプロセスを定義した情報を経路情報という。
図４は、従来のワークフローのシーケンスを示すシーケンスチャートである。ある一つの申請に対して自動で別の申請が起票されるワークフローに対応する。
まず、ユーザ４００がステップＳ４０１で伝票Ａの申請ボタンをクライアント４１０上で押す。
【００３０】
次にステップＳ４０２で、クライアント４００は、伝票Ｂを自動で申請するとともに、ステップＳ４０３で伝票Ａを申請する。ここで、伝票Ａの申請ボタンには、ボタンが押されると、伝票Ｂを自動で申請するとともに、自身も申請する設定がなされているものとする（詳細は後述する）。申請を受領したサーバ４２０は、ステップＳ４０４で伝票ＢをＤＢ４３０に格納し、問題がなければ、ステップＳ４０５でＤＢへコミットすることでデータベースへの反映を行う。
【００３１】
次にステップＳ４０６で、サーバ４２０は、伝票ＡをＤＢ４３０に格納し、問題がなければ、ステップＳ４０７でＤＢ４３０へコミットすることでデータベースへの反映を行う。
【００３２】
しかしながら、図４の方法では、ステップＳ４０４の伝票ＢとステップＳ４０６の伝票Ａの処理はパラレルに行われるため、どちらかに問題が発生した場合であっても、片側が成功すればＤＢへのコミットが行われてしまうという問題がある。
【００３３】
図５は第１のモードに対応するシーケンスチャートであり、伝票Ａと伝票Ｂが両方格納されてから、両方の伝票のコミットをする、トランザクション処理を行うワークフローのシーケンスを示すシーケンスチャートである。図４と同一のものには同一の符号を利用している。
【００３４】
ユーザ４００がステップＳ５０１で伝票Ａの申請ボタンを押す。次にステップＳ５０２で、クライアント４１０は、伝票Ａの申請ボタンが押されることによって自動申請される伝票Ｂと、伝票Ａを一緒に申請する。
【００３５】
サーバ４２０は、ステップＳ５０３で伝票Ｂを格納し、続いてステップＳ５０４にて伝票Ａを格納する。伝票Ａおよび伝票Ｂの両方に問題がなければ、ステップＳ５０５でＤＢ４３０へのコミットを行う。
【００３６】
図６は第２のモードに対応するシーケンスチャートである。図５では、トランザクション処理を行う場合の処理について説明したが、本シーケンスチャートでは、トランザクション処理を行わない場合に発生する問題に対処している。その問題とは、伝票Ａの申請に伴い、伝票Ｂが自動申請された時に、伝票Ｂのコミットには成功し、伝票Ａがコミットできないケースである。この場合、伝票Ａがコミットできなかったので、ユーザが再度伝票Ａを申請する場合、既にコミットされている伝票Ｂまでも再度申請されてしまうといった問題である。
【００３７】
この問題に対応するために、図６の第２のモードのシーケンスチャートでは、伝票Ａの申請に伴い自動申請された伝票Ｂが過去に申請済みかどうかを確認し、既に申請されている場合は、再度申請しないように制御するものである。図４や図５のシーケンスチャートと同一のものには同一の符号を利用している。
【００３８】
ユーザ４００がステップＳ６０１で伝票Ａの申請ボタンを押す。次にステップＳ６０２で、クライアント４１０は、伝票Ａを申請することによって自動申請された伝票Ｂが既にＤＢ４３０に申請済みか確認する。具体的には、ステップＳ６０４で、サーバ４２０がＤＢ４３０に、伝票ＡのＩＤとともに記録された伝票Ｂを探すことにより確認している。この後、伝票Ｂが申請されていなかった場合には伝票Ａの伝票番号を付加して伝票Ｂを申請し、申請済みであった場合は、伝票Ｂの申請は行わない。詳細な処理については、図７のフローチャートで説明する。
【００３９】
そして、クライアント４１０は、ステップＳ６０３で伝票Ａを申請し、サーバ４２０は、ステップＳ６０５で伝票Ａを格納し、問題がなければステップＳ６０６でＤＢ４３０へのコミットを行う。
一例として、住所変更届が申請された時に、通勤経路変更届が自動的に申請されるシステムについて説明する。
【００４０】
図９は、本発明を適用可能なワークフローシステムの伝票画面の一例を示す図である。住所変更届９００の申請ボタンＡが押されることにより、住所変更届が申請されると、自動で通勤経路変更届伝票９２０が申請されるように設定されている。なお、通勤経路変更届は、通勤経路変更届伝票９２０を使用して申請しても、伝票画面起動せずに申請してもよい。
【００４１】
まず住所届変更届９００について説明する。本伝票の画面はクライアントＰＣ上に表示され、ユーザが入力をすることで申請が行われる。ユーザは、伝票番号９０１、社員番号９０２、氏名９０４、所属部門９０５、変更後の住所９０６および住所変更日９０７などを所定の記入欄に入力する。これら項目は、自動でシステムに入力されるものあってもよい。
また、ユーザは必要に応じて備考９０８に備考を入力することも可能である。承認欄９０９では、承認者の印鑑やサインなどが入力可能である。
【００４２】
また、申請ボタン９１０、保留ボタン９１１、解除ボタン９１２、印刷ボタン９１３、メールボタン９１４および終了ボタン９１５が設定されている。各ボタンには、オブジェクトとも呼ばれ、ボタンが押された後の処理などを設定することが可能となっている。
【００４３】
図１０は、計算ボタン９１０のオブジェクト設定（編集）画面１０００である。伝票選択欄１００１では、住所変更届９００、オブジェクト欄１００２では、本オブジェクトの種類として「計算」、名称として「申請オブジェクト」が設定されている。なお、伝票選択欄１００１では、伝票選択ボタンを押すことにより、システムに登録されている伝票を呼び出し表示することが可能となっている。
条件式欄１００３では、オブジェクトの実行条件を設定することが可能である。本実施例では無条件が設定されていることを示す。
【００４４】
計算式欄１００４には、本オブジェクトを定義したボタンが押された時の計算式を設定する。本オブジェクトが定義された申請ボタン９１０が押された時に処理される内容である。計算式欄００５には、まず１番目の処理として「通勤経路変更オブジェクト」を抽出し、次に２番目の処理として「住所変更伝票」を配送する設定がなされている。ここで、抽出とは、通勤経路変更オブジェクトを呼び出し、通勤経路変更届を申請することをいう。また、配送とは、住所変更伝票を申請することをいう。つまり、住所変更届９１０の画面から申請ボタン９１０が押されると、通勤経路変更届が自動で申請されると同時に住所変更届の申請も行われる。
【００４５】
図１２は、図１０のオブジェクト編集画面１０００によって、申請オブジェクトに設定された内容が記憶されたイメージ図である。処理順１２０１では、設定されたオブジェクトが実行される際の処理の順番を示している。オブジェクトの種類１２０２では、オブジェクトの種類を示しており、処理内容１２０３では、設定されたオブジェクトの処理内容が設定されている。
【００４６】
まず１番目の処理として「通勤経路変更オブジェクト」を抽出し、次に２番目の処理として「住所変更伝票」を配送する設定がなされている。ここで、抽出とは、通勤経路変更オブジェクトを呼び出し、通勤経路変更届を申請することをいう。また、配送とは、住所変更伝票を申請することをいう。
【００４７】
図９の通勤経路変更届９２０は、ユーザが通勤経路の変更を行う際に利用する伝票であり、クライアントＰＣに表示されるものである。しかし、本実施形態では、申請ボタン９１０が押されると自動で通勤経路変更届が申請されるので、本通勤経路変更届９２０の画面は表示されないことになる。また、変更する通勤経路欄９２８に記入すべき内容は、不図示の自宅住所と最寄り駅、勤務先と利用駅とが対応付けて記録された対応表から選択されることになる。この対応表は、ワークフローサーバのＲＤＢＭＳ２０５に記憶されている。
【００４８】
図７は、クライアント４１０の制御フローを示すフローチャートである。本フローチャートの処理に入る前に行われている処理として、図１０で設定されたように伝票Ａ（住所変更届伝票）が申請されると、伝票Ｂ（通勤経路変更届伝票）が自動で申請されるような処理が行われている。
【００４９】
ステップＳ７０１で複数の伝票を一度に処理するかどうかのトランザクション処理を行うかどうかの判定を行う。具体的には、図５のシーケンスチャートで示した第１のモードの処理を行うかどうかの判定を行う。トランザクション処理を行うかどうかの設定は、ワークフローの定義情報に記憶されている。
【００５０】
ステップＳ７０１で、トランザクション処理が行われると判断された場合、ステップＳ７０９において、伝票Ｂ、伝票Ａを１つのトランザクションとして、サーバに申請する。ステップＳ７１０では、申請が成功したかどうかの判断を行い、成功した場合には、ステップＳ７１４で、ＯＫ表示し伝票画面を閉じる。一方、失敗した場合には、ステップＳ７１５で、エラー表示し、伝票画面を閉じる。失敗と判定するケースの例としては、通信エラー、配送先が見つからないなどのシステムエラー、データベースシステムのエラー、その他システムエラー（メモリ不足など）が挙げられる。
【００５１】
ステップＳ７０１で、トランザクション処理は行わないと判断した場合は、ステップＳ７０２において、再申請抑止機能がＯＮであるかどうかの判定を行う。再申請抑止機能を利用するかどうかの設定は、後述する図７のオブジェクト編集画面で行うことが可能である。
【００５２】
ステップＳ７０２で再申請抑止機能がＯＦＦであると判定された場合、ステップＳ７０３に進み、以降、図４のシーケンスチャートに示したワークフローの処理を行う。
【００５３】
ステップＳ７０３で伝票Ｂの申請を行い、ステップＳ７０４では、申請が成功したかどうかの判断を行う。成功した場合には、ステップＳ７０５に進み、一方、失敗した場合には、ステップＳ７１３に進み、エラー表示し、伝票画面を閉じて処理を終了する。
【００５４】
ステップＳ７０５で伝票Ａの申請を行い、ステップＳ７０６では申請が成功したかどうかの判断を行う。成功した場合は、ステップＳ７１１において正常終了し、伝票画面を閉じる。一方、失敗した場合には、ステップＳ７１２に進み、エラー表示し伝票画面を閉じて、処理を終了する。
【００５５】
ステップＳ７０２で再申請抑止機能がＯＮであると判定された場合、図６のシーケンスチャートで示した第２のモードの処理を行う。再申請抑止機能がＯＮかどうかの判定は、通勤経路変更オブジェクトに設定されている内容によって判定する。
【００５６】
これにより、住所変更に伴い通勤経路変更が自動で申請されるような場合、どちらかがエラーになると不具合の発生するものに関しては、トランザクション処理を適用することが可能となる。また、住所変更と通勤経路変更を非同期で処理するような設定も可能である。しかし、その場合は自動で申請される伝票が何度も申請されることになってしまう。その場合、再申請抑止機能を利用することにより、何度も申請されることを防ぐことが可能となる。そしてこれらの機能を組み合わせることにより、申請内容に合った、自動申請機能を実現することが可能となる。
【００５７】
図１１は、通勤経路変更オブジェクトのオブジェクト編集画面１１００である。伝票選択欄１１０１で住所変更届が選択されている。オブジェクト欄１１０２では、オブジェクトの種類として「抽出」、名称として「通勤経路オブジェクト」が設定されている。トランザクション欄１１０５、再申請抑止欄１１０６に「ＯＮ」か「ＯＦＦ」が設定されている。トランザクションが「ＯＮ」の場合は、図５に示すような伝票間で同期されたトランザクションモードの処理が行われる。「ＯＦＦ」設定された内容は、図４に示すような伝票間で非同期に処理を行うような処理が行われる。図１３に示すように、ＲＤＢＭＳ２００に記憶される。図１３は、図１１のオブジェクト編集画面で設定された内容が記憶されたＲＤＢＭＳのイメージ図である。
【００５８】
ステップＳ７０２で再申請抑止機能がＯＮであると判定されると、ステップＳ７０７で、伝票Ｂは申請済みかどうかの確認を行う。具体的には、ＤＢの格納されたテーブルを確認することで行われる。
【００５９】
図１４は、住所変更届の申請により、ＤＢに書き込まれたデータのイメージを示す図である。伝票番号１４０１、住所変更日１４０２、社員番号１４０３、氏名１４０４および変更後の住所１４０５が保存されている。
【００６０】
図１５は、通勤経路変更届の申請により、ＤＢに書き込まれたデータのイメージを示す図である。伝票番号１５０１、経路変更日１５０２、社員番号１５０３、氏名１５０４、変更後の経路１５０５および住所変更番号１５０６が記憶されている。住所変更伝票番号１５０６は、住所変更届の申請に伴い自動申請された時に付与される項目である。ユーザが手入力で申請する場合は、図９の通勤経路変更届伝票から申請されたものが記憶されている。
【００６１】
ステップＳ７０７で伝票Ｂが申請済みかどうかについては、既に住所変更届によって自動で申請された通勤経路変更届が申請済みか、つまり住所変更伝票番号１５０６に自動申請された元となる住所変更届の伝票番号が記載されているかどうかの判定によって行う。伝票Ｂが申請済（つまり再申請）であった場合は、ステップ３７０５に進む。
【００６２】
一方、伝票Ｂの申請がなされていない（つまり再申請ではなく初回の申請）場合はステップＳ７０８で、元となる住所変更届の伝票番号を住所変更伝票番号１５０６欄に付加する。これにより、万が一伝票Ａの書き込みに失敗した場合でも伝票Ｂは再申請されないようにすることができる。
次にステップＳ７０４で伝票Ｂの書き込みが成功したかの判定を行い、失敗した場合は、ステップＳ７１３でエラー表示し伝票画面を閉じて処理を終了する。
【００６３】
一方、伝票の書き込みが成功した場合には、ステップＳ７０５で伝票Ａの申請を行い、ステップＳ７０６による書き込みが成功したかの判定により、成功した場合には、正常終了し伝票画面を閉じ、失敗した場合には、ステップＳ７１２でエラー表示し伝票画面を閉じて処理を終了する。
図８は、ワークフローサーバ２００の制御フローを示すフローチャートである。図４〜図６のシーケンスチャートのサーバ４２０の処理に対応する。
【００６４】
まず、ステップＳ８０１で２つ以上の伝票の処理かどうかを確認する。これは、図７のステップＳ７０１で第１のモード、すなわちトランザクション処理である場合は、２つ以上の伝票の処理ということになる。
【００６５】
ステップＳ８０１で、２つ以上の処理、すなわちトランザクション処理であると判断された場合は、ステップＳ８０６に進み、伝票の数だけの繰り返しをスタートする。
【００６６】
ステップＳ８０７では、経路情報に設定された配送先を決定する。ステップＳ８０８で配送先が決定されたかの判定を行い、失敗と判定された場合は、ステップＳ８１４のロールバックの処理に進む。一方、配送先が決定された場合は、ステップＳ８０９でデータベースに格納する。ステップＳ８１０では格納が成功したかどうかの判断を行う。失敗と判定するケースの例としては、通信エラー、配送先が見つからないなどのシステムエラー、データベースシステムのエラー、その他システムエラー（メモリ不足など）が挙げられる。
【００６７】
ステップＳ８１０でデータベースへの格納に失敗した場合には、ステップＳ８１４のロールバックの処理に進む。一方、格納に成功した場合には、ステップＳ８１１に進み複数の伝票の数だけ繰り返す。繰り返しが終わったら、ステップＳ８１２のコミットの処理へ進む。
【００６８】
ステップＳ８０１で２つ以上の伝票の処理ではないと判断された場合は、ステップＳ８０２で、経路情報に設定された配送先を決定する。ステップＳ８０３で配送先が決定されたかの判定を行い、失敗と判定された場合は、ステップＳ８１４のロールバックの処理に進む。一方、配送先が決定された場合は、ステップＳ８０４でデータベースに格納する。ステップＳ８０５では格納が成功したかどうかの判断を行う。失敗と判定するケースの例としては、通信エラー、配送先が見つからないなどのシステムエラー、データベースシステムのエラー、その他システムエラー（メモリ不足など）が挙げられる。
【００６９】
ステップＳ８０５でデータベースへの格納に失敗した場合には、ステップＳ８１４のロールバックの処理に進み、一方、格納に成功した場合には、ステップ８１２のコミットの処理に進む。
ステップＳ８１２では、ＤＢへのコミットを行い、ステップＳ８１３でクライアントへ正常終了のステータスを返し処理を終了する。
ステップＳ８１３では、ロールバック処理を行い、ステップＳ８１５でクライアントにエラーのステータスを返して処理を終了する。
【００７０】
なお、図７のクライアントの処理および図８のサーバの処理に関しては一部又は全部をクライアント側、サーバ側で行うようにしても構わない。  よって、本発明によれば、複数の権限を有する起票者が保管した伝票を再度開くときに、煩わしいことなく、適切な権限でもって保管伝票を開くことが可能となる。
【００７１】
これにより、帳票をデータベースへ書き込む際、正常に書き込めなかった場合に、複数の関連する帳票間で処理結果に不具合が発生しないワークフローシステムを提供することが可能となる。
【００７２】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００７３】
また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。
【００７４】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００７５】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【００７６】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【００７７】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００７８】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００７９】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【００８０】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【００８１】
１０１  ＣＰＵ７
１０２  ＲＡＭ
１０３  ＲＯＭ
１０４  ＨＤ
１０６  入力装置
１０７  表示装置
１０８  通信インタフェース
【図１】
0005532915.tif 000002
【図２】
0005532915.tif 000003
【図３】
0005532915.tif 000004
【図４】
0005532915.tif 000005
【図５】
0005532915.tif 000006
【図６】
0005532915.tif 000007
【図７】
0005532915.tif 000008
【図８】
0005532915.tif 000009
【図９】
0005532915.tif 000010
【図１０】
0005532915.tif 000011
【図１１】
0005532915.tif 000012
【図１２】
0005532915.tif 000013
【図１３】
0005532915.tif 000014
【図１４】
0005532915.tif 000015
【図１５】
0005532915.tif 000016