Robotic Process Automation (RPA)

 View Only

Triggering bots on a file creation event

By Gabriel Sanchez posted Sat October 23, 2021 07:43 PM

  

The automation possibilities with RPA are plenty. IBM® Robotic Process Automation (IBM RPA) adds to the possibility list by providing not only a myriad of commands to handle different automation scenarios but also different ways to deploy your RPA bots. Because IBM RPA can start bots via an HTTP request to its API, you can easily integrate your bots with other systems.

In this article, I'll demonstrate how to start bots based on a system event. This is also called triggering. The system event in this article is creating or adding a new file into a folder under watch. The solution in this article integrates different technologies with IBM RPA to achieve the expected outcome: running a bot when a new file is added to a folder. All technologies are available out-of-the-box in newer versions of Windows®, starting from Windows 7.

Solution overview


The solution consists of creating a watcher using a PowerShell script and a task in Windows Task Scheduler. Both will work together to trigger the bot by calling the IBM RPA API.

The watcher, running on an infinite loop, tracks changes to a target folder, specifically new files. In the event of a new file in the folder, the watcher logs a message into a log repository in Windows Event Viewer. The task in the Task Scheduler is triggered because of this log message. The action this task does is to call the RPA API to start a bot.

The following diagram illustrates the workflow of this solution.

Solution design workflow

Rationale


With the currently available IBM RPA bot deployment options, you need to circumvent the fact that bots can't be triggered by system events. This article defines one possible solution. Keep in mind that other solutions, maybe even more elegant than this, might exist. You are also not limited to the events the watcher I create in this article handle; you can use other events if you need. Feel free to reach out to me with your ideas and suggestions.

One could argue that the RPA orchestrator could handle the demand. This is true if your queue provider is any other than the default RPA queue provider. If you are using the default queue provider, you'd still need to start a bot to enqueue the messages.

Also, orchestration can be an overpowered solution if you have only one runtime license. Nonetheless, it does have its benefits, like the control panel, the ability to manage the process instances, and the possibility of creating exception flows. The solution this article defines enables the possibility of creating exception flows too, but it is not as intuitive as the RPA orchestration process is.

Before you begin


System requirements

  • IBM® Robotic Process Automation (preferred version: 21.0.1).
    • At least one Runtime license. Optionally, one Studio license to develop your RPA scripts. You can check how many licenses you have by navigating to https://localhost:8099/web/en/licenses on the host computer.
  • Microsoft® Windows® 7 or up.
  • PowerShell 7 or up.

Security requirements

  • You need administrator access on the target Windows host to set up the different components for this procedure.

Procedure


The following steps describe how to set up your environment to trigger bots when a file creation event happens:

  1. Setup an event log and a source.
  2. Setup a task.
  3. Setup the watcher.
  4. Run the watcher.

See the results.

Setting up an event log and a source


To log an event, you need to set up an event log. An event log holds data about events a source raises. A source can be any software that can log events by referencing the Windows Event Viewer API.

You can create an event log and a source through PowerShell:

  1. Open PowerShell as an administrator.
  2. Run the following code:
New-EventLog -LogName 'RpaBot' -Source 'BotRuntime001'

You can change RpaBot and BotRuntime001 to the values you prefer, but I recommend creating a new event log for your bots and one source per bot. Remember to reference them later.

Setting up a task


To trigger a task on an event, you need to create a task on Windows Task Scheduler. A task can do a number of actions based on a trigger. There are a number of triggers, but the interesting trigger is the event trigger.

  1. Press the Windows key, type task scheduler, and click Task Scheduler.
    • Optional: Press Ctrl + R, type taskschd.msc, and click OK.
  2. On the explorer panel, click the Task Scheduler Library folder.
  3. Recommended: On the Actions panel, click New Folder. Click the new folder to reference it.
  4. On the Actions panel, click Create Task.

The Create Task window opens. The following procedure describes the options you need to set, split by tabs.

General tab

1. On the General tab, type the task Name.
2. Type the task Description.
3. In the Security options pane, select the options that suit your needs.

Triggers tab

1. Click New.
2. In Begin the task, select On an event.
3. In Settings, select Basic.
4. In Log, select the log name you created when running the PowerShell code. In this document, the log name is RpaBot.
5. In Source, select the source you created when running the PowerShell code. In this document, the source is BotRuntime001.
6. Type the EventID. The event ID is an arbitrary number you use to identify the logs you generate. You can define multiple triggers for different event IDs.
    - If you don't set an event ID, all logs will trigger this task. Choose an integer between 1 and 65535.
7. On the Advanced settings pane, check Delay task for and select 30 seconds. This setting is recommendable if you only have 1 runtime license available in the host computer.
8. Apply other advanced settings that suit your needs.
9. Check Enable.

Actions tab

1. Click New.
2. In Action, select Start a program.
3. In Program/script, type curl.
4. In Add arguments, type :
    
    -k https://localhost:8099/scripts/${scriptname}?unlockMachine=false

    where:

    - localhost  
        The host computer. In this case, the computer where you are creating this task. If you want to target another computer, change localhost to the IP address of the target computer.

    - ${scriptname}
        The name of the script you want to run.
   
    - unlockMachine=false
        A query string parameter to disable the bot from unlocking the host computer. In this state, the bot will try to attach to a running session on the host computer. If you want your bot to unlock the host computer, change false to true.


Conditions tab

On the Conditions tab, you find options to change the conditions for your task to run, like enabling the task to run only if the computer is on AC power or only if the computer is idle. Change them to your liking.

Settings tab

On the Settings tab, you find additional options that affect the behavior of your task. Change them to your liking, but I raise the attention to the following options:

  • Check Allow task to be run on demand.
  • Check Stop task if it runs longer than and select the time.
  • Check If the running task does not end when requested, force it to stop.
  • Select Queue a new instance if the task is already running. If you have only one runtime license available, this setting makes sure you use it efficiently by queueing upcoming tasks if one instance of this task is already running.

Setting up the watcher


To configure the watcher, copy and modify the following PowerShell script according to the comments in the script. You can modify it in any editor. Make sure to save the file with the .ps1 extension. 


# Start watcher to watch events on a folder. Write the event to log if new file on the folder.

# EventLog parameters.
$logname = 'RpaBot' # The log name. CHANGE to a different name if you want to.
$source = 'BotRuntime001' # The source that generates the log. CHANGE to a different source if you want to.
$eventId = 1 # The event ID. You can use any integer from 1 to 65535.
$eventMessage = "Start process." # The message that gets logged. You can change this if you want to.


# File system watcher initialization and settings
$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = 'absolute_folder_path' # Folder to watch for events. CHANGE to your folder absolute path.
$watcher.Filter = '*.*' # Files to watch. CHANGE filter to watch for specific file formats. Default is any file.
$watcher.IncludeSubdirectories = $false # If subdirectories should be considered. Set $true / $false
$watcher.EnableRaisingEvents = $true # If events can be raised. Set $true / $false


# Action on folder event is to write to logname.
$action = { 
    Write-EventLog -LogName $logname -Source $source -EventId $eventId -Message $eventMessage
          }


# Set events to watch for. Uncomment the line to enable action on that event.
# +----------+---------------------------------------------------------------------+
# |  Event   |                           Definition                                |
# +----------+---------------------------------------------------------------------+
# | Changed  | File or directory in the specified Path is changed.                 |
# | Created  | File or directory in the specified Path is created.                 |
# | Deleted  | File or directory in the specified Path is deleted.                 |
# | Renamed  | Occurs when a file or directory in the specified Path is renamed.   |
# +----------+---------------------------------------------------------------------+
Register-ObjectEvent $watcher "Created" -Action $action
# Register-ObjectEvent $watcher "Changed" -Action $action
# Register-ObjectEvent $watcher "Deleted" -Action $action
# Register-ObjectEvent $watcher "Renamed" -Action $action


while ($true) {Start-Sleep -Seconds 5} # Keep script running on endless loop. Close Powershell window to end watcher.
​​


Running the watcher


There are several ways you can run your watcher file:

Running the watcher by double-clicking the file

It is possible you need to configure your watcher so you can run it by double-clicking the file.

  1. Right-click your watcher PowerShell file and select Properties.
  2. If the Opens with field shows an application other than PowerShell: Click Change and locate the PowerShell executable in %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe.
  3. Click Apply and OK.

Running the watcher from the command prompt

  1. Press the Windows key on your keyboard, type Run, and press the Enter key.
  2. In the Run window, type cmd and click OK. The command prompt opens.
  3. Navigate to the folder containing your PowerShell file with the cd command. For example: cd C:\MyFolder.
  4. Type powershell .\watcher_script.ps1. The script runs using PowerShell in the command prompt.
Running the watcher from PowerShell

  1. Press the Windows key on your keyboard, type Run, and press the Enter key.
  2. In the Run window, type powershell and click OK. The PowerShell window opens.
  3. Navigate to the folder containing your PowerShell file with the Set-Location command. For example: Set-Location -Path C:\MyFolder.
  4. Type .\watcher_script.ps1. The script runs in the current PowerShell session.

Results


You can minimize the watcher PowerShell window. If you close it, the watcher stops.

Whenever the events you selected for the watcher happen, the watcher will record a message into the log you set up. This message will trigger the Windows task, which culminates into an HTTPS request action to start a bot to process your data.

Conclusion


Because you can use HTTPS requests to start a bot, you can integrate different systems or workflows into your automation solution. In this article, you saw how to integrate a PowerShell watcher and Windows Task Scheduler to call a bot whenever a new file is inserted or created into a folder.

With this solution, you can process data on demand. This solution is designed for environments where Runtime licenses are limited. You definitely can improve this solution by adding other integrations, if needed.

Note that you can create watchers for other types of events. Also, you don't necessarily need to use PowerShell if you can use other programming languages or other systems. PowerShell was chosen because it is embedded in Windows.​
#TaskAutomation(RPA)
#RoboticProcessAutomation(RPA)
#lowcode
#ArtificialIntelligence(AI)
0 comments
317 views

Permalink