As I am having a logic app where the trigger is service bus topic subscription. I want to add multiple subscription ("A", "B","C") for the given topic in my logic app service bus topic trigger . Whenever i select topic it only allows me to select single subscription. Is there any way to add multiple subscription from an array or static variables ? if yes then how to add conditions ? I tried using array, but i have to provide the index of the subscription.
I can use multi trigger logic app for all of the subscriptions to achieve what I am looking for, but is there any other way like using some wildcard characters ***** or / or something else which i am not familiar with .
The action supports selecting only one subscription as you have observed.
Multi Trigger Logic App is indeed one way to go about it but note that the designer doesn't support them, and you will be forced to edit only using the code view.
One alternative would be to split your logic app into two
one for your business logic that is triggered by a HTTP request
one (or more) that is triggered by the service bus subscription trigger and calls the first logic app
Another alternative is to leverage the Event Grid Integration in Service Bus, but note that this is currently applicable only for the Premium Tier.
In this approach, the logic app would trigger based on an event message from Event Grid with details of the subscription that has messages ready to process. You would then use the Get messages from a topic subscription action to fetch the messages to process.
Related
I have a service account that should represent the flow for multiple mail-accounts. The flow is started whenever a mail arrives in a mailbox, then a confirmation should be sent after that. Let's assume I have 100 different mail-accounts in the company and the flow should be triggered for all of them, this should be bundled (dynamically) in the service account. How can this be done?
With dynamically I mean not "hardcoded" mail-accounts in the trigger (because they are changing a lot).
I never have used logic apps, but are they a better solution for that?
I have 2 ways for this
WAY-1
You can either use a Distributed list mail where all the members in your team are the members and trigger an email.
WAY-2
I have created a list adding the person column and adding the members to the list in SharePoint and sent mails using that column. Here is the Screenshot of the flow that I used
I am creating an AdminUI for my users where I set all the permission. As part of the requirements, every time that a user logins on my IdentityServer I need to set some default permissions, but those are handle on my Admin application. Which is the best way to raise an event to let that application that a user was created on the IdentityServer?
The simplest is i think to create a simple WebApi in IdentityServer that returns the latest users and then let the other application poll this API every X seconds. In that way the system is cleanly decoupled. Perhaps expose the data as a a RSS XML document or a JSON list of items.
There is a built in eventing model in IdentityServer that you could use and push notifications to the Admin application. But push is a bit more complicated to get right, especially how to deal with all the failre/error cases.
I's suggest to add a custom event sink to process UserLoginSuccessEvent or any other event you need, here is list of all builtin events. Find their code here.
In the custom sink as suggested in the other answer you can call an API on admin app to inform it about changes.
Here is a sample for custom sink.
I think to keep two applications decoupled you better to setup a service-bus for simple implementation a sub/pub mechanism. when any user complete registration(or any other actions),then as mentioned in another answer handle the events and add message. admin UI should subscribed before to receive these messages with some information to create a user related data.
In my app i have an api layer that defines routes, services layer to perform business logic, and a repository layer that queries the database. Services will call into the repository layer to retrieve data, perform various business logic and then return a response back to the api layer.
Now, I have some business logic that needs to be completed inside a database transaction. For example, let's assume my app allows you to buy tickets to a given event:
Service layer calls repository to atomically reserve tickets in the db by decrementing number of available tickets.
Service layer then makes an api request to process the payment for the ticket.
If the payment succeeds, service layer calls repository to create an "order" for the user and the given event.
If the payment fails, however, i want to rollback the changes made to the ticket availability. (or if for some reason creating the order for the user fails, same thing).
The problem is that it seems like a leaky abstraction if the services layer is aware of database transactions. Is there a better paradigm for this?
You don't want to hold a database transaction open the whole time you are making an API request anyway... You probably want to insert a 'pending' order, then once you get the payment change the status to 'confirmed'. This lets you store details about the error and report on failed payments too
I'm rebuilding the CoinbaseCommerceButton component from scratch, and in order to improve the end-user experience I want to allow the user to continue on using my app after a payment has been detected. Is there a way to do this?
There are currently two ways to do this.
1. CoinbaseCommerceButton
There is an onPaymentDetected callback as documented here. After the callback is triggered, you can safely remove the button from the DOM and allow the user to continue using your application.
2. Webhook Subscriptions
Detected payments can also be registered for via webhooks with the charge:pending event type. See here for a more detailed explanation of how this can be achieved.
In the single page webapp I've recently built I'm getting data for my models using Restangular module. I'd like to add real-time updates to the app so whenever any model has been changed or added on the server I can update my model list.
I've seen this working very well in webapps like Trello where you can see the updates without refreshing the web page. I'm sure Trello webclient uses REST API.
What is a proper way to architect both server and client to archive this?
First of all, your question is too general and can have a lot of solutions that depend
on your needs and conditions.
I'll give you a brief overview for a single case when you want to leave REST APIs
and add some realtime with web sockets.
Get all data from the REST -- Sokets for notifications only.
Pros: Easy to implement both server side and client side. You only need to emit events on the server with
info about modified resource (like resource name and ID), and catch these events on the client side and fetch
data with REST APIs.
Cons: One more request to the server on every notification. That can increase traffic dramaticaly when you have a lot of active clients for a single resource (they will generate a lot of reverse requests to the server).
Get initial load from the REST -- Sockets for notifications with data payload.
Pros: All info comes with the notification and will not cause new requests to the server, so we have less traffic.
Cons: Harder to implement both server side and client side. You will need to add data to all the events on the server. You will need to fetch data from all the events on the client side.
Updated according to the comment
As for handling different types of models (just a way to go).
Client side.
Keep a factory for each model.
Keep in mind that you need realtime updates only for displayed data (in most cases), so you can easily
use memory caching (so you can find any entity by its ID).
Add listener for every type of changes (Created, Updated, Deleted).
In any listener you should call some initObject function, that will find entity in the cache by ID and extend it, if there is no entity with such ID, just create a new one and add it to cache.
Any Delete just removes an entity from the cache.
Any time you need this resource, you should return the link to cache object in order to keep two way databinding (that is why I use extend and not =). Of course, you need to handle the cases like: "User is editing the resource while notification about deleting comes".
Server side.
It is easier to send all the model then just modified fields (in both cases you must send the ID of resource).
For any Create, Update, Delete event push event to all engaged users.
Event name should contain action name (like New, Update, Delete) and the name of resource (like User, Task etc.). So, you will have NewTask, UpdateTask events.
Event payload should contain the model or just modified fields with the ID.
Collection changes can be handled in two ways: with add/update/remove items in collection or changing all the collection as a whole.
All modifications like PUT, POST, DELETE are made with REST of course.
I've made a super simple pseudo gist for the case 1). https://gist.github.com/gpstmp/9868760 but it can be updated for case 2) like so https://gist.github.com/gpstmp/9900454
Hope this helps.