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.
thinking out loud here, did you try setting the invoke workflow activity with the isolated as true?
Thanks for the input, looks like Libraries don’t support the isolated option. I get the following error message:
The following workflows invoke other workflows with “Isolated” option, which is not supported for library projects: …
oh ok, also how do you make your recursive workflow not to get into an infinite loop?
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
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))
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.
so you would have to do use like a try catch and a manual throw activity to make it stop?
Thanks for your proposal but did not work.
The recursivity works perfect in a normal workflow but it fails as soon as you try to encapsulate it in activity when creating a Library.
So, may be is a UiPath limitation.
Anybody have solved?
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.
I would really appreciate a simple sample project with recursion to be able to check it out.
I’d be happy to register a bug afterwards.
Sure, here it is:
RecursiveTest.zip (23.1 KB)
I have to correct myself. Recursively called library method will run into an error as soon as you want to implement it in a new project.
@loginerror it would be helpful to have recursion.
Thanks, I added your suggestion to our ideas tracker. It will be consider for future releases.
Hello @michael.new, @Enrico
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).
LibWithRecStateMachine.zip (9.8 KB)
Merci, I’ll check this out.
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
Thanks for your feedback. Currently, recursive calls in libraries are not supported but we are analyzing how to improve this in the future.
Can you please let us know what scenarios cannot be accomplished without recursive structure?
Launch.xaml (18.2 KB)
Late reply, but I am trying to write my unit test cases within the individual workflows of a library:
My annotated Test Cases:
@Description: Opens application when application is closed
- Application is closed
- Application is running
@Description: Doesn’t throw any errors when application is open
- Application is running
- 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.
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.
I was easily able to resolve this issue by simply replacing the invoke launch with an open browser activity.
Upon finishing my library, none of the other workflows required recursion!