I have a use case where I am continuously monitoring a folder for newly created files and executes a process when the FileChangeTrigger activates. Since the process takes a few minutes to execute, I want to make sure that I capture any additional triggers while executing. The UiPath documentation didn’t go in-depth into how the Monitor Events activity operates; would any of you have any insights into these questions?
If I create a flowchart or sequence outside of the MonitorEvents activity, will it stop monitoring during that time?
Is there a built-in queue for the number of times the MonitorEvents activity has been triggered?
Would it possible to use Orchestrator to monitor events and add new file triggers to the queue while the same robot is executing other processes?
I’m still quite new at this so any suggestions on best practices will be much appreciated.
Did you ever get any responses or did you figure this out?
Monitor Events obviously works counter-intuitively. I want to run a process and monitor for a key/mouse click, at which point perform some action, and return to the process.
I haven’t been able to do this simple logic. Nothing outside of the Event Handler ever gets run, which is one problem. Once in the Event Handler, how do you stop the process? The only solution I’ve found is to do a Close Application inside a Try/Catch and ignore the exception. Not pretty…
If so, you should be able to achieve this logic by changing the RepeatForever property of the MonitorEvents activity to False. When you do, the monitor activity will end after performing some action, allowing you to loop it back to the original process.
If the RepeatForever is set to True, then it would need to be done the way you had mentioned - cause an error and use the TryCatch block to ignore the error.
I hope that helps. Please let me know if that’s not the scenario you envisioned.
If I create a flowchart or sequence outside of the MonitorEvents activity, will it stop monitoring during that time?>
Yes (this question was obvious in retrospect)
There is a way to simultaneously run multiple MonitorEvents activities, with different triggers and different processes. This can be accomplished by placing the multiple MonitorEvents activities inside the Parallel activity (see attached XAML file below)
Is there a built-in queue for the number of times the MonitorEvents activity has been triggered?>
Yes. Even with Parallel MonitorEvents activities, UiPath seems to know how many times the each trigger has been fired and will execute the appropriate process that many times.
Note: with Parallel MonitorEvents, UiPath will alternate between processes when executing the queue.
Would it possible to use Orchestrator to monitor events and add new file triggers to the queue while the same robot is executing other processes?>
Potentially, by using the Parallel activity (I haven’t tested this). But it seems like overkill for the FileChangeTrigger activity
What I have done instead is create a loop where UiPath
Checks the monitored folder for changed files and adds them to an Orchestrator Queue (with the filename as a transaction item since my process uses the filename of the changed file)
Grabs items from the Queue using GetTransactionItem, pulls the specific filename, and executes the process.
I used Assign for this part. var_Filename = cstr(var_TransactionItem.SpecificContent(“transactionfilename”)). var_Filename is a String variable; var_TransactionItem is a QueueItem variable; transactionfilename is the
name for the filename that is stored in the Orchestrator Queue → Transaction.
Attached file note: you have to input two folder paths into the variables in order for the workflow to run Parallel monitor events.xaml (10.8 KB)
dzhou - thanks for simplifying it! The problem I found trying to do what you suggest, however, was that monitor events would hold up the process until I activated it with the alt-ctrl-left_button click. Not only did I have to set Repeat to False, but I had to make the monitor a separate process invoked by the main process. I’ll go back to what I had and see if I can follow you from there.
You’re correct - the way that I suggested runs the process and then monitors events sequentially, which is why the monitor events process is a separate process within the monitor events activity (the flowchart view didn’t show these details).
Were you envisioning it being simultaneous? Let me know what you find and what you were thinking in terms of the process flow. I can see if there is a better answer.
Sorry I don’t respond right away, I get no notification of an answer until I look for one.
Anyway, maybe the best way to describe what I want is an asynchronous monitor events process. I want to be able to react to a certain keystroke, but I still want the main process to keep running, NOT stop until a correct keystroke comes along. I guess the monitor events would be like a service program running in the background. Maybe that would be handled by 2 separate robots, but I’m still on the trial version and can’t test that at this point on my machine.
The way Monitor Events acts by default is the processing stops at the keystroke selection step and just sits there. If other keystrokes happen, nothing changes. When the right keystroke comes along, Monitor Events does its work and then returns control to the main process which starts running again.
Process A will run continuously while Process B only runs when the hotkeys “Alt + d” are triggered. I had it designed to run continuously, but you can easily make it into a flowchart sequence that loops into itself, which will allow you to add a stop all execution sequence.
I suspect you can use state machines to make this work more smoothly as well, but haven’t explored that yet.
Let me know if this works for what you’re thinking.
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu