Orion Context Broker - Subscriptions only notify the first 20 entities - fiware-orion

Using this script:
#!/bin/bash
(curl http://orionip:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: service' --header 'fiware-servicepath: /servicepath' \
-d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Sensor",
"isPattern": "true",
"id": "Parquimetro:.*"
}
],
"attributes": [
"recaudacion"
],
"reference": "http://cometip:80/notify",
"duration": "P4Y",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"recaudacion", "numeroTiques"
]
}
],
"throttling": "PT24H"
}
EOF
Makes a subscription for 170 entities (Parquimetro:1, Parquimetro:2, Parquimetro:3, ..., Parquimetro:170) to notify Comet for storing historical data, but only the first 20 entities got notified. I need it to notify all entities (which are right now 170, not 20).
Using /v1/subscribeContext?limit=200 doesn't help either.
Any idea?

There is an open issue at Orion github about it from time ago.
Currently Orion behaves that way, but there is a workaround in place: do a (paginated) query to get all entities just before doing the subscription. It could happen some "race condition" if some update arrives since the query and the subscription, but, depending on the use case, it may suffice.

Related

Getting the latest execution for a job via the Rundeck API

I'm using the latest version of Rundeck (3.3.10) and I'm having trouble getting the latest execution for a job via the Rest API.
If I call api/38/job//executions?max=1 it doesn't seem to bring back the latest execution if it is still running. Ideally, I'd also like to be able get the latest execution Start Time, End Time, User and result for each job in a single API call, but I'd resigned myself to calling the API once per job. There doesn't seem to be any way to sort the executions you get back from the API - they seem to be sorted by status first, so the running jobs appear at the end of the list.
Does anyone know a way around this? Thanks.
Yo can get that information using: executions?status=running&max=1 call.
Script example:
#!/bin/sh
# protocol
protocol="http"
# basic rundeck info
rdeck_host="localhost"
rdeck_port="4440"
rdeck_api="38"
rdeck_token="YRVaZikt64Am85RyLo1nyq8U1Oe4Q8J7 "
# specific api call info
rdeck_job="03f28add-84f2-4013-b8f5-e48feaf5977c"
# api call
curl --location --request GET "$protocol://$rdeck_host:$rdeck_port/api/$rdeck_api/job/$rdeck_job/executions?status=running&max=1" \
--header "Accept: application/json" \
--header "X-Rundeck-Auth-Token: $rdeck_token" \
--header "Content-Type: application/json"
Output:
{
"paging": {
"count": 1,
"total": 1,
"offset": 0,
"max": 1
},
"executions": [
{
"id": 7,
"href": "http://localhost:4440/api/38/execution/7",
"permalink": "http://localhost:4440/project/ProjectEXAMPLE/execution/show/7",
"status": "running",
"project": "ProjectEXAMPLE",
"executionType": "user",
"user": "admin",
"date-started": {
"unixtime": 1617304896289,
"date": "2021-04-01T19:21:36Z"
},
"job": {
"id": "03f28add-84f2-4013-b8f5-e48feaf5977c",
"averageDuration": 13796,
"name": "HelloWorld",
"group": "",
"project": "ProjectEXAMPLE",
"description": "",
"href": "http://localhost:4440/api/38/job/03f28add-84f2-4013-b8f5-e48feaf5977c",
"permalink": "http://localhost:4440/project/ProjectEXAMPLE/job/show/03f28add-84f2-4013-b8f5-e48feaf5977c"
},
"description": "sleep 20; echo \"hi\"",
"argstring": null,
"serverUUID": "630be43c-e71f-4102-be96-d017dd22233e"
}
]
}

Cygnus-Orion subscription endpoint

What is the best endpoint to subscribe Cygnus to Orion CB for subscription change: /v1/subscribeContext or /v2/subscriptions please?
Tried this, no response:
$(curl localhost:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: smartGondor' --header 'Fiware-ServicePath: /gardens' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Device",
"isPattern": "false",
"id": "raspiSensorTV"
}
],
"attributes": [
"Temperature Sensor",
"TimeInstant"
],
"reference": "http://localhost:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"Temperature Sensor"
]
}
],
"throttling": "PT1S"
}
EOF
This seems to work, but not sure if its the best way to go, as no observations are received.
$curl -iX POST \
'http://localhost:1026/v2/subscriptions' \
-H 'Content-Type: application/json' \
-H 'fiware-service: smartGondor' \
-H 'fiware-servicepath: /gardens' \
-d '{
"description": "Notify Cygnus of all context changes",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Device"
}
]
},
"notification": {
"http": {
"url": "http://cygnus:5050/notify"
},
"attrsFormat": "legacy"
},
"throttling": 5
}'
At the present moment Cygnus doesn't support NGSIv2 notifications so you need to use the NGSIv1 endpoint. You can find more information in this section of Cygnus documentation and this other.

Orion notification complex payload

I'm trying to use Orion notification to send SMS with Plivo.
This is how I send an SMS directly with Plivo:
curl -X POST https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1/Message/ -L -u MAMDA5ZDJIM:YzhiNDJjODNhNDkxMjhiYTgxZD -H 'Content-Type: application/json' -d #- <<EOF
{
"src": "0039414141414",
"dst": "0039414747111",
"text": "test SMS"
}
EOF
How should I encode it in Orion? I tried:
curl localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- <<EOF
{
"description": "A subscription to get info about WS_UPPA_Sensor2",
"subject": {
"entities": [
{
"id": "Sensor1",
"type": "SensingDevice"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"httpCustom": {
"url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
"headers": {
"Authorization": "Basic TUFNREE1WkRKSU1ETTFOWlZNWkQ6WXpoaU5ESmpPRE5oTkRreE1qaGlZVGd4WkRkaE5qYzNPV1ZsTnpZMA=="
},
"payload": "{%22src%22%3A%2200393806412092%22%2C%22dst%22%3A%2200393806412093%22%2C%22text%22%3A%22test%20SMS%20from%20Waziup%22}"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
Is there another way than percent encoding?
URL encoding (I understand is the one you refer by "percent encoding") is the only one which have an special treatment in custom notifications (details described as part of the Orion documentation).
In fact, taking into account the existing one is complete (I mean, any text can be expressed in the terms of URL encoding) there is no need of adding any other.

Doubts about notifications format in Orion usin APIv2

we are testing the subscription functionality using the APIv2. We are following the guidelines described in http://telefonicaid.github.io/fiware-orion/api/v2/ . We are able to create a correct subscription but the format of the notification messages that we received is not what we expected. The format of these messages is like the APIv1 version. Is this the expected behavior?
We are using the Docker image from https://hub.docker.com/r/fiware/orion/.
Version information about the build:
{
"orion" : {
"version" : "1.0.0-next",
"uptime" : "0 d, 1 h, 28 m, 47 s",
"git_hash" : "a729812c45d2749fffbc19add17631b2fffc8797",
"compile_time" : "Fri Apr 8 10:05:55 UTC 2016",
"compiled_by" : "root",
"compiled_in" : "838a42ae8431"
}
}
Steps to reproduce:
Create an entity:
(curl -X POST http://<cb_url>:<cb_port>/v2/entities?options=keyValues -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"type":"Room",
"id": "test",
"humidity":40
}
EOF
Create a subscription:
(curl -X POST http://<cb_url>:<cb_port>/v2/subscriptions -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"description": "One subscription to rule them all",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Room"
}
],
"condition": {
"attributes": [
"humidity"
],
"expression": {
"q": "humidity>40"
}
}
},
"notification": {
"callback": "http://192.168.99.1:5000",
"attributes": [
"humidity"
],
"throttling": 5
},
"expires": "2016-05-05T14:00:00.00Z"
}
EOF
Update attribute.:
(curl -X PUT <cb_url>:<cb_port>/v2/entities/test/attrs/humidity/value -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"value": 50
}
EOF
We get the notification with the following format:
{u'contextResponses': [
{u'contextElement': {
u'attributes': [{
u'name': u'humidity',
u'type': u'none',
u'value': {u'value': 50}
}],
u'id': u'test',
u'isPattern': u'false',
u'type': u'Room'
},
u'statusCode': {
u'code': u'200',
u'reasonPhrase': u'OK'
}}],
u'originator': u'localhost',
u'subscriptionId': u'5707b72882fc213130f4e5b9'}
NGSIv2 notification formats have not been yet implemented (at Orion 1.0.0). Note that NGSIv2 is yet in beta status and sometimes the specification (where the new notification format has been defined) is a step forward the implementation.
There is a github issue about this, to which you can subscribe in order to know when this feature gets implemented.
EDIT: NGSIv2 notification formats have been implemented in Orion 1.1.0.

Change order of Orion response

I'm calling orion with a Geo-location filter, like this one:
(curl localhost:1026/v1/queryContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "City",
"isPattern": "true",
"id": ".*"
}
],
"restriction": {
"scopes": [
{
"type" : "FIWARE::Location",
"value" : {
"circle": {
"centerLatitude": "40.418889",
"centerLongitude": "-3.691944",
"radius": "13500"
}
}
}
]
}
}
EOF
I read on the fiware orion documentation that the returned entities are returned by increasing entity/registration creation time. Like is explained here
There is the possibility to change this behaviour?
Changing the order is not possible in NGSIv1, but in NGSIv2 it has been taken into account. Have a look to this issue in the fiware-orion repository in order to monitor the implementation status of the feature.
EDIT: since Orion 0.28.0 you can use the orderBy URL parameter to change this behaviour, both in NGSIv1 (see this piece of documentation) and NGSIv2 (see "Ordering results" section in the NGSIv2 specification).