I have following questions related to events in composer.
Question 1: Can i write a READ acl rule for event to define which participant will receive this event?
Question 2: Is there a way to send events to specific participant?
Events are simply serialised and put onto the Hyperledger Fabric event bus. At present HLF doesn't have the concept of topic/queues to segregate the messages on the bus, or rich security policies to determine who can access the events.
At this time ACLs are not applied to Events, and there isn't a way to send events to a specific participant.
However we would really like to know your use cases and requirements in this are so please raise a github issue at
https://github.com/hyperledger/composer
and of course contributions welcome.
Related
I have a User Microservice, that publishes events when a user is created, modified, or deleted. In addition, I have a Calendar Microservice that needs the user data. The Calendar service, subscribes to the user events and keeps a read only copy of the needed data.
I have just added an Account Microservice that needs the existing user data and I have used the same model as above. What is the best way to get the existing user data into the Account Microservice?
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
I've loaded data a lot in the past. I know how to make it work, but I am looking for a best-practice and a way to do it with minimal coordination and dependencies with other services.
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
What you probably want here is a design in which you pull, rather than push, copies of the events to new systems: see Greg Young, Polyglot Data.
In broad strokes - the subscriber keeps track of the high water mark, and asks for more events after some mark, and then the event store answers that query with zero or more new events, in order. The twitter timeline api can give you a sense for how that might work -- sadly, the images that explained the ideas seem to have been removed from the docs, but some of them have been captured here at stack overflow, and by the wayback machine
I'm currently working on a project that is a sort of an extension to an existing project.
Existing Project:
A product that is already there and has a pub/sub system of its own. It uses GraphQL.
Let's take an example.
There's a group (GROUP_1) and some users are a part of that group.
Let's say user A calls a mutation, the other users' sessions subscribed to that mutation get an update regarding the same(that A made these changes). The changes are reflected in their frontend accordingly.
What do we need?
Instead of user A making the change, we want to update when a third party service notifies us to make the change.
The thing is that the third-party service uses MQTT protocol and will give us a topic (for GROUP_1) to which it will publish the messages and we need to subscribe to it. Upon receiving the message if the message satisfies our condition we will call the mutation on behalf of the user the message specifies.
Problem
So we need the client to listen to that topic forever.
And there can be an addition to the topics provided. New groups can be added in the future. So we will have different topics for different groups(GROUP_1, GROUP_2, etc)
Research that I did
To have a client that listens to a topic permanently and we can add to that client new topics as we generate new GROUPS.
And then let this client update the GraphQL API eventually reflecting changes in the session of the users in that GROUP.
I think that's not the way MQTT should be used, we should make changes in the existing project but that is not in our hands as of now.
Constraint
We can't change the existing workflow of GraphQL mutation and subscription that the existing project has.
Questions
Is there a better approach to do this with the given constraint?
If not then how should we go about creating a client that listens permanently. Shall we have a server that's up for the same or is there a better way to do this?
Maybe I'm not understanding your post, but the solution seems pretty simple: Create a new client that subscribes to what the "third party service" publishes to, and then publish to the Topic that the existing clients subscribe to, all the info that was passed in by the 3rd party. The beauty of a Pub/Sub architecture is that adding functionality to an existing system is done by just adding a new set of clients...subscribers, publishers, or both. The existing system doesn't have to change at all, if you can reuse the existing Topics and data formats. So you create a "Proxy" that takes in the new info, and publishes out in the old format.
I have implemented the "tompaana" solution for bot-agent-handoff (1 to 1 conversation), but how can I establish a "1 to n" scenario (i.e. one agent handling multiple users after bot escalation)?
I have implemented as per the link given below :
Referred link : https://github.com/tompaana/intermediator-bot-sample.
The way I have implemented it was using back channel in the directline api. When agent connects pass the agent details as well as session details with the "start conversation". However any mechanism that stores conversation reference of specific chat with the session would work
https://github.com/microsoft/BotFramework-WebChat/tree/master/samples/04.api/b.piggyback-on-outgoing-activities
For the intermediate-bot-sample, here is a comment by #tompanna with regards to a call center support scenario issue:
I think the best bet to implement a call center, given that one want to use the message router, is to take the message routing component source and customize it based on one's needs. LiveEngage is one that has routing capabilities out-of-the-box, but can be enhanced with custom code. I have implemented a simple connector for LivePerson service (Node.js). Ibex Dashboard is another OSS project by Microsoft containing enablers for this kind of a scenario (but does not do the job out-of-the-box).
You can take a look at the BotFramework HandOff experimental sample. Also, there is a Node sample by TDurnford where you can message #list to get a list of users waiting to talk to an agent in the queue, and message #connect to connect to the user waiting at the top of the queue.
Hope this helps.
When making something like a chat application using Spring Websockets, it is useful to know who all is subscribed to any given topic. For, e.g. presence data displayed in the clients.
I know that I can implement ApplicationListener and keep my own list of "connected users", but it seems like the library must already be doing this work.
What's the recommended way to get active subscription info from the library directly (and without maintaining my own list in memory or db).
You're right, you could use ApplicationContext events, but unfortunately those events deal with user sessions events and broker events - so you won't be notified when a user subscribes to a particular topic.
You could do that when using the SimpleBrokerMessageHandler, by getting the SubscriptionRegistry. But again, the SimpleMessageBroker is not for production use.
If you're using RabbitMQ, you can get that information from its REST API.
The thing is, this is very specific to the broker implementation, so I'm wondering if a feature like that makes sense in Spring Framework. Could you open a JIRA issue to start the discussion?
I'll try to explain my goal as good as I can;
I want to trigger a script whenever there is a new computer added to a Organizational Unit.
To do this i need to activate the logging of this event under the local security policy/audit policy. I guess my question is, do I need to do this on all the domain controllers, or is it enough to do it one just one?
Also, is it possible to see the event from a member server with the Management Tools pack installed? As I don't want to put too much work on the Domain Controllers.
Here is the Microsoft article that gives 4 ways of tracking changes in Microsoft Active-Directory. You will find everything you need from configuring the eventlog to receiving notifications by way of different kind of polling.