6 EPCIS データの共有
6.5 コレオグラフィ・モデル：サプライチェーン全体のデータ共有
2つの取引会社の間だけでEPCIS情報を共有する場合、情報の流れはごく簡単である。すでにビジネス関係があるため、
2社の間でどのデータを共有し、どのクエリ・モードを使うかを取り決める。
たくさんの会社が関わる取引環境では、もう少し複雑な状況になる。それぞれの当事者が多くの会社と取引を交わし、そ の取引関係の1つ1つにEPCISデータの交換が求められる可能性がある。さらに、直接の取引関係のない他社との間に
も、EPCISデータの共有が必要になることがある。例えば、A社がB社に販売し、B社がC社に販売している場合、A社とC
社の間に直接の取引関係はなくても、サプライチェーンの全体を知るためには、A社とC社の間のEPCISデータの共有が 必要になる。
ここで役に立つのが、コンテンツとコレオグラフィを分けて 考えることである。コンテンツ とはEPCISデータである。どのビ ジネス・ステップに可視化が必要か、そのステップの遂行をどのEPCISイベントで記録するか、イベントにどんなデータを 持たせるかなどのコンテンツは、本書のこれまでの章で述べた方法に従って設計する(3 章、4 章、5 章)。そこでは、各ビ ジネス・ステップのWhat、When、Where、Why の情報を、正確にモデリングすることに焦点を当てる。その一方で、取引 会社の間では、いつ、どのようにデータを受け渡すかも決めなければならない。これをコレオグラフィと呼ぶ。
コレオグラフィで決めるのは、データをどこに置くか、何をトリガーにして当事者間でデータをやり取りするか、プッシュを使 うかプルを使うか、どのネットワーキング・テクノロジを使うかなどである。コンテンツをコレオグラフィから切り離すことで、
取引相手の広がりの拡大や縮小、テクノロジの進歩があった際にも、EPCISのコンテンツの設計を保ったまま、変化に適 応していくことができる。
コレオグラフィには、いろいろなやり方が考えられる。その多くは、大きく分けて次の3つのどれかに入る：
■ 中央集中型コレオグラフィ
：
このモデルでは、サプライチェーンの中のいくつもの当事者からのEPCISイベントを、共 有リポジトリに送る。サプライチェーン全体から情報を調べたいときは、共有リポジトリにクエリを出すだけでよい。■ 分散型クエリ・コレオグラフィ
：
このモデルでは、EPCISデータを取得した各当事者が、自分のリポジトリでそのデータ を保管する。サプライチェーン全体の情報を調べたいときは、それぞれのデータをリポジトリに保管している当事者を 全部調べ上げて、クエリを出さなければならない。■ 分散型プッシュ・コレオグラフィ
：
このモデルでは、EPCISデータを取得した各当事者が、自分のリポジトリでそのデー6.3 クエリ・モード：プル vs プッシュ
EPCISクエリを使って、EPCISリポジトリのイベント・データを、その情報を必要とするアプリケーションまたは取引相手
に受け渡す。このデータ受渡しは、下記のようにいくつかのかたちのトリガーで発生する。
■ プル
：
要求/応答のやり取りによる受渡し。アプリケーションまたは取引会社が、EPCISクエリ条件を指定した要求を、EPCISリポジトリに出し、EPCISリポジトリが、その条件に一致するEPCISイベントの情報で応答する。
■ プッシュ
：
片方向のメッセージによる受渡し。データが必要なアプリケーションまたは取引相手に対して、EPCISリ ポジトリの方から、EPCISイベントの情報を送り付ける。この場合、さらに2つのかたちに分かれる：□ 事前取決め：送り手と受け手の各当事者が、EPCIS標準の範囲にない何かのやり方で、どのデータをどんな 条件のときに受け側に送るかを、事前に取り決めておく。それに従って、送り手が自身で判断した時点にイベ ント・データを送る。
□ サブスクリプション
：
受け手が、送り手に継続クエリ を送って、継続的に情報を必要とすることを伝える。継続 クエリには、“プル”の場合と同じようにEPCISクエリ条件を入れるとともに、イベント・データを送るトリガーにな る条件を添える。トリガー条件としては、定期スケジュール(例えば、毎日午前3時)のほか、何らかのトリガー・イベントを指定できる。トリガー条件が発現するごとに、送り側がクエリ条件を評価して、条件に一致する新し いイベント(前回のトリガー以降のもの)を送る。
“プッシュ”の2つの方法は、どちらも送り手から受け手に一方向の通信でEPCISイベントを送るが、事前取決めの形式で は、いつどのデータを送るかが送り手ですべて決まってしまっているのに対して、サブスクリプションの形式では、継続ク エリを通して、受け手が随時にニーズを伝えることができる点に違いがある。なお、6.7 節で述べるように、どの方法 (“プッシュ”と“プル”)も、最終的には送り手に、どのデータを送るかの決定権がある。
EPCISデータを収集するビジネス・プロセスを設計する際には、それぞれの形式のクエリを、各々の条件に応じて使い
分けることになる。一般的に言って、“プッシュ”は、EPCISデータの収集の要求が、繰り返し起こることが前もって分かる 場合に使い、“プル”は、例外的な状況など、前もって分からないデータ収集の要求があるときに使う。それぞれの方法を、
どんな状況で使うかの例を下の表に挙げている：
表6-3 ビジネス・シナリオと、それに対応するEPCISクエリ・モード
ビジネス・シナリオ クエリ・モード クエリ・モードの使い方
GTIN X、ロットYがリコールになり、製造元XYZで、
小売業者ABCに納入した製品に、対象品がないかを 調べる必要がある。
プル 製造元XYZから、ABC社のEPCISリポジトリに要求を送り、What
ディメンションにGTIN X、ロットYが入っていて、ビジネス・ステップ が“receiving”のイベントすべてを問い合わせる。
地域の規則により、卸売業者PQRからABC薬局に 医薬品を納入すると、各シリアル番号の情報を、出荷 から1時間以内に併せて送ることが求められる。
事前取決めによる プッシュ
PQR社とABC薬局が事前に取決めを交わし、さらにPQR社が データのメッセージを送るアドレスを、ABC薬局から連絡しておく。
PQR社は、ABC薬局向けに医薬品を出荷するごとに、EPCISリポ ジトリからABC薬局にメッセージを送って、What ディメンションにそ の医薬品のSGTINを持ち、ビジネス・ステップが“shipping”の EPCISイベントの情報を送り渡す。
小売業者ABCは、危険物質を含んだ製品Xの出荷 が、製造元XYZからあるときには、荷の特殊な取扱 いに備えるために通知を必要とする。
サブスクリプション によるプッシュ
小売業者ABCから継続クエリを出し、その中で、What ディメンショ ンにXのGTINを持ち、ビジネス・ステップが“shipping”で、デス ティネーション・リストに自社のGLNが入った全EPCISイベントを検 索する条件と、毎日1回実行するトリガーを指定する。
6.4 EPCIS クエリ制御インタフェース
EPCIS標準は、EPCISアクセス・アプリケーションまたは取引会社が、EPCISリポジトリとやり取りする標準のインタフェー
スを用意している。このインタフェースを通して、アプリケーションや取引会社は、“プル”のクエリの発行や、“プッシュ”のサ ブスクリプションの設定をはじめ、各種の操作ができる。
このインタフェースから実施できる操作を、下の表にまとめている：
表6-4 EPCISクエリ制御インタフェースの処理
処 理 説 明 要求の内容(EPCISアクセ
ス・アプリケーションまたは取 引会社から)
応答の内容(EPCISリポジトリ)
Poll “プル”のクエリの実行 EPCISクエリ条件 クエリ条件に一致するEPCISイベント
Subscribe “プッシュ”のサブスクリプショ ンの設定
サブスクリプションID (要求 側が指定)、EPCISクエリ条 件、トリガー条件、継続クエリ の結果を送るアドレス
確認応答
その後EPCISリポジトリは、トリガーが起こるごと に、条件に一致するイベントを指定のアドレスに送 る。
Unsubscribe 設定してあるサブスクリプショ ンの解除
サブスクリプションの設定に
使ったサブスクリプションID 確認応答 getSubscriptionIDs 現在有効なサブスクリプション
の問い合わせ
[添付情報なし] 要求側から設定してあるサブスクリプションのサブス
クリプションIDのリスト getStandardVersion EPCISリポジトリが対応して
いる、EPCIS標準のバージョ ンの問い合わせ
[添付情報なし] リポジトリの対応バージョンに応じて1.0または 1.1
getVendorVersion EPCISリポジトリの実装につ いての、ベンダー固有の情報 の問い合わせ
[添付情報なし] EPCISリポジトリのベンダーが設定している文字列
getQueryNames EPCISリポジトリが対応して いる、EPCISクエリのタイプの 問い合わせ
[添付情報なし] EPCISリポジトリが対応しているクエリのリスト。EP CIS標準で定義されているSimpleEventQuery は必ずあり、SimpleMasterDataQueryを含むこ ともある。ほかにベンダー固有のクエリを持つことも ある。
EPCIS標準は、EPCISクエリ・インタフェースで使うそれぞれの要求と応答のメッセージについて、XML表現を定義してい
る。
6.5 コレオグラフィ・モデル：サプライチェーン全体のデータ共有
2つの取引会社の間だけでEPCIS情報を共有する場合、情報の流れはごく簡単である。すでにビジネス関係があるため、
2社の間でどのデータを共有し、どのクエリ・モードを使うかを取り決める。
たくさんの会社が関わる取引環境では、もう少し複雑な状況になる。それぞれの当事者が多くの会社と取引を交わし、そ の取引関係の1つ1つにEPCISデータの交換が求められる可能性がある。さらに、直接の取引関係のない他社との間に
も、EPCISデータの共有が必要になることがある。例えば、A社がB社に販売し、B社がC社に販売している場合、A社とC
社の間に直接の取引関係はなくても、サプライチェーンの全体を知るためには、A社とC社の間のEPCISデータの共有が 必要になる。
ここで役に立つのが、コンテンツとコレオグラフィを分けて 考えることである。コンテンツ とはEPCISデータである。どのビ ジネス・ステップに可視化が必要か、そのステップの遂行をどのEPCISイベントで記録するか、イベントにどんなデータを 持たせるかなどのコンテンツは、本書のこれまでの章で述べた方法に従って設計する(3 章、4 章、5 章)。そこでは、各ビ ジネス・ステップのWhat、When、Where、Why の情報を、正確にモデリングすることに焦点を当てる。その一方で、取引 会社の間では、いつ、どのようにデータを受け渡すかも決めなければならない。これをコレオグラフィと呼ぶ。
コレオグラフィで決めるのは、データをどこに置くか、何をトリガーにして当事者間でデータをやり取りするか、プッシュを使 うかプルを使うか、どのネットワーキング・テクノロジを使うかなどである。コンテンツをコレオグラフィから切り離すことで、
取引相手の広がりの拡大や縮小、テクノロジの進歩があった際にも、EPCISのコンテンツの設計を保ったまま、変化に適 応していくことができる。
コレオグラフィには、いろいろなやり方が考えられる。その多くは、大きく分けて次の3つのどれかに入る：
■ 中央集中型コレオグラフィ
：
このモデルでは、サプライチェーンの中のいくつもの当事者からのEPCISイベントを、共 有リポジトリに送る。サプライチェーン全体から情報を調べたいときは、共有リポジトリにクエリを出すだけでよい。■ 分散型クエリ・コレオグラフィ
：
このモデルでは、EPCISデータを取得した各当事者が、自分のリポジトリでそのデータ を保管する。サプライチェーン全体の情報を調べたいときは、それぞれのデータをリポジトリに保管している当事者を 全部調べ上げて、クエリを出さなければならない。6.3 クエリ・モード：プル vs プッシュ
EPCISクエリを使って、EPCISリポジトリのイベント・データを、その情報を必要とするアプリケーションまたは取引相手
に受け渡す。このデータ受渡しは、下記のようにいくつかのかたちのトリガーで発生する。
■ プル
：
要求/応答のやり取りによる受渡し。アプリケーションまたは取引会社が、EPCISクエリ条件を指定した要求を、EPCISリポジトリに出し、EPCISリポジトリが、その条件に一致するEPCISイベントの情報で応答する。
■ プッシュ
：
片方向のメッセージによる受渡し。データが必要なアプリケーションまたは取引相手に対して、EPCISリ ポジトリの方から、EPCISイベントの情報を送り付ける。この場合、さらに2つのかたちに分かれる：□ 事前取決め：送り手と受け手の各当事者が、EPCIS標準の範囲にない何かのやり方で、どのデータをどんな 条件のときに受け側に送るかを、事前に取り決めておく。それに従って、送り手が自身で判断した時点にイベ ント・データを送る。
□ サブスクリプション
：
受け手が、送り手に継続クエリ を送って、継続的に情報を必要とすることを伝える。継続 クエリには、“プル”の場合と同じようにEPCISクエリ条件を入れるとともに、イベント・データを送るトリガーにな る条件を添える。トリガー条件としては、定期スケジュール(例えば、毎日午前3時)のほか、何らかのトリガー・イベントを指定できる。トリガー条件が発現するごとに、送り側がクエリ条件を評価して、条件に一致する新し いイベント(前回のトリガー以降のもの)を送る。
“プッシュ”の2つの方法は、どちらも送り手から受け手に一方向の通信でEPCISイベントを送るが、事前取決めの形式で は、いつどのデータを送るかが送り手ですべて決まってしまっているのに対して、サブスクリプションの形式では、継続ク エリを通して、受け手が随時にニーズを伝えることができる点に違いがある。なお、6.7 節で述べるように、どの方法 (“プッシュ”と“プル”)も、最終的には送り手に、どのデータを送るかの決定権がある。
EPCISデータを収集するビジネス・プロセスを設計する際には、それぞれの形式のクエリを、各々の条件に応じて使い
分けることになる。一般的に言って、“プッシュ”は、EPCISデータの収集の要求が、繰り返し起こることが前もって分かる 場合に使い、“プル”は、例外的な状況など、前もって分からないデータ収集の要求があるときに使う。それぞれの方法を、
どんな状況で使うかの例を下の表に挙げている：
表6-3 ビジネス・シナリオと、それに対応するEPCISクエリ・モード
ビジネス・シナリオ クエリ・モード クエリ・モードの使い方
GTIN X、ロットYがリコールになり、製造元XYZで、
小売業者ABCに納入した製品に、対象品がないかを 調べる必要がある。
プル 製造元XYZから、ABC社のEPCISリポジトリに要求を送り、What
ディメンションにGTIN X、ロットYが入っていて、ビジネス・ステップ が“receiving”のイベントすべてを問い合わせる。
地域の規則により、卸売業者PQRからABC薬局に 医薬品を納入すると、各シリアル番号の情報を、出荷 から1時間以内に併せて送ることが求められる。
事前取決めによる プッシュ
PQR社とABC薬局が事前に取決めを交わし、さらにPQR社が データのメッセージを送るアドレスを、ABC薬局から連絡しておく。
PQR社は、ABC薬局向けに医薬品を出荷するごとに、EPCISリポ ジトリからABC薬局にメッセージを送って、What ディメンションにそ の医薬品のSGTINを持ち、ビジネス・ステップが“shipping”の EPCISイベントの情報を送り渡す。
小売業者ABCは、危険物質を含んだ製品Xの出荷 が、製造元XYZからあるときには、荷の特殊な取扱 いに備えるために通知を必要とする。
サブスクリプション によるプッシュ
小売業者ABCから継続クエリを出し、その中で、What ディメンショ ンにXのGTINを持ち、ビジネス・ステップが“shipping”で、デス ティネーション・リストに自社のGLNが入った全EPCISイベントを検 索する条件と、毎日1回実行するトリガーを指定する。
6.4 EPCIS クエリ制御インタフェース
EPCIS標準は、EPCISアクセス・アプリケーションまたは取引会社が、EPCISリポジトリとやり取りする標準のインタフェー
スを用意している。このインタフェースを通して、アプリケーションや取引会社は、“プル”のクエリの発行や、“プッシュ”のサ ブスクリプションの設定をはじめ、各種の操作ができる。
このインタフェースから実施できる操作を、下の表にまとめている：