(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-06-06
(45)【発行日】2022-06-14
(54)【発明の名称】データ連携システム及びデータ連携方法
(51)【国際特許分類】
H04L 67/06 20220101AFI20220607BHJP
G06F 16/174 20190101ALI20220607BHJP
【FI】
H04L67/06
G06F16/174
(21)【出願番号】P 2021071435
(22)【出願日】2021-03-04
【審査請求日】2021-03-04
【早期審査対象出願】
(73)【特許権者】
【識別番号】519355688
【氏名又は名称】株式会社ストラテジット
(72)【発明者】
【氏名】ジェームズ ジョシュア エンリーケ
【審査官】今川 悟
(56)【参考文献】
【文献】特開2012-174205(JP,A)
【文献】特開2009-146226(JP,A)
【文献】米国特許出願公開第2020/0081586(US,A1)
【文献】国際公開第2015/011840(WO,A1)
【文献】特開2019-091477(JP,A)
【文献】特開2002-297421(JP,A)
【文献】特開平08-328975(JP,A)
【文献】特開2004-280847(JP,A)
【文献】松島 浩道 HIROMICHI MATSUSHIMA,Gitバージョン管理 初版 Git is a distributed version control system.,第1版,日本,SBクリエイティブ株式会社 小川 淳,2014年11月04日,第99頁
(58)【調査した分野】(Int.Cl.,DB名)
H04L 67/06
G06F 16/174
(57)【特許請求の範囲】
【請求項1】
各システムのうち任意の一つを連携元システムと定義し、連携元システム以外の任意のシステムを連携先システムと定義し、前記連携元システムのデータをマスターデータと定義し、
前記マスターデータのデータ変更があった際に、前記データ変更に関する情報を記憶する記憶装置と、
連携先システムと連携元システムとの所定の組みを参照し、前記連携先システムに前記連携元システムのデータに対応する変更すべき情報が存在するかを参照し、前記連携先システムに対応する変更すべき情報が存在する場合のみ、前記連携先システムに前記データ変更に関する情報を更新するように指定するURLを前記連携先システムへと発行し、直接的に前記連携先システムの情報を変更するデータ連携装置と、を有するデータ連携システム。
【請求項6】
各システムのうち任意の一つを連携元システムと定義し、連携元システム以外の任意のシステムを連携先システムと定義し、前記連携元システムのデータをマスターデータと定義し、
前記マスターデータのデータ変更があった際に、前記データ変更に関する情報を記憶する記憶ステップと、
連携先システムと連携元システムとの所定の組みを参照するステップと、
前記連携先システムに前記連携元システムのデータに対応する変更すべき情報が存在するかを参照するステップと、
前記連携先システムに対応する変更すべき情報が存在する場合のみ、前記連携先システムに前記データ変更に関する情報を更新するように指定するURLを前記連携先システムへと発行し、直接的に前記連携先システムの情報を変更するデータ連携ステップと、を有するデータ連携方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ連携システムに関するものである。
【背景技術】
【0002】
データ連携システムの一例が、特開2000-339204公報(特許文献1)に開示されている。特許文献1には、他システムで使用するファイル内の追加データを自システムのデータベース形式の追加データに変換する第1の変換手段と、前記自システムのデータベース形式の追加データにより自システムのデータベースを正規化を維持したまま更新する第2の変換手段と、を有することを特徴とする他システムで使用するファイル内の追加データにより自システムのデータベースを更新する方式が公開されている。
【0003】
並びに、従来技術について、連携元のシステムでマスターデータの変更があった際に、それをCSVの出力とアップロードで更新する方法が知られている。
【0004】
並びに、従来技術について、マスターデータを全般的に中間の連携アプリにて格納し、変更があった際に中間アプリの情報と連携先を更新する方法が知られている。
【先行技術文献】
【特許文献】
【0005】
【発明の概要】
【発明が解決しようとする課題】
【0006】
従来技術では、どのサービスがマスターの正となっているのかがわからないため、データが一方で更新されたらそれを複数の箇所でアップデートする必要があり、データの不整合が起こりやすい。マスターデータの一意性を担保すると共に、データ管理の一元化を図る必要がある。
【課題を解決するための手段】
【0007】
本開示は、各システムのうち任意の一つを連携元システムと定義し、連携元システム以外の任意のシステムを連携先システムと定義し、前記連携元システムのデータをマスターデータと定義し、前記マスターデータのデータ変更があった際に、前記データ変更に関する情報を記憶する記憶装置と、連携先システムと連携元システムとの所定の組みを参照し、前記連携先システムに前記連携元システムのデータに対応する変更すべき情報が存在するかを参照し、前記連携先システムに対応する変更すべき情報が存在する場合のみ、前記連携先システムに前記データ変更に関する情報を更新するように指定するURLを前記連携先システムへと発行し、直接的に前記連携先システムの情報を変更するデータ連携装置と、を有するデータ連携システムを提供する。
【発明の効果】
【0008】
本構成では、連携元と連携先のサービスのそれぞれのデータの内部IDと、HTTPにて通知を行うシステムを使用することで、リアルタイム性が担保されているデータ同期システムが構築可能である。
【0009】
データ連携システムのさらなる特徴と利点は、実施形態についての以下の記載から明確となる。
【発明を実施するための最良の形態】
【0010】
本発明による構成は、連携元システムAのユーザーが中間アプリ(MasterHub)で連携元システムと連携先システムの認証処理を行う。
【0011】
連携元システムと連携先システムともに認証と認可処理を行った後に、HTTP似て通知を行う仕組みを設定する(一般的にWebhookと呼ばれるもの)。
【0012】
連携元システムのマスターデータを連携先システムのマスターデータを同期する。中間アプリにて決められた条件(例えば名称、番号、等々)で一致したものは同じデータとみなして、中間アプリにて紐付け情報を保存する。
【0013】
連携元システムと連携先システムのマスターデータが同期され、紐付け情報が生成され中間アプリにて格納された後に、連携元システムからの変更を永続的に連携先システムに反映する。
【0014】
連携元システムのマスターデータで変更があった際に、中間アプリにて保持している紐付け情報を使用して、すでに連携済みかどうかを判断する。
【0015】
紐付け情報がすでに存在するものに関しては新たに重複して作成せずに、連携先のマスターデータを更新する。
【0016】
紐付け情報が存在しない場合は、新たに紐付け情報を中間アプリにて作成し、連携元システムのデータを連携先システムのマスターデータに反映させる(新規登録する)。
【0017】
連携元システムで削除が行われた場合、中間アプリにて格納されている紐付け情報を元に、連携先システムの該当するデータを発見し、削除する。
【0018】
複数の連携先が存在する場合、上記の手順を連携先ごとに行い、複数のシステム間でデータの一意性を担保し、マスターデータを完全に同期する。
【0019】
連携元システムから連携先システへデータ変更・追加・削除の変更を行う際に、中間アプリで内部的な識別子のみを格納することで、中間アプリと連携先アプリ間でデータの不整合を起こさず、且つセキュリティー性を担保する(中間アプリで貴重な情報を格納せず、ユーザーのデータが漏洩されることを防ぐ)。
以下、上記において説明したデータ連携システムの概要について説明する。
【0020】
各システムのうち任意の一つを連携元システムと定義し、連携元システム以外の任意のシステムを連携先システムと定義し、前記連携元システムのデータをマスターデータと定義し、前記マスターデータのデータ変更があった際に、前記データ変更に関する情報を記憶する記憶装置と、連携先システムと連携元システムとの所定の組みを参照し、前記連携先システムに前記連携元システムのデータに対応する変更すべき情報が存在するかを参照し、前記連携先システムに対応する変更すべき情報が存在する場合のみ、前記連携先システムに前記データ変更に関する情報を更新するように指定するURLを前記連携先システムへと発行し、直接的に前記連携先システムの情報を変更するデータ連携装置と、を有するデータ連携システム。
【0021】
本構成では、連携元と連携先のサービスのそれぞれのデータの内部IDと、HTTPにて通知を行うシステムとを使用することで、リアルタイム性が担保されているデータ同期システムが構築可能である。
【0022】
また、マスターデータの正となっているシステムで更新があった際に連携先で更新若しくは新規登録の処理を行い、内部IDで存在するかどうかを確認しているため、データの重複を最低限に減らすことができる。
【0023】
本構成では、連携先のサービスを複数で構成し、一連のサービス郡としてマルチ連携を行っても良い。
【0024】
連携元の内部IDを格納することで、複数のアプリに渡ってデータの一意性を担保することができる。
【0025】
連携元システムと連携先システムとのデータのうち、所定の値が一致するデータの組みを紐付け情報として格納する中間アプリケーションを更に備える、上述のデータ連携システム。
【0026】
本構成では、連携元システムと連携先システムのマスターデータが同期され、紐付け情報が生成され中間アプリにて格納された後に、連携元システムからの変更を永続的に連携先システムに反映することができる。
【0027】
紐付け情報が存在する条件では、連携先システムのデータを更新するようにURLを発行する、上述のデータ連携システム。
【0028】
紐付け情報が存在しない条件では、連携元システムのデータ変更の内容を連携先システムのデータに新規登録するように指定するURLを発行する、上述のデータ連携システム。
【0029】
紐付け情報が存在する条件で、連携元システムでデータの削除が行われた場合、中間アプリケーションにて格納されている紐付け情報を元に、連携先システムの紐付けされたデータを発見し、データを削除するように指定するURLを発行する、上述のデータ連携システム。
【0030】
本構成では、中間アプリで貴重な情報を格納せず、ユーザーのデータが漏洩されることを防ぐことができる。
【0031】
本構成では、システムだけではなく、データ連携方法としても、当然に発明として保護される。
【0032】
本開示に係るデータ連携システムは、上述した各効果のうち、少なくとも1つを奏することができればよい。
【要約】
【課題】従来技術として、連携元のシステムでマスターデータの変更があった際に、それをCSVの出力とアップロードで更新する方法が知られている。しかしながら、データが一方で更新されたらそれを複数の箇所でアップデートする必要があり、データの不整合が起こりやすい。
【解決手段】本開示は、連携先システムにデータ変更に関する情報を更新するように指定するURLを連携先システムへと発行し、直接的に連携先システムの情報を変更するデータ連携システムを提供する。
【選択図】なし