How to make time based notifications with Orion?
Say I want to send the value of an entity every day at noon.
It seems that the functionality has been deprecated: http://fiware-orion.readthedocs.io/en/master/deprecated/
I use Orion notification service to trigger the sending of SMS with an external service (Plivo). So I cannot perform a query instead as recommended in the deprecation notice.
If it's not feasible in Orion, what complementary module do you recommend?
Related
I have a full stack app that uses React, Node.js, Express, and MySQL. I want the react app to respond to database updates similar to Firebase: When data changes, I want a real-time notification sent to my app.
I want to use stock MySQL (no plugins), so that I can use AWS RDB or whatever.
I will use socket.io to push the real-time notifications to the web app.
To avoid off-target responses, I'll summarize various approaches that are not what I am looking for:
The server could poll, or each client could poll. (Not real-time, but included for completeness. When I search, polling is the only solution I find.)
Write a wrapper that handles all MySQL updates, handles subscriptions, and sends the notifications. This is a complicated component that adds complexity. Firebase is popular because it both increases performance and reduces complexity. I like Firebase a lot but want to do the same thing with MySQL.
Use Firebase to handle the real-time notifications. The MySQL wrapper could use Firebase to handle the subscriptions and notifications, but there is still the problem of triggering the notifications in the first place. Also, I don't want to use Firebase. (For example, my application needs to run in an air-gapped environment.)
The question: Using a stock MySQL database, when a table changes, can a notification server discover the change in real-time (no polling), so that it can send notifications?
The approach that works is to listen to the binary logs. This way, any change to the database will be communicated in real-time. The consumer of the binary logs can then publish this information in a number of ways. A common choice is to feed a stream of events to Apache Kafka.
Debezium, Maxwell, and NiFi work this way.
I want to know what Orion's Federation feature is.
I have read the Orion documentation and tried the federation function, and the data was registered in all three Orions.
I thought that the second Orion acts as a Proxy and does not store data, but is that not the case?
If all three Orions store data, is it correct to say that the Federation does not have its own function, but is a concatenation of Subscriptions?
The Federation mechanism you refer is the one on the documentation. In this case, it is based on subscriptions that copy the data among the brokers on entities changes.
Orion also has the registration and request forwarding mechanism. This case, once the register is done, the Context Broker forward the requests to the one registered. This approach sounds closer to the one you are describing but I encourage you to use the first method (based on subscriptions) since all the advanced operations like filtering are working without issues.
A well-designed Federation should not allow value shadowing by a local database. Unfortunately, that's not a feature offered by design by the Orion Broker. That is up to your design and nothing prevents the shadowing, as far as I understand i.e. even you have registered a provider for an Entity, someone can create locally such an Entity, which may be a mess and a source of conflict.
An alternative that may work is to perform the Federation by a REST Service custom built by you that just acts as a proxy against different Orion Brokers. If this custom service is a single entry point you could guarantee a pure Federated system with no shadowing of values.
If I plan to install multiple instances of Orion context broker in a high availability scenario like described here, I am wondering how event notifications are handled?
So If I Register/subscribe to an specific Event, which occours then, will I be notified/called one time, or one time for each CB-instance?
In multi node deployment of Orion ContextBroker as described in referred document, there will be one notification to each event from the broker which will receive the request. The HAProxy will route each incoming request to one of multiple ContextBroker, thus one notification will be generated based on subscription made.
So If you Register/subscribe to an specific Event, then, you will be notified/called one time from one ContextBroker which has received the reuqest.
Some more references about Orion and HA/scaling-out, in the case they can be usefull:
What would be the behavior of subscriptions and notifications in an Orion Load-Balancing scenario?
How to scale Orion GE?
I need to filter subscriptions through logged users (i.e. user_id or organization_id) in a generic context.
The requirements are that any users can manage (edit or delete) only own subscriptions.
As far as I know, there isn't APIs to filter subscriptions by userid, so how can get from orion all subscriptions inserted by owners?
Orion doesn't support the ownership concept in subscriptions. A possible workaround could be to use some descriptive field (in particular, the description field) and a PEP-like proxy using that information to implement a mechanism like the one you want.
At subscription creation time the proxy set the description to the user issuing the creation request.
At subscription modification time, the proxy check if the user issuing the update request matches the one in the description.
The proxy should forbid any attempt of setting/modifying the description field.
Not perfect, but may suffice your case. A proxy like that shouldn't be complex to implement in technologies like Nodejs.
Each day hundreds of thousands of items are inserted, updated and deleted on our service (backend using .Net and a MySql database).
Now we are integrating our service with another service using their RESTful API. Each time an item is inserted, updated or deleted on our service we also need to connect to their web service and use POST, PUT, DELETE.
What is a good implementation of this case?
It seems like not a very good idea to connect to their API each time a user inserts an item on our service as it would be a quite slow experience for the user.
Another idea was to update our database like usual. Then set up another server constant connecting to our database and fetching data that needs to be posted to the RESTful API. Is this the way to go?
How would you solve it? Any guides of implementing stuff like this would be great! Thanks!
It depends if you delay in updating the other service is acceptable or not. If not, than create a event and put this in queue of event processor who can send this to second service.
If delay is acceptable than there can be background batch job that can run periodically and send the data.