Hii Everyone, hope you are doing well
Im a junior dev
I have been facing a weird issue i.e
Whenever in a workflow there’s a error…the pre captured values in a arguments are getting deleted or showing null
Let me explain you in detail----
Assume there are 4 workflows name “A”, “B”, “C” & “D”
Consider “A” as main workflow
B is involked in A
C in invoked in B
D is invoked in C
All workflows have try catches
Some values are passing in from the Workflow “A” to “D”
& like wise some values are passing our from “D” to “A”
So in a scenario when there will a system exception or any type of error ,in the workflow “D”
then it supposed to travel to workflow “A” & should be handled in that final try catch
lets say there are some values generated in the flow “D” , “C” or “B”
So while coming out from those workflow, those values should reflect in the main workflow(A) right ?
when sending from A to others the call chain has to be respected and should not be broken
in case of failures ensure that the direction is in/out. Then A will get e.g the updated values as well
When an argument comes later into the picture e.g. C → D, then A is not aware of it, and never will be recognizing it.
In some cases, a dictionary will be a better choice.
dictArgumentSet send from A to B, B passes it forward … and the directions are in/out
In this dictionary, all workflows can add, modify particular arguments like A1, B1,C1…
However it is recommended to check, how much complexity /close couplings of the modules are needed and if it can be simplified. A too complicated Argument wiring loses the flexibility and results to call chain breaks.
@Jiban_Stars This is expected. When any exception occurs in the invoked workflow it will not return any values that generated in that workflow instead it returns null value
In your scenario when an exception occurs in the Workflow D then it going to catch block (As you mentioned each workflow has try catch block) from there its returning to Workflow A with null values
To avoid this case you can use separate try catches for the activities
There is a way around it, but it is rather cumbersome, especially if you deeply nest your workflows and need to pass on a value through several layers. Basically you enrich your exception object by storing all out_arguments in the exception.data dictionary, thus passing them on, to be read later in a different wokflow.
Disclaimer: I’m doing this just from memory, I hope I’m not making any critical errors.
Lets assume a simple examle:
You have workflow A, and Workflow B.
A invokes B which is supposed to return out_MyName as a string.
A stores the returned value in a variable MyName
The solution requires 2 error handlers:
one in workflow B, encompassing the entire sequence of Workflow B
one in Workflow A, surrounding only the invoke of B in workflow A.
The orriginal out argument is now part of the exception, and by rethrowing it the enriched exception is passed to the next error handler.
Catch of Handler A:
→ assign: MyName = exception.data(“MyNameKey”)
And voila… you passed an out arguement value through the handlers.
In 99.9% of the cases you don’t need this construction to pass on data but there’s a reason I figured this one out at some point… I found a usecase for it in a complex script.