I've been experimenting with Orion the last few days and and after a while I made it work the way I intended to.
I am facing an unexpected annoyance though, where a string attribute for a given entity context will fail to register.
Example:
http POST [my_orion_server_url]:1026/v1/updateContext < create_push.json
Where create_push.json is:
{
"contextElements": [
{
"type": "Push",
"isPattern": "false",
"id": "Push1",
"attributes": [
{
"name": "message",
"type": "string",
"value": "this is a test)"
}
]
}
],
"updateAction": "APPEND"
}
The server replies with:
HTTP/1.1 200 OK
Content-Length: 129
Content-Type: application/json
Date: Thu, 19 Nov 2015 11:47:03 GMT
{
"errorCode": {
"code": "400",
"details": "Illegal value for JSON field",
"reasonPhrase": "Bad Request"
}
}
If, on the other hand, I remove the parenthesis, everything works as expected:
json file:
{
"contextElements": [
{
"type": "Push",
"isPattern": "false",
"id": "Push1",
"attributes": [
{
"name": "message",
"type": "string",
"value": "this is a test"
}
]
}
],
"updateAction": "APPEND"
}
Server response:
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "message",
"type": "string",
"value": ""
}
],
"id": "Push1",
"isPattern": "false",
"type": "Push"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
Is this intended or a bug?
I can overcome the issue coding the parenthesis with something else and then decoding on reception, but being able to send a parenthesis straight with the entity would be way smoother and less annoying.
That is the expected behaviour. Please have a look to Orion documentation.
Related
I have a JSON API endpoint for retrieving the user. This resource will also be used to get the permissions of the user, for showing or hiding specific elements in our front end application.
The resource looks like this:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"jsonapi": {
"version": "1.0"
},
"meta": {
"content-type": "application/vnd.api+json"
},
"links": {
"self": "/users/some-uuid"
},
"data": {
"type": "users",
"id": "some-uuid",
"attributes": {
"email": "some-email#example.com",
"permissions": [
"view-all-users",
"view-all-shifts"
]
},
"relationships": {
"roles": {
"data": [
{
"type": "role",
"id": "some-role-uuid"
}
]
}
}
}
}
The permissions attribute holds the slugs for the permissions that the user has.
If this attribute was not present the front end application would have to include the resources roles and roles.permissions to be able to get to the user's permissions. That response would look like the following:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"jsonapi": {
"version": "1.0"
},
"meta": {
"content-type": "application/vnd.api+json"
},
"links": {
"self": "/users/some-uuid"
},
"data": {
"type": "users",
"id": "some-uuid",
"attributes": {
"email": "some-email#example.com",
"permissions": [
"view-all-posts",
"edit-all-posts"
]
},
"relationships": {
"roles": {
"data": [
{
"type": "role",
"id": "some-role-uuid"
}
]
}
},
"included": [
{
"type": "roles",
"id": "some-role-uuid",
"attributes": {
"name": "Editor"
},
"relationships": {
"permissions": {
"data": [
{
"type": "permission",
"id": "some-permission-uuid"
},
{
"type": "permission",
"id": "some-permission-uuid-2"
}
]
}
}
},
{
"type": "permissions",
"id": "some-permission-uuid",
"attributes": {
"slug": "view-all-posts"
}
},
{
"type": "permissions",
"id": "some-permission-uuid",
"attributes": {
"slug": "edit-all-posts"
}
}
]
}
}
In this case the front end has to do a lot of processing just to get to the permission slugs. My question here is: Is it bad to have a short hand attribute permissions on the user resource like the above example, or should the front end always get to the slugs through the relationships?
Note: In the future we will have an admin interface where the user can manage users, roles and permissions. That is why the roles and permissions are available as seperate entities.
Client apps can easily merge all the permissions from roles into one key/array themselves and work from there. This way you'll keep the principles of JSON API in tact and give the client apps the freedom to work with permissions as they prefer.
In version 1.7.0 of Orion CB running the docker version in Docker for Windows,
if I create a simple object doing POST http://localhost:1026/v1/updateContext
with the body:
{
"contextElements": [
{
"type": "Car",
"id": "myNewCar",
"attributes": [
{
"name": "maxSpeed",
"type": "integer",
"value": "220"
}
]
}
],
"updateAction": "APPEND"
}
I get the answer:
{
"contextResponses": [
{
"contextElement": {
"type": "Car",
"isPattern": "false",
"id": "myNewCar",
"attributes": [
{
"name": "maxSpeed",
"type": "integer",
"value": ""
}
]
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
Then, if I do POST http://localhost:1026/v1/queryContext with the same headers and the same components with the body
{
"entities": [
{
"type": "Car",
"isPattern": "false",
"id": "myNewCar"
}
]
}
I get the following:
{
"errorCode": {
"code": "404",
"reasonPhrase": "No context element found"
}
}
Which shouldn't be problematic (I can query the entities with v2 API, for instance) if it wasn't needed for integration with data representation tools such as SpagoBI as documented in http://spagobi.readthedocs.io/en/latest/user/NGSI/README/
What can I do? I am doing something wrong with the context provision?
Thanks!
My problem was that I was using a imported Postman collection of the API (Downloaded from https://github.com/telefonicaid/fiware-orion/tree/develop/doc/apiary/v2) and accidentally I was using the header Fiware-Service.
You are right and your tests work properly.
Thanks for the prompt reply!!
I'm newer to Swagger UI. I use swagger with Json. When the response is also Json. When clicking Try it Out, I see a correct Request URL, but the Swagger UI returns "no content" in the Response Body, and Response Code 0.
Mentioned that API's URL is not publicly accessible, but the site that hosts the Swagger UI is in the same network as the site that hosts the API.
I see this stack overflow question, but not found the solution.
My Swagger.Json file:
{
"swagger": "2.0",
"info": {
"version": "1.0.0",
"title": "Swagger for Rest API",
"description": "A sample API that uses a application as an example to demonstrate features in the swagger-2.0 specification",
"termsOfService": "http://helloreverb.com/terms/",
"contact": {
"name": "Swagger API team",
"email": "abc#gmail.com",
"url": "http://xxxx.com"
},
"license": {
"name": "MIT",
"url": "http://opensource.org/licenses/MIT"
}
},
"host": "localhost:85xx",
"basePath": "/v1",
"schemes": [
"http"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/test/{username}/{albumname}/{imagename}": {
"get": {
"description": "Returns all images from the system that the user has access to",
"operationId": "findface",
"produces": [
"application/json",
"application/xml"
],
"parameters": [
{
"name": "username",
"in": "path",
"description": "tags to filter by",
"required": true,
"type": "string"
},
{
"name": "albumname",
"in": "path",
"description": "maximum number of results to return",
"required": true,
"type": "string"
},
{
"name": "imagename",
"in": "path",
"description": "maximum number of results to return",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"description": "OK",
"schema": {
"type": "array",
"items": {
"$ref": "#/definitions/test1"
}
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
}
},
"definitions": {
"test1": {
"type": "object",
"required": [
"id",
"name"
],
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"name": {
"type": "string"
},
"tag": {
"type": "string"
}
}
},
"errorModel": {
"type": "object",
"required": [
"code",
"message"
],
"properties": {
"code": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
}
}
}
Please can any one help.
Thank in Advance.
It should be a CORS issue. You should add Access-Control-Allow-Origin: * into response headers.
Please refer: https://github.com/swagger-api/swagger-ui/blob/master/README.md#cors-support
It should be a CORS issue. You should add Access-Control-Allow-Origin: * into response headers.
Use this code in the startup class
// global cors policy
app.UseCors(x => x
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader());
I'm currently trying to subscribe Orion and Cosmos. All data sent to Orion is being updated without any issue. But, when posting to http://xxx.xxx.xx.xx:1026/v1/subscribeContext I'm getting the following error:
{
"subscribeError": {
"errorCode": {
"code": "400",
"reasonPhrase": "Bad Request",
"details": "JSON Parse Error"
}
}
}
This is the json string I'm sending:
{
"entities": [
{
"type": "Location",
"isPattern": "false",
"id": "Device-1"
}
],
"reference": "http://52.31.144.170:5050/notify",
"duration": "PT10S",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"position"
]
}
],
"attributes": [
"position"
]
}
The entity updating OK in Orion is:
{
"type": "Location",
"isPattern": "false",
"id": "Device-1",
"attributes": [
{
"name": "position",
"type": "coords",
"value": "24,21",
"metadatas": [
{
"name": "location",
"type": "string",
"value": "WGS84"
}
]
},
{
"name": "id",
"type": "device",
"value": "1"
}
]
}
I've tried with many different examples from readthedocs, and other responses in StackOverflow unsuccessfully.
Which is the correct format? Should I call /subscribeContext before or after updating Orion with /contextEntities?
Orion Context Broker version is 0.26.1.
Thank you in advance.
Taking into account that the same payload works ok when send using curl (see this execution session) I tend to think that some issue in the client (maybe hiden by a programming framework?) is causing the problem.
I use Orion to send updates to Proton-CEP when a change of an object occurs.
However, I have many such objects updates occurring every few seconds. So I send these updates to Orion in batches, like this:
{
"contextElements": [
{
"type": "Queue",
"isPattern": "false",
"id": "Queue.routes_queue",
"attributes": [
{
"name": "volume",
"type": "integer",
"value": "3"
}
]
},
{
"type": "Queue",
"isPattern": "false",
"id": "Queue.optimizer_queue",
"attributes": [
{
"name": "volume",
"type": "integer",
"value": "4"
}
]
}
],
"updateAction": "APPEND"
}
I have a subscription which is supposed to send these event (when the volume has changed) to CEP for processing.
{
"entities": [
{
"type": "Queue",
"isPattern": "true",
"id": "Queue.*"
}
],
"attributes": [
"volume"
],
"reference": "http://<cep-host>:8080/ProtonOnWebServer/rest/events",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"volume"
]
}
],
"throttling": "PT1S"
}
CEP is configured to listen to these events, and write them to a file. Unfortunately, only the first element is written.
I have confirmed that this is not a CEP problem by using the provided accumulator-server script. I can see only a single update being exposed:
POST http://localhost:1028/accumulate
Content-Length: 741
User-Agent: orion/0.24.0 libcurl/7.19.7
Host: localhost:1028
Accept: application/xml, application/json
Content-Type: application/xml
<notifyContextRequest>
<subscriptionId>5645bb21abde60e23096acef</subscriptionId>
<originator>localhost</originator>
<contextResponseList>
<contextElementResponse>
<contextElement>
<entityId type="Queue" isPattern="false">
<id>Queue.routes_queue</id>
</entityId>
<contextAttributeList>
<contextAttribute>
<name>volume</name>
<type>integer</type>
<contextValue>4</contextValue>
</contextAttribute>
</contextAttributeList>
</contextElement>
<statusCode>
<code>200</code>
<reasonPhrase>OK</reasonPhrase>
</statusCode>
</contextElementResponse>
</contextResponseList>
</notifyContextRequest>
=======================================
::1 - - [13/Nov/2015 10:29:05] "POST /accumulate HTTP/1.1" 200 -
Can Orion send updates for all elements that have changed?
The solution is simply to remove the throttling. Throttling applies to the entire subscription, not just to a single object in the matched pattern.