I tried the below query to add a schemaExtension, but it failed with an Authorization_RequestDenied response.
url: https://graph.microsoft.com/v1.0/schemaExtensions/
post data:
{
"id": "voctestextension",
"description": "voc test extension",
"targetTypes": ["User"],
"properties": [
{
"name": "trainings",
"type": "Integer"
},
{
"name": "incidents",
"type": "String"
}
]
}
Response
{
"error": {
"code": "Authorization_RequestDenied",
"message": "Insufficient privileges to complete the operation.",
"innerError": {
"request-id": "1d4d625d-99bc-46fc-9e7a-ac30d0840219",
"date": "2018-03-14T13:17:45"
}
}
}
I have given the following permissions:
In the JSON you're POSTing to Graph, can you try setting the owner property? It should be an application id of an app that you've registered.
From the documentation page for creating schema extensions:
The appId of the application that is the owner of the
schema extension. This property can be supplied on creation, to set
the owner. If not supplied, then the calling application's appId will
be set as the owner. So, for example, if creating a new schema
extension definition using Graph Explorer, you must supply the owner
property. Once set, this property is read-only and cannot be changed.
Related
I'm having a hard time understanding how context providers work in the Orion Context Broker.
I followed the examples in the step-by-step guide written by Jason Fox. However, I still do not exactly get what happens in the background and how the context broker exactly creates the POST from the registration. Here is what I am trying to do:
I do have a WeatherStation that provides sensor data for a neighborhood.
{
"id": "urn:ngsi-ld:WeatherStation:001",
"type": "Device:WeatherStation",
"temperature": {
"type": "Number",
"value": 20.5,
"metadata": {}
},
"windspeed": {
"type": "Number",
"value": 60.0,
"metadata": {}
}
}
Now I like the WeatherStation to be a context provider for all buildings.
{
"id": "urn:ngsi-ld:building:001",
"type": "Building"
}
Here is the registration that I try to use.
{
"id": null,
"description": "Random Weather Conditions",
"provider": {
"http": {
"url": "http://localhost:1026/v2"
},
"supportedForwardingMode": "all"
},
"dataProvided": {
"entities": [
{
"id": "null",
"idPattern": ".*",
"type": "Building",
"typePattern": null
}
],
"attrs": [
"temperature",
"windspeed"
],
"expression": null
},
"status": "active",
"expires": null,
"forwardingInformation": null
}
The context broker accepts both entities and the registration without any error.
Since I have a multi-tenant setup I use one fiware_service for the complete neighborhood but every building would later have a seperate fiware_servicepath. Hence, the weatherstation has a different servicepath than the building. Although I also tried to put them both on the same path.
For now I used the same headers for all entities.
{
"fiware-service": "filip",
"fiware-servicepath": "/testing"
}
Here is the log of the context broker (version: 3.1.0):
INFO#2021-09-23T19:17:17.944Z logTracing.cpp[212]: Request forwarded (regId: 614cd2b511c25270060d873a): POST http://localhost:1026/v2/op/query, request payload (87 bytes): {"entities":[{"idPattern":".*","type":"Building"}],"attrs":["temperature","windspeed"]}, response payload (2 bytes): [], response code: 200
INFO#2021-09-23T19:17:17.944Z logTracing.cpp[130]: Request received: POST /v2/op/query?options=normalized%2Ccount&limit=1000, request payload (55 bytes): {"entities": [{"idPattern": ".*", "type": "Building"}]}, response code: 200
The log says that it receives the request and forwards it as expected. However, as I understand it this would simply point to the same building entity again. Hence, it is somehow a circular forwarding. I also cannot tell anything about the headers of the request.
I do not understand how the forwarded request from the building can actually query the weather station for information. When I query my building I still only receive the entity with no own properties:
{
"id": "urn:ngsi-ld:building:001",
"type": "Building"
}
I also tried to vary the url of the registration but with no success.
Is this scenario actually possible with the current implementation? It would be very useful
Is there any example for this including also the headers?
I know that I could simply use reference but that would put more work on the user.
Thanks for any help on this.
It is messy, but you could achieve this via a subscription. Hold the weather station as a separate entity in the context broker and poll or push updates into the entity. The subscription would fire whenever the data changes and make two NGSI requests:
Find all entities which have a Relationship servicedBy=WeatherStationX
Run an upsert on all entities to add a Property to each entity:
{
"temperature" : {
"type" : "Property",
"value" : 7,
"unitCode": "CEL",
"observedAt": "XXXXX",
"providedBy": "WeatherStation1"
}
}
Where observedAt comes either from the payload of the weather station or the notification timestamp.
Within the existing IoT Agents, provisioning the link attribute allows a device to propagate measures to a second entity (e.g. this Thermometer entity is measuring temperature for an associated Building entity)
{
"entity_type": "Device",
"resource": "/iot/d",
"protocol": "PDI-IoTA-UltraLight",
..etc
"attributes": [
{"object_id": "l", "name": "temperature", "type":"Float",
"metadata":{
"unitCode":{"type": "Text", "value" :"CEL"}
}
}
],
"static_attributes": [
{
"name": "controlledAsset",
"type": "Relationship",
"value": "urn:ngsi-ld:Building:001",
"link": {
"attributes": ["temperature"],
"name": "providedBy",
"type": "Building"
}
}
]
}
At the moment the logic just links direct one-to-one, but it would be possible to raise a PR to check for an Array and update multiple entities in an upsert - the relevant section of code is here
I have created event grid topic in azure using event schema = "Event Grid Schema".
The next steps for me is trying to send messages to that event grid topic so the subscribers can do something when the message has been successfully received in event grid topic.
However, I had a problem when sending the message to event grid topic. It always reject my JSON request with error "Required property 'subject' was not set. even tough, I have explicitly set the subject in my JSON post body.
I have also add 'aeg-sas-key' value in header for authentication purposes.
Here is an example of my JSON format:
{
"id": "19291",
"subject": "myapp/vehicles/motorcycles",
"topic": "VehicleData",
"eventType": "statusupdated",
"eventTime": "2019-05-12T18:41:00.9584103Z",
"data":{
"firstName": "Jason",
"postalAddress": "xyz"
},
"dataVersion": "1.0",
"metadataVersion": "string"
}
and Here is the output:
{
"error": {
"code": "BadRequest",
"message": "Required property 'subject' was not set. Report '433759ee-6570-466e-ae12-a6dc5fccbfe1:5/14/2019 4:01:32 AM (UTC)' to our forums for assistance or raise a support ticket.",
"details": [
{
"code": "InputJsonInvalid",
"message": "Required property 'subject' was not set. Report '433759ee-6570-466e-ae12-a6dc5fccbfe1:5/14/2019 4:01:32 AM (UTC)' to our forums for assistance or raise a support ticket."
}
]
}
}
Any idea why it always ask for subject even tough I have provided the subject in my JSON?
Based on the docs:
Post to custom topic for Azure Event Grid
Azure Event Grid event schema
use the following payload:
[
{
"id": "19291",
"subject": "myapp/vehicles/motorcycles",
"topic": null,
"eventType": "statusupdated",
"eventTime": "2019-05-12T18:41:00.9584103Z",
"data": {
"firstName": "Jason",
"postalAddress": "xyz"
},
"dataVersion": "1.0",
"metadataVersion": null
}
]
If you created the topic using the Azure Portal, did you somewhere specify the inputSchemaMapping?
According to the specifications here: https://learn.microsoft.com/en-us/rest/api/eventgrid/topics/createorupdate
You need to specify a inputSchemaMapping when opting for the CustomEventSchema.
When using GET projects/:project_id/folders/:folder_id/search, Forge Data Management API on a model with a deleted last version, is there a any information in the "attributes" or other returned data that indicates the file is deleted?
Currently, a second call to GET projects/:project_id/items/:item_id/versions is used to determine if the latest version is deleted (below) but it would be preferable to not call another request to get this information.
Returned JSON from /versions (with some data removed):
"data": [{
"type": "versions",
"id": "urn:adsk.wipprod:fs.file:vf.w0cwXPUwQziKIHtKBtYRaA?version=3",
"attributes": {
"versionNumber": 3,
"extension": {
"type": "versions:autodesk.core:Deleted",
"version": "1.0",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/versions:autodesk.core:Deleted-1.0"
},
"data": {
"originalName": "**.rvt"
}
}
}]
The json attribute.hidden = true seems to indicate deleted. This can be accessed via the filter[hidden] = true. I'm closing this as the correct answer.
It's really hard to find a clear answer about how to create a comment on an issue which is internal only.
The JIRA Cloud REST API Documentation specifies the following schema for setting properties on comments when creating or updating a comment on an incident
https://docs.atlassian.com/jira/REST/cloud/#api/2/issue/{issueIdOrKey}/comment-addComment
"properties": {
"type": "array",
"items": {
"title": "Entity Property",
"type": "object",
"properties": {
"key": {
"type": "string"
},
"value": {}
},
"additionalProperties": false
}
}
To make a comment on an issue internal (meaning only service desk agents can see the comment) you need to set the sd.public.comment key to have the value { "internal": true }
Which can be achieved by passing the following JSON in the body of the create or update API request.
{
"properties": {
"key": "sd.public.comment",
"value": {
"internal": true
}
}
}
You will also need to set the Content-Type header on the request.
Content-Type: application/json
The following is an example of a creating an internal comment using a Groovy script - the scripting language used by ScriptRunner (a popular JIRA plugin)
post("/rest/api/2/issue/${issue.id}/comment")
.header("Content-Type", "application/json")
.body([
body: "This is the text which will appear in the comment",
properties: [
[key: "sd.public.comment", value: [ "internal": true ]]
]
]).asString()
Note that Object / JSON mapping will differ depending on which scripting language or HTTP Request framework you are using.
In the Consul ACL Internals documentation, sample configuration is provided to set some default ACL rules in both HashiCorp Configuration Language and JSON. It looks like this:
{
"key": {
"": {
"policy": "read"
},
"foo/": {
"policy": "write"
},
"foo/private": {
"policy": "deny"
}
},
"service": {
"": {
"policy": "write"
},
"secure-": {
"policy": "read"
}
},
"event": {
"": {
"policy": "write"
},
"destroy-": {
"policy": "deny"
}
},
"query": {
"": {
"policy": "read"
}
},
"keyring": "read",
"operator": "read"
}
The documentation only explains how to set up the default role.
Using the HTTP API, you can create role tokens with rules by passing JSON similar to this to the create endpoint:
{
"Name": "my-app-token",
"Type": "client",
"Rules": ""
}
But I want to be able to set this up in my static configuration files to have multiple roles with their associated policies.
How can I do this? Do I just add Name, Type, Roles and a UUID? If so, where/how do I do so?
I have figured out through the Consul Google Groups page that, according to a user, ACLs cannot currently be defined as static config files and must be configured via the HTTP API:
Currently the ACLs cannot be directly inserted into
a configuration file that Consul will read. The API is the primary way of interaction with ACLs.
(As of 10 October 2015)
https://groups.google.com/d/msg/consul-tool/fGuFTq0fvcU/f6-mwh4aCQAJ