Fiware Cygnus - Change service for only some entities with name mappings? - fiware

Context :
I have a machine with Orion Context Broker, Cygnus and Ckan. I have 3 entities (sensor1, sensor2, sensor3) and I use name mappings for these three entities to write in a single Ckan datastore named sensors. So far everything works.
What I want :
These 3 entities are in the fiware-service default and I want them to write in the fiware-service paris (the paris organization in Ckan)
Question :
How to make the name mapping change the default fiware-service of these 3 entities into paris, without changing it for all entities?
What I tried :
I tried this, the problem with this code is that all entities of the fiware-service default are moved to the fiware-service paris, not just my trhee entities.
{
"serviceMappings": [
{
"originalService": "default",
"newService": "paris",
"servicePathMappings": [
{
"originalServicePath": "/",
"entityMappings": [
{
"originalEntityId": "sensor1",
"originalEntityType": "device",
"newEntityId": "sensors",
"attributeMappings": []
},
{
"originalEntityId": "sensor2",
"originalEntityType": "device",
"newEntityId": "sensors",
"attributeMappings": []
},
{
"originalEntityId": "sensor3",
"originalEntityType": "device",
"newEntityId": "sensors",
"attributeMappings": []
}
]
}
]
}
]
}

Looking to the examples in the Cygnus documentation maybe you could try with a regular expression pattern:
Last but not least, the original names support Java-based regular expressions.
For instance:
{
"serviceMappings": [
{
"originalService": "default",
"newService": "paris",
"servicePathMappings": [
{
"originalServicePath": "/",
"entityMappings": [
{
"originalEntityId": "sensor[1-3]",
"originalEntityType": "device",
"newEntityId": "sensors",
"attributeMappings": []
}
]
}
]
}
]
}
I'm not fully sure it works for you but it may help...

Related

Couchbase: How to remove channel access for a document through Sync function

I'm new to couchbase. I want to update channels for some of the documents through sync functions. But right now, it is not updating but adding an extra channel to the document's meta but not removing the existing channel. Can anyone suggest how I can remove the existing channel in the document?
Sync Function:
function(doc, oldDoc) {
//....
if (doc.docType === "differentType") {
channel("differentChannel");
expiry(2332800);
return;
}
//.......
}
Document:
{
"channels": [
"abcd"
],
"docType": "differentType",
"_id" : "asjnc"
}
Metadata:
{
"meta": {
"id": "asjnc",
"rev": "64-1b500000000",
"expiration": 1650383285,
"flags": 0,
"type": "json"
},
"xattrs": {
"_sync": {
"rev": "1-db30e607872",
"sequence": 777,
"recent_sequences": [
777
],
"history": {
"revs": [
"1-db30e607872"
],
"parents": [
-1
],
"channels": [
[
"differentChannel"
]
]
},
"channels": {
"differentChannel": null
}
}
}
}
Expectation of the document with the same metadata:
{
"channels": [ ], // <--- no channels
"docType": "differentType",
"_id" : "asjnc"
}
With this sync function, for the document of type differentType, the channel differentChannel is set in the xattrs section in the metadata. But the channel that was added earlier from the couchbaseLite is not getting removed. Can anyone help?
I answered this in the Couchbase Forums: https://forums.couchbase.com/t/remove-channels-from-a-document/33212
The "channels" property in a document is counter-intuitively not describing what channels the document is currently in - it's just a user-definable field that happens to be the default routing for channels if you don't specify a sync function. It's up to the writer of the document what it should contain.
If you have another means of channel assignments (like "docType" in your case), then you don't need to specify "channels" in the document. The sync metadata shows that the document is in "differentChannel" at revision 1-db30e607872 but the contents of the document can be arbitrary.

ambari rest API + set json configuration in ambari

To create a new config group, it is mandatory to provide a config group name, a tag and the cluster name to which it belongs. The tag as seen in this example is a name of the service. Two config groups with the same tag cannot be associated with the same host.
how to run the following json file with curl ?
in order to set this config group in ambari
POST /api/v1/clusters/c1/config_groups
[
{
"ConfigGroup": {
"cluster_name": "c1",
"group_name": "hdfs-nextgenslaves",
"tag": "HDFS",
"description": "HDFS configs for rack added on May 19, 2010",
"hosts": [
{
"host_name": "host1"
}
],
"desired_configs": [
{
"type": "core-site",
"tag": "nextgen1",
"properties": {
"key": "value"
}
}
]
}
}
]
 reference - https://github.com/swagle/test/blob/master/docs/api/v1/config-groups.md
Is your question about how to send multiline json with curl? You can find different methods here.

On watson conversation panel how to set the intent right on the respond json?

i am building a conversation on the watson conversaton, and in a point, togeter with my "response" json, i woul also link to set a new intent for the user, i tried to add this to the json, but with no result.
There is a way to do this?
As you can see in the Official documentation, you can use context variables for save values.
A context variable is a variable that you define in a node, and
optionally specify a default value for. Other nodes or application
logic can subsequently set or change the value of the context
variable.
So, in this case, you'll create in your JSON advance (like your example) something like:
{
"context": {
"intent": "fgts",
"confidence": 1
},
"output": {
"text": {
"values": [
"Your text here"
],
"selection_policy": "sequential"
}
}
}
And in your back-end application, you can access the value in the response JSON object from your POST /message, with something like: response.context.intent and response.context.confidence
Obs.: By default, Watson Conversation service will return the name of the intent that Watson recognizes and the confidence level.
If really after these instructions you want to use your method. You can see my example below:
{
"output": {
"text": {
"values": [
"text here"
],
"selection_policy": "sequential"
},
"intents": "test"
}
}
And your app return:
{ intents: [ { intent: 'helpBot', confidence: 0.5930036529133407 } ],
entities: [],
input: { text: 'ajuda' },
output:
{ text: [ 'text here' ],
nodes_visited: [ 'node_16_1511443279233' ],
intents: 'test',
log_messages: [] },
context:
{ conversation_id: '83d88b05-7c76-457d-bd5f-7820be455a3e',
system:
{ dialog_stack: [Object],
dialog_turn_counter: 2,
dialog_request_counter: 2,
_node_output_map: [Object],
branch_exited: true,
branch_exited_reason: 'fallback' } } }
See more about accessing values using Conversation Service.

Chef use node_name variable in JSON role

Is there a way to use NODE_NAME value in a role ?
In fact, I'm writing a base role that is setting nodes hostnames and I wish to use NODE_NAME as "short_hostname".
{
"name": "Chef-RHEL",
"description": "Chef-RHEL role",
"json_class": "Chef::Role",
"default_attributes": {
"set_fqdn": "*.example.com",
"system": {
"timezone": "Europe/Paris",
"short_hostname": "{NODE_NAME}",
"domain_name": "example.com"
}
},
"override_attributes": {
},
"chef_type": "role",
"run_list": [
"recipe[system::default]"
],
"env_run_lists": {
}
}
NODE_NAME is correctly configured in /etc/chef/client.rb.
Thanks a lot !!! :)
This is not possible directly, roles are static JSON data only. You can use some kind of string replacement in the recipe code but that requires changes in the cookbook consuming the attribute first.

PATCH request for SCIM 2.0

We are sending PATCH request to a server in SCIM specification.
As per the SCIM specifications, the request should contain following attributes in PATCH request.
op
path
value
So if we are changing the 'givenName' attribute from core schema then the PATCH request will be in following way, (ref: https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2)
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[
{
"op":"replace",
"path":"name.givenName",
"value":"Ravindra"
}
]
}
Now what should be the 'path' attribute if are modifying any SCIM extension, let's say enterprise extension.
Is the following representation is correct for enterprise extension?
{
"schemas" : ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[
{
"op":"replace",
"path":"urn:ietf:params:scim:schemas:extension:enterprise:2.0:user.department",
"value":"Engineering"
}
]
}
As in the ABNF to which scim filters should adhere (see section 3.4.2.2 of RFC 7644), when you refer to an attribute part of an extension you should do URI:attribute_path, so in your case this is "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department"
I was getting a similar error when attempting to PATCH the "active" value of an enterprise user. The solution is simple: change your "path" value in the example above to simply "department".
For completeness, here's the PATCH body that worked for me in Postman:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op":"replace",
"path":"active",
"value":"false"
}
]
}
Attribute '.Operations.[].value' must be of type hash
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"Operations": [
{
"op": "replace",
"value": {
"active": false
}
}
]
}
Hope this will work!!