My app is checking to see if blob storage has changed. If it has changed it will send an email and work as intended. However if the blob storage has not changed it will continuously check the trigger till it has.
My app contentiously check for triggersHow the logic app is set up. The other 2 parts work fine
Related
I have a azure logic app that monitors my emails and when target is found, it drops the attachment into blob storage. The plan is a consumption plan.
The issue is, sometimes it takes up to 50 minutes for the email to be grabbed and dropped. I know there is a startup time when things go idle, but I was reading seconds/minutes. Not close to an hour. Does anyone know how I can trouble shoot this?
sometimes it takes up to 50 minutes to grab and drop the email
Based on this doc ,
The reason for delay is:
When the triggers encounter a new file, it will try to ensure that the new file is completely written. For instance, it is possible that the file is being written or modified, and updates are being made at the time the trigger polled the file server. To avoid returning a file with partial content, the trigger will take note of the timestamp such files which are modified recently, but will not immediately return those files. Those files will be returned only when the trigger polls again. Sometimes, this may lead a delay up to twice the trigger polling interval. This also means that the trigger does not guarantee to return all files in a single run when "Split On" option is disabled.
For more information you can refer this:
. Automate tasks to process emails by using Azure Logic Apps | MS DOC, .
.How to Send an Email with one or more attachments after getting the content from Blob storage? | SO Thread & Logic app Created with add email attachments in Blob storage .
Is it sensible to use the stop() method to issue a rest api call, and send data up to the cloud (which may take 0.1s-5s based on connectivity)?
requestBuilder.acceptJson().body(jsonDataBody).getAsJsonMap()
I ask, as i can consistently reproduce an issue on the simulator where no data is being sent when i close the app, but it goes if i call the same process via a button. On real devices it seems to work fine, but i am getting occasional customer feedback that it isn't always working, ie. data isn't being sent to the cloud (tho no errors). I cannot reproduce it using my own real devices.
I'm having to code blind and just force it by putting in a new async rest call when i do screen navigation, which does the same as stop() except uses this method
requestBuilder.acceptJson().body(jsonDataBody).fetchAsJsonMap()
Background:
I have my data in a cloud database, fronted by Rest APi's. My app uses storage to store the datetime of when the last upload and download of data was. When i open my app, via start(), it issues a rest call and gets all data, with a datetime stamp > last download datetime. when i close my app i issue another call, via stop(), to send all data locally changed since the last upload datetime, to the cloud. Each record has a lastUpdateDatetime entity property.
Thanks
That's problematic due to two reasons. First the simpler case:
OS's can invoke stop()/start() quickly so you're app will stop and start almost immediately and this might trigger data corruption if you don't guard against it
The worse problem is that if an operation takes a bit longer some OS's might kill it. You can use background fetch to perform downloads/uploads while your app isn't running and that would solve the technical problem here
Personally, I would just send data on change. If change it too rapid I'd add a time threshold for sending but send during the app running and not on stop(). Notice that on the device the situation is far more complex as it can suddenly decide to kill the app to make room for the phone app or another critical app. You need to program defensively and try to avoid assumptions where possible.
I've got a logic app that I want to be able to run ad hoc and specify the parameters when run. The closest manual trigger i could find was the HTTP request.
As a workaround, I'm calling it from postman where the JSON body can be defined.
While postman works, I'm looking for a way to trigger the app from within azure and provide the JSON body.
Thank you
Actually there are many way to trigger the logic app and process the json data.
You could try with service bus trigger or blob trigger, the below is my test with servicebus. I send a json message with Service bus Explorer. Note: in the logic app the json data is encoded with base64.
The below is the result.
However from the action you could find it has a Interval property to set, it means it may be not triggered immediately. And mostly other triggers need to set the Interval, so if you want to trigger immediately, suppose the HTTP request is the best.
My workaround is a Recurrence trigger every 1 minute and let it kick off and then edit the trigger to every 1 month and save it. Then I disable the Logic App to make sure it does not trigger automatically.
Inside my logic app, I am initializing a variable and this variable's value can change over the course of logic app execution. While logic app is still in running mode (waiting for external event to happen) I want a way to find the current value of the variable in logic app.
I can always store value of this variable in data store like SQL server or blob storage and read it from there but I don't want to use external storage. Given that logic apps are kind of stateful in a way, I am wondering if there is a way to get variable value.
So, there isn't a way to peek at the state of a Logic App while it's running. Some data might be available in the Run History, but that's not necessarily real-time and there no easy way to correlate it with any external info.
That means an external mechanism is you're only practical solution, but there's nothing wrong with that.
My suggestion would be an Azure Function + Redis Cache. The Logic App can update its state periodically by some key value, [LogicAppName]+[OrderID] for example, then another client can query on that same pattern.
Eventually, you may want to elevate this to Application Insights if you fine the need to track the entire app or business processes.
I use simple action like Http POST action with fake url and "post" my variable in the post data.
if you need it to run on the actual environment (not only when debugging) you can set the Configure run after to continue even when the HTTP step failed.
I would like to have a "user message" available for every request sent back by the server. If there is not a user message, the message goes back blank. If there is one, an icon is activated on each user screen after their request is completed.
[edit]
The "user message" is something that is being set by an administrator for the application I'm deploying. The administrator can enter text into a field and click a button to send this message to every other user of the system. Any time another user performs any kind of action, the current user message is attached to the JSON response and handled by the front end.
In order to optimize this, I want the message to be stored in memory (not in the database).
I have tried to use static. I have tried to use HttpApplicationState. In both cases, the value of the user message is "blanked out" after some period of time. After some research, it appears that both statics and HttpApplicationState are subject to IIS and when it decides to recycle the application pool. (or some such)
This volatility of a static is mysterious: it should be static - so long as IIS itself lives, this variable should live. It should not be dependent on some kind of "reset" or whatever. The HttpApplicationState is some other situation that I don't fully understand.
I would like a way to store a value in a non-volatile variable that I can rely on. If I set this value today, it should be there tomorrow, or next week, so long as IIS is not stopped and restarted.
Any help?
here is what i have done to solve the problem as per the accepted answer below:
the user message is a sometime thing. so when the message gets set by some administrator, store the response in the database at that point in time and store it in the Application["UserMessage"] object.
when round-trips from users come in, the in-memory text for the user message gets added to the json return value.
the message can be cleared by the administrator at any time, which clears both the in-memory message and the database field.
when IIS decides enough is enough and recycles the application, the Application_Start() method (among other tasks) will also re-seed the user message from the database value that was stored when the user message was set (as per step 1).
now the application works as expected. no extra price is paid going to the database for every user request into the system - the user message always comes from memory. in addition to this, the database is updated or loaded for the user message very few times.
Application cache is a good place for it. The problem for you is, you think you cannot rely on it. Please see the later part of my answer where you will find how to make sure that the value is always there even if after iis restarts or iis recycles your application.
You can store the value in application cache. It can be done as follows
Application.Add(name,object)
Later you can retrieve it in each request by using this code
Application[name]
It works like session but the only difference is it is application wide and all the request from all user will get it. When you first time assign set the value, store it in db as well as application cache so that you can later make a query from db and store it in application cache if value is not there and then retrieve it from application cache.
You should restore the application cache from the database on Application_Start() event which fires every time the application starts or restarts. This way you can ensure that it is always in the application cache.
I would like a way to store a value in a non-volatile variable that I
can rely on. If I set this value today, it should be there tomorrow,
or next week, so long as IIS is not stopped and restarted.
In this case you cannot store this value in memory. The memory is something that is allocated for you by IIS to host the AppDomain of your application. IIS could recycle your application at any time and wipe out the memory. While IIS continues to live your application doesn't. So you cannot rely on it. The only reliable solution in this case is to persist this information in some non-volatile storage such as a file, database, ... the choice is really up to you but it should be out of the process of your AppDomain.