In my process, if there is a business exception, I used the Throw activity (i.e. new BusinessRuleException(“exception message”) to exception it out and then grab the next item in the queue and continue the process. When a business rule exception occurs, its supposed to be caught in the Try-catch of the framework and set the Transaction Status to ‘Failed’ in orchestrator, but when i run my process and it encounters a business exception it still sets the Transaction Status to ‘Success’.
What is causing this, and how can this be solved??
If i have to take a guess it is not going into the throw section at all, have you had logs (or verbose logging) which might indicate that the flow did end up in throw and still didnt set the transaction as failure?
Do share your workflow if not confidential so that an extra pair of eyes can peruse through it
i am unable to send it since it has sensitive information. I used the ReFramework, and didn’t change any of the default settings in SetTransactionStatus.
i have a throw activity in my process.xaml, which is in the Try block. In the Catch block it has the BusinessRuleException, and in the Finally block it invokes the SetTransactionStatus.xaml.
When I step into each step, it shows that goes back to the try-catch and to the finally block, but when it goes to the decision tree for Success, Handle Business Exception and Handle exception, it goes success.
On the off chance you are using any other exception type (other than the ccoveted ‘SystemException’ type) then all generic exceptions will not be caught that might also be the issue.
Sure when you are available let us take a look at the arg. mapping and also the exception block
Sure thing. Maybe even check the conditional exception blocks also with the throw statements - as it is a success and exception is based on Generic errors (un-handled) and the handled conditions there might be some logical error too. It is too abstract to imagine what might have gone awry without the workflow though You can share screens with redacted data .