JP2005100074A

JP2005100074A - 中間データベースを利用した企業間リアルタイムデータ連携装置及び方法

Info

Publication number: JP2005100074A
Application number: JP2003332650A
Authority: JP
Inventors: Keiichiro Higashiya; 敬一郎東谷; Katsunori Morizumi; 勝則森住
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-09-25
Filing date: 2003-09-25
Publication date: 2005-04-14

Abstract

【課題】従来のバッチ処理型のデータ連携方法では、一意なマッピングによるデータ変換しか対応できない。また、異なる商習慣や業務上の制約条件を持つ複数のバックエンドシステム同士をリアルタイムで連携させる事は困難である。
【解決手段】送信元ネットワークユニットＡのウェブサーバ２ａとバックエンド連携サーバ３の間に、中間データベース１ａを設け、ここで送信元ネットワークユニットＡのバックエンドシステム４ａと送信先ネットワークユニットＢのバックエンドシステム４ｂのギャップを吸収させる。具体例としては、起点をデータベース管理ツール１ｂからの中間データベース１ａのデータレコード登録とし、このデータに基づいて４ａにリアルタイムでデータ登録を実施し、登録結果情報を中間データベース１ａに付加した形でウェブサーバ２ａからネットワークユニットＢのウェブサーバ２ｂにデータ伝送を実施する。
【選択図】図１

Description

本発明は、企業間連携(Ｂ２Ｂ)等において、リアルタイムでの双方向データ連携を実現する為の手段に関するものである。

異なるシステム間でのデータ連携は、従来から実施されている。このデータ連携を実現した例としては、特許文献１や特許文献２に記載されたものがある。これらによれば、データ内容やフォーマット等の変換テーブルを設けたり、連携パターンデータや連携元／連携先システム定義情報を用いることにより、異なるシステム間でのデータ連携を実現している。

特開2002-099451号公報

特開2002-298072号公報

従来のデータ連携方法によると、次の様な問題があった。
（１）バックエンドシステムまでの連携を実施する場合、コード変換やフォーマット変換等を実施する必要がある為バッチ処理となり、人の判断が介在する余地が無く、互いの商習慣の違い等による様々な制約条件までは吸収しきれない。
（２）全てのノウハウをシステム化する必要があり、其々異なる制約条件のバックエンドシステムを持つ複数の送信先及び送信元がある場合、互いのバックエンドシステム側でのインターフェースシステムが肥大化してしまい、運用やシステムメンテナンスも煩雑になる。

本発明は、互いの異なる商習慣上の制約や業務上の様々な制約条件に依存する事なく、効率的に双方向でのリアルタイムデータ連携を実現する方法及び装置を提供することを目的とするものである。本発明の他の目的は、制約条件にギャップがある各々のバックエンドシステムに修正を加える事なく、効率的にリアルタイムでの双方向データ連携が可能な、企業間リアルタイムデータ連携装置及び方法を提供することにある。

本発明は、連携先の制約条件を満足するデータを互いのバックエンドシステムの間に予め準備する事により、様々な制約条件の違いを吸収した効率的な双方向リアルタイムデータ連携が可能な、企業間リアルタイムデータ連携装置及び方法を提供するものである。

本発明の特徴は、制約条件を異にする複数のネットワークユニットがネットワークを介して双方向連携可能に接続される装置であって、前記各ネットワークユニットは、バックエンドシステムと連携に必要なフロントエンドシステムとを具備するものにおいて、前記各ネットワークユニットは、前記フロントエンドシステムと前記バックエンドシステムの間に、連携先の制約条件を満足する情報を予め準備する手段を備えていることにある。

前記連携先の制約条件を満足する情報を予め準備する手段は、前記フロントエンドシステムと前記バックエンドシステムの間に位置する中間データベースと、該中間データベースの管理を行なう管理システムで構成できる。なお、中間データベースは必ずしもデータベースを準備する必要はなく、通常のフラットファイル等でも代替可能である。また、管理システムは、中間データベースを管理(登録／更新／検索)する為の、ユーザに提供されるツールであり、オンライン処理画面等を持つものである。

本発明によれば、自ウェブサーバと自バックエンド連携サーバの間に、自バックエンドシステムとデータコミュニケーション先バックエンドシステム側の制約条件を吸収する為のデータベースを設ける事により、各々のバックエンドシステムへの修正を実施する事なく互いのバックエンドシステムを含めたリアルタイムでのデータ連携が実現可能となる。この効果は、異なる制約条件を持つ自バックエンドサーバ及びデータ連携先のバックエンドサーバの数が増えれば増える程、データベース構造を工夫する事により大きくなると考える。また、システム開発コストも抑制可能である。さらに、ユーザはデータベース管理ツールにより、自バックエンドシステム及び送信先バックエンドシステムのステータス及びデータの管理が容易となる。

以下、本発明の実施例について、図を参照して詳細に説明する。
図１は、本発明の一実施例になる企業間リアルタイムデータ連携システムの構成図である。なお、図中の矢印は、データの流れを示すものである。ユーザの自社内等のネットワークユニットＡには、ユーザのパートナー等インターネットαを介して電子データを送受信する相手のネットワークユニットＢとの直接の窓口となるウェブサーバ２ａと、ネットワークユニットＡ内での基幹業務システムが稼動するバックエンドサーバ４ａとのリアルタイムデータ連携を司るバックエンド連携サーバ３が存在し、さらにその間に接続された中間データベース（データベース群）１ａと、この中間データベース１ａの管理システム（管理ツール）１ｂとがある。管理システム１ｂは、ユーザが情報を入力し、あるいは検索するためのオンライン処理画面を備えている。

中間データベース１ａは、自バックエンドシステムとデータコミュニケーション先バックエンドシステム側の制約条件を吸収する為のデータベースである。これを設けることにより、各々のバックエンドシステムへの修正を実施する事なく互いのバックエンドシステムを含めたリアルタイムでのデータ連携を可能にするものである。中間データベースすなわちデータベース群１ａには、ネットワークユニットＢのウェブサーバ２ｂとウェブサーバ２ａの間で送受信されるデータやバックエンドサーバ４ａ及びバックエンドサーバ４ｂへのデータ更新ステータス等を格納する為のデータテーブル群と、バックエンドシステム（サーバ）４ａとウェブサーバ２ａのデータ内容を関連づける為のクロスリファレンステーブル群とがある。なお、中間データベースは必ずしもデータベースを準備する必要はなく、通常のフラットファイル等でも代替可能である。

これらのデータテーブル群及びクロスリファレンステーブル群のテーブル構成は、それぞれ図２及び図３に示す通りである。

まず、データテーブル２００は、図２のように、ユーザのバックエンドシステム４ａ更新用の項目群ａと、ウェブサーバ２ａ及び２ｂ間の送受信データ格納用項目群ｂと、バックエンドステータスｃと、相手とのコミュニケーションステータスｄとにより構成されている。尚、項目群ｅは、項目群ａと項目群ｂの共用項目群であり、バックエンドサーバ４ａからの更新結果のフィードバック項目(リターン値)で、結果を相手のネットワークユニットＢに送信する為に使用される項目であり、バックエンドサーバ４ａでしか生成できない項目或いは、相手ネットワークユニットＢからの受信データのうちバックエンドシステム４ａ更新に使用される項目である。

また、クロスリファレンステーブル３００は、図３のように、コード変換を必要とする項目の変換キーｆと、バックエンドシステム４ａでのコードｇと、相手とのデータ送受信時に使用するコードｈとが存在する、一般的なコード変換テーブルである。

一方、データベース管理ツール１ｂは、以下の機能を具備している。これらの各機能は、プログラムとデータ、及びこのプログラムを実行処理するコンピュータにより、実現される。また、これらの各機能は、図４に示すオンライン処理画面（初期メニュー画面）を操作することで、実行可能となっている。

Ｋ０１：新規注文登録機能(図５参照)
Ｋ０２：データテーブル詳細検索機能(図７Ａ、図７Ｂ参照)
Ｋ０３：注文変更機能
Ｋ０４：クロスリファレンステーブル検索/編集機能
Ｋ０５：注文関連情報(フォーキャスト/在庫)送信機能
ユーザは、データテーブル詳細検索機能Ｋ０２により、自バックエンドシステムステータスｃやコミュニケーションステータスｄ、さらには、相手先からの受注回答情報等を確認する事が可能である。

なお、図６は、データベース管理ツール１ｂのオンライン処理画面の一実施例を示す図であり、新規注文登録の状態を示している。

また、図７Ａは、データベース管理ツール１ｂのデータテーブル検索画面に表示された全件リストの例、図７Ｂは、個別案件の明細情報の表示例である。

本発明はこれらの機能を利用して、以下の処理手順によって、企業間のリアルタイムデータ連携を実現するものである。

尚、以下に述べる例の前提条件として注文書データの送信及びその回答データの受信プロセスを取り上げる。また、解決すべき送信相手との商習慣上等のバックエンドシステム間のギャップとしては、「日本では、注文を実施する際に一品一様で注文書データを作成するのが通例であり、かつ自社のバックエンドシステムでは１つの注文書に希望納期は１つしか保持できないとする。これに対して米国では多品一様で、かつ受注先企業では１つの受注で１品目に対して１Ｗ単位の納期で分割して受注する様なバックエンドシステムをもっている。」事とする。

図５Ａ、図５Ｂにより、本発明の一実施例として、商習慣の異なる日本企業と米国企業の間における新規注文登録処理の動作手順について、説明する。
先ず、Ｓ０１で、ユーザ（日本企業）は、データベース管理ツール１ｂにより、相手（米国企業）のバックエンド制約を満足する１Ｗ単位納期別の注文要求データをデータベース１ａに登録する。すなわち、データベース管理ツール１ｂのオンライン登録画面５００(図６参照)から、データベース１ａのデータテーブル２００の送受信データ格納用項目群ｂに、相手のバックエンド制約を満足する１Ｗ単位納期別の注文要求データを、複数品目分登録する(図１の矢印（１）)。

Ｓ０２で、上記注文要求データに、自社バックエンドシステム４ａの制約条件を満足する編集項目が追加される。すなわち、上記注文要求データを自社バックエンドシステム４ａの制約条件である１注文１納期の購買依頼データとする為に、代表納期及び１Ｗ単位注文要求数の合計数量が集計され、データテーブル２００のバックエンド更新用の項目群ａに登録される。

同時に、図３のクロスリファレンステーブル３００を使用してデータ送信用のコードに変換されたデータも、データテーブル２００の送受信データ格納用項目群ｂに合わせて登録される(Ｓ０３)。

さらに、このデータテーブル２００のバックエンドステータスｃに、バックエンドシステム４ａに対して新規購買依頼データ登録要求を意味するステータスがセットされる(Ｓ０４)。

次に、自社のバックエンドシステム４ａへのデータ登録処理が実施される（Ｓ０５）。すなわち、バックエンド連携サーバ３は常にデータベース１ａのデータテーブル２００のバックエンドステータスｃをポーリング方式で監視しており、そのステータスとして新規の購買依頼データ登録要求ステータスのデータレコードが存在した場合に、該当レコードのバックエンドシステム更新用項目群ａの情報をレコード単位でバックエンドシステム４ａに送信する(図１の矢印（２）、（３）)。

バックエンドシステム４ａは、送られてきたメッセージキューデータに基づいて購買依頼データを登録し、正常に登録された場合はバックエンド連携サーバ３を介してデータベース１ａのデータテーブル２００に注文番号を返して共用項目群ｅへ登録する(Ｓ０６、図１の矢印（４）、（５）)。

また、全ての品目についての共用項目群ｅに更新が完了した際に、データテーブル２００のコミュニケーションステータスｄは、受注先Ｂのウェブサーバ２ｂへのデータ送信準備完了を意味するステータスがセットされる。

次に、相手先へ注文データの送信を行なう（Ｓ０８）。ネットワークユニットＡのウェブサーバ２ａは、データベース１ａのデータテーブル２００のコミュニケーションステータスｄをポーリング方式で監視しており、発注すべき注文データについて相手先への送信を行なう。すなわち、データ送信準備完了ステータスとなったデータの送受信データ格納用項目群ｂのうち、送信用項目を１つのメッセージデータとして、規定のフォーマットでウェブサーバ２ｂに送信する(図１の矢印（６）、（７）)。

尚、送信が完了した時点で(Ｓ０９)、データテーブル２００のコミュニケーションステータスｄを、送信完了を意味するステータスに更新する。

送信先のネットワークユニットＢでは、受注システム４ｂに受信したデータを取り込み、それに対する受注回答データをウェブサーバ２ｂ経由でウェブサーバ２ａへ返信する(Ｓ１０、図１の矢印（８）)。受注回答データには、受注ＯＫ／ＮＧ／保留を意味するステータス及び価格情報や回答納期/数量等が含まれる。

ネットワークユニットＡのウェブサーバ２ａは、データが返送されてくると、そのデータを品目単位に分割し、代表回答納期及び価格情報をデータベース１ａの送受信データ格納項目群ｂのうち共用データ格納項目群ｅに登録する（Ｓ１１）。また、ＯＫ／ＮＧ／保留の回答項目をバックエンドステータスｃへ上書き更新する(図１の矢印（９）)。

この時、１Ｗ単位の個別の回答納期及び回答数量は、送受信データ格納項目群ｂのうちの受信データ格納項目に登録される。また、バックエンドシステム４ａの更新用となる代表回答納期及び合計回答数量が、バックエンド更新用項目群ａに登録される(Ｓ１２)。尚、データベース１ａの更新が全て完了した時点で、コミュニケーションステータスｄは、受信完了を意味するステータスに更新される。

ネットワークユニットＡのバックエンド連携サーバ３は、データテーブル１ａのバックエンドステータスｃを監視しており(Ｓ１３)、回答が受注ＯＫを意味するステータスの場合は、該当レコードデータをバックエンドシステム４ａへ送信し、共用データ格納項目群ｅに基づいて該当する購買依頼データの更新処理を実行する(Ｓ１４、図１の矢印（１０）、（１１）)。

更新が正常に完了したら、バックエンド連携サーバ３を経由して該当レコードのバックエンドステータスｃを更新完了ステータスに変更する(Ｓ１５、図１の矢印（１２）、（１３）)。

Ｓ１３で回答が保留の場合は、バックエンド連携サーバ３は何もせず、ネットワークユニットＢのウェブサーバ２ｂから再度ＯＫかＮＧかの回答が送信されるのを待つ。(Ｓ１６）。もし、回答が受注ＮＧの場合は、バックエンドシステム４ａの購買依頼データの取消し要求及び取消し処理が実施される（Ｓ１６、Ｓ１７）。

このように、中間データベース１ａ及びデータベース管理ツール１ｂにより、送信元ネットワークユニットＡのバックエンドシステム４ａと送信先ネットワークユニットＢのバックエンドシステム４ｂのギャップを吸収させることで、各々のバックエンドシステムへの修正を実施する事なく互いのバックエンドシステムを含めたリアルタイムでのデータ連携が可能になる。

尚、図８は、図２に示したデータテーブル２００の具体的構成例である。すなわち、
キー項目がRN_NUMBERであり、バックエンド更新様項目群ａが、BUYER_MATERIAL_ID(発注者品目コード)、REQUEST_TOTAL_QUANTITY(注文要求合計数量)、CONFIRM_TOTAL_QUANTITY(回答合計数量)、CONFIRM_UNITPRICE(回答単価)、VENDER_CODE(取引先コード)で構成されている。また、送受信データ格納項目群ｂが、PO_NUMBER(注文番号)、GTIN(GTINコード)，SELLER_MATERIAL_ID(受注者品目コード)、REQUEST_TOTAL_QUANTITY、CONFIRM_TOTAL_QUANTITY、QUANTITY_MEASURE_CODE (数量単位)、REQUEST_UNITPRICE(希望単価)、CONFIRM_UNITPRICE，REQUEST_DATE(注文要求日)，CONFIRM_DATE(回答日)、SHIP_TO_DUNS(納入先DUNSナンバー)、SHIP_TO_DUNS4(納入場所DUNS+4)、CONTACT_NAME(担当者名)、EMAIL_ADDRESS(Ｅメールアドレス)、TEL_NO(電話番号)、COMMENT_TEXT(コメント)、SUBLINE_STATUS_1〜5(明細ステータス１〜５)、SUBLINE_REQUEST_QUANTITY_1〜5(明細要求数量１〜５)、SUBLINE_CONFIRM_QUANTITY_1〜5(明細回答数量１〜５)、SUBLINE_REQUEST_DATE_1〜5(明細要求納期１〜５)、及びSUBLINE_CONFIRM_DATE_1〜5(明細回答納期１〜５)で構成されている。また、バックエンドステータスｃが、BACKEND_STATUS、コミュニケーションステータスｄがCOMM_STATUS、共通項目群ｅがREQUEST_TOTAL_QUANTITY、CONFIRM_TOTAL_QUAN TITY、CONFIRM_UNITPRICEで構成されている。

また、ユーザが上記注文内容を変更したい場合には、データベース管理ツール１ｂの注文変更機能Ｋ０３を用いて処理する。この注文変更機能により、新規注文に関する図５のＳ０１〜Ｓ１５と同様の処理の流れが、注文変更要求及びその回答という形で実行される。詳細については、説明を省略する。

尚、バックエンドシステム間のギャップが制約条件を異にする、例えば複数の日本企業の、ネットワークユニット間に存在する場合も、同様に本発明を適用することができることは言うまでも無い。この場合でも、中間データベース１ａ及びデータベース管理ツール１ｂにより、送信元ネットワークユニットＡのバックエンドシステム４ａと送信先ネットワークユニットＢのバックエンドシステム４ｂのギャップを吸収させることで、各々のバックエンドシステムへの修正を実施する事なく互いのバックエンドシステムを含めたリアルタイムでのデータ連携が可能になる。

図９は、本発明の他の実施例として、大規模な事業体及び複数パートナーＢ〜Ｎとした場合の企業間リアルタイムデータ連携システムの実施例であり、中間ＤＢを拡張して統合データベース群１とし、事業体単位にバックエンド連携サーバ３ａ〜３ｎを設置した例である。この実施例の場合は、図１の例で説明した実施例に、以下の機能を追加する事により実現可能となる。まず、連携システムとして、インターネットαを介して電子データを送受信するネットワークユニットＡ〜Ｎが接続可能に構成されている。中間データベース１ａのデータテーブル２００には、事業体識別コード及びバックエンドサーバＩＤを追加し、クロスリファレンステーブル３００にはバックエンドサーバＩＤ及び相手先識別コードを追加する。また、バックエンド連携システム３ａ〜３ｎ側に、自バックエンド連携サーバ監視対象の事業体識別コードによる絞り込み機能及びバックエンドサーバ毎の配信振分け機能を追加し、データベース管理ツール１ｂにはクロスリファレンステーブルにおけるバックエンドサーバＩＤ及び相手先識別コードに応じたコード変換機能を追加する。この実施例によれば、大規模な事業体及び複数パートナーＢ〜Ｎとした場合でも、送信先毎の様々な制約条件にフレキシブルに対応可能である。すなわち、制約条件にギャップがある各々のバックエンドシステムに修正を加える事なく、効率的に各企業間のリアルタイムでの双方向データ連携が可能となる。

本発明の一実施例になる企業間リアルタイムデータ連携システムの構成図と、データの流れを示す図である。本発明で使用するデータベース群のデータテーブル構成の例を示す図である。本発明で使用するデータベース群のクロスリファレンステーブル構成の例を示す図である。本発明の一実施例になるデータベース管理ツールのメニュー画面を示す図である。本発明の一実施例における処理手順を示すフローチャートである。本発明の一実施例における処理手順を示すフローチャートである。本発明の一実施例になるデータベース管理ツール画面を示す図である。本発明のデータベース管理ツールのデータテーブル検索画面に表示された、全件リストの例を示す図である。本発明のデータベース管理ツールのデータテーブル検索画面に表示された、個別案件の明細情報の表示例を示す図である。本発明のデータテーブルの一実施例である。本発明の拡張形の例を表す図である。

符号の説明

Ａ〜Ｎ…ネットワークユニット、
１…統合データベース群、
１ａ…データベース群、
１ｂ…データベース管理ツール、
２ａ，２ｂ…ウェブシステム(サーバ)、
３，３ａ〜３ｎ…バックエンド連携システム(サーバ)、
４ａ〜４ｎ…バックエンドシステム(サーバ)、
ａ…バックエンド更新用項目群、
ｂ…送受信データ格納用項目群、
ｃ…バックエンドステータス、
ｄ…コミュニケーションステータス、
ｅ…ａ及びｂの共用項目群、
ｆ…コード変換項目の変換キー、
ｇ…バックエンドシステムコード、
ｈ…送受信データコード、
Ｋ０１〜Ｋ０５…データベース管理ツールの機能、

Claims

制約条件を異にする複数のネットワークユニットがネットワークを介して双方向連携可能に接続される装置であって、前記各ネットワークユニットは、バックエンドシステムと連携に必要なフロントエンドシステムとを具備するものにおいて、
前記各ネットワークユニットは、前記フロントエンドシステムと前記バックエンドシステムの間に、連携先の制約条件を満足する情報を予め準備する手段を備えていることを特徴とする企業間リアルタイムデータ連携装置。
請求項１において、前記連携先の制約条件を満足する情報を予め準備する手段は、前記フロントエンドシステムと前記バックエンドシステムの間に位置する中間データベースと、該中間データベースの管理を行なう管理システムとを有し、
前記中間データベースは、送信元及び送信先のフロントエンドシステム間で送受信されるデータや、送信元及び送信先のバックエンドサーバへのデータ更新ステータス等を格納する為のデータテーブル群と、前記バックエンドシステムと前記ウェブサーバのデータ内容を関連づける為のクロスリファレンステーブル群とを備えていることを特徴とする企業間リアルタイムデータ連携装置。
請求項１において、前記連携先の制約条件を満足する情報を予め準備する手段は、前記フロントエンドシステムと前記バックエンドシステムの間に位置する中間データベースと、該中間データベースの管理を行なう管理システムとを有し、
前記中間データベースと前記管理システムにより、送信すべきデータレコードを送信先ネットワークユニットの制約条件を満たす形式で前記中間データベースにリアルタイムに登録すると共に、前記データレコードを自ネットワークユニットの制約条件を満たす形式で自バックエンドシステムに登録し、前記中間データベースに登録された情報を前記フロントエンドシステムから送信先ネットワークユニットに伝送する構成としたことを特徴とする企業間リアルタイムデータ連携装置。
請求項２または３において、前記中間データベースを連携制御用統合データベースと位置づけ、Ｎ対Ｎの双方向リアルタイムデータ連携装置としたことを特徴とする企業間リアルタイムデータ連携装置。
制約条件を異にする複数のネットワークユニットがネットワークを介して双方向連携可能に構成され、前記各ネットワークユニットはバックエンドシステムと連携に必要なフロントエンドシステムとを具備する、企業間リアルタイムデータ連携装置における連携方法であって、
連携先の制約条件を満足する情報を前記互いのバックエンドシステムの間に予め準備し、
前記準備された情報を前記フロントエンドシステムから送信先ネットワークユニットに伝送することを特徴とする企業間リアルタイムデータ連携方法。