I am trying to show an entity stored in my OrionContextBroker instance in the Wirecloud MapViewer widget. I create the context using this JSON POST REST request to miOrionInstance:1026/v1/updateContext like this:
{
"contextElements": [
{
"type": "Room",
"isPattern": "false",
"id": "Room1",
"attributes": [
{
"name": "position",
"type": "string",
"value": "43.47258, -3.8026643"
}
]
}
],
"updateAction": "APPEND"
}
I am able to recover this information through the NGSIUpdater Widget with no problem, but I am unable to show this entity in the MapViewer widget. I have tried to wire the NGSISource Operator to the NGSIEntityToPol Operator and finally to the MapViewer Widget (in Insert/Update centered Pol).
The configuration of the NGSISource operator is:
NGSI server URL: http://miOrionInstanceIP:1026
NGSI proxy URL: http://ngsiproxy.lab.fi-ware.org
NGSI entity types: Room
Id Pattern:
Monitored NGSI Attribures: position
And the configuration of the NGSIEntityToPol Operator is the following:
Coordinates attribute: position
But nothing appears in the map.
Thanks,
The "NGSI entity types" value is incorrect, it should contain the entity type of the entities you are interested in (e.g. Room). The rest of your configuration seems correct, so if changing this setting doesn't solve your problems, you may be facing the same problems described at this question.
Related
I have a response object in my swagger.json file that includes a nested object as one of its fields. When I use Autorest.Powershell to generate a client for this API, it flattens the nested object. So when the service returns the following response:
{
"code": 200,
"status": "OK",
"data": {
"FileName": "gameserver.zip",
"AssetUploadUrl": "https://example.com"
}
}
my Autorest.Powershell client returns a flattened object like this:
{
"code": 200,
"status": "OK",
"dataFileName": "gameserver.zip",
"dataAssetUploadUrl": "https://example.com"
}
Is there some sort of configuration setting I can use to disable this behavior?
Here are the relevant portions of my swagger.json file, if it helps:
"definitions": {
"GetAssetUploadUrlResponse": {
"type": "object",
"properties": {
"AssetUploadUrl": {
"description": "The asset's upload URL.",
"type": "string"
},
"FileName": {
"description": "The asset's file name to get the upload URL for.",
"type": "string"
}
},
"example": {
"FileName": "gameserver.zip",
"AssetUploadUrl": "https://example.com"
}
}
},
"responses": {
"GetAssetUploadUrlResponse": {
"description": "",
"schema": {
"type": "object",
"properties": {
"code": {
"type": "integer",
"description": "The Http status code. If X-ReportErrorAsSuccess header is set to true, this will report the actual http error code."
},
"status": {
"type": "string",
"description": "The Http status code as a string."
},
"data": {
"$ref": "#/definitions/GetAssetUploadUrlResponse"
}
},
"example": {
"code": 200,
"status": "OK",
"data": {
"FileName": "gameserver.zip",
"AssetUploadUrl": "https://example.com"
}
}
}
}
}
There are several ways, none of which is really straightforward (as, I'm starting to believe, is the case with most things AutoRest-related; sorry, couldn't resist :-P ).
There are three semi-official ways. Semi-official here means they are based on public AutoRest mechanism but are not themselves documented. Being semi-official, they might only work with certain versions of AutoRest components, so, here are the ones I used
(from autorest --info):
#autorest/core (3.0.6369)
#autorest/modelerfour (4.15.414)
#autorest/powershell (3.0.421)
Finally, here are the relevant parts of AutoRest's code base: inline properties plug-in and configuration directive definition
inlining-threshold setting
This setting control the maximum number of properties an inner object could have for it to be considered eligible for inlining. You can set it either on the command line or in the "literate config" .md file.
```yaml
inlining-threshold: 0
```
In theory, setting this to 0 should prevent any inner member's properties from being inlined, however the plug-in has a hard-coded exception that if the inner object is in a property that's itself named properties then the limit is ignored and it's still flattened.
definitions:
SomeSchema:
type: "object"
properties:
detail_info: # <-- threshold honored
$ref: "#/definitions/InfoSchema"
properties: # <-- this is always flattened because of its special name
$ref: "#/definitions/OtherSchema"
no-inline directive
The PowerShell AutoRest plug-in also defines a custom directive that is used to specify that certain schemas should never be inlined. Using "literate config", it goes like
```yaml
directive:
- no-inline:
- OtherSchema
- ThirdSchema
```
The pros of this approach are that the no-inline directive overrides the "always inline properties in a property named properties" exception mentioned above, so it can be used to alleviate the problem.
The cons are that all schema names should be listed explicitly. (It seems the directive should also support Rx name expression but I couldn't get no-inline: ".*" to work)
Low-level transform
This is approach disables inlining unconditionally in all cases, however it is coupled to the specific internal code model used by AutoRest. (In principle, the model should be stable, at least within major versions). It also relies on the PowerShell plug-in using a specific (non-contractual) property to flag schemas excluded from inlining.
```yaml
directive:
- from: code-model-v4-no-tags
where: $.schemas.objects.*
transform: |
$.language.default['skip-inline'] = true;
```
I'm trying to migrate chatbot to use newly introduced Assistant API v2.
My chatbot infrastructure includes Middleware services which modifies the context after getting the response from Watson. In some case I used to remove particular properties from the context and it worked fine. However I noticed that after migration to API v2 this approach does not work anymore as the deleted properties are somehow stored on Watson side.
For example I received following context from Watson:
{
"assistantId": "---",
"sessionId": "---",
"messageInput": {
"Text": "Some text",
"Options": {
"Debug": "true",
"ReturnContext": "true",
"Restart": "false"
}
},
"context":
{
"Global": "null",
"Skills": {
"AdditionalProperties": {
"main skill": {
"user_defined": {
"id": "23",
"description": "Dont know"
},
"system": {---}
}
}
}
}
}
Then I remove 'description' from the context and send request to Watson once more. Surprisingly 'description' is still there with the same value ('Dont know').
Possible solution would be not to remove a property but to set it's value to empty string. But even in this case my dialog does not work correctly as Watson somehow stores the point in dialog it was visiting previously (or not, these are my guesses). I assume it might be related to system.state property which stores an encoded state of the dialog (again - or not).
My question is why is dialog behaving this way?
How does it store the context information so I can't remove properties from user_defined context?
And how can I reset dialog state to initial keeping the same conversation_id (session_id)?
P.S. I'm using Watson API v2: 2020-04-01
I am accessing a RESTful API that pages results in groups of 50 using the HTTP connector. The REST connector doesn't seem to support Client Certificates so I can't use the pagination in that.
I have a Pipeline Variable called SkipIndex that defaults to 0. Inside the Until loop I have a Copy Data Activity that works (HTTP source to BLOB sink), then a Set Variable Activity that I am trying to get to increment this Variable.
{
"name": "Add 50 to SkipIndex",
"type": "SetVariable",
"dependsOn": [
{
"activity": "Copy next to temp",
"dependencyConditions": [
"Succeeded"
]
}
],
"userProperties": [],
"typeProperties": {
"variableName": "SkipIndex",
"value": {
"value": "50++",
"type": "Expression"
}
}
}
Everything I have tried results in errors such as "The expression contains self referencing variable. A variable cannot reference itself in the expression." and the one above with 50++ causes a sink error during debug.
How can I get the Until loop to increment this variable after it retrieves data?
Agree that REST Connector does supports pagination but does not for Client Certificates Authentication type.
For the idea of your Until activity scenario,i am tripped by the can't self-reference a variable in an expression limitation also. Maybe you could make a little trick on that: Add one more variable to persist the index number.
For example,i got 2 variables: count and indexValue
Until Activity:
Inside Until Activity:
V1:
V2:
BTW, no usage of 50++ in ADF.
Cassandra Table Column:
pickuploc map<text, frozen<location>>
Java entity:
#Column("pickuploc")
protected Map<String,Location> pickupLocation;
When execute select query from the table column "pickuploc" not exactly getting mapped to pickupLocation attribute in defined in the entity.
Here is the response I got:
"pickupLocation": {
"4171": {
"type": {
"name": "UDT",
"keyspace": "delivery",
"typeName": "location",
"frozen": true,
"fieldNames": [
"buid"],
"typeArguments": [],
"collection": false
}
}
}
Using Spring-Data-Casandra-1.5.8
Spring Data Cassandra supports as of 1.5 and 2.0 only primitive types within maps. There's already a ticket to improve Map support. Leave your vote to increase the demand to get it implemented.
Should be fixed in version 2.2.
See https://jira.spring.io/browse/DATACASS-487
We have created a complextype field "carriers" which is an array of Carrier objects. See below metadata
"dataProperties": [
{
"name": "carriers",
"complexTypeName":"Carrier#Test",
"isScalar":false
}]
The Carrier entity is defined as below:
{
"shortName": "Carrier",
"namespace": "Test",
"isComplexType": true,
"dataProperties": [
{
"name": "Testing",
"isScalar":true,
"dataType": "String"
}
]
}
We are trying to return an array of complextype in breeze from a REST service call. We get an error in breeze.debug.js in the method proto._updateTargetFromRaw. The error is because the datatype is null.
Any idea how to fix this issue?
I'm guessing the problem is in your "complexTypeName". You wrote "Carrier#Test" when I think you meant to write "Carrier:#Test". The ":#" combination separates the "short name" from the namespace; you omitted the colon.
Hope that's the explanation.