Orion Context Provider 查詢多個實體

Question

稅務信息系統包含有關該市每個公民的所有稅務信息。

遵循 FIWARE 原則，消費者向 Orion 查詢實體（公民）稅務信息，並將請求轉發給上下文提供者（即：TaxInformationSystem）似乎是有意義的。

Query citizen X tax information -> Orion -> TaxInformationSystem_CP

根據文檔，上下文提供者可以將自己注冊為特定屬性的來源。 例如，這可以使這項工作：

http://{{orion}}/v2/entities/urn:citizenID/attrs/name/tax

但是，這似乎要求每個公民都注冊為一個實體，因此稅務信息系統應該注冊多次（每個公民一個）。 （還有居住信息系統、健康信息系統，還有……）

"entities": [
  {
    "id" : "citizenID",      //one per citizen ???
    "type": "taxInformation"
  }
],

至少，這似乎是很多不必要/多余的工作。

閱讀更多后， 似乎尚未實施/支持任何解決方法

• 似乎我不能使用查詢參數http://{{orion}}/v2/entities/tax?citizen=X ，因為它們沒有轉發給 CP
• 如果沒有先明確創建實體，似乎我無法查詢任何公民稅http://{{orion}}/v2/entities/X/tax
• 似乎我無法設置idPattern （目前僅。*支持），因為它會返回所有公民稅，因為經紀人沒有轉發請求，也沒有將實體過濾到 CP
• 既不是 typePattern

（IIUC， isPattern現在似乎已棄用，取而代之的是 idPattern/typePattern）

難道我做錯了什么？ 每個公民注冊一次是 go 的唯一途徑嗎？

Answer 1

在 FIWARE 中，以及在每個系統或平台中，都有更多使用和成熟的功能，而另一些則更具實驗性和令人頭暈目眩。 真實用例和真實客戶對某些功能（以及在現實生活和實際部署中的使用）的要求越多，他們就會得到更多的整合、證明和擴展。 注冊的情況並非如此，復雜的聯合場景不在當前的 state 中。 我同意它們啟用了一些非常有趣的實驗用例，但在實際部署中，聯合場景增加了額外的復雜性，使它們在這個階段不受歡迎。

Answer 2

不知道我是否完全理解你的情況......

您可以像這樣為所有公民進行注冊：

{
  "dataProvided": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "taxInformation"
      }
    ],
    "attrs": [
      ...
  },
  "provider": {
    "http": {
      "url": "http://thetaxsystem.com"
    }
  }
}

因此，如果您想獲取特定公民的稅務信息，您可以在 CB 執行以下操作：

GET /v2/entities/1234567H?type=taxInformation

並且該注冊將導致將請求作為上下文提供者發送到稅務系統。

編輯： Context Broker ( this one ) 存在一個問題，它阻止了這個案例的工作。 特別是第二種情況：

regR = .* , 查詢 = 'E', attrs = {null}

EDIT2：上述案例已在 Orion Context Broker 中解決。 它現在在 master 分支中可用（dockerhub 中的:latest標簽），並將包含在下一個 Orion Context Broker 版本（3.1.0）中。