CirculeID

API & integration

ここにあるどれも、二つ目の入力先にはなりません

仕様のマスターは貴社の PLM、取引のマスターは貴社の ERP のままです。パスポートはそれらに対するビューであり、両者が持てない2つのもの — アクセスポリシーと各主張の裏づけ — を付け加えます。

プロトコル
HTTPS上のREST
プッシュ
署名付きWebhook
マスターデータ
貴社のものであり続けます

Definition

パスポート基盤はERPやPLMとどう連携しますか。

置き換えるのではなく、その上に載ります。仕様はPLMに、取引はERPに、フットプリントの計算は会計ツールに残ります。データはREST API、定期エクスポート、サプライヤーからの提出を通じてパスポートへ流れ込み、パスポートが変わればWebhookが貴社システムに通知します。

The part most integration plans underestimate is the third input. Tier-two composition and certification data usually exists in none of your systems, because until now nothing required you to hold it.

責務

統合後、どのシステムが何を担うか

この表を最初に合意しておくことが、6週間後にマスターデータの重複をめぐって揉めるのを防ぎます。
パスポート連携後の、データ区分ごとのマスターとなるシステム
DataSystem of recordWhat CirculeID adds
Product specificationPLMThe passport projection and its required-field gap report
Transactions and batchesERPBatch identity bound to a resolvable passport
Carbon footprintLCA or carbon accounting toolThe figure held against the product with its methodology
Supplier evidenceThe supplierSigned credentials, so the claim carries its author
Supply chain eventsWMS, MES and logistics partnersOne EPCIS 2.0 history, queryable by object
Access policyCirculeIDWho sees which field, evaluated at resolution time

インターフェース

データの流れ

  • REST API

    パスポート、イベント、クレデンシャルにはHTTPS上のJSONを用い、キーは環境ごとに限定します。

  • 定期インポート

    外部へ通信できないシステム向けに、貴社側で形を変えるのではなく、受信時に対応づけます。

  • サプライヤーからの提出

    貴社が保有していないデータのための経路です。貴社が転記するのではなく、サプライヤーが署名します。

  • 署名付きWebhook

    パスポート、イベント、クレデンシャルの変更を貴社システムへ送信し、バックオフを伴って再試行します。

  • 項目の対応づけ

    貴社の項目の慣行を標準モデルに一度対応づけ、以降はインポートごとに適用します。

  • 変更履歴

    重要な変更は日付付きのイベントとして記録されるため、二度の読み取り結果を突き合わせられます。

手順

現実的な連携の順序

この順序で進めることが計画を誠実に保ちます。第三段階が律速であり、他に依存しないからです。
  1. 01

    マスターとなるシステムを確定する

    マッピングを書き始める前に、どのシステムがどのデータ区分を所有するかを決めてください。ここを飛ばすと、マスターデータの重複が生まれます。

  2. 02

    一つの製品グループを対応づける

    実際のエクスポートを取り込み、ギャップレポートをご確認ください。委任法令が求めていて、現時点で誰も保有していない項目が分かります。

  3. 03

    サプライヤーの登録を始める

    直ちに、並行して着手してください。ここが全体の律速であり、技術というより関係構築の作業です。

  4. 04

    コールバックを接続する

    貴社システムをパスポートとクレデンシャルの変更に購読させれば、下流の処理はポーリングではなく反応で動きます。

回答

よくある質問

製品データのマスターはどのシステムのままですか。

貴社のものです。仕様のマスターは PLM、取引のマスターは ERP、フットプリント計算のマスターは貴社のカーボン会計ツールのままです。CirculeID が保持するのはパスポート — それらのシステムを束ね、アクセス制御と裏づけを備えたビュー — であり、基礎データを二重に維持する場所にはなりません。

データは実際どのように入ってきますか。

3つの方法があり、通常は組み合わせます。外部呼び出しが可能なシステム向けの REST API、それができないシステム向けのスケジュール実行エクスポート、そして貴社がまったく保有していないデータのためのサプライヤー提出です。3つ目が通常は作業の大半を占めます。二次サプライヤーの組成データは、貴社のどのシステムにもまず存在しないからです。

元データが変更された場合はどうなりますか。

パスポートは更新されます。組成の訂正や新たな認証など変更が重要な場合は、以前の値を黙って上書きするのではなく日付付きのイベントとして記録されるため、昨年読み取ったパスポートと今年読み取ったパスポートを突き合わせられます。

既製のコネクタはありますか。

主要なERPおよびPLMについては用意しています。ただしマッピングを不要にするのではなく短縮するものです。導入ごとに独自の項目慣習と回避策の歴史があります。コネクタは、マッピングの議論を省く手段ではなく、その出発点とお考えください。

何かが変わったことを、当社のシステムはどう知りますか。

Webhook。パスポート、イベント、クレデンシャルの変更は署名付きコールバックを送出し、貴社システムはこれを購読します。これにより下流の処理はポーリングなしで新しいサプライヤークレデンシャルに反応できます。配信はバックオフを伴って再試行され、失敗ログは黙殺されず可視化されます。

Next step

PLMのエクスポートを一つお持ちください

対応づけを行い、貴社の製品グループについてギャップレポートを作成し、作業が実際にどこにあるかを現実的にお示しします。

Index