I am trying to implement a recursive workflow in a library. I have used this recursive workflow before in a project, and I want to move it to a library to prevent the hassle of copying the workflow and all its dependencies every time I want to reuse it. Furthermore, what is a hassle for me might be a big waste of time for others I want to share it with.
Whenever I try to publish the library with the recursive workflow, I get the following error:
The following workflows are in at least one invocation cycle: …
I already removed the recursive bits and published the library to validate that the recursion is the issue, and it seems that the trigger for this error is having a workflow that invokes itself.
Has anyone encountered this before? If so, did you manage to create a recursive workflow in a Library? I would really like to get this hammered out, it would be very nice to have my old components organized neatly into a library.
Depends on the specifics of the workflow. You can have a depth counter that starts at some finite positive number then input a statement in your code something like
if counter = 0
then do_some_stuff()
otherwise recursive(counter-1))
You can set it up so that the recursion is based on some other input, like a list(of list(of list(of …))) where you want to do the same thing to each item, but you don’t know how deep it goes. Then your logic could be something like:
if elem.gettype() Is gettype(New list(of object))
then recursive(elem)
otherwise some_other_processing_procedure(elem)
This is a bit more difficult to do in .Net, as you would actually set up your top level list as a list(of object) then add list(of object) or, say, strings as its elements. If you are familiar with tree structures in computer science, the list(of list(of list(…))) is just one way of representing a tree structure.
Hi Michael, bcorrea and Jonatan,
I am running into the same situation. I am building a library with recursion which works fine as long as I test it in the studio.
Now I want to publish the library and get the same error message.
I guess there is no solution available?
So I have to copy the recursion part into several calling workflows?
The solution is ugly but possible. Its not allowed to invoke your workflows again, but you can invoke library methods. So, publish your library and invoke your methods from your library.
@loginerror Do you know why we cant use a workflow file recursively? I believe there is some kind of validation going on when we try to publish a library with a wf file invoking itself and that error is thrown… When we do the same as a normal process, all goes fine.
We are not supporting recursion in libraries yet, but until then, one workaround is to design the recursive workflow/activity as a state machine and instead of callling invoke workflow, a transition to the same state can be made to simulate the recursion. I know it s not ideal and the activity will not be so simple anymore, but if you really need a behavior like this, a state machine is always helpful.
I’ve made a simple example with a counter, same as above, to simulate recursive(counter - 1).
Just want to add another thing here, you also have the option to create a custom activity with recursion using the Visual Studio Extension: Using The Activity Creator
Launch.xaml (18.2 KB)
Late reply, but I am trying to write my unit test cases within the individual workflows of a library:
Ie.
My annotated Test Cases: @TestCase @ID: Closed @Description: Opens application when application is closed @Preconditions:
Application is closed @Postconditions:
Application is running
@TestCase @ID: Open @Description: Doesn’t throw any errors when application is open @Preconditions:
Application is running @Postconditions:
No errors are thrown
out_Browser or out_Window is assigned properly
I’m using an ‘in_RunMode’ argument combined with a switch to create automated unit tests for all of the individual workflows in a library (yes I know the switch isn’t in lower case right now, but you get the idea)
If there is a better way to accomplish this sort of functionality, let me know.
EDIT
I have a separate workflow that is dynamically generating the automated test case dependencies (ie. Launch.xaml with ‘X’ runmode must pass before Launch.xaml with ‘Y’ runmode). Sure there is currently a exception case where we have completely circular dependencies, but as of now, UiPath won’t even allow us to compile the code even if we are sure there are no circular dependecies.
Anil_G
ashokkarale
Ajay_Mishra
Gautham_Pattabiraman
BHUSHAN_NAGAONKAR1
vrdabberu
ABHIMANYU_THITE1
lrtetala
samantha_shah
shyamala_shyamu