Flexible debugging idea - mark activity as a 'debug' activity with ability to globaly switch it off/on

Feedback Studio
,
1

The idea here is simple and consists of two parts:

  • mark any activity as a ‘debugging’ activity
    (this could be achieved by dragging and dropping a debug flag on top of it)
  • have a switch on the ribbon to activate/deactivate all debugging activities

It would work for any workflow opened in the current project.

This would be a tremendous help in situations when you want to test a single workflow in a framework and you have to add additional activities such as “Read range”, “Assigns”, “Log message”, etc.
If you could add them once and then be able to simply switch them off when no longer needed, it would be awesome.

Of course you can delete them or disable them separately, but with many workflows inside a framework it gets cumbersome.

2

Cool!

3

It would help to have a message property in every activity. Instead of adding an entire activity just to write a line, you could specify the write line in the activity itself. Not only would it save some hassle but would also minimize file size and increase real estate when designing workflows.

1 Like
5

Somewhat, but the current output leaves a lot to be desired. If you run in debug, it drastically slows the process and gives you a lot of unnecessary information. It would be great to add custom write lines (that read how you want them to) so you can have the output you want in standard F5 run mode. You can obviously do that now but only with the use of a write line activity. Why not just have a property in each activity that writes a line out when the activity executes?

This would not only prevent you from having to add a write line activity to your workflow but could also allow you to only display the output line under certain circumstances. For instance, you have a variable ‘Mode’ with a value of ‘QA’. When adding an execute query activity you could set the write line property to If(Mode=“QA”, “test write line”, nothing). This would output “test write line” only when in QA mode.

On a side note, I think it would be nice for the trace output to display more than 2000 lines but that is for another conversation/request.

1 Like
6

Hi @bcarp

I actually made a similar suggestion in the past which is somehow related:

I will merge these two topics, as they share a common idea of improving the debugging experience as far as log messages are concerned

Hopefully other users will chime in with their ideas too :slight_smile:

1 Like
7

So similar to this I guess?

8

This would be a big plus for me - currently I have an bool asset, ie process1IsDebugMode, and then all ‘debugging activities’ inside an if statement - implementing a debugging “mode” would save alot of time and make the flows alot cleaner.

Would also save having to go through deleting all write lines, hard coded values, etc when promoting flows into Prod.

9

Hi team,

Would it be possible to include robot execution directives for different run modes (or DEBUG at least)?

It would ease transitions between stages as one would not need to worry (that much :wink: ) about leaving a stray Highlight, or worse yet MessageBox, somewhere, as well as having another alternative with test flows.

Similar effect could be achieved with Asset configuration (bool asset IsTestRun etc. and it in IF’s), but since there are no truly global variables, it would either need to be passed aroung as an argument, or you need GetAsset calls in numerous workflows (which impacts performance).

Another use case is showcase demo - with run mode directives you could use the exact same workflow to show how the robot works as well as actually running it (less changes → less opportunities for errors). Increasingly useful if you’re using WindowMessage or Simulate input flags.
Example:

Sequence:
	OpenBrowser(someAddress)
	#if DEMO
		Hover(selector)
		Highlight(selector)
	#endif
	Click(selector, Simulate)
	#if DEMO
		Highlight(someTableSelector)
	#endif
	DataScrape(someTableSelector)
	#if DEMO
		MessageBox(OutputDataTable(scrapeResult))
	#endif
	....

Opinions?

3 Likes
10

how to mark a activity as ‘debugging’ activity? i can’t find debug flag.

11

Hi @pitaty

It is for now just an idea that might or might not enter our Studio at one point in the future.

2 Likes
12

Is it possible to add a demo mode setting to UiPath? We have been doing a lot demos lately to varies user groups, and one of the biggest complains we received is that the robot is acting too fast and is difficult to follow - especially those actions that do not result visual change (such as read text and click a button).

To overcome the issue, I had to use “highlight” activities either prior or in parallel with key actions (see attached). The coloring choice in the “highlight” activities also allowed me to visualize different action types to users. e.g. red for input, green for read, gold for click…

However, robots in PROD would not need these activities and it is a pain to have to constantly add/remove them, especially in lengthy processes. Is it possible to add a project level switch have them auto added/removed? Or alternatively, have the key selector actions comes with another true/false parameter called “highlight”? This way, we can use assign a global variable to it for easier control.

Thanks.

image
image840×451 11.2 KB

13

Hi,
running process in debug mode would not be an option?

Cheers

14

Thanks for the suggestion J0ska.

You are right on point, and the highlight feature in debug mode was the first thing I went to; unfortunately it is extremely slow (5 times or so) even with logging checked off and I do not always have patient audiences.

I am sure there are additional invisible logging steps taken in the backend during debugging mode, but if there is a “Fast Highlight” option that should serve the purpose just fine.

15

Instead of removing the highlight activity, just create a workflow that takes a boolean as input parameter, with an If inside. If the boolean is true, call activity highlight. Then, in your main workflow, have this boolean as an asset that you pass as argument everytime you can you highlight workflow. You’d have to just change the asset boolean from True to False if you wanna disable highlighting.

16

Thanks bartierc. I was going to do that, if UiPath does not come back with a more generic solution (I think the beta 2019.8 version had some advanced running choices, so maybe there is still hope).

I do not mind adding several dozens of if/thens, but it just feels wrong to sacrfice actual PROD runtime performance for something only needed during demo stage. Also the messy nesting of if/thens and parallel activities make code review less appeasing for audit and other developers.

17

you would not see the if/else, just one activity (an invoke worklow) that contains the if/else, doesn’t take much more space than one Highlight Activity

1 Like
18

I see, so you are saying, instead of using the default “highlight” activity, create a special workflow called “demo highlight” that is conditionlly triggered on a boolean argument.

That is a better idea. I like it. Thanks.

19

Yep that’s it :slight_smile: It would look like this :

image
image793×387 16.9 KB

booleanHighlight can receive value from an Orchestrator boolean asset (if you use Orchestrator), then you’d just have to set this asset from True to False to deactivate highlighting. If you don’t have an orchestrator, just have it a classic variable in your main workflow and then pass it as an argument to other workflows.

20

Or you could also make a HighlightAndClick (and HighlightAndType) workflow instead, it would receive a String input argument for the Click/Type selector, and you can even put the click/type in this workflow.

21

That would be a bit overkill as there might be many different types of interaction (read, wait for element, etc) that need more delicate control (like simulate click vs background vs default). I would stick with just the conditional highlight for now. Thanks for the suggestions though.