I currently have a process built into the REFramework. I have come across a situation where when an activity within the Process Transaction State errors out ( a ‘system exception’ is the failure in the output) The framework gets stuck in a continuous loop from Init -->Process Transaction → Error Transition → Init. There is a ‘system error’ transition from Init to End process. However, the framework will never transition to the system error from the Init State and continues the loop mentioned above. How can I correct this?
You’ll want to include a “MaxRetries” or similar constant and have it increase a counter each time it fails. When the counter = MaxRetries, then have it end instead of Init
Thanks for the reply! I know there is MaxRetryNumber already set up in the Config file which can be utilized if not working with Orchestrator. I am not using orchestrator in this instance. Is there a simple way that I am overlooking to integrate the MaxRetryNumber into the framework? Currently I have the MaxRetryNumber set and the retry is being counted in the output. When the max number of retries has been reached the output indicates that “Max number of retries reached”. However, the framework continues to iterate through the ‘init- process transaction - error - init’ loop.
I typed out a few different things, but erased a lot of it because I’m wondering if you maybe haven’t put in a way for the program to end? It is up to the developer to set TransactionItem to Nothing at the end of the process. The end state is triggered by ‘TransactionItem is Nothing’ so if that never happens, then it will continually try to fetch a new item in the Get Transaction Data state.
You should double and triple check that you have a valid way of assigning a null pointer (Nothing) to TransactionItem.
I had to look at the version of ReFramework I had and I noticed that in the SystemError pathway from Init to End Process, all it checks is the SystemError, which gets set back to Nothing in the Init. Alas, it will go to the next Transaction and try to process it until there are no more Transactions left.
Is my analysis correct? Perhaps it is stuck trying to do every Transaction, so it’s taking forever to End with Error. Typically, that’s what you want in a Business process, however, I can see that as a problem as well. Maybe you must use a BusinessRule Exception depending on the error and use that in the SystemError pathway so it doesn’t try to do the next Transaction.
I understand what you are saying. The SystemError being set back to Nothing in the Init is causing the issue I think. In this instance, there is only one transaction that needs to be processed except for one day a week where I am just re-invoking the xmal that contains the actual process to run a second time. The framework endlessly loops, attempting to execute the same process over and over.
I thought setting the MaxRetryNumber would work but per my previous post, the MaxRetryNumber is only counting the failures. Once the MaxRetryNumber is reached the framework resets back to 0 and iterates through the MaxRetryNumber again and again and again…
Maybe I am not utilizing the MaxRetryNumber correctly?
The program will end when it has been ran successfully and when certain errors occur. A “System Exception” being thrown is what causes the framework to endlessly loop.
It should reset back to 0 in order to do next Transaction. Can you check to make sure the next Transaction is getting stored correctly? If it never gets to the end of the Transactions then it will repeat the current one. So, it might depend on how you are getting the Transaction item, cause if you use for example “TransactionNumber” and that number never increments then you get stuck in a loop.
Also, one thing that might help is to output the Exception Message, like exception.Message or SystemError.Message. If you never see the Exceptions you’ll never know why it keeps repeating or continuing with steps.
I probably should have stated this earlier…This is a simple process so, there is no ‘Get Transaction Data’ state. The ‘Init’ is proceeded directly by 'Process Transaction". The framework inits, processes the single transaction and ends.Therefore, there is TransacttionItem/TransactionNumber being used. Wouldn’t the MaxRetryNumber be the only way to have the framework kill the process and not attempt to retry?
You need the Process state to exit to the End state when it is has no more items to process.
There are probably 2 ways to do this I think:
edit the Exit path from the Process state to the End state to check that “there are no more items to process”
or
edit the Exit path from the Init state to the End state to check the retryNumber is >= MaxRetryNumber, and to not re-initialize retryNumber to zero.
Since your process is a simple one, you might choose #2
However, keep in mind that if you process more items in the future you might want to retry every item when a failure occurs, which may or may not be a good thing also.
ClaytonM had some good ideas that I’d recommend you follow.
In the future, I wouldn’t recommend changing the entire structure of the ReFramework for a workflow.
If it truly is a very simple process, it might be better to make a simple flowchart or sequence instead of trying to integrate it into the ReFramework.
Otherwise, if there’s a potential to add more transactions in your process or you like the structure of the ReFramework and want to utilize it, then you should keep it as is without large changes. This means not deleting entire states (i.e. Get Transaction Data) because it then defeats the purpose of using a framework because you’re essentially creating something new. Instead, you should keep that state in and simply feed it your one and only transaction.
There’s a fair amount of interconnected pieces in the ReFramework, so simply deleting a state is likely to cause issues as it’s easy to forget which pieces need to be altered when that happens. It’s much better to keep the framework as is, or to not use it at all.
Thanks for the suggestions. I am attempting #2. I am able to get it to not re-initialize retryNumber pretty easily. However, I am having trouble with the exit path out of Init to End Process. What is the best way to recall the MaxRetryNumber from the Config from within the Transition?
Thanks for the feedback. Will definitely will take this into consideration in the future. We set this “Simple Framework” up as an exercise for future “simple processes” per the instruction and under the supervision of an on-site UiPath instructor. The hope is once this transaction issue is resolved the framework can be used for other single-process automations.
Hi. I don’t think I understand your question. You can get the MaxRetryNumber from a 1-dimensional dictionary by using something like CInt(Config(“MaxRetryNumber”))… MaxRetryNumber is the Name of the setting.
But to be honest, there are disadvantages to using it directly like this, because you must remember the key for every setting, whereas if you store the setting in a variable, you can type the first letter and it shows up in a list.
It might be preference, but to me, I find it best to use the Config in your Main workflow but store the individual settings to arguments when you pass the settings to your Process workflows. What I mean is, Init.xaml returns the dictionary Config, then when you pass settings to your GetTransaction or Process.xaml have individual arguments for each setting. So, when you work within your other workflows you don’t need to use Config(“key”) everywhere you need to use that setting and can instead use variables.
Having arguments for each setting will also make your modularization more versatile and user-friendly.
Anil_G
A_Learner
19learningcurve
SorenB
kulasinghasampath