このチュートリアルでは、NGSI-LD 内のサブスクリプションとレジストレーションの使用方法について説明し、NGSI-v2 と NGSI-LD の同等操作の類似点と相違点を強調します。このチュートリアルは、元のコンテキスト・プロバイダとサブスクリプションのチュートリアルに似ていますが、全体で NGSI-LD インターフェイスからの API 呼び出しを使用します。

このチュートリアルでは、全体で cUrl コマンドを使用していますが、 Postmanドキュメントとしても利用できます。

⚠️ 注: このチュートリアルは、システムを NGSI-LD に切り替えたりアップグレードしたりする NGSI-v2 開発者向けに設計されています。リンクト・データシステムを最初から構築する場合、または NGSI-v2 にまだ慣れていない場合は、 NGSI-LD 開発者向けチュートリアルのドキュメントを参照することをお勧めします。

リンクト・データのサブスクリプションとレジストレーション ¶

“Do not repeat after me words that you do not understand. Do not merely put on a mask of my ideas, for it will be an illusion and you will thereby deceive yourself.”

― Jiddu Krishnamurti

NGSI-LD サブスクリプションとレジストレーションは、スマート・リンクト・データ・ソリューション内のコンポーネントが相互にやり取りできるようにする基本的なメカニズムを提供します。

簡単な注意として、分散システム内では、サブスクリプションはサードパーティ・コンポーネントにコンテキスト・データの変更が発生したことを通知し (コンポーネントはさらにアクションを実行する必要があります) 、レジストレーションは Context Broker に別ソースからコンテキスト情報が利用可能であることを通知します。

これらの操作はどちらも、受信コンポーネントが受信したリクエストを完全に理解し、結果のペイロードを作成して解釈できることが必要です。ここでの NGSI-v2 と NGSI-LD の操作の違いはわずかですが、リンクト・データの概念の組み込みを容易にするためのマイナーな修正が行われたため、さまざまなコンポーネント間の規約がマイナー・アップデートを含むように変更されました。

在庫管理システム内のエンティティ ¶

リンクト・データ・エンティティ間のリレーションシップは、次のように定義されています。既存のデータに加えて、tweets 属性はコンテキスト・プロバイダ (Context Provider) によって提供されます。他のすべての点で、このモデルは以前のチュートリアルと同じです。

在庫管理フロントエンド ¶

シンプルな Node.js Express アプリケーションは、以前のチュートリアルで NGSI-LD を使用するように更新されました。モニタ・ページを使用して最近のリクエストのステータスを監視し、2つの Store ページを使用して商品を購入します。サービスが実行されると、これらのページには次の URL からアクセスできます :

イベント・モニタ¶

イベント・モニタは次の場所にあります: http://localhost:3000/app/monitor

FIWARE Monitor

Store 001¶

Store001 は次の場所にあります: http:/localhost:3000/app/store/urn:ngsi-ld:Building:store001

Store

Store 002¶

Store002 は次の場所にあります: http:/localhost:3000/app/store/urn:ngsi-ld:Building:store002

Store2

前提条件 ¶

Docker ¶

物事を単純にするために、両方のコンポーネントが Docker を使用して実行されます。Docker は、さまざまコンポーネントをそれぞれの環境に分離することを可能にするコンテナ・テクノロジです。

Windows に Docker をインストールするには、こちらの指示に従ってください
Mac に Docker をインストールするには、こちらの指示に従ってください
Linux に Docker をインストールするには、こちらの手順に従ってください

Docker Compose は、マルチコンテナ Docker アプリケーションを定義して実行するためのツールです。 YAML ファイルを使用して、アプリケーションに必要なサービスを設定します。これは、すべてのコンテナ・サービスを単一のコマンドで起動できることを意味します。Docker Compose は、Docker for Windows および Docker for Mac の一部としてデフォルトでインストールされますが、Linux ユーザはこちらにある手順に従う必要があります。

Cygwin ¶

簡単な bash スクリプトを使ってサービスを開始します。Windows ユーザは、Windows 上の Linux ディストリビューションに似たコマンドライン機能を提供するために cygwin をダウンロードするべきです。

アーキテクチャ ¶

デモ・スーパーマーケット・アプリケーションは、準拠している Context Broker と NGSI-LD の呼び出しを送受信します。 NGSI-LD インターフェースは、Orion Context Broker の実験バージョンで利用できるため、デモ・アプリケーションは1つの FIWARE コンポーネントのみを使用します。

現在、Orion Context Broker は、オープンソース MongoDB テクノロジに依存して、保持しているコンテキスト・データの永続性を維持しています。外部ソースからコンテキスト・データをリクエストするために、シンプルな Context Provider NGSI proxy も追加されました。コンテキストを視覚化し、対話するために、簡単な Express アプリケーションを追加します。

したがって、アーキテクチャは次の4つの要素で構成されます。

NGSI-LD を使ってリクエストを受け取る Orion Context Broker
基礎となる MongoDB データベース :
- データ・エンティティ、サブスクリプション、レジストレーションなどのコンテキスト・データ情報を保持するために Orion Context Broker によって使用されます
Context Provider NGSI は、次のことができます :
- NGSI-LD を使用してリクエストを受信します
- 独自の API を独自の形式で使用して、公開されているデータソースにリクエストを送信します
- コンテキスト・データを NGSI-lD 形式で NGSI-LD 形式で Orion Context Broker に返します
在庫管理フロントエンド は、次のことができます :
- ストア情報を表示
- 各ストアで購入できる製品を表示
- ユーザが製品を "購入" して在庫数を減らすことを許可

要素間のすべての対話は HTTP リクエストによって開始されるため、エンティティはコンテナ化され、公開されたポートから実行できます。

必要な設定情報は、関連する orion-ld.yml ファイルの services セクションで確認できます。以前のチュートリアルで説明しています。

起動 ¶

services Bash スクリプトを実行して、コマンドラインから初期化できます。以下のようにコマンドを実行して、リポジトリのクローンを作成して必要なイメージを作成してください :

git clone https://github.com/FIWARE/tutorials.LD-Subscriptions-Registrations.git
cd tutorials.LD-Subscriptions-Registrations
git checkout NGSI-v2

./services orion

注: クリーンアップして最初からやり直す場合は、次のコマンドで実行できます :
./services stop

コンポーネント間の相互作用 ¶

NGSI-LD でのサブスクリプションの使用 ¶

http:/localhost:3000/app/store/urn:ngsi-ld:Building:store001 に移動して、スーパーマーケットのデータを表示して操作します。

サブスクリプションを作成 (Store 1) - 低在庫 ¶

NGSI-LD サブスクリプションは、/ngsi-ld/v1/subscriptions/ エンドポイントを使用して、NGSI-v2 /v2/subscriptions エンドポイントと同様の方法で設定できます。ただし、ペイロード本体は少し異なります。まず、リンクト・データ @context は属性として、または Link ヘッダに存在する必要があります。@context がボディに配置されている場合、Context-Type ヘッダはペイロードが application/ld+json、つまり、リンクト・データと JSON であることを示す必要があります。提供された @context は、通知リクエスト (notification request) の一部として通知を行うときにも使用されます。

NGSI-LD サブスクリプション・リクエストの type は常に type=Subscription です。サブスクリプションの構造が変更されました。サブスクリプションを設定するとき、ペイロードに対する個別の subject セクションはなくなり、条件を監視およびトリガーするエンティティはサブスクリプションの description と同じレベルに設定されるようになりました。

condition.attrs は1つ上のレベルに移動し、watchedAttributes に名前が変更されました
condition.expression が1つ上のレベルに移動し、q に名前が変更されました

ボディの notification セクションには、サブスクリプションの条件が満たされると、影響を受けるすべての Shelf エンティティを含む POST リクエストが URL http://tutorial:3000/subscription/low-stock-store001 に送信されることが記載されています。notification.format=keyValues をリクエストして通知ペイロードを修正し、 notification.endpoint.accept=application/json を指定して通知ボディから @context を削除できるようになりました。 @context は失われず、単に Link ヘッダとして渡されます。要約すると、サブスクリプション内のすべてのフラグは、 Context Broker 自体への GET リクエストと同じように機能します。フラグが設定されていない場合、デフォルトで @context を含む完全な NGSI-LD レスポンスが返され、さらに制限を追加することでペイロードを削減および修正できます。

1 リクエスト:¶

curl -L -X POST 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \
-H 'Content-Type: application/ld+json' \
--data-raw '{
  "description": "Notify me of low stock in Store 001",
  "type": "Subscription",
  "entities": [{"type": "Shelf"}],
  "watchedAttributes": ["numberOfItems"],
  "q": "numberOfItems<10;locatedIn==urn:ngsi-ld:Building:store001",
  "notification": {
    "attributes": ["numberOfItems", "stocks", "locatedIn"],
    "format": "keyValues",
    "endpoint": {
      "uri": "http://tutorial:3000/subscription/low-stock-store001",
      "accept": "application/json"
    }
  },
   "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld"
}'

サブスクリプションを作成 (Store 2) - 低在庫 ¶

この2番目のリクエストは、別のエンドポイント (URL http://tutorial:3000/subscription/low-stock-store002) に通知を送信します。notification.format=normalized および notification.endpoint.accept=application/ld+json は、通知リクエストのボディで @context が渡され、ペイロードが展開されたエンティティで構成されることを保証します。

2 リクエスト:¶

curl -L -X POST 'http://localhost:1026/ngsi-ld/v1/subscriptions/' \
-H 'Content-Type: application/json' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--data-raw '{
  "description": "LD Notify me of low stock in Store 002",
  "type": "Subscription",
  "entities": [{"type": "Shelf"}],
  "watchedAttributes": ["numberOfItems"],
  "q": "numberOfItems<10;locatedIn==urn:ngsi-ld:Building:store002",
  "notification": {
    "attributes": ["numberOfItems", "stocks", "locatedIn"],
    "format": "normalized",
    "endpoint": {
      "uri": "http://tutorial:3000/subscription/low-stock-store002",
      "accept": "application/ld+json"
    }
  }
}'

サブスクリプションの詳細を取得 ¶

サブスクリプションの詳細は、/ngsi-ld/v1/subscriptions/ に GET リクエストを行うことで取得できます。すべてのサブスクリプション CRUD アクションは、以前と同じ HTTP 動詞に引き続きマップされます。Accept:application/json を追加すると、レスポンスボディから@context 要素が削除されます。

3 リクエスト:¶

curl -L -X GET 'http://localhost:1026/ngsi-ld/v1/subscriptions/'

レスポンス:¶

レスポンスは、システム内のサブスクリプションの詳細で構成されています。内部的にブローカーは長い名前を一貫して使用するため、q 属性内のパラメータは完全な URIs を使用するように拡張されました。2つのサブスクリプションによって提供されるペイロードの違いについては、以下で説明します。

[
    {
        "id": "urn:ngsi-ld:Subscription:5e62405ee232da3a07b5fa7f",
        "type": "Subscription",
        "description": "Notify me of low stock in Store 001",
        "entities": [
            {
                "type": "Shelf"
            }
        ],
        "watchedAttributes": [
            "numberOfItems"
        ],
        "q": "https://fiware.github.io/tutorials.Step-by-Step/schema/numberOfItems<10;https://fiware.github.io/tutorials.Step-by-Step/schema/locatedIn==urn:ngsi-ld:Building:store001",
        "notification": {
            "attributes": [
                "numberOfItems",
                "stocks",
                "locatedIn"
            ],
            "format": "keyValues",
            "endpoint": {
                "uri": "http://tutorial:3000/subscription/low-stock-store001",
                "accept": "application/json"
            }
        },
        "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld"
    },
    {
        "id": "urn:ngsi-ld:Subscription:5e624063e232da3a07b5fa80",
        "type": "Subscription",
        "description": "Notify me of low stock in Store 002",
        "entities": [
            {
                "type": "Shelf"
            }
        ],
        "watchedAttributes": [
            "numberOfItems"
        ],
        "q": "https://fiware.github.io/tutorials.Step-by-Step/schema/numberOfItems<10;https://fiware.github.io/tutorials.Step-by-Step/schema/locatedIn==urn:ngsi-ld:Building:store002",
        "notification": {
            "attributes": [
                "numberOfItems",
                "stocks",
                "locatedIn"
            ],
            "format": "keyValues",
            "endpoint": {
                "uri": "http://tutorial:3000/subscription/low-stock-store002",
                "accept": "application/json"
            }
        },
        "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld"
    }
]

サブスクリプション・イベントの取得 ¶

ブラウザで2つのタブを開きます。イベント・モニタ (http://localhost:3000/app/monitor) に移動して、サブスクリプションの起動時に受信されるペイロードを確認し、store001 (http:/localhost:3000/app/store/urn:ngsi-ld:Building:store001) 、在庫が10未満になるまでビールを購入します。在庫不足のメッセージが画面に表示されます。

low-stock

low-stock-store001 は、Store001 内の棚 (shelves) の商品が少なくなると発生します。サブスクリプションのペイロードは以下のようになります。

low-stock-json

ペイロード内のデータは、リクエストで指定された属性のキーと値のペアで構成されています。これは、サブスクリプションが format=keyValues 属性を使用して作成されたためです。endpoint.accept=application/json が設定されているため、 @context はペイロードのボディに存在しません。その結果、data 配列は v2/subscription/ ペイロードと非常によく似た形式で返されます。data 配列に加えて、subscriptionId は、通知がいつ起動されたかを説明する notifiedAt 要素とともにレスポンスに含まれます。

次に store002 (http:/localhost:3000/app/store/urn:ngsi-ld:Building:store002) に移動して、在庫が10未満になるまでビールを購入します。在庫不足のメッセージが再び画面に表示され、イベント・モニタ内でペイロードを確認できます。

low-stock-ld

2番目のサブスクリプションは、@context とともに正規化された完全な NGSI-LD ペイロードを渡すように設定されています。これは、サブスクリプション自体の中で format=normalized 属性を使用することと、endpoint.accept=application/ld +json を設定することで実現され、各エンティティとともに @context も渡されます。

NGSI-LD でのレジストレーションの使用 ¶

コンテキスト・レジストレーションを使用すると、エンティティ内の一部 (またはすべて) のデータを外部コンテキスト・プロバイダから提供できます。これは、NGSI-LD エンドポイントのサブセットにのみレスポンスする別のマイクロサービスである別の完全なコンテキスト・プロバイダである可能性があります。ただし、だれが何を提供するかについて作成されたコントラクトが必要です。

すべてのレジストレーションは、2つのタイプのいずれかに細分することができます。単一のコンテキスト・プロバイダがエンティティ全体のメンテナンスを担当する単純なレジストレーションと、属性が複数のコンテキスト・プロバイダに分散している部分的なレジストレーションです。単純なレジストレーションの場合、すべてのコンテキスト・リクエストが転送されます。

リクエスト	Context Broker でのアクション	コンテキスト・プロバイダでのアクション
GET	リクエストをコンテキスト・プロバイダに渡し、レスポンスを変更せずにプロキシします	内部で保持されているエンティティに基づく GET リクエストの結果で Context Broker にレスポンスします
PATCH	リクエストをコンテキスト・プロバイダに渡し、HTTP ステータス・コードをプロキシします	コンテキスト・プロバイダ内のエンティティを更新し、ステータス・コードで Context Broker にレスポンスします
DELETE	コンテキスト・プロバイダにリクエストを渡します	コンテキスト・プロバイダ内のエンティティを削除し、ステータス・コードで Context Broker にレスポンスします

事実上、すべての単純なレジストレーションは "このエンティティは別の場所に保持されています" と言っていますが、エンティティ・データは、この Context Broker へのリクエストを介してリクエストおよび変更できます。すべての Context Brokers は単純なレジストレーションをサポートする必要があります。実際、"エンティティの排他性" の概念がない、つまり、個々の broker にエンティティがバインドされていない大規模システムで動作する Context Brokers のフェデレーション・アレイの操作には、このような単純なレジストレーションが必要です。

部分レジストレーションの場合、状況はより複雑になります。

リクエスト	Context Broker でのアクション	コンテキスト・プロバイダでのアクション
GET	エンティティがローカルに存在すると仮定して、追加のプロキシされた属性のリクエストをコンテキスト・プロバイダに渡し、ローカルに保持されている属性とコンテキスト・プロバイダからの追加情報のレスポンスを連結します	内部で保持されているエンティティに基づく GET リクエストの結果で Context Broker にレスポンスします
PATCH	ローカルに保持されている属性を更新し、追加の属性の更新リクエストをコンテキスト・プロバイダに渡し、全体的な結果に応じて成功または部分的に成功の HTTP ステータス・コードを返します	コンテキスト・プロバイダ内に保持されているエンティティのリクエストされた属性を更新します。ステータス・コードで Context Broker にレスポンスします
DELETE	エンティティを削除する場合は、ローカル・インスタンス全体を削除してください。ローカルに保持されている属性を削除する場合は、それらを削除してください。コンテキスト・プロバイダに保持されている属性を削除する場合は、コンテキスト・プロバイダにリクエストを渡します	コンテキスト・プロバイダ内のエンティティ属性を削除し、ステータス・コードで Context Broker にレスポンスします

各部分レジストレーションは、"このエンティティの追加の拡張コンテキストは別の場所に保持されている" と述べています。エンティティ・データは、この Context Broker へのリクエストを介してリクエストおよび変更できます。この場合、エンティティ・データは個々の Context Broker に効果的にバインドされるため、大規模なフェデレーション環境で実行する場合は特別な処理が必要になる場合があります。ここで、フェデレーションのユースケースの特別なニーズをカバーすることは、このチュートリアルの目的ではありません。

Context Broker 内では、単一のエンティティが単純なレジストレーションと部分的なレジストレーションの両方に同時に参加できないことに注意してください。これは、エンティティ全体とそのエンティティの一部のみの両方がリモートで取得されることを意味し、これは無意味です。このような状況が要求された場合、Context Broker は 409 - Conflict HTTP response を返します。

また、エンティティが Context Broker 内にすでに存在する場合、エンティティの単純なレジストレーションは拒否され、エンティティ属性の部分レジストレーションは、Context Broker 内に存在する、またはすでに部分レジストレーションの対象となっている場合、拒否されます。後者は、datasetId を使用することで発生する可能性があります。

内部的に X-Forwarded-For ヘッダは、Context Broker A がエンティティを Context Broker B にレジストレーションし、 Context Broker B がエンティティを Context Broker C にレジストレーションし、Context Broker C がエンティティを Context Broker A にレジストレーションする循環依存関係を回避するために使用されます。ただし、X-Forwarded-For ヘッダは、クライアントにレスポンスする前に削除されます。

通常の操作では、NGSI-LD レスポンスは、複数のソースから照合されたデータが Context Broker 内に直接保持されているかどうか、または情報が外部から取得されたかどうかを公開しません。エラーが発生した場合 (タイムアウトなど) にのみ、HTTP ステータス・エラーコードにより、外部で保持されている情報を取得または修正できなかったことがわかります。

レジストレーションを作成 ¶

すべての NGSI-LD コンテキスト・プロバイダのレジストレーション・アクションは、/ngsi-ld/v1/csourceRegistrations/ エンドポイントで実行されます。標準の CRUD マッピングが適用されます。@context は、Link ヘッダとして、またはリクエストのボディ内で渡す必要があります。

リクエストのボディは、次の変更を加えた同等の NGSI-v2 に似ています:

NGSI-v2 dataProvided オブジェクトは、information という配列になりました
NGSI-v2 属性は、properties と relationships の個別の配列に分割されました
NGSI-v2 provider.urlが endpoint に移動しました

4 リクエスト:¶

curl -L -X POST 'http://localhost:1026/ngsi-ld/v1/csourceRegistrations/' \
-H 'Content-Type: application/json' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--data-raw ' {
    "type": "ContextSourceRegistration",
    "information": [
        {
            "entities": [
                {
                    "type": "Building",
                    "id": "urn:ngsi-ld:Building:store001"
                }
            ],
            "properties": [
                "tweets"
            ]
        }
    ],
    "endpoint": "http://tutorial:3000/static/tweets"
}'

注 properties は 1.1.1 NGSI-LD コア・コンテキストで定義されています。1.3.1 では、2つの別個の属性 (propertyNames と relationshipNames) に置き換えられる予定です。この変更は、GeoJSON-LD を完全にサポートするために行われました。Context Broker は、更新されたコア・コンテキストをサポートする場合とサポートしない場合があります。

レジストレーションの詳細を取得 ¶

レジストレーションの詳細を取得するには、GETリクエストを /ngsi-ld/v1/csourceRegistrations/ エンドポイントに送信し、 Link ヘッダの適切な JSON-LD コンテキストとフィルタリングするエンティティの type を指定します。

5 リクエスト:¶

curl -G -iX GET 'http://localhost:1026/ngsi-ld/v1/csourceRegistrations/' \
-H 'Accept: application/ld+json' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"'  \
-d 'type=Building'

レスポンス:¶

レスポンスはレジストレーションの詳細を返します。この場合、properties の短い名前が @context とともに返されています。

[
    {
        "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld",
        "id": "urn:ngsi-ld:ContextSourceRegistration:5e6242179c26be5aef9991d4",
        "type": "ContextSourceRegistration",
        "endpoint": "http://tutorial:3000/static/tweets",
        "information": [
            {
                "entities": [
                    {
                        "id": "urn:ngsi-ld:Building:store001",
                        "type": "Building"
                    }
                ],
                "properties": [
                    "tweets"
                ]
            }
        ]
    }
]

Store 1 から取得 ¶

レジストレーションが設定されると、要求されたエンティティがリクエストされると、追加のレジストレーション済みプロパティとリレーションシップが透過的に返されます。単純なレジストレーションの場合、エンティティ全体を取得するリクエストはレジストレーションされたエンドポイントにプロキシされます。部分的なレジストレーションの場合、プロパティとレジストレーションは Context Broker 内に保持されている既存のエンティティに追加されます。

6 リクエスト:¶

curl -iX GET 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json'

執筆時点では、フェデレーションされた、Scorpio Broker の場合、このリクエストはローカル・エンティティのみの取得を示していることに注意してください。レジストレーションから転送されたデータは、代わりに次の方法で取得する必要があります: /ngsi-ld/v1/entities/?id=urn:ngsi-ld:Building:store001

レスポンス:¶

レスポンスには、追加の tweets プロパティが含まれるようになりました。このプロパティは、 http://tutorial:3000/static/tweets/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001 から取得した値を返します。例えば、フォワーディング・エンドポイント

{
    "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld",
    "id": "urn:ngsi-ld:Building:store001",
    "type": "Building",
    "furniture": {
        "type": "Relationship",
        "object": [
            "urn:ngsi-ld:Shelf:unit001",
            "urn:ngsi-ld:Shelf:unit002",
            "urn:ngsi-ld:Shelf:unit003"
        ]
    },
    "address": {
        "type": "Property",
        "value": {
            "streetAddress": "Bornholmer Straße 65",
            "addressRegion": "Berlin",
            "addressLocality": "Prenzlauer Berg",
            "postalCode": "10439"
        },
        "verified": {
            "type": "Property",
            "value": true
        }
    },
    "name": {
        "type": "Property",
        "value": "Bösebrücke Einkauf"
    },
    "category": {
        "type": "Property",
        "value": "commercial"
    },
    "location": {
        "type": "GeoProperty",
        "value": {
            "type": "Point",
            "coordinates": [
                13.3986,
                52.5547
            ]
        }
    },
    "tweets": {
        "type": "Property",
        "value": [
            "It has great practical value – you can wrap it around you for warmth as you bound across the cold moons of Jaglan Beta;",
            "You can lie on it on the brilliant marble-sanded beaches of Santraginus V, inhaling the heady sea vapours;",
            "You can sleep under it beneath the stars which shine so redly on the desert world of Kakrafoon;",
            "Use it to sail a mini raft down the slow heavy river Moth;",
            "Wet it for use in hand-to-hand-combat;",
            "Wrap it round your head to ward off noxious fumes or to avoid the gaze of the Ravenous Bugblatter Beast of Traal  (a mindboggingly stupid animal, it assumes that if you can’t see it, it can’t see you – daft as a bush, but very, very ravenous);",
            "You can wave your towel in emergencies as a distress signal, and of course dry yourself off with it if it still seems to be clean enough."
        ]
    }
}

同じレスポンスデータは、スーパーマーケット・アプリケーション自体で確認できます。実際には、このデータは一連のリクエストを介して作成されています。 Context Broker は urn:ngsi-ld:Building:store001 データを担当しますが、他のソースから提供できる情報があるかどうかを確認します。私たちの場合、CSourceRegistration は、もう1つの属性が使用できることを示しています。次にブローカーはコンテキスト・プロバイダに tweets 情報をリクエストし、タイムリーにレスポンスする場合、 tweets 情報が結果のペイロードに追加されます。

スーパーマーケット・アプリケーションは、スーパーマーケット・アプリケーション自体の画面に受信データを表示します :

tweets-1

コンテキスト・プロバイダから直接取得¶

すべてのコンテキスト・プロバイダは、固定されたコントラクトに従う必要があります。少なくとも、 /ngsi-ld/v1/entities/<entity-id> GET リクエストのさまざまな種類にレスポンスできる必要があります。レジストレーションが特定のプロパティに制限されている場合、このリクエストにはクエリ文字列に attrs パラメータも含まれます。

コンテキスト・プロバイダのユースケースに応じて、JSON-LD @context を解釈できる必要がある場合とそうでない場合があります。この場合、リクエストは完全な tweets 属性を返すだけです。

レジストレーションされた属性を照会するときに、同じリクエストが Context Broker 自体によって行われます。

7 リクエスト:¶

curl -L -X GET 'http://localhost:3000/static/tweets/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001?attrs=tweets' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/ld+json'

レスポンス:¶

ご覧のように、@context はリクエストで返されています (Content-Type ヘッダが設定されているため) 。残りのレスポンスは、標準の NGSI-LD リクエストに似ています。

{
    "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld",
    "id": "urn:ngsi-ld:Building:store001",
    "type": "Building",
    "tweets": {
        "type": "Property",
        "value": [
            "It has great practical value – you can wrap it around you for warmth as you bound across the cold moons of Jaglan Beta;",
            "You can lie on it on the brilliant marble-sanded beaches of Santraginus V, inhaling the heady sea vapours;",
            "You can sleep under it beneath the stars which shine so redly on the desert world of Kakrafoon;",
            "Use it to sail a mini raft down the slow heavy river Moth;",
            "Wet it for use in hand-to-hand-combat;",
            "Wrap it round your head to ward off noxious fumes or to avoid the gaze of the Ravenous Bugblatter Beast of Traal  (a mindboggingly stupid animal, it assumes that if you can’t see it, it can’t see you – daft as a bush, but very, very ravenous);",
            "You can wave your towel in emergencies as a distress signal, and of course dry yourself off with it if it still seems to be clean enough."
        ]
    }
}

コンテキスト・プロバイダの直接更新¶

読み取り/書き込みインターフェースの場合、関連する ngsi-ld/v1/entities/<entity-id>/attrs エンドポイントに PATCH リクエストを行うことで、コンテキスト・データを修正することもできます。

8 リクエスト:¶

curl -L -X PATCH 'http://localhost:3000/static/tweets/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001/attrs' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json' \
--data-raw '{
  "tweets": {
    "type": "Property",
    "value": [
      "Space is big.",
      "You just won'\''t believe how vastly, hugely, mind-bogglingly big it is.",
      "I mean, you may think it'\''s a long way down the road to the chemist'\''s, but that'\''s just peanuts to space."
    ]
  }
}'

9 リクエスト:¶

レジストレーションされた属性が Context Broker からリクエストされた場合、 http://tutorial:3000/static/tweets/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001 から取得した更新された値を返します。例えば、フォワーディング・エンドポイント

curl -L -X GET 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001?attrs=tweets&options=keyValues' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"'

レスポンス:¶

これにより、前の PATCH リクエストで更新された値と一致するようにレスポンスが変更されます。

{
    "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld",
    "id": "urn:ngsi-ld:Building:store001",
    "type": "Building",
    "tweets": [
        "Space is big.",
        "You just won't believe how vastly, hugely, mind-bogglingly big it is.",
        "I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space."
    ]
}

コンテキスト・プロバイダは tweets 情報の提供を担当するため、コンテキスト・プロバイダの変更は常に Context Broker 自体へのリクエストに反映されます。スーパーマーケット・アプリケーションはコンテキストに関係なく Context Broker を呼び出しているため、更新された tweets データはスーパーマーケット・アプリケーション自体の画面に表示されます。

tweets-2

したがって、 Context Broker は、世界の現在の状態の完全な全体像を返すことができます。

フォワード更新 (Forwarded-update)¶

10 リクエスト:¶

Context Broker への PATCH リクエスト (ngsi-ld/v1/entities/<entity-id>/ または ngsi-ld/v1/entities/<entity-id>/attrs) は、レジストレーションが見つかった場合、レジストレーションされたコンテキスト・プロバイダに転送されます。したがって、副作用としてコンテキスト・プロバイダの状態を変更することが可能です。もちろん、すべてのコンテキスト・プロバイダが必ずしも読み書き可能であるとは限らないため、転送されたコンテキストの属性を変更しようとしても、完全に尊重されるとは限りません。

ただし、この場合、PATCH ngsi-ld/v1/entities/<entity-id> へのリクエストは、レジストレーションで見つかったレジストレーションされた各属性に対する、一連の ngsi-ld/v1/entities/<entity-id>/attrs リクエストとして正常に転送されます。

curl -L -X PATCH 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001/attrs/tweets' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json' \
--data-raw '{
  "type": "Property",
  "value": [
    "This must be Thursday",
    "I never could get the hang of Thursdays."
  ]
} '

11 リクエスト:¶

前の操作の結果は、GET リクエストを使用してエンティティ全体を取得することで確認できます。

curl -L -X GET 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:Building:store001?attrs=tweets&options=keyValues' \
-H 'Link: <https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
-H 'Content-Type: application/json'

レスポンス:¶

これにより、Context Broker に送信されてからコンテキスト・プロバイダのエンドポイントにフォワーディングされた前の PATCH リクエストで更新された値と一致するようにレスポンスが変更されます。

{
    "@context": "https://fiware.github.io/tutorials.Step-by-Step/tutorials-context.jsonld",
    "id": "urn:ngsi-ld:Building:store001",
    "type": "Building",
    "tweets": [
        "This must be Thursday",
        "I never could get the hang of Thursdays."
    ]
}

ご覧のように、更新された tweets データもスーパーマーケット・アプリケーション自体に表示されます :

tweets-3

イベント・モニタ¶

Store 001¶

Store 002¶

1 リクエスト:¶

2 リクエスト:¶

3 リクエスト:¶

レスポンス:¶

4 リクエスト:¶

5 リクエスト:¶

レスポンス:¶

6 リクエスト:¶

レスポンス:¶

コンテキスト・プロバイダから直接取得¶

7 リクエスト:¶

レスポンス:¶

コンテキスト・プロバイダの直接更新¶

8 リクエスト:¶

9 リクエスト:¶

レスポンス:¶

10 リクエスト:¶

11 リクエスト:¶

レスポンス:¶

License¶