I currently have a Logic App that has an empty false path since the Logic App. The only reason I use a condition is because the LogicApp should stop when the condition is false. Is there a better alternative to stop a Logic App when a certain condition/statement is reached?
You can use Terminate action:
This action stops the run for a workflow instance, cancels any actions in progress, skips any remaining actions, and returns the specified status. For example, you can use the Terminate action when your logic app must exit completely from an error state. This action doesn't affect already completed actions and can't appear inside Foreach and Until loops, including sequential loops.
You can refer to my logic app:
This is my test result, it seems there is no problem：
Related
Lets say I want to have a TimerTrigger function app that executes every 10 seconds and prints an increasing count(1...2...3...),
how can I achieve this WITHOUT using environment variable?
You're already using an Azure Storage account for your function. Create a table within that storage account, and increment the counter there. This has the added benefit of persisting across function restarts.
Since you're using a TimerTrigger, it's implicit that there will only ever be one instance of the function running. If this were not the case, you could end up in a race condition with two or more instances interleaving to incorrectly increment your counter.
I suggest you look into Durable Functions. This is an extension for Azure Functions that allow state in your (orchestrator) functions.
In your case, you can have a single HTTP triggered starter function that starts a long running orchestrator function. The HTTP function passes the initial count value to the orchestrator function. You can use the Timer functionality of Durable Functions to have the orchestrator wait for the specified amount of time before continuing/restarting. After the timer expires, the count value is incremented and you can restart the orchestrator function with this new count value by calling the ContinueAsNew method.
This periodic work example is almost what you need I think. You still need to add the initial count to be read as the input, and increment it before the ContinueAsNew method is called.
If you need more details about Durable Functions, I have quite some videos that explain the concepts.
I'm trying to check some file conditions inside change-content trigger and cancel the submit based on that condition.
If my trigger fails the operation is still submited to the server. How can I prevent submit?
Any help is much appreciated!
update:
I was using nodejs script as a trigger, exception is not enought to prevent a submit operation. There should be process.exit(1).
Your trigger needs to return a non-zero exit code in order to fail the calling operation.
Make sure that the trigger is blocking and returning its status code to the caller, rather than returning zero and forking so it can run asynchronously.
Note that triggers that run after the fact (like change-commit) can't block an operation, but change-content should be able to prevent a submit from finishing.
I have a nodejs app that has a finite specific sequence of actions.
One of the actions is getting an array of images, sending it to a client, and displaying it for a manual human filtering.
After filtering was done, (say a button was pressed), I need the nodejs app to keep executing the sequence until it's done.
I've been wondering over and over how to perform such a thing (and if possible, without the use of sockets.)
I tried creating a boolean representing if filtering was done, and using
while (!boolean), but server seems to be busy running it so it can't event handle the response which should update that same boolean.
Is there a better way?
Ok completely new to this essentially we want to be able to time out a session after 10mins. that's pretty easy.
We also want to wait for external user input -- essentially data from a multi step form. also pretty easy.
We want to be able to Task.WaitAny (waitforexternalevent("updatedata"), timeout)
But this is causing issues in the orchestration.
Individually these concepts work, however we see the Task.WaitAny to unblock and reuse the first "updatedata" event.. other "updatedata" events never reach the orchestration.
Is this expected behavior, are we mixing concepts in an invalid way, or is this a bug?
We might need to see some more of your code, but with what you've described here I think the behavior you're seeing is what should be expected.
Your orchestration is "waiting" on the timeout or the external event. Once that external event is triggered, the orchestration is going to move forward and, even if something triggers that event again, the orchestration is not expecting/waiting on it.
Again, this is based on the sliver of code you've included in your question thus far. If you need to handle the event being broadcast into the orchestration multiple times you would need to have a loop of some kind.
Hi I'm making a business application in which user can write his custom code and execute it.
How can i handle situations when the custom code generates infinite loops ?
A way is to handle each request in separate child process and kill that process on request completion but if there are thousands of users this doesn't seem to be appropriate. What else can be done in such cases ?