Rework the 'Invoke workflow'

The invoke workflow is one of the oldest and massively used for Robust implementations.

Here is a couple of improvement which would make even better and reduce the number of redundant activities that we include inside the invoked workflow.

Log (incoming and outgoing) arguments

It is very often that we need/want to log arguments values to help us understand the context of our workflow execution and helping troubleshooting a potential issue.

Here is a paint “mock-up” of how this could look like.

This is an idea that we discuss with @Mihai_Dunareanu during the presentation of his Enhanced REFramework quite some time ago which could help to give some data granularity in the reporting without too much effort

The logged value could either create its own log entry or simply added as a log field (of the second activity developed bellow)

This could also be interesting to have this type of feature for some of the core key activities (ex: open browser, giving the option to log the URL variable)

Log Start/End of the workflow

It is also very common to have as a standard to log the beginning and completion of a workflow.
This would then drastically reduce the amount of activity inside what is invoked to have this as an option.

Continue on error

Yes, this can be done in a try catch, but why not give the option to do it in one checkbox and now having to having to click inside the try/catch activity to access the content.

It would also be interesting (as it would be for the current ‘Continue on error’ on activity) to still log the exception occurring.

The current ‘isolated’ option does not seem to cover this scenario either (exception are still throw)

Find all references

Would be nice to be able to right → ‘Find all references/invocations’ on a workflow in the project panel to rapidly find them.

Would also be interesting for the activities.

Cheers

Cool. @mircea

@mircea

I would also add that it has always bugged me that you can’t see the annotations of the arguments inside the Invoke. Import should bring those in also, so developers who use these invokes can see how and what the arguments are being used for.

3 Likes

Thanks guys. :slight_smile:

But Invoke Workflow has “Continue on error”

My bad… I would swear I checked and it wasn’t there when I needed it!

Cheers

Hi,

I also think the Invoke workflow could use some rework, as it is crucial when developing well structured projects, but I’m not sure if I agree with the direction Florent proposes.

Let’s say these checkboxes are implemented, what happens when you have parameters that are not strings or basic types such as dictionaries, datatables and so on? You probably wouldn’t get the information you want from the object’s string representation and you’d have to edit the workflow to add some custom logging actions anyway.
I for one don’t really like debugging by logging, but in the case of workflow arguments I am forced to use logging because arguments are not visible in the Locals pane when debugging. I’m not sure if this should be a separate post, but I really wish I could inspect arguments in the debugger just like I inspect local variables.

The start and end of all activities are already visible in Debug mode so it might be useful but I find the workaround to be simple enough (adding the logging activities in the workflow itself)

This would be nice, but not just on the project panel. I think it could work on the workflow invocation activity itself and maybe also on the workflow’s tab.
I think the challenge is that workflows references are actually expressions, so you may not know the actual value at design time to compare them. This could be handled the same way as for the “Open Workflow” command, by ignoring invocations of something other than a string literal.

1 Like

Hi @robotoni,

First thanks for your comment that I am happy to read, being disagreed with is far better than being disregarded.

Let’s say these checkboxes are implemented, what happens when you have parameters that are not strings or basic types such as dictionaries, datatables and so on?

There is still the options to have those checkbox greyed out / disabled for non “printable” type. I don’t see any issue printing datatable (like the output datatable activity is doing it) and dictionaries), It could have a specific implementation.

you’d have to edit the workflow to add some custom logging actions anyway

Idea is not to cover everything but adding value with the most common things, of course there will always be “exceptions”

The start and end of all activities are already visible in Debug mode so it might be useful but I find the workaround to be simple enough (adding the logging activities in the workflow itself)

The invoke workflow’s are usually representing the skeleton of the workflow and it would be useful to have them highlighted, as an option. It would be handy to have them not in the middle of tons of other trace logs, for readability.

The idea is also to have it visible not only during runtime debugging (in Studio) but also in post production support, when you often do not have the studio installed on the infrastructure.

Once again, this is already a practice to do so in couple of RPA CoEs.

This would be nice, but not just on the project panel. I think it could work on the workflow invocation activity itself and maybe also on the workflow’s tab.

Well, the idea that I presented aim for something different. Let’s imagine you have a project with a complex structure, different folders and you are wondering if the workflow you have on a specific folder is even used somewhere, more than one time etc… You may want to go the Invokation quickly, without having to look all the xaml flowcharts/sequences. This is somewhat covered by the global search function but having Find all references, like other IDE have, would be a plus.

Cheers

1 Like