Hi All,
I'm trying to handle exceptions raised through API calling, but execution stops even after Abort Transaction is set to No. My API is an integration service, I'm calling this API in Services app, which is further used in Reactive App to show a red icon - for users with the error - and disables that user (sets isActive to False in DB).
Context:I have a list of emails which I run it through GetSchedule(Microsoft Graph API) method one by one to get Schedule of their calendar. But it stops after the first call.
Also, upon searching I found this statement in documention :"In Reactive Web and Mobile apps, the Abort Transaction property isn't available when you are handling exceptions in client side."
What does this mean?
Thanks,
Aman
yes, exactly,
put the stuff that causes the exceptions (API call) and the handling of those exceptions in that separate CallApi action.
So, I don't think you are doing anything in your own database, so this is fine, otherwise, you would have to think about at some point also committing.
I don't exactly know what you are doing in all those ListAppends, but I would probably just give a single 'result' back from the new CallApi action, and do the appropriate ListAppends in the parent action (but that's a matter of personal taste, I would want the lower action to only know things about the current email he is working on, not about all the others)
Dorine
So 'happy flow', means everything that happens when nothing goes wrong, so the flow where no exceptions happen at all. So in Outsystems, the happy flow of a given action, is what happens on the left between Start and end node.
Hi @Aman Devrath ,
On exception, the code leaves the happy flow the exception handler is for, and doesn't go back to it, it only flows through the appropriate exception flow.
After that, it goes on flowing throught any happy flow in a higher level (e.g. a calling action) than where the exception was handled. As long as exception is not handled, the happy flow is skipped.
Abort transaction is not about flow, but about how the database transaction is dealt with. Setting this to yes will make sure everything that happened inside this transaction is rolled back, as if it never happened.
Database transactions live on server side, not on client side.
So for your underlying question (if I read this correctly), you would like to go on with next item in loop if exception happens. For that, move the flow for a single item + the exception handling of what goes wrong in that flow, into a separate action. In the action where you loop, just loop (for each) and call that lower action in the flow.
Oh,
I forgot to say, if you would do an abort transaction for the item that goes wrong, you will have to do a commit transaction for items that go right, either at end of happy flow of your action doing a single item, or inside the forEach, right after calling it.
Thanks for the reply @Dorine Boudry.When you said this - "move the flow for a single item + the exception handling of what goes wrong in that flow, into a separate action. In the action where you loop, just loop (for each) and call that lower action in the flow." - my current logic utilizes for each loop and I have a called exception handlers for all the exceptions. Shouldn't this work ?
nope,
whenever an exception happens, for example inside your loop, the flow goes to the exception handler, (if there is any) and NEVER GOES BACK to the happy flow on the right side of that action. The place it goes next after running through the exception flow, is the happy flow of the calling action.
Oh. I get it now.
after the changes - after the append is the new action which has all the API calls and assignments to variables The new action:
This is what you meant right
Also, Just to confirm, happy flow here means the code which runs properly just after the exception is raised. correct?
Thank you so much @Dorine Boudry. You are my savior.
This issue caused me 2 days delay, but you fixed this in an hour. I couldn't reply yesterday as I had to test it for multiple scenarios so it took a while.
Again, thank you so much.
Best Regards,Aman.
Aman,
That means that the transaction will continue to run when there are errors on the client side. (You want this anyway as client's javascript errors would trigger abort transactions...)
Regarding your processes aborting, you'll want to make sure that every action in every level of the chain has abort set to no. This means any action that calls this action, and all actions this action calls.
From my experience using it for just this sort of situation (Open AI REST calls that tend to time out or have issues) you'll want to have the abort chain as simple as possible... (Single handler for 'All errors', abort no) in every level of the action call chain.Good luck!Best,RAD Manage
Hi @RAD Manage ,
that's not what it means, there are no transactions on client side.
I'm not sure where I mentioned that there were any transactions on the client side, however, there are certainly client side error handlers, which, as mentioned, do not have the functionality to revert transactions.
This means that any client side errors will never cause transaction aborts....I'm not sure where you think the incorrect response is...
yeah,
your first sentence, actually, confused me, it looks like you say transactions will continue to run on client side, and that javascript errors could possibly abort a transaction ??
Sorry if I misunderstood.