Logic app executed twice for the same message from servicebus queue with message state=Active and Scheduled - azure-logic-apps

A message is being dropped to Service bus queue with ScheduledEnqueueTimeUTC and Service Bus Connector in Logic app has trigger set to pick messages from queue at 12:05AM EST EveryDay.
Problem: Logic app has picked the same message twice one with Service bus message properties State='Scheduled' and other with state='Active' with same sequenceNumber. May i know when this happens and how can this be solved.

Problem: Logic app has picked the same message twice one with Service
bus message properties State='Scheduled' and other with state='Active'
with same sequenceNumber. May i know when this happens and how can
this be solved.
Here we discovered one of the workarounds that will meet your needs. To pick and send a message only once, we must set our settings to split on as seen below.
NOTE: I tried using Logic app standard, as this option is not available in Consumption plan
Please refer this MS DOC & SO THREAD for more information .

Related

How can I get notified for every Exception occurrence in Google App Engine?

I want to get notified (through email of slack channel) for every Exception occurence in my GAP services.
When I'm trying to create a notification through GCP Error Reporting, it seems like I'm being able to get one notification per incident (and not per occurrence), and that it is also being queried only once a day/hour/month.
I've also tried to create a policy in GCP Logs Monitoring based on log severity, but of course I don't get notified only for exceptions, and the slack notifications just announce that a threshold is being passed, without the actual data I want to get by push.
Any way I can make Error Reporting notify me per each occurance?
Is there any other internal tool by GCP that notify when event occurs? or should I use an external tool such as Epsagon/Operations (formally Stackdriver)?
So it seems like there is no availability for getting a pushed event on each exception occurrence, and since I didn't want to query it by pull (with ereport) or to get only new exceptions (through Stackdriver), I had to go with an external service such as Datadog.

How to read azure service queue message in Logic apps?

I am trying to create small Azure Logic app which will have some order flows.I will get the message in service bus queue. I need to get the message in logic app and based upon the message content, I need to follow the further steps. The message will contain the order data as well. There will be conditional logic, let's suppose, if order type is "new", I need to call HTTP request where I need to pass the message data as body content in POST request.
I have create a service bus queue and in logic apps, added service bus trigger which will be called when message will be received in service bus queue(automatically).
I need to able to implement conditional logic but as i am newbie in this, i am not sure how to pass this data in condtional logic from message.
You just need to mention the condition in the block and design the flow that we require. If the condition is true I have added the HTTP action mentioning the required details. For understanding purpose I have mentioned the other condition to trigger an email.
Here the flow of my logic app
If you want to continue the flow just click Add an action in True Connector.
REFERENCES:
Get started with Azure Service Bus queues (Azure.Messaging.ServiceBus) - Azure Service Bus | Microsoft Docs

What happens when an Azure Logic App is disabled?

What happens when an Azure Logic App is disabled?
Does the current "run" finish, or is it terminated at whatever action is currently on?
In our case, we have a logic app that has a trigger on a message being added to a Service Bus queue ... the Logic App is doing a Peek/Lock read of the message
Various actions, including a SQL Db write, and finishing with a Service Bus complete on the message
If the current run finishes, then we don't have to worry, as that particular message has been "processed"
But if the current run is terminated wherever it is, Service Bus will return the message to the queue after the timeout, and then when the Logic App is re-enabled, we'd re-process the original message from the Service Bus queue
Current in flight runs will finish, but the trigger will stop checking for new events and invoking new runs. You can cancel runs to stop ones that are in progress, but currently is a separate gesture to just disable.

Should I need a database to ensure immediate consistency with a message-oriented middleware?

App A wants to send domain events to App B through a middleware like RabbitMQ.
Let's take the example of one domain event called UserHasBeenRegistered, involving by the creation of the User entity.
A would inform B that this latter should send a welcome email, by sending this event.
I have in mind two workflows:
First:
- App A registers the user and the event is generated.
- App A sends the event directly to B through a queue provided by RabbitMQ
Second:
- App A registers the user and the event is generated.
- App A saves the event in some kind of event store as a database table (if relational) in the same local transaction used for persisting in database this new user.
- An asynchronous scheduler queries the event store, find this new user registration and sends the message through the RabbitMQ's queue.
Do you see the difference?
Yes, one is longer than the other... but the second is far more safe! albeit less performant.
Indeed, what while in the first case, the registration is rollback due to an exception thrown just after the publishing was made? => the mail would be sent whereas the user was not persisted.
This could be fixed by implementing a global XA transaction (two-phases commit), but it is well known that some middleware don't support it.
Therefore, is the second workflow mostly used in critical application?
What are its drawbacks?
I plan to implement one of both solutions for my project.
I had the same task and it was done as a mix of your two workflows:
App A registers the user and the event is generated.
App A sends the event which has ttl set to non-zero value directly to B through a queue provided by RabbitMQ.
App B receive event and send welcome message to user and store flag that welcome message sent.
There are background script which check whether there are newly registered users from last ttl + 1 time interval who doesn't receive messages.
You can remove background script and flag storing and stick with first workflow from you q. The cases when messages lost or any other cases are damn rare (with welcome messages sending it might be 1 failure per 1billion users) and unnecessary application complication may give you more errors.
The second workflow looks also stable, but why you are using RabbitMQ then?

Apache Camel - Listening to route events like completion of a route

I’m stuck at one particular requirement in camel , I’m processing a set of files and when any exception occurs i send a message to an exception queue , and from the exception queue im sending an email about the failure , the functionality is working fine but I end up sending many mails, like if 10 files fail im sending 10 emails, is there a way to send only one mail , like I would want to wait for the entire route to finish , then go look the exception queue and send a single mail stating what has failed (by processing the exception queue )
I'm open for suggestions.
I had to do this scenario once (inversed though - mail on success). I had a handy MySQL database configured and ready, so I just added each event from the queue to the database. Then once every now and then, extracted all info (and deleted it)- simply select * from events; delete from events; from the database and created a mail.
You could process the error queue with the aggregator pattern, it is very nice for these tasks. http://camel.apache.org/aggregate-example.html . You still need to know WHEN the aggregator should fire off a message. If you can, trigger a "finish, send mail" event such as in the example in the link above.
The most simple way would be to time schedule these mail notifications. Take a look at: http://camel.apache.org/simplescheduledroutepolicy.html . You can set it to run your route for some good choice of time, then when it fires off, you set the aggreator to complete upon timeout, and make the timeout good enough to empty any reasonable queue size of errors, but not too large.
At least that's my suggestions to your issue

Resources