I want to be notified when an entity is created or deleted.
Does Orion support subscribing to the creation and deletion of entities?
Yes it does, in Orion Context Broker - NGSIv2 - you have got the following alteration triggers:
entityUpdate: notification is sent whenever a entity covered by the subscription is updated (no matter if the entity actually changed or not)
entityChange: notification is sent whenever a entity covered by the subscription is updated and it actually changes (or if it is not an actual update, but forcedUpdate option is used in the update request)
entityCreate: notification is sent whenever a entity covered by the subscription is created
entityDelete: notification is sent whenever a entity covered by the subscription is deleted
Complete documentation:
https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#subscriptions-based-in-alteration-type
Best.
Related
Currently, I try to send SaleToAcquirerData metadata to the terminal when the order to sync to Adyen Backend, I have checked at Adyen Backend but don't see metadata and my webhook cannot receive metadata
I need to send metadata to the terminal and receive metadata at my webhook
In this answer, I expect that you
Already receive webhooks events and that your webhook is well configured
That you receive core data from webhook events but that the POS related additional data is missing
Have you activated the POS additional data for this specific webhook?
You can do it in the Customer Area, Developer -> Webhook, select your webhook and then "Additional settings".
The UI looks like this :
Save, and exit. Your future webhooks events should contain POS metadata. Please note that you may still receive some events without the metadata that you except, because they were already generated at the time they were created.
EDIT : In case you want to use the API for this, you can also PATCH the existing webhook with additional settings using the new Management API.
While waiting for extra information, your question may be understood another way : You want to access the metadata field of the additional data section of a webhook event.
In that case, these metadata fields should be submitted at the time of payment in the POST /payments request.
You can find more information about this in the Webhooks documentation.
This is a follow up to the following question:
How to prevent Ocp-Apim-Trace: true and ocp-apim-trace-location in production?
My API consumers must have a subscription key to be able to use my API.
However, I do not want them to see the detail traces provided in ocp-apim-trace-location. The detail trace provides them visibility to my internal service URLs and details that can be a potential security risk.
How to eliminate tracing (prevent Ocp-Apim-Trace) when the call includes a subscription key?
There is no way to disable tracing funtionality, not sending this header will disable tracing collection for one request only. But do know, that only admin users are capable of collecting traces, if this header is supplied along with subscription key that does not belong to admin account (or no subscription key at all) no traces will be collected. The idea here is that traces may expose information service owner may not be willing to share with developers.
Actually, you could design APIs belong to an open product to be callable anonymously.
Create a new product and uncheck Require subscription in its settings. Any API added to such product will be callable without a key anonymously.
So that you could let your consumer anoymously call your API without subscription key and then eliminate tracing.
For more details, you could refer to this article.
I'm working on synchronization from our application to Exchange and back. I've set up a streamingnotification to the calendar of a room/resource defined in Exchange.
When I create an appointment in the calendar of the room I get a notification in my application, which is great. However, I also want to change this appointment from our application and send these changes to the calendar of the room in Exchange. That is no problem, but then I also receive a notification from Exchange. Basically Exchange is telling me that item 'x' has changed, when I'm the one who changed it, so I already know and don't want to process this change.
Is there a way to determine where the change originated from, or tell EWS to not send a streamingnotification when I edit an item?
Whenever you change an Item in EWS with UpdateItem the lasted ChangeKey is returned in the Response https://msdn.microsoft.com/en-us/library/office/dn605828(v=exchg.150).aspx . This property allows you to track when changes occur on the Item or to validate if no changes has occurred since the last modification.
The PidTagLastModifierEntryId property https://msdn.microsoft.com/en-us/library/gg672131(v=exchg.80).aspx will tell you who last modified an appointment.
I'm trying to send an event to a consumer, in order to modify one attribute on an entity of the Context Broker.
The issue is, that I've got the entity that is going to receive the derivation event, under a Fiware-Service and Fiware-ServicePath.
I don't know where to place that information. I found no information on any of the documents (not even in user guide nor programmer guide).
Where should I place Fiware-Service and Fiware-ServicePath to be part of the header of the REST call?
Indeed, the feature of CEP to add headers to meet options in Orion has been created, but exact schedule for implementation not finalized yet.
Unfortunately, CEP does not support this feature presently.
There is some way to subscribe to Orion (e.g. Car entity), without receive the old entities?
Example:
Orion has -> Car A, Car B.
I do onchange subscription and Orion sends me at same time:
Car A notification and Car B notification.
We need the following:
Orion has -> Car A, Car B.
I do onchange subscription but don't receive nothing at this moment. If in a future Orion receives Car B, or changes some attribute of Car A or Car B, then send the notification.
Is that possible?
The behaviour is explained in the the user manual:
You may wonder why accumulator-server.py is getting this message if you don't actually do any update. This is because the Orion Context Broker considers the transition from "non existing subscription" to "subscribed" as a change.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).