(57)【要約】      （修正有）【課題】通常受信した順番に変換処理を行っていくＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）データのフォーマット変換処理は、緊急の割り込み案件が発生した際には緊急案件を優先的に変換する運用を採用することが好ましい。しかし、緊急案件のデータ量が大きい場合にも緊急案件を優先してしまうと、他の処理を停滞させることになってしまうため、フォーマット変換順番を調整するシステムを提供する。【解決手段】緊急案件のフォーマット変換をする際に、フォーマット変換するためにかかるであろう変換時間に応じてフォーマット変換を行う順番を調整することで、緊急案件のデータ状態を加味して、処理の順番を決定することができる。これにより、他の処理案件えの影響を極力低減させることができる。【選択図】図８
2015162159.tif 000002
【特許請求の範囲】
【請求項１】
基幹システムで管理される形式のデータを受信する受信手段と、
前記受信手段によって受信した順に、ＥＤＩ通信をおこなう際に用いる形式のデータとなるようにフォーマット変換する変換手段と、を有するＥＤＩシステムであって、
前記受信手段で受信されたデータが緊急案件であるか判断する判断手段と、
前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段と、を有することを特徴とするＥＤＩシステム。
【請求項２】
ＥＤＩ通信を行う際に用いるＥＤＩ通信形式のデータを受信する受信手段と、
前記受信手段によって受信した順に、基幹システムで管理される形式のデータとなるようにフォーマット変換する変換手段と、
を有するＥＤＩシステムであって、
前記受信手段で受信されたデータが緊急案件であるか判断する判断手段と、
前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段と、を有することを特徴とするＥＤＩシステム。
【請求項３】
前記調整手段は、前記緊急案件のデータのフォーマット変換するためにかかる変換時間が所定の時間未満である場合に、前記変換手段によって変換が予定されている他のデータの順番より先に前記緊急案件のデータのフォーマット変換が行われるように、順番を調整することを特徴とする請求項１または２に記載のＥＤＩシステム。
【請求項４】
前記調整手段は、前記緊急案件のデータのフォーマット変換するためにかかる変換時間が所定の時間以上である場合に、前記変換手段によって変換が予定されている他のデータの優先度に応じて、前記緊急案件のデータのフォーマット変換が行われる順番を調整することを特徴とする請求項１乃至３のいずれか１項に記載のＥＤＩシステム。
【請求項５】
過去に前記変換手段によりフォーマット変換にかかった実績時間を記憶している記憶手段と、
現在の時刻を取得する時刻取得手段と、
前記受信手段で受信したデータの種別と前記時刻取得手段で取得した現在時刻とを用いて前記記憶手段に記憶される実績時間をもとに、前記受信手段で受信したデータをフォーマット変換する際にかかる予測時間を算出する算出手段と、をさらに有し、
前記調整手段は、前記算出手段で算出された予測時間を前記変換時間として用いることを特徴とする請求項１乃至４のいずれか１項に記載のＥＤＩシステム。
【請求項６】
前記記憶手段は、前記実績時間を、過去に変換したデータのサイズ、データの種別、変換を行った実績時刻に対応付けて記憶しており、
前記算出手段は、前記受信手段で受信したデータに対応する予測時間を算出するために用いる実績時間を、前記受信手段で受信したデータの種別と前記現在時刻とを用いて前記記憶手段の中から特定し、当該特定された実績時間を、当該実績時間に対応するデータのサイズ及び前記受信手段で受信したデータのサイズを用いて算出することで、前記予測時間を算出することを特徴とする請求項５に記載のＥＤＩシステム。
【請求項７】
基幹システムで管理される形式のデータを受信する受信工程と、
前記受信工程によって受信した順に、ＥＤＩ通信をおこなう際に用いる形式のデータとなるようにフォーマット変換する変換工程と、を行うＥＤＩシステムであって、
前記受信工程で受信されたデータが緊急案件であるか判断する判断工程と、
前記判断工程で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換工程によってフォーマット変換を行う順番を調整する調整工程と、を有することを特徴とする制御方法。
【請求項８】
ＥＤＩ通信を行う際に用いるＥＤＩ通信形式のデータを受信する受信工程と、前記受信工程によって受信した順に、基幹システムで管理される形式のデータとなるようにフォーマット変換する変換工程と、を有するＥＤＩシステムの制御方法であって、
前記受信工程で受信されたデータが緊急案件であるか判断する判断工程と、
前記判断工程で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換工程によってフォーマット変換を行う順番を調整する調整工程と、を有することを特徴とする制御方法。
【請求項９】
基幹システムで管理される形式のデータを受信する受信手段と、前記受信手段によって受信した順に、ＥＤＩ通信をおこなう際に用いる形式のデータとなるようにフォーマット変換する変換手段と、を有するＥＤＩシステムで実行可能なプログラムであって、
前記ＥＤＩシステムを
前記受信手段で受信されたデータが緊急案件であるか判断する判断手段、
前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段、
として機能させることを特徴とするプログラム。
【請求項１０】
ＥＤＩ通信を行う際に用いるＥＤＩ通信形式のデータを受信する受信手段と、前記受信手段によって受信した順に、基幹システムで管理される形式のデータとなるようにフォーマット変換する変換手段と、を有するＥＤＩシステムで実行可能なプログラムであって、
前記ＥＤＩシステムを、
前記受信手段で受信されたデータが緊急案件であるか判断する判断手段、
前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段、として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、およびその制御方法、プログラムに関する。
【背景技術】
【０００２】
企業における受発注業務においては業務効率化のために、インターネット回線等を利用したデータ通信で電子商取引を行うＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）方式が広く導入されている。この方式を用いることにより、注文書や請求書などの商取引データを、電話やＦＡＸや郵送物といった方法でやり取りするのではなく、取引先と自社のコンピュータをつないだネットワークを介して、電子データの形でやり取りすることができる。
【０００３】
このようなＥＤＩ通信に用いられるデータ形式を企業ごとに固有の形式としてしまうと、取引先ごとにデータ形式が異なるという事態が生じるため、業界内で標準規格を設けて標準化された規格に則ったデータ形式でデータ交換がなされるのが一般的である。
【０００４】
一方、各企業においては、受発注業務を管理するための自社システム（基幹システム）を持っているが、このような自社システムで用いられるデータ形式は、ＥＤＩ規格の形式と異なることが多い。
【０００５】
そのため、各企業においては、トランスレータと呼ばれるシステムやソフトウェアを用いて「自社システムで利用されるデータ形式をＥＤＩ通信に用いられるデータ形式」に又は、「ＥＤＩ通信に用いられるデータ形式を自社システムで利用されるデータ形式」に変換するフォーマット変換が適宜行われている。このようなＥＤＩ通信におけるトランスレータに関する技術は、例えば特許文献１に開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−１８２５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
このような変換処理は、受信した順番に変換処理を行っていくのが通常であるが、緊急の割り込み案件が発生した際には緊急案件を優先的に変換する運用を採用することが好ましい。
【０００８】
しかし、このような緊急案件のデータ量が大きい等、変換処理に長時間かかるような場合には、すぐにフォーマット変換が完了するような案件でも長時間待機するという状況が発生する。このような状況は、その後の処理を停滞させることになるため、好ましくない。
【０００９】
そこで、本発明は上記課題を鑑みてなされたものであり、緊急案件のデータの状態を加味して処理の順番を決定できる仕組みを提供することを目的としている。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明に係るＥＤＩシステムは、基幹システムで管理される形式のデータを受信する受信手段と、前記受信手段によって受信した順に、ＥＤＩ通信をおこなう際に用いる形式のデータとなるようにフォーマット変換する変換手段と、を有し、前記受信手段で受信されたデータが緊急案件であるか判断する判断手段と、前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段と、を有することを特徴とする。
【００１１】
また、別の手段として、本発明に係るＥＤＩシステムは、ＥＤＩ通信を行う際に用いるＥＤＩ通信形式のデータを受信する受信手段と、前記受信手段によって受信した順に、基幹システムで管理される形式のデータとなるようにフォーマット変換する変換手段と、を有し、前記受信手段で受信されたデータが緊急案件であるか判断する判断手段と、前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段と、を有することを特徴とする。
【発明の効果】
【００１２】
このように設けることで、緊急案件のデータの変換にかかる時間を加味して処理の順番を決定することで、他の案件への影響を極力低減できる処理の順番を決定することができる。
【図面の簡単な説明】
【００１３】
【図１】ＥＤＩシステムのシステム構成の一例を示す図である。
【図２】基幹システム１０１、運用管理サーバ１０２のハードウェア構成の一例を示す図である。
【図３】ＥＤＩシステム１０１の機能構成の一例を示す図である。
【図４】本発明の実施形態における、ＥＤＩ通信処理の流れを説明するためのフローチャートである。
【図５】本発明の実施形態における、変換時間を予測する処理の流れを説明するためのフローチャートである。
【図６】変換時間を予測する際に参照する変換実績テーブルの一例である。
【図７】変換時間を予測する際に参照する変換時間サンプル値マスターテーブルの一例である。
【図８】本発明の実施形態における、変換順序入替処理の流れを説明するためのフローチャートである。
【図９】変換順序の入替を行う際に参照する変換実行判断テーブルの一例である。
【図１０】変換実行一覧テーブルの一例である。
【図１１】ＥＤＩ通信フォーマットの一例である。
【図１２】ＥＤＩ通信フォーマットの一例である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１５】
図１は、本実施形態におけるＥＤＩシステムのシステム構成を示す図である。
【００１６】
図１に示すように本願発明は、自社のＥＤＩシステム１０１と、取引先のＥＤＩシステムとが公衆回線や専用線やインターネット回線等のネットワーク１０３を介して通信可能に構成されている。このネットワーク１０３を介して、企業間の電子商取引に関する電子情報であるＥＤＩデータを相互に交換することができる。具体的には注文書や請求書などの商取引データがやり取りされる。
【００１７】
自社のＥＤＩシステム１０１は、社内の受発注業務を管理するための基幹システム１００と、ＥＤＩ通信を行うための運用管理サーバ１０２がＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０７を介して相互にデータ通信可能に接続されている。このような仕組みは取引先のＥＤＩシステム１０５においても同様である。
【００１８】
このようなＥＤＩ通信に用いられるデータ形式は、企業ごとに固有の形式であると取引先ごとにデータ形式が異なるという事態が生じるため、業界内で標準規格（以下業界標準とも称する）を設け、この標準規格に則ったデータ形式でデータ交換がなされるというのが一般的である。
【００１９】
一方基幹システム１００においては、ＥＤＩ通信を行うためのデータ形式と異なる形式のデータで受発注業務の管理が行われている。そのため、運用管理サーバ１０２は、トランスレータとして機能し、ＥＤＩ通信を用いて取引先にデータを送信する際には、基幹システム１００で管理される形式のデータを、運用管理サーバ１０２がＥＤＩ通信のデータ形式に変換を行う。さらに、ＥＤＩ通信でデータを受信した際にも、運用管理サーバ１０２がトランスレータとして機能し、運用管理サーバ１０２がＥＤＩ通信のデータ形式を、基幹システム１００で管理する形式のデータに変換する。すなわち、運用管理サーバ１０２は、通信可能なプロトコルで送受信することで、自社の基幹システム１００と、取引先のＥＤＩシステム１０５との間のデータ交換の仲介を行う。
【００２０】
なお、図１のネットワーク１０３、１０７上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００２１】
図２は、各種端末のハードウェア構成の一例を示す図である。
【００２２】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２３】
また、ＲＯＭ２０２あるいは外部メモリ２１１（記憶手段）には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、基幹システム１００、運用管理サーバ１０２の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２４】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２５】
また、入力コントローラ（入力Ｃ）２０５は、キーボードや不図示のマウス等のポインティングデバイス等の入力デバイス２０９からの入力を制御する。
【００２６】
ビデオコントローラ（ＶＣ）２０６は、ディスプレイ２１０等の表示器への表示を制御する。表示器の種類はＣＲＴや、液晶ディスプレイを想定するが、これに限らない。
【００２７】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。
【００２８】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００２９】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。
【００３０】
また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３１】
本発明の基幹システム１００、運用管理サーバ１０２が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。
【００３２】
さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルも外部メモリ２１１に格納されている。
【００３３】
ところで、上述の運用管理サーバ１０２をトランスレータとして用いて、「基幹システムで利用されるデータ形式をＥＤＩ通信に用いられるデータ形式」に変換に又は、「ＥＤＩ通信に用いられるデータ形式を基幹システムで利用されるデータ形式」に変換する変換処理は、受信した順番に変換処理を行っていくのが通常であるが、緊急の割り込み案件が発生した際には、早期に発注処理をかける必要があるため緊急案件を優先的に変換する運用が好ましい。
【００３４】
しかし、このような緊急案件のデータ量が大きい等、変換処理に長時間かかるような場合には、すぐにフォーマット変換が完了するような案件でも長時間待機するという状況が発生する。このような状況は、その後の処理を停滞させることになるため、好ましくない。
【００３５】
というのは、ＥＤＩ通信を用いてやり取りされる受発注データの中には、緊急案件でないものの、早期にその後の処理を行いたい優先度の高い案件も存在する。このような案件のフォーマット変換処理が予定されている状態で緊急案件が発生した場合に、緊急案件を先に処理する取扱いを採用していると優先度の高い案件の処理が後回しにされ、当該案件のその後の処理に影響を及ぼす可能性が生じるためである。
【００３６】
そのため、本実施形態では、フォーマット変換処理に必要な変換時間が比較的短い案件の場合には、他の案件の状態にかかわらず緊急案件の処理を最優先で行わせる。そして、フォーマット変換処理に必要な変換時間が比較的長い案件の場合には、他の案件の状態を加味して、変換順序を決定させている。なお、緊急案件ではない場合には、既に変換処理が予定されている案件の次に変換されるようにする。
【００３７】
詳細な決定方法については後述するが、緊急案件の変換時間をもとに変換順序の決定を行っている。このように変換順序を決定することにより、他の変換処理への影響を低減することができる。
【００３８】
ところで、各案件の処理にかかる変換時間は、変換対象の商取引の情報（伝票に含まれる明細の数等）に依存することがわかっているが、それのみならずデータファイル内の文字列の配置差によっても違いがでることが知られている。そのため、以下に説明する方法を用いて予測した予測時間を緊急案件の変換時間として用い、変換順序を決定することが好ましいといえる。
【００３９】
以下、図１１及び１２を用いて、このようなデータファイル内の文字列の配置差によって変換時間に差が出る理由を示す。
【００４０】
図１１と図１２は、いずれも同じ数の明細の情報が含まれる伝票のＥＤＳ通信に用いられるデータ形式の一例である。図１１は、６つの伝票が設けられており、各伝票に１つの明細が含まれているように作られたＥＤＩ形式の通信データである。図１２は、図１１と同様に６つの明細が含まれているが、１つの伝票に３つの明細が含まれるように設けられており、伝票は２つしか設けられていないＥＤＩ形式の通信データである。つまり、明細の数は同数であり、商取引上は同じ情報を送受信しているにもかかわらず、文字列の配置が異なっているため、データフォーマットを変換する際にかかる時間に違いが生じるということがわかる。
【００４１】
このようなデータファイル内の文字列の配置差は、企業内の基幹システムにおけるデータの管理方法の差に依存するところが多いため、企業ごとの癖といえる。つまり、データのフォーマット変換にかかる時間を詳細に予測するためには、相手先を加味する必要があるといえる。また、各企業の運用管理サーバ１０２は、１日のうち決まった時間に決められた業務を別途行う場合もあるため、各企業の運用管理サーバ１０２の変換時間帯の状況も加味する必要があるといえる。
【００４２】
また、業界標準のフォーマットは、発注・出荷などのメッセージ種別ごとにフォーマットが異なっているため、変換時間を予測する際には、メッセージ種別を加味する必要もある。さらに業界標準のフォーマットは、定期的にバージョンアップが行われているが、このようなバージョンによってもフォーマットの変換時間は異なってくるため、変換時間を予測する際にはバージョンも加味する必要がある。
【００４３】
すなわち、緊急案件のデータを受信し、処理の順番を決定する際に用いる緊急案件の変換時間は、上記のことを加味して予測された変換時間（以下、予測変換時間）を用いることが好ましいといえる。そのため、本実施形態においては変換時間として予測変換時間を用いる例を用いて説明を行う。なお、緊急案件の変換時間に大きなばらつきが生じないような場合には、変換時間として予測変換時間を用いずに、例えばデータの容量に比例して変化する変換時間を用いてもよい。
【００４４】
図３を用いて、本実施形態におけるフォーマット変換の順番を調整可能なＥＤＩシステム１０１の機能構成について説明する。図３（ａ）は、取引先のＥＤＩシステム１０５にＥＤＩ通信形式のデータを送信する際の機能を示した機能構成図であり、図３（ｂ）は、取引先のＥＤＩシステム１０５からＥＤＩ通信形式のデータを受信する際の機能を示した機能構成図である。
【００４５】
図３（ａ）に示す基幹システム１００は、データ出力部３００を備えており、運用管理サーバ１０２は、フォーマット変換部３０１と、ＥＤＩ通信出力部３０２と、変換順序調整部３０３と、フォーマット変換時間算出部３０４と、現在時刻取得部３０５と、変換実績記憶部３０６と、案件判定部３０７とを備えている。
【００４６】
案件判定部３０７は、データ出力部３００から基幹システム１００で管理されている形式のデータを受信すると、緊急案件として処理するかどうかを判定する。
【００４７】
緊急案件として処理すると判定された場合には、変換フォーマット変換時間算出部３０４で、現在時刻取得部３０５から取得した現在時刻と変換実績記憶部３０６から取得した実績時間とを参照してデータの変換にかかる予測時間を算出する。そして予測時間に応じて、フォーマット変換を行う順番を変換順序調整部３０３で調整する。そして、調整手段で調整された順番に応じて、フォーマット変換部３０１において、フォーマット変換を行う。
【００４８】
なお、案件判定部３０７において緊急案件として処理すると判定有れなかった場合には、現在変換が予定されている案件の一番最後に変換が行われるように変換順序調整部３０３が調整を行い、その順番に応じて、フォーマット変換部３０１でフォーマット変換が行われる。
【００４９】
そして、フォーマット変換が完了した後に、ＥＤＩ通信出力部３０２が変換後のＥＤＩ通信形式のデータを用いて取引先のＥＤＩシステム１０５に対してデータ送信動作を行う。
【００５０】
図３（ｂ）に示す基幹システム１００は、データ受信部３１０を備えており、運用管理サーバ１０２は、フォーマット変換部３０１と、ＥＤＩ通信入力部３１２と、変換順序調整部３０３と、フォーマット変換時間算出部３０４と、現在時刻取得部３０５と、変換実績記憶部３０６と、案件判定部３０７とを備えている。
【００５１】
案件判定部３０７は、ＥＤＩ通信入力部３１２に取引先のＥＤＩシステム１０５から送信されたＥＤＩ通信形式のデータを受信すると、緊急案件として処理するかどうかを判定する。
【００５２】
緊急案件として処理すると判定された場合には、変換フォーマット変換時間算出部３０４で、現在時刻取得部３０５から取得した現在時刻と変換実績記憶部３０６から取得した実績時間とを参照してデータの変換にかかる予測時間を算出する。そして予測時間に応じて、フォーマット変換を行う順番を変換順序調整部３０３で調整する。そして、調整手段で調整された順番に応じて、フォーマット変換部３０１において、フォーマット変換を行う。
【００５３】
なお、案件判定部３０７において緊急案件として処理すると判定有れなかった場合には、現在変換が予定されている案件の一番最後に変換が行われるように変換順序調整部３０３が調整を行い、その順番に応じて、フォーマット変換部３０１でフォーマット変換が行われる。
【００５４】
そして、フォーマット変換が完了した後に、基幹システム１００のデータ受信部３１０がデータを受信して格納する。
【００５５】
次に、図４及び図５のフローチャートを用いてＥＤＩ通信に用いるデータを変換する順番を調整する流れを詳細に説明する。なおここでは流通ＢＭＳにおいて採用されている、基幹システムのデータ形式としてＣＳＶ形式を用い、ＥＤＩ通信のデータ形式としてＸＭＬ形式（ＥＤＩフォーマット）を用いている場合の例を用いて説明を行うが、これらのデータ形式に限られないことは言うまでもない。
【００５６】
図４（ａ）は、取引先のＥＤＩシステム１０５にＥＤＩ通信形式のデータを送信する際の流れを説明するフローチャートであり、図４（ｂ）は、取引先のＥＤＩシステム１０５からＥＤＩ通信形式のデータを受信した際の流れを説明するフローチャートである。
【００５７】
図４（ａ）（ｂ）のフローチャートに示す処理は、運用管理サーバ１０２のＣＵＰ２０１が外部メモリ２１１に記憶されている制御プログラムをＲＡＭ２０３に読み出して実行することにより実現される。
【００５８】
図４（ａ）において、Ｓ４０１では、運用管理サーバ１０２のＣＰＵ２０１が、基幹システムから出力されたＣＳＶ形式のデータが、緊急案件かどうかを判断する。具体的には受信データの情報種に『緊急発注』と指定されている案件である場合には、緊急案件と判定し、それ以外の情報種である場合には緊急案件ではないと判定する。
【００５９】
Ｓ４０１で、緊急案件であると判定された場合には、Ｓ４０２に進み、Ｓ４０２で変換時間予測処理を行い、さらにＳ４０３で変換順序の入替処理を行う。このＳ４０２及びＳ４０３の処理の詳細については後述する。その後Ｓ４０４に進みＳ４０３の入替処理に応じた順番となるように図１０（ａ）（ｂ）に示すような変換実行一覧テーブルの更新を行う。
【００６０】
図１０に示す変換実行一覧テーブルは、ＩＤ１００１ごとに、相手先１００２、予測変換時間１００４、優先順位１００５、変換実行時間１００６、変換終了時間１００７が記憶されており、現在フォーマット変換が予定されている全件のデータが管理されている。すなわち、新たにフォーマット変換が予定されているデータが発生した場合には、そのデータが適当な位置に追加されることになる。具体的には、Ｓ４０３の変換処理で変換された順番となるように、変換実行一覧テーブルが更新される。
【００６１】
一方Ｓ４０１で、緊急案件でないと判定された場合には、Ｓ４０４に進み、変換実行一覧テーブルの最後に本案件追加して、変換実行一覧テーブルの更新を行う。すなわち現在変換が予定されている案件の次に変換が行われるように更新を行う。具体的には図１０に示す変換実行テーブルのデータの、一番下にデータが追加されるように変換実行一覧テーブルの更新が行われる。
【００６２】
そして、Ｓ４０５では、運用管理サーバ１０２のＣＰＵ２０１が、変換実行一覧テーブルに登録されている順番に、基幹システム１００のＣＳＶ形式のデータを、ＥＤＩ通信に用いられるＸＭＬ形式のデータに変換するように制御する。
【００６３】
そして、Ｓ４０６では、Ｓ４０５の変換処理にかかった実際の時間を外部メモリ２１１等の記憶手段に記憶させ、変換時間実績の更新処理を行う。このように実績を保存しておくことにより、Ｓ４０２で行われる次の予測処理の際に、従前の変換処理にかかったデータの１つとして利用することができ、より詳細に案件のフォーマット変換処理にかかる予測時間を算出することができるようになる。
【００６４】
Ｓ４０７では、Ｓ４０５で変換されたＸＭＬ形式のデータを、取引先のＥＤＩシステム１０５に対して送信する。これにより取引先のＥＤＩシステム１０５にＥＤＩ通信形式のデータを送信する動作が完了する。
【００６５】
次に、図４（ｂ）を用いて、取引先のＥＤＩシステム１０５からＥＤＩ通信形式のデータを受信する際の動作を説明する。
【００６６】
Ｓ４１１では、運用管理サーバ１０２のＣＰＵ２０１が、取引先のＥＤＩシステム１０５からＥＤＩ通信によるＸＭＬ形式のデータを受信する。
【００６７】
次に、Ｓ４１２では、運用管理サーバ１０２のＣＰＵ２０１が、Ｓ４１１で受信したＸＭＬ形式のデータが、緊急案件かどうかを判断する。具体的には受信データの情報種に『緊急発注』と指定されている案件である場合には、緊急案件と判定し、それ以外の情報種である場合には緊急案件ではないと判定する。
【００６８】
Ｓ４１２で、緊急案件であると判定された場合には、Ｓ４１３に進み、Ｓ４１３で変換時間予測処理を行い、さらにＳ４１４で変換順序の入替処理を行う。Ｓ４１３及びＳ４１４の処理の詳細については後述する。その後Ｓ４１５に進みＳ４１４の入替処理に応じた順番となるように変換実行一覧テーブルの更新を行う。
【００６９】
一方Ｓ４１２で、緊急案件でないと判定された場合には、Ｓ４１５に進み、変換実行一覧テーブルの最後に本案件追加して、変換実行一覧テーブルの更新を行う。すなわち現在変換が予定されている案件の次に変換が行われるように更新を行う。
【００７０】
そして、Ｓ４１６では、運用管理サーバ１０２のＣＰＵ２０１が、変換実行一覧テーブルに登録されている順番に、ＥＤＩ通信に用いられるＸＭＬ形式のデータを、基幹システム１００のＣＳＶ形式のデータに変換するように制御する。
【００７１】
そして、Ｓ４１７では、Ｓ４１６の変換処理にかかった実際の時間を外部メモリ２１１等の記憶手段に記憶させ、変換時間実績の更新処理を行う。このように実績を保存しておくことにより、Ｓ４１３で行われる次の予測処理の際に、従前の変換処理にかかったデータの１つとして利用することができ、より詳細に案件のフォーマット変換処理にかかる予測時間を算出することができるようになる。
【００７２】
これにより、取引先のＥＤＩシステム１０５からＥＤＩ通信形式のデータを受信する際の動作が完了する。
【００７３】
次に、図５を用いて図４（ａ）のＳ４０２及び図４（ｂ）のＳ４１３で行われる変換時間の予測処理について説明する。
【００７４】
まずＳ５０１では、運用管理サーバ１０２のＣＰＵ２０１が、変換処理が行われる時刻を現在時刻として取得する。
【００７５】
次に、Ｓ５０２では、運用管理サーバ１０２のＣＰＵ２０１が、外部メモリ２１１等の記憶手段に記憶されている図６に示すような変換実績テーブルを参照して、過去に変換した実績データに一致するデータ種別があるかを判断する。
【００７６】
図６に示す変換実績テーブルには、過去に変換処理されたデータが一覧として順に記憶されており、ＩＤ６０１ごとに、相手先名６０２、業界標準バージョン６０３、メッセージ種６０４、変換方向６０５、変換前データサイズ６０６、変換後データサイズ６０７、その際にかかった変換時間６０８（実績時間）、変換処理が開始された変換開始時刻６０９（実績時刻）が対応付けて記憶されている。
【００７７】
つまり、Ｓ５０２で具体的には、これから変換しようとしているデータの、「相手先名」「業界標準のバージョン」「メッセージ種」「変換方向」といったデータ種別をもとに、変換実績テーブルを参照して、データ種別が一致する実績データがあるかを判断し、データ種別が一致する実績データがある場合には、当該実績データを抽出してＳ５０３に進む。一方、データ種別が一致する実績データがない場合には、Ｓ５０６に進む。なお、「業界標準のバージョン」は大きな差が出ない場合もあるため、データ種別の一致判断に用いなくてもよい。
【００７８】
次に、Ｓ５０３では、運用管理サーバ１０２のＣＰＵ２０１が、Ｓ５０２で抽出した実績データの変換開始時刻６０９を参酌し、当該変換時刻とＳ５０１で取得した現在時刻との時間差が所定の時間以内に変換処理の開始が行われた実績データがあるかを判断する。図５においては、現在時刻の前後３０分以内に変換処理が行われた実績データが存在するかを判断している例を示している。所定の時間差以内に変換処理が行われた実績データが存在する場合には、その実績データを、予測変換時間を算出するために用いるデータとして特定する。また、ここでは、変換処理が開始された時間をもとに判断しているが、図６に示すような変換実績テーブルに変換開始時刻６０９のかわりに変換終了時刻を記憶させておき、これを用いて判断してもよい。
【００７９】
次に、Ｓ５０３で、所定の時間差以内に変換処理が行われた実績データが存在しないと判断された場合には、Ｓ５０５に進み、所定の時間差より大きな時間差の実績データのうち、現在時刻に最も近い実績データを、予測変更時間を算出するために用いるデータとして特定する。
【００８０】
Ｓ５０２において、過去の実績データに、データ種別が一致するデータが存在しなかった場合には、Ｓ５０６において、外部メモリ２１１等の記憶手段に記憶しておいた図７のような変換時間サンプル値マスターテーブルを参酌して、サンプルデータを特定する。
【００８１】
図７に示す変換時間サンプル値マスターテーブルには、サンプル値（サンプル時間）としての変換時間が記憶されており、ＩＤ７０１ごとに、業界標準バージョン７０２、メッセージ種７０３、変換方向７０４、変換前データサイズ７０５、変換後データサイズ７０５、変換時間７０７が記憶されている。
【００８２】
つまり、Ｓ５０６で具体的には、これから変換しようとしているデータの、「業界標準バージョン」「メッセージ種」「変換方向」といったデータ種別をもとに、変換時間サンプル値マスターテーブルを参酌して、データ種別が一致するサンプルデータを、予測変更時間を算出するために用いるデータとして特定する。
【００８３】
Ｓ５０７では、Ｓ５０４乃至Ｓ５０６で、予測変更時間を算出するために用いる基準データとして特定したデータの変換時間を用いて予測変換時間を算出する。
【００８４】
具体的には、「予測変換時間（秒）＝変換時間（秒）×（これから変換する変換対象ファイルのデータサイズ）÷（基準データにおける変換前のデータサイズ）」という計算式（式１）を用いて算出することができる。
【００８５】
なお、Ｓ５０２において複数の実績データが抽出された場合には、現在時刻に最も近い実績データを、予測変更時間を算出するために用いるデータとして特定、この特定されたデータを基準データとして予測変換時間を算出してもよい。
【００８６】
また、Ｓ５０２において複数の実績データが抽出された場合には、それぞれに対して上述の式１を用いて予測変換時間を算出し、これらの平均をユーザに通知するようにしてもよい。
【００８７】
以上のように、過去の実績値がある場合には実績データと「相手先名」「メッセージ種」「変換方向」といったデータ種別が少なくとも一致するデータを用いて、ＥＤＩ通信で用いられる形式のデータと基幹システムで用いられるデータとをフォーマット変換する際にかかる変換時間を予測することで、より信頼性の高い値として算出することができる。
【００８８】
なお、本実施形態においては、図６に実績データとして、変更方向が異なっても１つの実績データとして保存している場合の例を示したが、変更方向ごとに別々の実績データとして保存してもよいことは言うまでもない。
【００８９】
次に、図８のフローチャートを用いて図４（ａ）のＳ４０３及び図４（ｂ）のＳ４１４で行われる変換順序の入替処理について説明する。
【００９０】
Ｓ８０１では、運用管理サーバ１０２のＣＰＵ２０１が、これからフォーマット変換するデータの送信の相手先と、情報種をキーとして、図９に示すような変換実行判断テーブルから条件に一致するレコードを抽出する。具体的には送信先と情報種とが一致するレコードを抽出する。
【００９１】
図９に示す変換実行判断テーブルには、ＩＤ９０１ごとに、相手先名９０２、情報種９０３、変換閾値９０４、優先順位９０５が予め登録されており、外部メモリ２１１等に記憶されている。
【００９２】
Ｓ８０２では、運用管理サーバ１０２のＣＰＵ２０１が、Ｓ８０１で抽出したレコードの変換閾値と優先順位が取得できたかを判定する。取得できたと判定された場合には、Ｓ８０３へと進む。一方、変換閾値と優先順位が取得できなかった場合には、Ｓ８０７に進み、次の変換対象となるような変換実行時間を設定する。具体的には、現在の時刻を変換実行時間と設定することができる。
【００９３】
Ｓ８０３では、Ｓ４０２またはＳ４１３で取得された予測変換時間が、Ｓ８０１で抽出し、Ｓ８０２で取得した変換閾値をこえているかを判定する。Ｓ８０３で予測変換時間が、変換閾値を超えていないと判断された場合（閾値時間未満）には、直ぐに変換処理を行っても短い時間でフォーマット変換処理を完了することができると想定され、他の処理に与える影響は小さいといえるため、Ｓ８０７に進み、次の変換対象となるような変換実行時間を設定する。具体的には、現在の時刻を変換実行時間と設定することができる。
【００９４】
一方、Ｓ８０３で予測変換時間が変換閾値を超えていると判定された場合（閾値時間以上）には、Ｓ８０４に進み、図１０に示す変換実行一覧テーブルに記憶されている一覧の中から、これから変換を予定している緊急案件の優先順位よりも優先順位１００５が高い案件を抽出する。
【００９５】
Ｓ８０５では、優先順位１００５の高いレコードが抽出されたかどうかを判定する。Ｓ８０５で優先順位１００５の高いレコードが抽出されないと判定された場合には、Ｓ８０７に進み、現在フォーマット変換が行われている処理の次の変換対象となるような変換実行時間を設定する。具体的には、現在の時刻を変換実行時間と設定することができる。
【００９６】
一方、Ｓ８０５で、優先順位１００５の高いレコードが抽出されたと判定された場合には、Ｓ８０６に進み優先順位が高い処理の一覧の中で、一番遅い変換処理終了時間となっている案件の後に変換処理が行われるように、変換実行時間を設定する。
【００９７】
そして、Ｓ８０８では、運用管理サーバ１０２のＣＰＵ２０１が、Ｓ８０６及びＳ８０７で設定された変換実行時間と当該データの予測変換時間とから変換終了時間を算出する。
【００９８】
さらにＳ８０９では、運用管理サーバ１０２のＣＰＵ２０１が、後続の処理となった変換レコードの変換実行時間と変換終了時間を順次算出する。
【００９９】
このように、算出された変換実行時間と変換終了時間とを用いて、Ｓ４０４またはＳ４１５において、変換実行一覧テーブルの更新が行われる。
【０１００】
次に、図１０の変換実行一覧テーブルを用いて、変換実行一覧テーブルの更新がされた状態を説明する。図１０（ａ）は、変換実行一覧テーブルに、次に処理予定に追加される変換予定データ１１００が追加される際の状態を説明する図である。図１０（ｂ）は、図１０（ａ）に示す変換予定データが追加されたのちの変換実行一覧テーブルを示している。
【０１０１】
１１００のような情報種が緊急発注のデータが入力された場合には、変換予定データ１１００の予測時間（３５分）と、図９の変換実行判断テーブルのＩＤ１１の変換閾値（３０分）とを比較する（Ｓ８０３）。ここでは、予測時間の方が長いため、Ｓ８０４に進む。そして図１０（ａ）のリストにある５つのＩＤのうち、変換予定データ１１００の優先順位より、高い優先順位は、ＩＤ１〜４であるため、この次に実行されるように変換実行時間が設定される（Ｓ８０６）。すなわち、図１０（ａ）の変換実行一覧テーブルのＩＤ４とＩＤ５との間に、変換予定データ１１００が追加することになる。つまり、変換予定データ１１００の変換終了時間を算出し、本件の後に処理されるＩＤ５については、変換予定データ１１００に続いて処理がされるように時間が再計算される。そして、計算されたデータを反映し更新した一覧テーブルが図１０（ｂ）である。
【０１０２】
以上のように、データのフォーマット変換処理に必要な変換時間が比較的短い案件の場合には、他の案件の状態にかかわらず緊急案件の処理を最優先で行わせる。これにより、緊急案件のデータ量が小さく、変換処理にほとんど時間がかからないような場合には、他の案件に先立ち、変換処理を完了させることができるため、早期に緊急発注等の処理を完了させることができる。
【０１０３】
そして、データのフォーマット変換処理に必要な変換時間が比較的長い案件の場合には、他の案件の優先順位を加味し、優先順位が高いものは先に処理されるような変換順序を決定している。これにより、優先度の高い他の案件が、緊急案件のために処理されるまでに時間がかかってしまうという状態を防止することができる。
【０１０４】
すなわち、このように緊急案件のデータの変換にかかる時間を加味して処理の順番を決定することで、他の案件への影響を極力低減できる処理の順番を決定することができる。
【０１０５】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１０６】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置の情報処理装置が前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１０７】
したがって、本発明の機能処理を情報処理装置で実現するために、前記情報処理装置にインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１０８】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１０９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１１０】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１１１】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理を情報処理装置で実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１１２】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行して情報処理装置にインストールさせて実現することも可能である。
【０１１３】
また、情報処理装置が、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、情報処理装置上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１１４】
さらに、記録媒体から読み出されたプログラムが、情報処理装置に挿入された機能拡張ボードや情報処理装置に接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１１５】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１１６】
１００  基幹システム
１０１  ＥＤＩシステム
１０２  運用管理サーバ
１０３  ネットワーク
１０５  取引先ＥＤＩシステム
１０７  ネットワーク
【図１】
2015162159.tif 000003
【図２】
2015162159.tif 000004
【図３】
2015162159.tif 000005
【図４】
2015162159.tif 000006
【図５】
2015162159.tif 000007
【図６】
2015162159.tif 000008
【図７】
2015162159.tif 000009
【図８】
2015162159.tif 000010
【図９】
2015162159.tif 000011
【図１０】
2015162159.tif 000012
【図１１】
2015162159.tif 000013
【図１２】
2015162159.tif 000014