Problems with v1/queryContext needed for SpagoBI integration - fiware

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!!

Related

Can a JSON API resource have an attribute which is a shorthand for a relationship?

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.

How to merge swagger multiple files in single swagger doc file?

I have different swagger files for multiple APIs, like swagger1.json for OpenStack API, swagger2.json for Users API etc and I was trying to merge these all swagger files in one single file using remote $ref method.
Here is swagger1.json file for OpenStack api
{
"stacks": {
"get": {
"tags": [
"openstack"
],
"summary": "Returns stacks from OpenStack",
"description": "Returns all stacks from the OpenStack based on tenantId.",
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"parameters": [
{
"in": "query",
"type": "string",
"name": "tenantId",
"description": "search stacks for tenantId from OpenStack",
"required": false
}
],
"responses": {
"200": {
"description": "OK"
},
"400": {
"description": "Unknown Error"
},
"401": {
"description": "Unauthorized"
}
}
}
}
}
And this is the swagger-merge.json where I want to add multiple swagger doc file using remote reference.
{
"swagger": "2.0",
"info": {
"description": "something here",
"version": "v0.7.0",
"title": "The API Gateway",
"contact": {
"email": "dp#gmail.com"
}
},
"host": "localhost",
"port":"9191",
"basePath": "/api/openstack",
"tags": [
{
"name": "OpenStackApi",
"description": "Get stacks and running instance form OpenStack"
}
],
"schemes": [
"https"
],
"paths": {
"$ref": "./swagger1.json#/stacks"
}
}
This isn't working for me. I am not able to see API methods I have written inside swagger1.json file. I have upload swaggerUI output. Any idea about what I am doing wrong and how can I solve this issue?
You can't $ref the whole contents of paths, you can only refer individual path items:
"paths": {
"/stacks": { <--- endpoint path
"$ref": "./swagger1.json#/stacks"
}
}

Error 400 when using Google API Explorer

I'm getting the following error when using the Google API Explorer to insert into GCP's Datastore.
I've tried using another name and ID, but still the error. How do I rectify this?
Below are the request body and error.
{
"mode": "Transactional",
"mutations": [
{
"insert": {
"key": {
"path": [
{
"id": "56294995342131231",
"name": "CL-001",
"kind": "Log"
}
],
"partitionId": {
"namespaceId": "",
"projectId": "triplog-169706"
}
},
"properties": {
"Title": {
"stringValue": "Space Needle"
},
"Longitude": {
"doubleValue": 0.00
},
"Latitude": {
"doubleValue": 0.00
},
"Date": {
"timestampValue": "2015-07-03T10:51:50.649Z"
},
"Rating": {
"integerValue": "5"
},
"Notes": {
"stringValue": "Wonderful site to see"
}
}
}
}
]
}
{
"error": {
"code": 400,
"message": "Invalid value at 'mutations[0].insert.key.path[0]' (oneof), oneof field 'id_type' is already set. Cannot set 'name'",
"status": "INVALID_ARGUMENT",
"details": [
{
"#type": "type.googleapis.com/google.rpc.BadRequest",
"fieldViolations": [
{
"field": "mutations[0].insert.key.path[0]",
"description": "Invalid value at 'mutations[0].insert.key.path[0]' (oneof), oneof field 'id_type' is already set. Cannot set 'name'"
}
]
}
]
}
}
Based on the docs, it looks like you should only be setting either a "name" or "id" in the Path Element, not both.
https://cloud.google.com/datastore/docs/reference/rest/v1/Key#PathElement
I've finally got it.
To get the "transaction", just run the beginTransaction API.
POST https://datastore.googleapis.com/v1/projects/{projectId}:beginTransaction
This will response with an identifier, which is a long string. Use that as the value of the "transaction".

Orion JSON Bad Request

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.

How can I index .JSON in elasticsearch

I am starting with elasticsearch now and i don't know anything about it.
I have folowing .JSON:
[
{
"label": "Admin Law",
"tags": [
"#admin"
],
"owner": "generalTopicTagText"
},
{
"label": "Judicial review",
"tags": [
"#JR"
],
"owner": "generalTopicTagText"
},
{
"label": "Admiralty/Shipping",
"tags": [
"#shipping"
],
"owner": "generalTopicTagText"
}
]
My mapping is this:
{
"topic_tax": {
"properties": {
"label": {
"type": "string",
"index": "not_analyzed"
},
"tags": {
"type": "string",
"index_name": "tag"
},
"owner": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
I need to put the first .Json into Elasticsearch, but it does not work.
All I know is that i am defining only 1 of this:
{
"label": "Judicial review",
"tags": [
"#JR"
],
"owner": "generalTopicTagText"
}
So when i try to put all of them with my elasticsearch.init, it will not work.
But I really don't know how to declare the mapping.Json to put the all .Json, it is like i need something like a for there.
You have to insert them json after json. But what you should do is use the bulk api of elasticsearch to insert multiple documents in one request. Check this api doc to see how it works
You can do something like this
curl -XPUT 'localhost:9000/es/post/1?version=2' -d '{
"text" : "your test message!"
}'
here is the documentation for index json with elasticsearch