按照我之前的问题如何在MapViewer小部件中显示OrionContextBroker中的实体我使用Rush配置了我的上下文代理实例,我使用https://ngsiproxy.lab.fi-ware.org作为NGSI代理.
我启动orionContextBroker实例,如下所示:contextBroker -rush localhost:5001,一切似乎都正常工作(我可以插入/查询数据等),但是当MapViewerWidget被加载时,我从OrionInstance日志中获取此消息:
INFO@17:32:53 clientSocketHttp.cpp[152]: Starting transaction to ngsiproxy.lab.fi-ware.org:443/callbacks/19:32:59-1:19:33:01-1
WARNING@17:32:53 clientSocketHttp.cpp[342]: Notification failure for localhost:5001 (curl_easy_perform failed: Couldn't connect to server)
INFO@17:32:53 clientSocketHttp.cpp[359]: Transaction ended
谢谢!
在当前版本的Orion Context Broker,0.23.0中,新增功能之一是它支持根据属性值(NGSI v2)过滤实体.我正在执行GET操作,如http://telefonicaid.github.io/fiware-orion/api/v2/所示,我获得的是整套实体,没有过滤操作.有关如何使用新的REST API NGSI v2的明确示例,请您帮我解决这个问题吗？
非常感谢你提前
我已在FILAB中部署了Orion实例，并已配置了Cygnus inyector，以便在Cosmos中存储信息。
但是...让我们想象一下这样一种场景，其中实体的数量急剧增加。在这种假设的情况下，仅Orion GE的一个实例是不够的，因此有必要部署更多实例。
比例程序是什么？考虑到最大配额为：
VM实例：5个VCPU：10个硬盘：100 GB内存：10240 MB公用IP：1
我知道配额可能会更改，但是免费帐户限额是多少？
Cosmos头节点中的硬盘限制是多少？（理论上为5GB配额）
是否可以通过单个公共IP部署更多Orion Context Broker实例，还是有必要要求多个公共IP？怎么样？
总而言之，我要求提供有关拟议方案的扩展程序和免费帐户限制（可能的最大配额）的信息。
先感谢您。亲切的问候。
拉蒙
这个问题非常类似于Orion CB Entity在通过IDAS注册设备时的缺失属性,但在那里没有找到明确的答案.
我一直在尝试使用IDWare通过IDAS将UL2.0送到在Fiware-Lab环境中工作的Orion CB:
我有一个FI-WARE Lab帐户,生成了令牌.修改了config.ini文件:
[user]
# Please, configure here your username at FIWARE Cloud and a valid Oauth2.0 TOKEN for your user (you can use get_token.py to obtain a valid TOKEN).
username=MY_USERNAME
token=MY_TOKEN
[contextbroker]
host=130.206.80.40
port=1026
OAuth=no
# Here you need to specify the ContextBroker database you are querying.
# Leave it blank if you want the general database or the IDAS service if you are looking for IoT devices …考虑到 Orion Context Broker 的“生产”使用，我想知道 Orion Context Broker 在消息传递方面提供了什么样的保证——无论是从生产者还是消费者的角度来看？特别是，要记住各种可能的故障场景（CB 故障/重启、网络瞬时故障、消费者故障/重启等），以及 CB 中资源拥塞的可能性。几个例子：
1）如果上下文更新操作成功，是否保证后续查询将返回最新数据（例如，即使CB在确认更新请求后立即失败，然后重新启动）？
2）如果消费者订阅了某些上下文信息，是否保证它将收到所有相关更新——恰好一次，至少一次，甚至根本没有？（例如，CB 和消费者之间出现暂时性网络故障的情况）
3）如果消费者更新了其订阅，是否能保证后续更新能够准确反映它？（例如，如果CB在确认订阅请求后立即失败，然后重新启动）
4）如果消费者订阅了上下文更改（“onchange”，无限制），并且生产者有多个后续更新影响同一属性，是否保证每个更改都将被发送（或者可能会跳过某些更改） -- 例如，由于 CB 在某个时间段内需要发送太多通知），按任何特定顺序？
ETC...
谢谢！
当尝试使用STH来存储和检索发送到OCB的数据时,我在进行订阅时遇到问题.
我的问题是订阅创建顺利.当我按以下方式创建订阅时:
POST /v1/contextSubscriptions HTTP/1.1
Host: <cb_host>:1026
Content-Type: application/json
Fiware-Service: myService
Fiware-ServicePath: /myServicePath
Cache-Control: no-cache
{
"entities": [
{
"type": "cameraSimple",
"isPattern": "true",
"id": "sensor03"
}
],
"attributes": [
"class"
],
"reference": "http://<cb_host>:8666/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"class"
]
}
],
"throttling": "PT5S"
}
我收到以下答案:
{
"subscribeResponse": {
"subscriptionId": "588b4f38e2066a50fa98df9b",
"duration": "P1M",
"throttling": "PT5S"
}
}
但是在Fiware服务器上,我看到有关运行容器的终端中的条件的错误,以及有关属性的另一个错误:
orion | ERROR@14:06:10 safeMongo.cpp[302]: Runtime Error (field 'conditions' was supposed to be an array but type=4 in BSONObj …我想在 Orion Context Broker NGSI API 级别提供访问控制，以确保真正的数据隔离。我想确保租户只能查询/更新他们的上下文，而不能查询/更新其他租户的上下文。
为此，我开始在 Orion Context Broker 前面放置一个Wilma PEP Proxy实例。然后，我根据官方IdM Keyrock docker映像配置了自己的 Identity Manager keyrock GE 实例，并根据官方AuthzForce docker 映像配置了自己的 Authorization PDP GE 。
经过几天的配置和多次尝试，我终于可以让这三个安全通用启用器正常工作，使用PEP 代理级别 2对 Orion Context Broker NGSI API 的请求进行身份验证和授权。
但是，2 级授权不足以保证我想要的，因为服务（租户）和子服务（应用程序路径）信息都在请求的标头中。特别是在Fiware-Service 和Fiware-ServicePath 标头中。为了构建基于标头的授权策略，您需要使用级别 3：XACML 授权。
问题是我在 Fiware 的官方文档中进行了一些挖掘，但找不到任何 XACML 策略的示例。除了 Wilma PEP Proxy 的官方文档（请参阅此处）外，您可能必须修改 PEP Proxy 源代码才能获得此级别的授权。
由于这种情况被认为是检查请求的高级参数，例如正文或自定义标头，因此这取决于具体的用例。因此，程序员应该修改 PEP 代理源代码以包含特定要求。
有这样可能吗？
我真的需要修改 PEP 代理源代码来实现像租户只能访问他的数据这样简单的事情吗？
我有兴趣访问活动订阅列表,但在阅读了所有关于API的wiki之后(https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_- _User_and_Programmers_Guide#Context_subscriptions)我没有找到任何允许获取它们列表的操作.
这样做有什么操作吗？有人可以给我详细介绍吗？
我正在尝试实施本教程。“docker-compose”内容是这样的：
# WARNING: Do not deploy this tutorial configuration directly to a production environment
#
# The tutorial docker-compose files have not been written for production deployment and will not
# scale. A proper architecture has been sacrificed to keep the narrative focused on the learning
# goals, they are just used to deploy everything onto a single Docker machine. All FIWARE components
# are running at full debug and extra ports have been exposed to allow for …