JP2011018257A - 情報処理装置、およびその情報処理方法、プログラム、記憶媒体。 - Google Patents

Abstract

【課題】業務プロセス毎に異なるマッピング定義を登録する必要をなくし、運用管理者の負担やミスの発生の軽減することを可能とする。
【解決手段】入力データのフォーマット形式から出力データのフォーマット形式へ変換するための定義情報と、入力データの種別を識別する条件とを対応づけたレコードを複数レコード記憶し、複数レコードから１レコードを選択する。取得された入力データが、選択されたレコードに含まれる入力データの種別を識別する条件に合致するかを判定して、合致すると判定された場合、前記条件に対応づけて記憶される前記定義情報を用いて、前記取得された入力データのフォーマット形式の変換を行い、一方、合致しないと判定された場合、他のレコードを選択する。
【選択図】図１０

Description

電子商取引（ＥＤＩ）システムにおけるデータ交換時のフォーマット変換に用いる、マッピング定義の切り替えに関する。

近年、企業などにおいては受発注業務における業務効率化のために、電子商取引を行うＥＤＩシステムが導入されている。

通常、企業内で利用されるシステムは、その企業が独自に決めたフォーマットで構築されている。そのため、他の企業との間で電子商取引をするために、ＥＤＩシステムが業界標準のフォーマットに変換を行う。この変換において、フォーマット変換の内容を定義したものがマッピング定義である。

相手企業と通信を行うための業界標準のフォーマットは、発注・出荷などのメッセージ種別毎にフォーマットが異なっている。また、業界標準フォーマットは定期的にバージョンアップが行われており、バージョンが異なればフォーマットも異なる。すなわち、メッセージ種別・バージョン毎に必要となるマッピング定義は異なり、多数のマッピング定義を作成する必要がある（図８を参照。）。

このような多数のマッピング定義を使い分けるため、通常は、相手先・通信するメッセージ種別毎にＥＤＩシステムに業務プロセスを定義し、業務プロセス毎にフォーマット変換に使用するマッピング定義を登録する。

そのため、多数の業務プロセスに対しそれぞれ正しいマッピング定義をＥＤＩシステムに登録するという設定作業が必要となり、運用担当者の負担になると共に、マッピング定義の登録ミスを発生させる可能性があった。図９は、従来の流れを示す図である。

このような運用担当者の負担やミスの発生を軽減する技術として、変換元・変換先のプロトコルの組によってマッピング定義を選択する技術が特許文献１に開示されている。

特開２００３−１７８２２２号公報

しかしながら、特許文献１の技術では、変換元・変換先のプロトコルの組で使用するマッピング定義を判断するため、通信は同一のプロトコルで行われるが通信されるメッセージ種が異なる場合に対応することができない。

また、通信で使用する標準フォーマットのバージョンを上げる際、全業務プロセスに登録されているマッピング定義を、新たなバージョンのものに一斉に変更しなければならない。相手先によってバージョンアップのタイミングが異なる場合もあり、その点でも運用管理者の負担は大きなものとなる。

本発明は上記課題を解決するものであり、業務プロセス毎に異なるマッピング定義を登録する必要をなくし、運用管理者の負担やミスの発生の軽減することを可能とする。

本発明は、入力データのフォーマット形式を出力データのフォーマット形式へ変換する情報処理装置であって、入力データのフォーマット形式から出力データのフォーマット形式へ変換するための定義情報と、入力データの種別を識別する条件とを対応づけたレコードを複数レコード記憶する記憶手段と、前記定義情報を用いて、入力データのフォーマット形式を出力データのフォーマット形式へ変換する変換手段と、入力データを取得する取得手段と、前記記憶手段により記憶される複数レコードから１レコードを選択する選択手段と、前記取得手段により取得された入力データが、前記選択手段により選択されたレコードに含まれる入力データの種別を識別する条件に合致するかを判定する判定手段とを有し、前記判定手段により、合致すると判定された場合、前記変換手段は、前記条件に対応づけて前記記憶手段に記憶される前記定義情報を用いて、前記取得された入力データのフォーマット形式の変換を行い、一方、前記判定手段により、合致しないと判定された場合、前記選択手段は、他のレコードを選択することを特徴とする。

本発明によれば、業務プロセス毎に異なるマッピング定義を登録する必要をなくし、運用管理者の負担やミスの発生の軽減することが可能となる。

本発明の実施形態のＥＤＩシステムの構成を示す図である。 ジョブ運用管理サーバのハードウェア構成を示す図である。 ジョブ運用管理サーバに搭載されるＥＤＩデータ変換機能の構成を概略的に示す機能ブロック図である。 本発明の実施形態のジョブ運用管理サーバの基本的な処理フローを示す図である。 ステップＳ４００の詳細処理の流れを示すフローチャートである。 ステップＳ４０１の詳細処理の流れを示すフローチャートである。 ステップＳ４０２の詳細処理の流れを示すフローチャートである。 従来のＥＤＩシステムの構成の一例を示す図である。 従来のＥＤＩシステムにおけるマッピング定義を選択する流れを示す図である。 本願発明によるマッピング定義を選択する流れを示す図である。 マッピング定義設定エディタ画面の一例を示す図である。 マッピング定義切替設定エディタ画面の一例を示す図である。 マッピング定義切替設定テーブルの一例を示す図である。 マッピング定義切替処理の具体例を示す図である。 マッピング定義の一例を示す図である。

本発明は、従来、運用管理者が正しいマッピング定義を選択し、ＥＤＩシステムに登録していたものを（図９を参照。）、トランスレータにより、マッピング定義を選択させるようにするものである（図１０を参照）。

以下、図面を用いて本発明の実施の形態を説明する。

図１は、本発明の実施形態のＥＤＩシステム（情報処理システム）の構成を示す図である。

ＥＤＩシステム１０１と取引先ＥＤＩシステム１０４を備えた取引先１０５とは、ネットワーク１０３を介して商取引に関する電子情報であるＥＤＩデータ１０８を相互に交換する。

ＥＤＩシステム１０１は、ネットワーク１０７を介して互いに接続されている基幹システム１００、ジョブ運用管理サーバ（情報処理装置）１０２を備えている。

尚、図１のネットワーク１０７上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。

ジョブ運用管理サーバ１０２は、ＥＤＩ通信機能・ＥＤＩデータ変換機能・運用管理機能を有し、基幹システム１００と取引先ＥＤＩシステム１０４との間のデータ交換の仲介を行う。ここでいう仲介とは、ＥＤＩデータを双方のフォーマット形式に変換し、通信可能なプロトコルで送受信することを指す。

次に、図１のジョブ運用管理サーバ１０２のハードウェア構成について、図２を用いて説明する。

図２は、ジョブ運用管理サーバ１０２のハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やＦＤ或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるＣＦメモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラム２１２が用いる定義ファイル２１３及び各種情報テーブル２１４は外部メモリ２１１に格納されており、これらについての詳細な説明は後述する。

図３は、ジョブ運用管理サーバに搭載されるＥＤＩデータ変換機能の構成を概略的に示す機能ブロック図である。

これらの装置は主にＷｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）などのＯＳを搭載したコンピュータを想定しているが、本発明では、使用ＯＳは特定しない。

なお、ＥＤＩデータ変換機能は、トランスレータともいう。

変換エンジン部３００は、マッピング定義エディタ部３０１で作成したマッピング定義に基づいて、入力されたＥＤＩデータのフォーマット形式を変換し出力するための機能である。

マッピング定義エディタ部３０１は、変換エンジン部３００で実行するフォーマット変換の内容を作成するための機能である。

マッピング定義切替設定エディタ部３０２は、変換に使用するマッピング定義を切り替える条件や使用するマッピング定義の設定を作成するための機能である。

マッピング定義切替エンジン部３０３は、与えられたマッピング定義切替設定を元に入力データを解析・条件判定し、使用するマッピング定義を選択して変換エンジン部に渡すための機能である。

図４は、本発明の実施形態のジョブ運用管理サーバの基本的な処理フローを示す図である。それぞれのステップの詳細については後述する。

まず、ステップＳ４００において、ジョブ運用管理サーバは、マッピング定義エディタ部３０１を用いて利用者が行いたいフォーマット変換のマッピング定義を作成し、ファイルに保存する。この詳細な処理の説明については、図５を用いて後に説明する。

次に、ステップＳ４０１において、ジョブ運用管理サーバは、マッピング定義切替設定エディタ部３０２を用いて利用者が行いたいマッピング定義切替の設定を作成し、ファイルに保存する。この詳細な処理の説明については、図６を用いて後に説明する。

最後に、ステップＳ４０２において、ジョブ運用管理サーバは、作成されたマッピング定義切替設定と入力データを元に、マッピング定義切替エンジン部が使用するマッピング定義を選択し、そのマッピング定義を用いて変換エンジン部が入力データのフォーマット変換を行い、結果をファイルに出力する。この詳細な処理の説明については、図７を用いて後に説明する。

続いて、上述したＳ４００〜Ｓ４０２の各ステップの詳細な処理の流れを、図を用いて説明する。

図５は、ステップＳ４００の詳細処理の流れを示すフローチャートである。

ここで、ステップＳ４００は、利用者がマッピング定義エディタ部３０１を用いて入力データから出力データへのフォーマット変換のマッピングを定義し、ファイルに作成したマッピング定義を保存する処理である。

なお、本処理の動作の主体は、ジョブ運用管理サーバである。

まず、ステップＳ５００において、ジョブ運用管理サーバは、図１１のマッピング定義設定エディタ画面を表示装置へ表示する。利用者は、この画面を使用してマッピング定義を作成する。

次に、ステップＳ５０１において、ジョブ運用管理サーバは、利用者が図１１の入力データ定義ウィンドウ１１００を介して入力した入力データのフォーマット定義を受け付ける。

ここで、入力データのフォーマットとは、入力データがどのような形をしているかの定義である。例えば、入力データがＸＭＬならばその構造と各項目のデータ型、ＣＳＶならば項目数と各項目のデータ型、固定長ならばレコード長とそのレコードを構成する各項目の長さ・データ型を定義する。

図１１の入力データ定義ウィンドウ１１００は、入力データがＸＭＬである場合のフォーマット定義の一例を示している。

ＸＭＬのルートタグがＯｒｄｅｒＭｅｓｓａｇｅであり、その下にＨｅａｄｅｒタグとＬｉｓｔＯｆＯｒｄｅｒｓタグが出現する。ＬｉｓｔＯｆＯｒｄｅｒｓタグは複数回出現しうる。Ｈｅａｄｅｒタグの下にはＳｅｎｄｅｒタグとＲｅｃｅｉｖｅｒタグが出現する。ＬｉｓｔＯｆＯｒｄｅｒｓタグの下にはＰａｙｅｒタグ、Ｂｕｙｅｒタグ、Ｏｒｄｅｒタグが出現し、Ｏｒｄｅｒタグは複数回出現しうる。Ｏｒｄｅｒタグの下には、ＴｒａｄｅＩＤタグ、ＩｔｅｍＮａｍｅタグが出現する。

次に、ステップＳ５０２において、ジョブ運用管理サーバは、利用者が図１１の出力データ定義ウィンドウ１１０１を介して入力した出力データのフォーマット定義を受け付ける。

ここで、出力データのフォーマットとは、出力データがどのような形をしているかの定義であり、入力データのフォーマットと同様の定義を行う。

図１１の出力データ定義ウィンドウ１１０１は、出力データがＣＳＶである場合のフォーマット定義の一例を示している。

ＣＳＶのレコードを構成する各項目に、Ｓｅｎｄｅｒ、Ｒｅｃｅｉｖｅｒ、Ｐａｙｅｒ、Ｂｕｙｅｒ、ＴｒａｄｅＩＤ、ＩｔｅｍＮａｍｅという名称をつけている。

次に、ステップＳ５０３において、ジョブ運用管理サーバは、利用者が図１１のマッピングスクリプトウィンドウ１１０２を介して定義した入力データから出力データへのデータ項目のマッピング定義を受け付ける。

図１１のマッピングスクリプトウィンドウ１１０２が、マッピングの定義の一例を示している。

１行目では、ＣＳＶの１レコード目のＳｅｎｄｅｒ項目に、ＸＭＬのＯｒｄｅｒＭｅｓｓａｇｅタグの下のＨｅａｄｅｒタグの下のＳｅｎｄｅｒタグの値を入力することを記述している。ＣＳＶのレコードの数は０から数えるため、１番目のレコードを指定するために、”Ｓｅｎｄｅｒ［０］”のように０を指定している。

２行目では、ＣＳＶの１レコード目のＲｅｃｅｉｖｅｒ項目に、ＸＭＬのＯｒｄｅｒＭｅｓｓａｇｅタグの下のＨｅａｄｅｒタグの下のＲｅｃｅｉｖｅｒタグの値を入力することを記述している。ＣＳＶのレコードの指定は１行目と同様である。

３行目では、ＣＳＶの１レコード目のＰａｙｅｒ項目に、ＸＭＬのＯｒｄｅｒＭｅｓｓａｇｅタグの下のＬｉｓｔＯｆＯｒｄｅｒｓタグの下のＰａｙｅｒタグの値を入力することを記述している。ＣＳＶのレコードの指定は１行目と同様である。また、ＬｉｓｔＯｆＯｒｄｅｒｓタグは複数出現する可能性があるため、１番目のＬｉｓｔＯｆＯｒｄｅｒｓタグを指定している。ＣＳＶのレコードの数と同様、ＸＭＬのタグの数も０から数えるため、１番目のタグを指定するために”ＬｉｓｔＯｆＯｒｄｅｒｓ［０］”のように０を指定している。

以上のように、出力する全ての項目についてマッピングを行うが、本発明にはマッピング定義の内容は関係ないため、以降の項目については省略する。

次に、ステップＳ５０４において、ジョブ運用管理サーバは、さらに入力データから出力データへのマッピングの要求がなかったかを判定する。あった場合は、ステップＳ５０３に戻る。一方、なかった場合は、全てのマッピングの要求が定義されものとして、ステップＳ５０５に遷移する。

次に、ステップＳ５０５において、ジョブ運用管理サーバは、マッピング定義をファイルに保存して、マッピング定義作成処理を終了する。

図１５にマッピング定義（定義情報）の一例を示す。

ここでのマッピング定義の内容は、図１１のマッピング定義エディタ画面の例のように、入力データがＸＭＬ、出力データがＣＳＶである場合を示している。

入力データのフォーマット定義が３２００に、出力データのフォーマット定義が３２０１に、入力データから出力データへのデータ項目のマッピングが３２０２にそれぞれ保存される。

本発明では、マッピング定義の内容は関係ないため、詳細については省略する。

図６は、ステップＳ４０１の詳細処理の流れを示すフローチャートである。

ここで、ステップＳ４０１は、利用者がマッピング定義切替設定エディタ部３０２を用いて、マッピング切替設定を定義し、ファイルに作成したマッピング定義切替設定を保存する処理である。

なお、本処理の動作の主体は、ジョブ運用管理サーバである。

まず、ステップＳ６００において、ジョブ運用管理サーバは、図１２のマッピング定義切替設定エディタ画面を表示装置へ表示する。初期表示では、全ての項目は空欄である。以下、ファイルに保存するまで、利用者の行う設定はメモリ上に保持しておく。

次に、ステップＳ６０１において、ジョブ運用管理サーバは、ユーザにより優先度設定欄１２００の欄に入力された優先度を示す数値の入力を受け付ける。入力があった場合、それに応じて画面表示を変更する制御を行う。

ここで、優先度は、相手先から送信されてくる可能性の高いメッセージの優先度が高くなるように設定されるべきである。例えば、相手先Ａと相手先Ｂからバージョン１．３のメッセージが送付され、相手先Ｃからバージョン１．２のメッセージが送付されるような場合、バージョン１．３の変換を行う設定を優先度１、バージョン１．２の変換を行う設定を優先度２とする。

このようにすることで、よりデータ変換回数が多くなる可能性の高いメッセージについて、フォーマット変換を速やかに行うことが可能となる。

また、このように優先度を設けて複数のマッピング定義切替設定を行うことで、複数の業務プロセル毎のマッピング定義の登録をまとめて行うことができるため運用管理者の負担が軽減される。

次に、ステップＳ６０２において、ジョブ運用管理サーバは、ユーザにより識別条件設定欄１２０１の欄に入力されたＸＭＬスキーマファイル名の入力を受け付ける。入力があった場合、それに応じて画面表示を変更する制御を行う。

ここで、ＸＭＬスキーマファイルとは、ＸＭＬの論理的構造を定義するための言語であるＸＭＬスキーマを用いて、ＸＭＬの構造を記述したファイルである。ＸＭＬスキーマを用いてＸＭＬを検証することで、ＸＭＬの正しさをチェックすることが可能である。ＸＭＬスキーマの仕様は、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）が策定し、公開している。

次に、ステップＳ６０３において、ジョブ運用管理サーバは、ユーザによりマッピング定義設定欄１２０２の欄に入力された使用するマッピング定義の入力を受け付ける。入力があった場合、それに応じて画面表示を変更する制御を行う。

次に、ステップＳ６０４において、ジョブ運用管理サーバは、ユーザにより出力ファイル設定欄１２０３の欄に入力された出力ファイル名の入力を受け付ける。入力があった場合、それに応じて画面表示を変更する制御を行う。

次に、ステップＳ６０５において、ジョブ運用管理サーバは、条件追加ボタン１２０５が押下されたかどうかを判定する。押下された場合は、優先度設定欄１２００、識別条件設定欄１２０１、マッピング定義設定欄１２０２、出力ファイル設定欄１２０３、条件削除ボタン１２０４までの欄を一行分追加して表示する制御を行う。新たな条件を設定可能なように画面表示を変更し、ステップＳ６０１に遷移する。一方、押下されなかった場合は、ステップＳ６０６に遷移する。

次に、ステップＳ６０６において、ジョブ運用管理サーバは、条件削除ボタン１２０４が押下されたかどうかを判定する。押下された場合、ステップＳ６０７に遷移する。押下されなかった場合、ステップＳ６０８に遷移する。

次に、ステップＳ６０７において、ジョブ運用管理サーバは、押下された削除ボタン１２０４と、同じ行に存在する優先度設定欄１２００、識別条件設定欄１２０１、マッピング定義設定欄１２０２、出力ファイル設定欄１２０３を画面から消去し、入力されていた値をメモリ上から消去する。そして、ステップＳ６０８に遷移する。

次に、ステップＳ６０８において、ジョブ運用管理サーバは、保存ボタン１２０６が押下されたかどうかを判定する。押下された場合は、ファイル選択画面を表示し、利用者にマッピング定義切替設定を保存するファイルを選択してもらい、ステップＳ６０９に遷移する。押下されなかった場合は、ファイルへの保存を行わずに処理を終了する。

次に、ステップＳ６０９において、ジョブ運用管理サーバは、ステップＳ６０８で指定されたファイルに、メモリ上に保持していたマッピング定義切替設定の内容の保存を行う。ここでは、図１２のマッピング定義切替設定エディタ画面のように設定されたと仮定して、処理を説明する。

設定情報は、図１２のマッピング定義切替設定エディタ画面の各項目であり、マッピング定義切替設定テーブルに保存する。このマッピング定義切替設定テーブルの内容は、ファイルに複数レコード保存される。図１３にマッピング定義切替設定テーブルの一例を示す。

まず、マッピング定義切替設定エディタ画面の画面項目１２００〜１２０３を１レコードずつマッピング定義切替設定テーブルの１３００〜１３０３にそれぞれ保存する。その際のキー項目は、優先度になる。

設定の保存が完了後、処理を終了する。

図７は、ステップＳ４０２の詳細処理の流れを示すフローチャートである。

ここで、ステップＳ４０２は、マッピング定義切替設定ファイルの識別条件と入力データを比較し、適合した識別条件に設定されたマッピング定義を使用してフォーマット変換を実行する処理である。

なお、本処理の動作の主体は、ジョブ運用管理サーバである。

まず、ステップＳ７００において、ジョブ運用管理サーバは、トランスレータの起動時にあらかじめ定められたマッピング定義切替設定ファイルの内容を読み込む。

なお、トランスレータの起動は、ＥＤＩシステムが相手先企業からメッセージを受信（入力データの取得）し、そのメッセージを基幹システムへと取り込める形式へと変換する際に行われる。

次に、ステップＳ７０１において、ジョブ運用管理サーバは、識別対象となる優先度の初期値を変数ｎに設定する。初期値は１である。

次に、ステップＳ７０２において、ジョブ運用管理サーバは、優先度ｎに指定されている識別条件のＸＭＬスキーマファイルを読み込む。図１３を例にすると、優先度「１」の場合は、「Ｓｃｈｅｍａ＿Ｖ１．３．ｘｓｄ」を読み込み、優先度「３」の場合は、「Ｓｃｈｅｍａ＿Ｖ１．１．ｘｓｄ」を読み込むことになる。

次に、ステップＳ７０３において、ジョブ運用管理サーバは、ステップＳ７０２で読み込んだＸＭＬスキーマファイルを用いて、入力データの検証を行う。検証は、入力データがどのようなものであるかの検証を行う（＝入力データの種別が条件に合致するかを確認するものである。）。本実施の形態では、入力データがＸＭＬであることが前提となっているので、そのＸＭＬのバージョンを確認している。ただし、検証は、これに限られるものではなく、様々な検証を行うことができる。

なお、ＸＭＬの検証は、例えばアプリケーションの開発言語がＪａｖａ（登録商標）であるならば、ＸｅｒｃｅｓなどのＸＭＬライブラリに、検証を行うための機能が用意されており、それを使用することで行うことが可能である。他の開発言語であったとしても、同様である。

次に、ステップＳ７０４において、ジョブ運用管理サーバは、ステップＳ７０３での検証結果を判定する。検証に成功した場合は、ステップＳ７０７に遷移する。一方、検証に失敗した場合は、ステップＳ７０５に遷移する。

次に、ステップＳ７０５において、ジョブ運用管理サーバは、次に入力データとの比較を行う優先度の値を設定する。変数ｎに１を加算し、ステップＳ７０６に遷移する。

次に、ステップＳ７０６において、ジョブ運用管理サーバは、入力されたマッピング定義切替設定に優先度ｎが設定されているか否かの確認を行う。優先度ｎが設定されていれば、ステップＳ７０２に遷移して、優先度ｎで設定されたＸＭＬスキーマを用いて、入力データの検証を実行する。優先度ｎが設定されていなければ、変換失敗としてフローを異常終了する。

次に、ステップＳ７０７において、ジョブ運用管理サーバは、ステップＳ７０４の検証結果の確認、検証に成功した場合に遷移し、優先度ｎに設定されたマッピング定義を使用して入力データのフォーマット変換を実行する。

次に、ステップＳ７０８において、ジョブ運用管理サーバは、ステップＳ７０７で実行したフォーマット変換の結果を判定する。変換に成功していた場合、変換成功としてフローを正常終了する。変換に失敗していた場合、変換失敗としてフローを異常終了する。

ここで、マッピング定義切替処理の具体例を図１４に示す。

図１３のマッピング定義切替設定には、優先度１から３までのＸＭＬスキーマ・マッピング定義・出力ファイルが設定されている。このマッピング定義切替設定に対し、優先度３の識別条件であるＸＭＬスキーマ”Ｓｃｈｅｍａ＿ｖ１．１．ｘｓｄ”で検証成功となるＸＭＬが入力データとして与えられたとする。

トランスレータが起動されると、まず、優先度１の識別条件であるＸＭＬスキーマ”Ｓｃｈｅｍａ＿ｖ１．３．ｘｓｄ”で入力ＸＭＬの検証を行う（３１０１）。検証の結果は失敗である。優先度１の識別条件に適合しなかったので、次の優先度である優先度２で入力データの検証を行う。

次に、優先度２の識別条件であるＸＭＬスキーマ”Ｓｃｈｅｍａ＿ｖ１．２．ｘｓｄ”で入力ＸＭＬの検証を行う（３１０２）。検証の結果は失敗である。優先度２の識別条件に適合しなかったので、次の優先度である優先度３で入力データの検証を行う。

さらに、優先度３の識別条件であるＸＭＬスキーマ”Ｓｃｈｅｍａ＿ｖ１．１．ｘｓｄ”で入力ＸＭＬの検証を行う（３１０３）。検証の結果は成功であるので、入力データは優先度３の識別条件に適合したことになり、優先度３に設定されたマッピング定義”Ｍａｐ１１．ｍａｐ”を用いて変換を実行する（３１０４）。

変換後のファイル名は、優先度３に設定されたファイル名”Ｏｕｔｐｕｔ１１．ｔｘｔ”となる（３１０５）。

以上説明したように、本発明によれば、業務プロセス毎に異なるマッピング定義を登録する必要をなくし、運用管理者の負担やミスの発生の軽減することが可能となる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図４〜７の処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４〜７の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは４〜７の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ 基幹システム
１０１ ＥＤＩシステム
１０２ ジョブ運用管理サーバ
１０３ ネットワーク
１０４ ＥＤＩシステム
１０５ 取引先
１０６ 自社フォーマット
１０７ 社内ネットワーク
１０８ 業界標準フォーマット

Claims (5)

1. 入力データのフォーマット形式を出力データのフォーマット形式へ変換する情報処理装置であって、
   入力データのフォーマット形式から出力データのフォーマット形式へ変換するための定義情報と、入力データの種別を識別する条件とを対応づけたレコードを複数レコード記憶する記憶手段と、
   前記定義情報を用いて、入力データのフォーマット形式を出力データのフォーマット形式へ変換する変換手段と、
   入力データを取得する取得手段と、
   前記記憶手段により記憶される複数レコードから１レコードを選択する選択手段と、
   前記取得手段により取得された入力データが、前記選択手段により選択されたレコードに含まれる入力データの種別を識別する条件に合致するかを判定する判定手段とを有し、
   前記判定手段により、合致すると判定された場合、前記変換手段は、前記条件に対応づけて前記記憶手段に記憶される前記定義情報を用いて、前記取得された入力データのフォーマット形式の変換を行い、一方、前記判定手段により、合致しないと判定された場合、前記選択手段は、他のレコードを選択することを特徴とする情報処理装置。
2. 前記記憶手段は、各レコードに優先度を示す情報を更に記憶し、
   前記選択手段は、前記記憶手段により記憶される優先度を示す情報を用いて、１レコードを選択することを特徴とする請求項１に記載の情報処理装置。
3. 入力データのフォーマット形式から出力データのフォーマット形式へ変換するための定義情報と、入力データの種別を識別する条件とを対応づけたレコードを複数レコード記憶する記憶手段を有する、入力データのフォーマット形式を出力データのフォーマット形式へ変換する情報処理装置における情報処理方法であって、
   前記定義情報を用いて、入力データのフォーマット形式を出力データのフォーマット形式へ変換する変換ステップと、
   入力データを取得する取得ステップと、
   前記記憶手段により記憶される複数レコードから１レコードを選択する選択ステップと、
   前記取得ステップにより取得された入力データが、前記選択ステップにより選択されたレコードに含まれる入力データの種別を識別する条件に合致するかを判定する判定ステップとを有し、
   前記判定ステップにより、合致すると判定された場合、前記変換ステップは、前記条件に対応づけて前記記憶手段に記憶される前記定義情報を用いて、前記取得された入力データのフォーマット形式の変換を行い、一方、前記判定ステップにより、合致しないと判定された場合、前記選択ステップは、他のレコードを選択することを特徴とする情報処理方法。
4. 入力データのフォーマット形式を出力データのフォーマット形式へ変換する情報処理装置において実行可能なプログラムであって、
   入力データのフォーマット形式から出力データのフォーマット形式へ変換するための定義情報と、入力データの種別を識別する条件とを対応づけたレコードを複数レコード記憶する記憶手段、
   前記定義情報を用いて、入力データのフォーマット形式を出力データのフォーマット形式へ変換する変換手段、
   入力データを取得する取得手段、
   前記記憶手段により記憶される複数レコードから１レコードを選択する選択手段、
   前記取得手段により取得された入力データが、前記選択手段により選択されたレコードに含まれる入力データの種別を識別する条件に合致するかを判定する判定手段として前記情報処理装置を機能させ、
   前記判定手段により、合致すると判定された場合、前記変換手段は、前記条件に対応づけて前記記憶手段に記憶される前記定義情報を用いて、前記取得された入力データのフォーマット形式の変換を行い、一方、前記判定手段により、合致しないと判定された場合、前記選択手段は、他のレコードを選択することを特徴とするプログラム。
5. 請求項４に記載のプログラムをコンピュータ読み取り可能に記憶した記憶媒体。

Images