情報処理装置、情報処理方法、プログラム
【課題】 ＥＤＩシステムにおいて、より業務に則したデータ交換処理の監視機能を提供すること
【解決手段】 受信したデータに対して処理を実行する情報処理装置であって、受信したデータの処理の実行を監視するスケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定し、時間内に前記データの処理が実行されなかったと判定された場合は実行されなかった旨を管理者に通知する。また、メール通知までに処理が実行された場合には、通知メールを削除し、遅延通知は行わない。
【解決手段】 受信したデータに対して処理を実行する情報処理装置であって、受信したデータの処理の実行を監視するスケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定し、時間内に前記データの処理が実行されなかったと判定された場合は実行されなかった旨を管理者に通知する。また、メール通知までに処理が実行された場合には、通知メールを削除し、遅延通知は行わない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子商取引における処理の実行状況を管理する技術に関する。
【背景技術】
【０００２】
多くの企業では、ＥＤＩシステムを用いて自社フォーマットと業界標準フォーマットを変換し、業界標準プロトコルにより取引先とのデータ交換を行っている。
【０００３】
ＥＤＩシステムを用いたデータ交換においては、データ交換の実行結果（処理が正常に終了したか、異常が発生したか）については、電子メール等を用いて通知することが可能である。しかし、そもそもデータの送受信自体が発生したか否かについては、運用管理機能にある履歴画面を手動で表示し、目視による確認を行う必要がある。そのため、運用者は常に履歴画面を確認する必要があるが、手間がかかり不便である。
【０００４】
ＥＤＩシステム（自社システム）からデータを発信（送信）する場合は、実行結果さえ通知できれば良いが、外部システムから発信されたデータを受信する場合には、どのタイミングでデータが発信されるかが不明であるため、上述の確認作業が必要となる。
【０００５】
そこで、特許文献１には、ＥＤＩファイル転送システムと組み合わせるジョブスケジューラの遅延通知を行うシステムが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−１２８９０６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記特許文献１のシステムでは、着信待機時間と遅延監視時間が同一の設定となっている。すなわち、着信（受信）を待機している時間内にデータを受信できなければ、処理が遅延していると判断される。
【０００８】
しかし、着信待機時間と遅延監視時間は必ずしも一致しないケースが存在する。例えば、２４時間、常に着信を待機しているが、所定の時間帯に着信ができなければ通知をしたいといった場合である。
【０００９】
このような場合、特許文献１のシステムでは、着信待機時間と遅延監視時間が同一であることから対応できず、ユーザの要望に沿えないことがある。
【００１０】
また、特許文献１では、遅延監視時間内に処理が完了していない場合には通知がされることになる。しかし、遅延監視時間内に処理が完了していなくても、監視時間内に処理が開始され、遅延通知がされるまでの間に処理が完了しているという場合には、遅延とみなさず正常扱いとしたいケースも存在する。
【００１１】
さらに、特許文献１のシステムでは、ひとつひとつのジョブ（データ交換）ごとに遅延した旨の通知がなされてしまい、大量のジョブを処理するシステムにおいては、大量の通知がなされることもあり、業務が煩雑となってしまう。
【００１２】
そこで、上記課題を解決するべく、本発明は、ＥＤＩシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、受信したデータに対して処理を実行する情報処理装置であって、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、を備えることを特徴とする。
【００１４】
また、本発明は、受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、を備えることを特徴とする。
【００１５】
また、本発明は、受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、前記情報処理装置を、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ＥＤＩシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明のＥＤＩシステムの構成の一例を示すシステム構成図である。
【図２】図１に示したＥＤＩサーバ１００，メールサーバ１０１に適用可能な情報処理装置のハードウェア構成を示すブロック図である。
【図３】図１に示したＥＤＩサーバ１００の機能構成の一例を示すブロック図である。
【図４】本発明におけるＥＤＩシステムにおける遅延通知処理の一例を示すフローチャートである。
【図５】本発明におけるＥＤＩシステムにおける遅延監視処理の一例を示すフローチャートである。
【図６】本発明におけるＥＤＩシステムにおける通信処理の一例を示すフローチャートである。
【図７】本発明におけるＥＤＩシステムにおけるメール送信処理の一例を示すフローチャートである。
【図８】本発明におけるＥＤＩシステムのファイル転送監視スケジュール状況テーブルの一例を示すデータ構成図である。
【図９】本発明におけるＥＤＩシステムのメール通知実行スケジュール状況テーブルの一例を示すデータ構成図である。
【図１０】本発明におけるＥＤＩシステムのユーザマスタテーブルの一例を示すデータ構成図である。
【図１１】本発明におけるＥＤＩシステの通知メール状況テーブルの一例を示すデータ構成図である。
【図１２】ファイル転送監視スケジュールの設定を受け付ける画面の一例である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１９】
図１は、ＥＤＩサーバ１００、１つのメールサーバ１０１がローカルエリアネットワーク（ＬＡＮ）を介して接続される構成となっている。また、ＥＤＩサーバ１００と、１又は複数の接続先（取引先）側ＥＤＩシステム１０２が公衆回線・専用線・インターネットなどのネットワークを介して接続される構成となっている。
【００２０】
ＥＤＩサーバ１００は、各種テーブル（後述する図８〜１１に示す）を記憶し、接続先側ＥＤＩシステム１０２とファイル転送処理（データ交換処理）を行う。その結果、ファイル転送処理に遅延が発生した場合、メールサーバ１０１に対してメール送信を要求する。送信されたメールは、事前に登録したメールアドレスへ送信され、遅延が発生したことを担当者が検知できる仕組みである。具体的には、事前に登録されたファイル転送監視スケジュール状況テーブル（図８）をもとに、ファイル転送に遅延がないかを監視する。もし、遅延がある場合は、メールサーバ１０１に対して、遅延通知メールを送信する。
【００２１】
またメール通知は、即時通知とまとめ通知の２種類が用意されているものとする。まとめ通知を選択していた際は、メール通知までの間に通信が実行された場合に、遅延通知メールを送信しないようにステータスを更新するといった制御が可能である。
【００２２】
なおＥＤＩサーバ１００は本発明における情報処理装置の適用例となる構成である。
【００２３】
メールサーバ１０１は、メール送信を行うためのＳＭＴＰサーバ機能を搭載したサーバである。
【００２４】
接続先側ＥＤＩシステム１０２は、ＥＤＩ通信プロトコルを搭載したサーバである。ＥＤＩサーバ１００や、その他のＥＤＩシステムと接続し、ファイル転送を行うことができる。
【００２５】
以下、図２を用いて、図１に示したＥＤＩサーバ１００，メールサーバ１０１、接続先ＥＤＩシステム１０２に適用可能な情報処理装置のハードウェア構成について説明する。
【００２６】
図２は、図１に示したＥＤＩサーバ１００、メールサーバ１０１、接続先ＥＤＩシステム１０２に適用可能な情報処理装置のハードウェア構成を示すブロック図である。
【００２７】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。
【００２８】
２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００２９】
また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。
【００３０】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３１】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ４００）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３２】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３３】
ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３４】
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
【００３５】
図３は、本発明の実施例におけるＥＤＩサーバ１００の機能構成の一例を示すブロック図である。
【００３６】
監視スケジュール設定受付部３０１は、図１２に示す設定画面を介して、転送ファイル毎に監視スケジュールの設定を受け付ける。
【００３７】
判定部３０２は、監視スケジュール設定受付部３０１で受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する。また、通知時刻受付部３０４で受け付けた通知時刻までに当該データの処理が実行されたか否かを判定する。
【００３８】
通知部３０３は、判定部３０２により監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、当該実行されなかった旨（処理が遅延している旨）を管理者に通知する。
【００３９】
通知時刻受付部３０４は、通知部３０３により管理者に対して処理が実行されなかった旨を通知する時刻を管理者ごとに受け付ける。受け付けた結果が図９に示すメール通知実行スケジュール状況テーブルに登録される。
【００４０】
通知メール記憶部３０５は、図１１に示す通知メール状況テーブルを記憶する。すなわち、判定部により監視スケジュールで特定される時間内にデータ処理が実行されなかったと判定されたデータに関して、処理が遅延している旨を通知するメールを記憶する。
【００４１】
通知メール削除部３０６は、図１１のテーブルに登録された通知メールのうち、判定部３０２で通知時刻までにデータの処理が実行されたと判定された場合、当該データにかかる通知メールを削除する（削除済みにステータスを更新する）。
【００４２】
次に、図４を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する遅延通知処理について説明する。
【００４３】
なお、図４のフローチャートで示す処理については、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００４４】
ステップＳ４０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延監視処理を実行する。遅延監視処理は、ファイル転送処理において遅延が発生したことを検知し、遅延通知メールを登録する処理である。詳細については、図５のフローチャートを用いて後述する。
【００４５】
ステップＳ４０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延通知メール（ステップＳ４０１で登録されたメール）の消し込み処理を実行する。消し込み処理は、ファイル転送処理自体は遅延していたが、遅延通知メールを送信するまでの間に処理が実行された場合に、当該処理にかかる遅延通知メールを削除する処理である。本処理の詳細については、図６のフローチャートを用いて後述する。
【００４６】
ステップＳ４０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延通知メールの送信処理を実行する。ステップＳ４０１で登録されたメールを送信する処理であり、本処理の詳細については、図７のフローチャートを用いて後述する。
【００４７】
次に図５を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する遅延監視処理について説明する。
【００４８】
なお図５のフローチャートで示す処理は、図４のステップＳ４０１の処理の詳細であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００４９】
ステップＳ５０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延監視状態に遷移すべき情報があるか否か、すなわち監視開始時刻が到来したレコードがあるか否かを判断する。
【００５０】
具体的には、ファイル転送監視スケジュール状況テーブル（図８）から、ステータスが「監視待ち」であり「監視開始時刻」がＥＤＩサーバ１００のシステム時刻を経過したレコードを検索する。検索の結果当該レコードが存在した場合は、遅延監視状態に遷移すべき情報があると判断される。
【００５１】
遅延監視状態に遷移すべき情報があると判断された場合（ステップＳ５０１：ＹＥＳ）は、処理をステップＳ５０２に移行する。
【００５２】
遅延監視状態に遷移すべき情報がないと判断された場合（ステップＳ５０１：ＮＯ）は、処理をステップＳ５０３に移行する。
【００５３】
ステップＳ５０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０１で検索されたレコードのステータスを「監視中１」に変更する。「監視中１」とは、当該レコードの監視開始時刻から監視終了時刻の間であり、通信処理が実行されていない状態を示す。
【００５４】
ステップＳ５０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延完了状態に遷移すべき情報があるか否か、すなわち通信処理が実行されないまま監視終了時刻が到来したレコードがあるか否かを判断する。
【００５５】
具体的には、ファイル転送監視スケジュール状況テーブル（図８）から、ステータスが「監視中１」であり、「監視終了時刻」がＥＤＩサーバ１００のシステム時刻を経過したレコードを検索する。検索の結果、当該レコードが存在した場合は、遅延完了状態に遷移すべき情報が存在すると判断される。
【００５６】
遅延完了状態に遷移すべき情報が存在すると判断された場合（ステップＳ５０３：ＹＥＳ）は、処理をステップＳ５０４に移行する。
【００５７】
遅延完了状態に遷移すべき情報が存在しないと判断された場合（ステップＳ５０３：ＮＯ）は、処理をステップＳ５０７に移行する。
【００５８】
ステップＳ５０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で検索されたレコードを遅延通知が必要な情報とみなし（監視中である（通信処理が実行されていない）のに、監視終了時刻が到来したため）、通知メール状況テーブル（図１１）に当該レコードを追加する。この際、ユーザマスタテーブル（図１０）に登録されたユーザすべてに対して遅延通知をするため、ユーザマスタテーブルに登録されたユーザ分のレコードを追加する。また、ステータスは「通知待ち」とする。
【００５９】
ステップＳ５０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で検索され抽出されたレコードの遅延判定が「終了時」の場合は、ステップＳ５０８へ処理を移行する。他方、遅延判定が「開始時延長」の場合は、処理をステップＳ５０６へ移行する。
【００６０】
なお、「遅延判定が終了時」とは、監視終了時刻が到来した時点で通信処理が終了（完了）していない場合には遅延と判定することを意味する。
【００６１】
また、「遅延判定が開始時延長」とは、監視終了時刻が到来した時点で通信処理が終了（完了）していなくても、遅延している旨のメールを送信するまでの間に処理が開始されていれば、遅延とは判定されないことを意味する。このような判定の仕方を採用することで、遅延監視時刻が到来したあとであっても、遅延を通知するメールが送信されるまでの間に処理がなされた場合には、遅延している旨のメールを送信せずに済ませることが可能となる。
【００６２】
ステップＳ５０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で抽出されたレコードのうち、遅延判定が「開始時延長」のレコードのステータスを「監視中２」に更新する。これにより、「監視中２」のステータス時にファイル転送が正常終了した場合、未通知の遅延通知メールを消し込むことが可能となる。
【００６３】
なお、「監視中２」とは、監視終了時刻からメール通知までの間における監視をしている状態を示すステータスである。
【００６４】
ステップＳ５０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延完了状態に遷移すべき情報、すなわち監視終了時刻が到来しているのに未通信のレコードがあるか否かを判断する。具体的には、ファイル転送監視スケジュール状況テーブルからステータスが「監視中２」であり通信ステータスが「未通信」のレコードを検索し抽出する。レコードが抽出された場合、すなわち遅延完了状態に遷移すべき情報がある場合（ステップＳ５０７：ＹＥＳ）は処理をステップＳ５０８に移行する。レコードが抽出されなかった場合、すなわち遅延完了状態に遷移すべき情報がない場合（ステップＳ５０７：ＮＯ）は、処理をステップＳ５１０へ移行する。
【００６５】
ステップＳ５０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延状態を確定するために、ステップＳ５０５またはステップＳ５０７で抽出されたレコードに対して、遅延結果を「遅延あり」に更新する。
【００６６】
ここで、遅延結果が「遅延あり」とは、監視終了時刻までにファイル転送処理が実行されなかったことを意味する。
【００６７】
ステップＳ５０９では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０８で遅延結果を更新したレコードについて、ステータスを「監視済み」に更新する。なお、ステータスが「監視中２」であるレコードについては、ステータスの更新は行わない。
【００６８】
ステップＳ５１０では、ＥＤＩサーバ１００のＣＰＵ２０１は、ユーザからの遅延監視終了要求があるか否かを判断する。
【００６９】
遅延監視終了要求があった場合は、本フローチャートに示す処理を終了する。
【００７０】
遅延監視終了要求がない場合は、処理をステップＳ５０１に戻し、本フローチャートの処理を繰り返す。
【００７１】
次に、図６を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する通信処理について説明する。
【００７２】
なお、図６のフローチャートで示す処理は、図４のステップＳ４０２に該当する処理であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００７３】
ステップＳ６０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、ファイル転送監視スケジュール状況テーブルの処理対象レコードの通信ステータスを「通信中」に更新する。
【００７４】
ステップＳ６０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、処理対象レコードにかかる転送ファイルについて、ファイル転送処理を実行する。
【００７５】
ステップＳ６０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０２の処理の結果、通信結果が正常であったか否かを判断する。
【００７６】
正常であった場合（ステップＳ６０３：ＹＥＳ）は、処理をステップＳ６０４へ移行する。
【００７７】
正常ではない場合は（ステップＳ６０３：ＮＯ）は、処理をステップＳ６０９に移行する。
【００７８】
ステップＳ６０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ファイル転送監視スケジュール状況テーブルのレコードから、処理対象のレコードであり、ステータスが「監視中１」または「監視中２」のレコードを検索する。
【００７９】
ステップＳ６０４における検索の結果、該当するレコードが存在する場合（ステップＳ６０４：ＹＥＳ）は、処理をステップＳ６０５に移行する。
【００８０】
ステップＳ６０４における検索の結果、該当するレコードが存在しない場合（ステップＳ６０４：ＮＯ）は、処理をステップＳ６０９に移行する。
【００８１】
ステップＳ６０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０４で検索されたレコードに対して、遅延結果を「遅延なし」に更新する。
【００８２】
ステップＳ６０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０４で検索されたレコードに対して、ステータスを「監視済み」に更新する。
【００８３】
ステップＳ６０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、通知メール状況テーブル（図１１）からステップＳ６０４で検索されたレコードと関連するレコードであり、ステータスが「通知待ち」のレコードを検索する。
【００８４】
ステップＳ６０７における検索の結果、該当するレコードが存在する場合（ステップＳ６０７：ＹＥＳ）は、処理をステップＳ６０８に移行する。
【００８５】
ステップＳ６０７における検索の結果、該当するレコードが存在しない場合（ステップＳ６０７：ＮＯ）は、処理をステップＳ６０９に移行する。
【００８６】
ステップＳ６０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０７で検索されたレコードのステータスを「削除済み」に更新する。これにより、ステータスが「監視中２」であるときにファイル転送処理が実行されたレコードについては、遅延通知のメールを送信しないことが可能となる。
【００８７】
ステップＳ６０９では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０１で変更したステータスを戻すために、ファイル転送監視スケジュール状況テーブルの通信ステータスを「未通信」に更新する。
【００８８】
次に、図７を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行するメール送信処理について説明する。
【００８９】
なお図７のフローチャートで示す処理は、図４のステップＳ４０３に示す処理であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００９０】
ステップＳ７０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、メールのまとめ通知を実施するために、ユーザマスタテーブル（図１０）で「まとめ通知あり」のユーザのうち、メール通知実行スケジュール状況テーブル（図９）から、ステータスが「実行待ち」であり、メール通知時刻がＥＤＩサーバ１００のシステム時刻を経過したれレコードを検索する。すなわち、まとめメール通知すべきユーザがいるか否かを判断する。
【００９１】
ステップＳ７０１の検索の結果、該当するレコードが抽出された（存在した）場合（ステップＳ７０１：ＹＥＳ）は、処理をステップＳ７０２に移行する。
【００９２】
ステップＳ７０１の検索の結果、該当するレコードが抽出されなかった（存在しなかった）場合（ステップＳ７０１：ＮＯ）は、処理をステップＳ７０５に移行する。
【００９３】
ステップＳ７０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、通知メール状況テーブル（図１１）のレコードのうち、ステップＳ７０１で抽出されたレコードのユーザＩＤと対応するレコードであり、ステータスが「通知待ち」のレコードを検索する。すなわち、通知先ユーザへ通知すべきレコードを検索する。
【００９４】
検索の結果、抽出できた場合（該当するレコードが存在した場合）（ステップＳ７０２：ＹＥＳ）は、処理をステップＳ７０３に移行する。
【００９５】
検索の結果、抽出できなかった場合（該当するレコードが存在しない場合）（ステップＳ７０２：ＮＯ）は、処理をステップＳ７０５に移行する。
【００９６】
ステップＳ７０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０２で抽出された全てのレコードのメール情報を、１ユーザに対して１通のメールにまとめて送信する。具体的には、同一のユーザＩＤのレコードのメール内容を、１メールに添付し、メールサーバへＳＭＴＰプロトコルでユーザマスタテーブル（図１０）のメールアドレス宛てに送信する。
【００９７】
ステップＳ７０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０２で抽出されたレコードのステータスを「通知済み」に更新する。
【００９８】
ステップＳ７０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、まとめ通知ではなく即時通知にメールを検出するために、ユーザマスタテーブル（図１０）のまとめ通知が「なし」であるユーザを検索し、当該ユーザＩＤで通知メール状況テーブル（図１１）を検索し、ステータスが「通知待ち」のレコードを抽出する。
【００９９】
該当するレコードが存在した場合（ステップＳ７０５：ＹＥＳ）は、処理をステップＳ７０６に移行する。
【０１００】
該当するレコードが存在しない場合（ステップＳ７０５：ＮＯ）は、処理をステップＳ７０８に移行する。
【０１０１】
ステップＳ７０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０５で抽出されたれレコードから、１レコード１メールとしてユーザに送信する。
【０１０２】
ステップＳ７０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０５で抽出されたレコードのステータスを通知済みに更新する。
【０１０３】
ステップＳ７０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、ユーザからのメール送信監視終了要求があるか否かを確認し、終了要求があれば処理を終了する。終了要求が無ければ、処理をステップＳ７０１に移行し、再度メール送信監視処理を繰り返す。
【０１０４】
図１２は、ファイル転送監視スケジュールの設定を受け付ける画面の一例である。転送ファイル毎に監視スケジュールの設定を受け付ける。
【０１０５】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１０６】
また、本発明におけるプログラムは、図４〜図７の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図４〜図７の各装置の処理方法ごとのプログラムであってもよい。
【０１０７】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【０１０８】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【０１０９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０１１０】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１１】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１２】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１３】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１１４】
１００ ＥＤＩサーバ
１０１ メールサーバ
１０２ 接続先ＥＤＩシステム
１０３ ＬＡＮ
１０４ 広域ネットワーク
【技術分野】
【０００１】
本発明は、電子商取引における処理の実行状況を管理する技術に関する。
【背景技術】
【０００２】
多くの企業では、ＥＤＩシステムを用いて自社フォーマットと業界標準フォーマットを変換し、業界標準プロトコルにより取引先とのデータ交換を行っている。
【０００３】
ＥＤＩシステムを用いたデータ交換においては、データ交換の実行結果（処理が正常に終了したか、異常が発生したか）については、電子メール等を用いて通知することが可能である。しかし、そもそもデータの送受信自体が発生したか否かについては、運用管理機能にある履歴画面を手動で表示し、目視による確認を行う必要がある。そのため、運用者は常に履歴画面を確認する必要があるが、手間がかかり不便である。
【０００４】
ＥＤＩシステム（自社システム）からデータを発信（送信）する場合は、実行結果さえ通知できれば良いが、外部システムから発信されたデータを受信する場合には、どのタイミングでデータが発信されるかが不明であるため、上述の確認作業が必要となる。
【０００５】
そこで、特許文献１には、ＥＤＩファイル転送システムと組み合わせるジョブスケジューラの遅延通知を行うシステムが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−１２８９０６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記特許文献１のシステムでは、着信待機時間と遅延監視時間が同一の設定となっている。すなわち、着信（受信）を待機している時間内にデータを受信できなければ、処理が遅延していると判断される。
【０００８】
しかし、着信待機時間と遅延監視時間は必ずしも一致しないケースが存在する。例えば、２４時間、常に着信を待機しているが、所定の時間帯に着信ができなければ通知をしたいといった場合である。
【０００９】
このような場合、特許文献１のシステムでは、着信待機時間と遅延監視時間が同一であることから対応できず、ユーザの要望に沿えないことがある。
【００１０】
また、特許文献１では、遅延監視時間内に処理が完了していない場合には通知がされることになる。しかし、遅延監視時間内に処理が完了していなくても、監視時間内に処理が開始され、遅延通知がされるまでの間に処理が完了しているという場合には、遅延とみなさず正常扱いとしたいケースも存在する。
【００１１】
さらに、特許文献１のシステムでは、ひとつひとつのジョブ（データ交換）ごとに遅延した旨の通知がなされてしまい、大量のジョブを処理するシステムにおいては、大量の通知がなされることもあり、業務が煩雑となってしまう。
【００１２】
そこで、上記課題を解決するべく、本発明は、ＥＤＩシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、受信したデータに対して処理を実行する情報処理装置であって、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、を備えることを特徴とする。
【００１４】
また、本発明は、受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、を備えることを特徴とする。
【００１５】
また、本発明は、受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、前記情報処理装置を、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、ＥＤＩシステムにおいて、より業務に則したデータ交換処理の監視機能を提供することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明のＥＤＩシステムの構成の一例を示すシステム構成図である。
【図２】図１に示したＥＤＩサーバ１００，メールサーバ１０１に適用可能な情報処理装置のハードウェア構成を示すブロック図である。
【図３】図１に示したＥＤＩサーバ１００の機能構成の一例を示すブロック図である。
【図４】本発明におけるＥＤＩシステムにおける遅延通知処理の一例を示すフローチャートである。
【図５】本発明におけるＥＤＩシステムにおける遅延監視処理の一例を示すフローチャートである。
【図６】本発明におけるＥＤＩシステムにおける通信処理の一例を示すフローチャートである。
【図７】本発明におけるＥＤＩシステムにおけるメール送信処理の一例を示すフローチャートである。
【図８】本発明におけるＥＤＩシステムのファイル転送監視スケジュール状況テーブルの一例を示すデータ構成図である。
【図９】本発明におけるＥＤＩシステムのメール通知実行スケジュール状況テーブルの一例を示すデータ構成図である。
【図１０】本発明におけるＥＤＩシステムのユーザマスタテーブルの一例を示すデータ構成図である。
【図１１】本発明におけるＥＤＩシステの通知メール状況テーブルの一例を示すデータ構成図である。
【図１２】ファイル転送監視スケジュールの設定を受け付ける画面の一例である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１９】
図１は、ＥＤＩサーバ１００、１つのメールサーバ１０１がローカルエリアネットワーク（ＬＡＮ）を介して接続される構成となっている。また、ＥＤＩサーバ１００と、１又は複数の接続先（取引先）側ＥＤＩシステム１０２が公衆回線・専用線・インターネットなどのネットワークを介して接続される構成となっている。
【００２０】
ＥＤＩサーバ１００は、各種テーブル（後述する図８〜１１に示す）を記憶し、接続先側ＥＤＩシステム１０２とファイル転送処理（データ交換処理）を行う。その結果、ファイル転送処理に遅延が発生した場合、メールサーバ１０１に対してメール送信を要求する。送信されたメールは、事前に登録したメールアドレスへ送信され、遅延が発生したことを担当者が検知できる仕組みである。具体的には、事前に登録されたファイル転送監視スケジュール状況テーブル（図８）をもとに、ファイル転送に遅延がないかを監視する。もし、遅延がある場合は、メールサーバ１０１に対して、遅延通知メールを送信する。
【００２１】
またメール通知は、即時通知とまとめ通知の２種類が用意されているものとする。まとめ通知を選択していた際は、メール通知までの間に通信が実行された場合に、遅延通知メールを送信しないようにステータスを更新するといった制御が可能である。
【００２２】
なおＥＤＩサーバ１００は本発明における情報処理装置の適用例となる構成である。
【００２３】
メールサーバ１０１は、メール送信を行うためのＳＭＴＰサーバ機能を搭載したサーバである。
【００２４】
接続先側ＥＤＩシステム１０２は、ＥＤＩ通信プロトコルを搭載したサーバである。ＥＤＩサーバ１００や、その他のＥＤＩシステムと接続し、ファイル転送を行うことができる。
【００２５】
以下、図２を用いて、図１に示したＥＤＩサーバ１００，メールサーバ１０１、接続先ＥＤＩシステム１０２に適用可能な情報処理装置のハードウェア構成について説明する。
【００２６】
図２は、図１に示したＥＤＩサーバ１００、メールサーバ１０１、接続先ＥＤＩシステム１０２に適用可能な情報処理装置のハードウェア構成を示すブロック図である。
【００２７】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。
【００２８】
２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００２９】
また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。
【００３０】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３１】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ４００）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３２】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３３】
ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３４】
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
【００３５】
図３は、本発明の実施例におけるＥＤＩサーバ１００の機能構成の一例を示すブロック図である。
【００３６】
監視スケジュール設定受付部３０１は、図１２に示す設定画面を介して、転送ファイル毎に監視スケジュールの設定を受け付ける。
【００３７】
判定部３０２は、監視スケジュール設定受付部３０１で受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する。また、通知時刻受付部３０４で受け付けた通知時刻までに当該データの処理が実行されたか否かを判定する。
【００３８】
通知部３０３は、判定部３０２により監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、当該実行されなかった旨（処理が遅延している旨）を管理者に通知する。
【００３９】
通知時刻受付部３０４は、通知部３０３により管理者に対して処理が実行されなかった旨を通知する時刻を管理者ごとに受け付ける。受け付けた結果が図９に示すメール通知実行スケジュール状況テーブルに登録される。
【００４０】
通知メール記憶部３０５は、図１１に示す通知メール状況テーブルを記憶する。すなわち、判定部により監視スケジュールで特定される時間内にデータ処理が実行されなかったと判定されたデータに関して、処理が遅延している旨を通知するメールを記憶する。
【００４１】
通知メール削除部３０６は、図１１のテーブルに登録された通知メールのうち、判定部３０２で通知時刻までにデータの処理が実行されたと判定された場合、当該データにかかる通知メールを削除する（削除済みにステータスを更新する）。
【００４２】
次に、図４を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する遅延通知処理について説明する。
【００４３】
なお、図４のフローチャートで示す処理については、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００４４】
ステップＳ４０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延監視処理を実行する。遅延監視処理は、ファイル転送処理において遅延が発生したことを検知し、遅延通知メールを登録する処理である。詳細については、図５のフローチャートを用いて後述する。
【００４５】
ステップＳ４０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延通知メール（ステップＳ４０１で登録されたメール）の消し込み処理を実行する。消し込み処理は、ファイル転送処理自体は遅延していたが、遅延通知メールを送信するまでの間に処理が実行された場合に、当該処理にかかる遅延通知メールを削除する処理である。本処理の詳細については、図６のフローチャートを用いて後述する。
【００４６】
ステップＳ４０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延通知メールの送信処理を実行する。ステップＳ４０１で登録されたメールを送信する処理であり、本処理の詳細については、図７のフローチャートを用いて後述する。
【００４７】
次に図５を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する遅延監視処理について説明する。
【００４８】
なお図５のフローチャートで示す処理は、図４のステップＳ４０１の処理の詳細であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００４９】
ステップＳ５０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延監視状態に遷移すべき情報があるか否か、すなわち監視開始時刻が到来したレコードがあるか否かを判断する。
【００５０】
具体的には、ファイル転送監視スケジュール状況テーブル（図８）から、ステータスが「監視待ち」であり「監視開始時刻」がＥＤＩサーバ１００のシステム時刻を経過したレコードを検索する。検索の結果当該レコードが存在した場合は、遅延監視状態に遷移すべき情報があると判断される。
【００５１】
遅延監視状態に遷移すべき情報があると判断された場合（ステップＳ５０１：ＹＥＳ）は、処理をステップＳ５０２に移行する。
【００５２】
遅延監視状態に遷移すべき情報がないと判断された場合（ステップＳ５０１：ＮＯ）は、処理をステップＳ５０３に移行する。
【００５３】
ステップＳ５０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０１で検索されたレコードのステータスを「監視中１」に変更する。「監視中１」とは、当該レコードの監視開始時刻から監視終了時刻の間であり、通信処理が実行されていない状態を示す。
【００５４】
ステップＳ５０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延完了状態に遷移すべき情報があるか否か、すなわち通信処理が実行されないまま監視終了時刻が到来したレコードがあるか否かを判断する。
【００５５】
具体的には、ファイル転送監視スケジュール状況テーブル（図８）から、ステータスが「監視中１」であり、「監視終了時刻」がＥＤＩサーバ１００のシステム時刻を経過したレコードを検索する。検索の結果、当該レコードが存在した場合は、遅延完了状態に遷移すべき情報が存在すると判断される。
【００５６】
遅延完了状態に遷移すべき情報が存在すると判断された場合（ステップＳ５０３：ＹＥＳ）は、処理をステップＳ５０４に移行する。
【００５７】
遅延完了状態に遷移すべき情報が存在しないと判断された場合（ステップＳ５０３：ＮＯ）は、処理をステップＳ５０７に移行する。
【００５８】
ステップＳ５０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で検索されたレコードを遅延通知が必要な情報とみなし（監視中である（通信処理が実行されていない）のに、監視終了時刻が到来したため）、通知メール状況テーブル（図１１）に当該レコードを追加する。この際、ユーザマスタテーブル（図１０）に登録されたユーザすべてに対して遅延通知をするため、ユーザマスタテーブルに登録されたユーザ分のレコードを追加する。また、ステータスは「通知待ち」とする。
【００５９】
ステップＳ５０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で検索され抽出されたレコードの遅延判定が「終了時」の場合は、ステップＳ５０８へ処理を移行する。他方、遅延判定が「開始時延長」の場合は、処理をステップＳ５０６へ移行する。
【００６０】
なお、「遅延判定が終了時」とは、監視終了時刻が到来した時点で通信処理が終了（完了）していない場合には遅延と判定することを意味する。
【００６１】
また、「遅延判定が開始時延長」とは、監視終了時刻が到来した時点で通信処理が終了（完了）していなくても、遅延している旨のメールを送信するまでの間に処理が開始されていれば、遅延とは判定されないことを意味する。このような判定の仕方を採用することで、遅延監視時刻が到来したあとであっても、遅延を通知するメールが送信されるまでの間に処理がなされた場合には、遅延している旨のメールを送信せずに済ませることが可能となる。
【００６２】
ステップＳ５０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０３で抽出されたレコードのうち、遅延判定が「開始時延長」のレコードのステータスを「監視中２」に更新する。これにより、「監視中２」のステータス時にファイル転送が正常終了した場合、未通知の遅延通知メールを消し込むことが可能となる。
【００６３】
なお、「監視中２」とは、監視終了時刻からメール通知までの間における監視をしている状態を示すステータスである。
【００６４】
ステップＳ５０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延完了状態に遷移すべき情報、すなわち監視終了時刻が到来しているのに未通信のレコードがあるか否かを判断する。具体的には、ファイル転送監視スケジュール状況テーブルからステータスが「監視中２」であり通信ステータスが「未通信」のレコードを検索し抽出する。レコードが抽出された場合、すなわち遅延完了状態に遷移すべき情報がある場合（ステップＳ５０７：ＹＥＳ）は処理をステップＳ５０８に移行する。レコードが抽出されなかった場合、すなわち遅延完了状態に遷移すべき情報がない場合（ステップＳ５０７：ＮＯ）は、処理をステップＳ５１０へ移行する。
【００６５】
ステップＳ５０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、遅延状態を確定するために、ステップＳ５０５またはステップＳ５０７で抽出されたレコードに対して、遅延結果を「遅延あり」に更新する。
【００６６】
ここで、遅延結果が「遅延あり」とは、監視終了時刻までにファイル転送処理が実行されなかったことを意味する。
【００６７】
ステップＳ５０９では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ５０８で遅延結果を更新したレコードについて、ステータスを「監視済み」に更新する。なお、ステータスが「監視中２」であるレコードについては、ステータスの更新は行わない。
【００６８】
ステップＳ５１０では、ＥＤＩサーバ１００のＣＰＵ２０１は、ユーザからの遅延監視終了要求があるか否かを判断する。
【００６９】
遅延監視終了要求があった場合は、本フローチャートに示す処理を終了する。
【００７０】
遅延監視終了要求がない場合は、処理をステップＳ５０１に戻し、本フローチャートの処理を繰り返す。
【００７１】
次に、図６を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行する通信処理について説明する。
【００７２】
なお、図６のフローチャートで示す処理は、図４のステップＳ４０２に該当する処理であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００７３】
ステップＳ６０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、ファイル転送監視スケジュール状況テーブルの処理対象レコードの通信ステータスを「通信中」に更新する。
【００７４】
ステップＳ６０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、処理対象レコードにかかる転送ファイルについて、ファイル転送処理を実行する。
【００７５】
ステップＳ６０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０２の処理の結果、通信結果が正常であったか否かを判断する。
【００７６】
正常であった場合（ステップＳ６０３：ＹＥＳ）は、処理をステップＳ６０４へ移行する。
【００７７】
正常ではない場合は（ステップＳ６０３：ＮＯ）は、処理をステップＳ６０９に移行する。
【００７８】
ステップＳ６０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ファイル転送監視スケジュール状況テーブルのレコードから、処理対象のレコードであり、ステータスが「監視中１」または「監視中２」のレコードを検索する。
【００７９】
ステップＳ６０４における検索の結果、該当するレコードが存在する場合（ステップＳ６０４：ＹＥＳ）は、処理をステップＳ６０５に移行する。
【００８０】
ステップＳ６０４における検索の結果、該当するレコードが存在しない場合（ステップＳ６０４：ＮＯ）は、処理をステップＳ６０９に移行する。
【００８１】
ステップＳ６０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０４で検索されたレコードに対して、遅延結果を「遅延なし」に更新する。
【００８２】
ステップＳ６０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０４で検索されたレコードに対して、ステータスを「監視済み」に更新する。
【００８３】
ステップＳ６０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、通知メール状況テーブル（図１１）からステップＳ６０４で検索されたレコードと関連するレコードであり、ステータスが「通知待ち」のレコードを検索する。
【００８４】
ステップＳ６０７における検索の結果、該当するレコードが存在する場合（ステップＳ６０７：ＹＥＳ）は、処理をステップＳ６０８に移行する。
【００８５】
ステップＳ６０７における検索の結果、該当するレコードが存在しない場合（ステップＳ６０７：ＮＯ）は、処理をステップＳ６０９に移行する。
【００８６】
ステップＳ６０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０７で検索されたレコードのステータスを「削除済み」に更新する。これにより、ステータスが「監視中２」であるときにファイル転送処理が実行されたレコードについては、遅延通知のメールを送信しないことが可能となる。
【００８７】
ステップＳ６０９では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ６０１で変更したステータスを戻すために、ファイル転送監視スケジュール状況テーブルの通信ステータスを「未通信」に更新する。
【００８８】
次に、図７を用いて、本発明の実施形態においてＥＤＩサーバ１００が実行するメール送信処理について説明する。
【００８９】
なお図７のフローチャートで示す処理は、図４のステップＳ４０３に示す処理であり、ＥＤＩサーバ１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００９０】
ステップＳ７０１では、ＥＤＩサーバ１００のＣＰＵ２０１は、メールのまとめ通知を実施するために、ユーザマスタテーブル（図１０）で「まとめ通知あり」のユーザのうち、メール通知実行スケジュール状況テーブル（図９）から、ステータスが「実行待ち」であり、メール通知時刻がＥＤＩサーバ１００のシステム時刻を経過したれレコードを検索する。すなわち、まとめメール通知すべきユーザがいるか否かを判断する。
【００９１】
ステップＳ７０１の検索の結果、該当するレコードが抽出された（存在した）場合（ステップＳ７０１：ＹＥＳ）は、処理をステップＳ７０２に移行する。
【００９２】
ステップＳ７０１の検索の結果、該当するレコードが抽出されなかった（存在しなかった）場合（ステップＳ７０１：ＮＯ）は、処理をステップＳ７０５に移行する。
【００９３】
ステップＳ７０２では、ＥＤＩサーバ１００のＣＰＵ２０１は、通知メール状況テーブル（図１１）のレコードのうち、ステップＳ７０１で抽出されたレコードのユーザＩＤと対応するレコードであり、ステータスが「通知待ち」のレコードを検索する。すなわち、通知先ユーザへ通知すべきレコードを検索する。
【００９４】
検索の結果、抽出できた場合（該当するレコードが存在した場合）（ステップＳ７０２：ＹＥＳ）は、処理をステップＳ７０３に移行する。
【００９５】
検索の結果、抽出できなかった場合（該当するレコードが存在しない場合）（ステップＳ７０２：ＮＯ）は、処理をステップＳ７０５に移行する。
【００９６】
ステップＳ７０３では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０２で抽出された全てのレコードのメール情報を、１ユーザに対して１通のメールにまとめて送信する。具体的には、同一のユーザＩＤのレコードのメール内容を、１メールに添付し、メールサーバへＳＭＴＰプロトコルでユーザマスタテーブル（図１０）のメールアドレス宛てに送信する。
【００９７】
ステップＳ７０４では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０２で抽出されたレコードのステータスを「通知済み」に更新する。
【００９８】
ステップＳ７０５では、ＥＤＩサーバ１００のＣＰＵ２０１は、まとめ通知ではなく即時通知にメールを検出するために、ユーザマスタテーブル（図１０）のまとめ通知が「なし」であるユーザを検索し、当該ユーザＩＤで通知メール状況テーブル（図１１）を検索し、ステータスが「通知待ち」のレコードを抽出する。
【００９９】
該当するレコードが存在した場合（ステップＳ７０５：ＹＥＳ）は、処理をステップＳ７０６に移行する。
【０１００】
該当するレコードが存在しない場合（ステップＳ７０５：ＮＯ）は、処理をステップＳ７０８に移行する。
【０１０１】
ステップＳ７０６では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０５で抽出されたれレコードから、１レコード１メールとしてユーザに送信する。
【０１０２】
ステップＳ７０７では、ＥＤＩサーバ１００のＣＰＵ２０１は、ステップＳ７０５で抽出されたレコードのステータスを通知済みに更新する。
【０１０３】
ステップＳ７０８では、ＥＤＩサーバ１００のＣＰＵ２０１は、ユーザからのメール送信監視終了要求があるか否かを確認し、終了要求があれば処理を終了する。終了要求が無ければ、処理をステップＳ７０１に移行し、再度メール送信監視処理を繰り返す。
【０１０４】
図１２は、ファイル転送監視スケジュールの設定を受け付ける画面の一例である。転送ファイル毎に監視スケジュールの設定を受け付ける。
【０１０５】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１０６】
また、本発明におけるプログラムは、図４〜図７の処理方法をコンピュータが実行可能なプログラムである。なお、本発明におけるプログラムは図４〜図７の各装置の処理方法ごとのプログラムであってもよい。
【０１０７】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【０１０８】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【０１０９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０１１０】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１１】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１２】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１３】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１１４】
１００ ＥＤＩサーバ
１０１ メールサーバ
１０２ 接続先ＥＤＩシステム
１０３ ＬＡＮ
１０４ 広域ネットワーク
【特許請求の範囲】
【請求項１】
受信したデータに対して処理を実行する情報処理装置であって、
前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、
前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記通知手段により前記管理者に対して通知をする時刻の設定を受け付ける通知時刻受付手段をさらに備え、
前記判定手段は、さらに、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたか否かを判定し、
前記判定手段により、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたと判定された場合、前記通知手段は、当該データの処理が遅延している旨の通知はしないことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知するための電子メールを記憶する通知メール記憶手段をさらに備え、
前記通知手段は、前記通知メール記憶手段を、前記通知時刻時受付手段で受け付けた時刻に前記管理者に対して送信することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記通知メール記憶手段に記憶された電子メールのうち、前記判定手段により前記通知時刻受付手段で受け付けた時刻までに処理が実行されたと判定されたデータにかかる遅延通知メールを削除する通知メール削除手段をさらに備えることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記通知手段は、前記管理者に対する遅延通知が複数ある場合、当該通知をひとつの通知として当該管理者に通知することを特徴とする請求項１に記載の情報処理装置。
【請求項６】
受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、
前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、
前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、
前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、
を備えることを特徴とする情報処理方法。
【請求項７】
受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、
前記情報処理装置を、
前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、
前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とするプログラム。
【請求項１】
受信したデータに対して処理を実行する情報処理装置であって、
前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、
前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記通知手段により前記管理者に対して通知をする時刻の設定を受け付ける通知時刻受付手段をさらに備え、
前記判定手段は、さらに、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたか否かを判定し、
前記判定手段により、前記通知時刻受付手段で受け付けた時刻までに前記データの処理が実行されたと判定された場合、前記通知手段は、当該データの処理が遅延している旨の通知はしないことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知するための電子メールを記憶する通知メール記憶手段をさらに備え、
前記通知手段は、前記通知メール記憶手段を、前記通知時刻時受付手段で受け付けた時刻に前記管理者に対して送信することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記通知メール記憶手段に記憶された電子メールのうち、前記判定手段により前記通知時刻受付手段で受け付けた時刻までに処理が実行されたと判定されたデータにかかる遅延通知メールを削除する通知メール削除手段をさらに備えることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記通知手段は、前記管理者に対する遅延通知が複数ある場合、当該通知をひとつの通知として当該管理者に通知することを特徴とする請求項１に記載の情報処理装置。
【請求項６】
受信したデータに対して処理を実行する情報処理装置における情報処理方法であって、
前記情報処理装置の監視スケジュール設定受付手段が、前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付工程と、
前記情報処理装置の判定手段が、前記監視スケジュール設定受付工程により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定工程と、
前記情報処理装置の通知手段が、前記判定工程により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知工程と、
を備えることを特徴とする情報処理方法。
【請求項７】
受信したデータに対して処理を実行する情報処理装置において実行されるプログラムであって、
前記情報処理装置を、
前記受信したデータの処理の実行を監視するスケジュールの設定を受け付ける監視スケジュール設定受付手段と、
前記監視スケジュール設定受付手段により受け付けた監視スケジュールで特定される時間内に、前記データの処理が実行されたか否かを判定する判定手段と、
前記判定手段により、前記監視スケジュールで特定される時間内に前記データの処理が実行されなかったと判定された場合、実行されなかった旨を管理者に通知する通知手段として機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１３−１０９４１１（Ｐ２０１３−１０９４１１Ａ）
【公開日】平成２５年６月６日（２０１３．６．６）
【国際特許分類】
【出願番号】特願２０１１−２５１９０９（Ｐ２０１１−２５１９０９）
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
【公開日】平成２５年６月６日（２０１３．６．６）
【国際特許分類】
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【出願人】（３９０００２７６１）キヤノンマーケティングジャパン株式会社 (656)
【出願人】（３１２０００２０６）キヤノンＭＪアイティグループホールディングス株式会社 (259)
【出願人】（５９２１３５２０３）キヤノンＩＴソリューションズ株式会社 (528)
[ Back to top ]