Scheduling IBM RPA (Robotic Process Automation) - WDG processes into HWA

Scheduling IBM RPA (Robotic Process Automation) – WDG processes into HWA

HCL Workload Automation (HWA) enables any user in any industry segment to automate anything and run anywhere. HWA — which has been around for many years now — is an enterprise scheduling product that automates business flows, focusing mainly on back-end (non-human) automations. Virtually any task that can be scripted can be scheduled on HWA. Acting as a universal scheduler, HWA interconnects automations running on legacy applications at data centers to modern workloads running on containers in cloud environments.

IBM Robotic Process Automation (RPA) is an automation product which primarily automates UI-based tasks. For example, old systems that lack command line or API access can be automated by creating “robots” on IBM RPA. These robots transcribe human-based actions into an executable script or “robot” which then can be scheduled from IBM RPA.

By integrating HWA and IBM RPA, we can interconnect both unattended (back-end) automations and GUI-based automations — as well as benefiting from all the advantages enterprise scheduling brings, including notification, audit, advanced monitoring, and scheduling capabilities.

In this post, we’ll see how to schedule jobs running on IBM RPA. As of this blog post, HWA integrates with three market-leader RPA products, which can be accessed here.

IBM RPA provides two mechanisms to trigger robots on its target systems: via synchronous API or asynchronous API, both of which can be triggered via HWA by leveraging the “Restful” job type.

IBM RPA Synchronous API:

The synchronous API is exposed on the IBM RPA runtime agent. Any bot that has been published on the same RPA server as the agent can be triggered. This method is the easiest to accomplish but lacks main functionalities such as security and load balancing.

1. To illustrate this process, first we create a bot in RPA Studio. This bot will just write an info message.

Figure 1. Bot on RPA Studio

1. To create an HWA job to run a bot in RPA via synchronous API is straightforward. Create a new job type “Restful.” Under “Action,” we’ll provide the API which is listening on the RPA runtime agent. In this example, we’ll run the bot named HWATestBot, and we’ll pass the unlockMachine=false parameter. With this parameter, the bot tries to connect to an existing user session.

Figure 2. Restful job type action

1. Figure 3 shows a successful job execution. Figure 4 shows the job log on IBM RPA.

Figure 3. Successful job execution in HWA

Figure 4. Script job execution on IBM RPA

IBM RPA Asynchronous API:

The asynchronous API is more robust and is exposed on the RPA server instead of the runtime agent. The main advantage is the ability to perform workload management options.

The API will allow us to run process definitions. It creates an instance for the defined RPA process, thus running the automation script(s) listed for the process step. The image below displays a process sample, which includes queue, process, and step(s).

Figure 5. RPA process definition

Once the IBM RPA process is created / identified, it can be scheduled via HWA. Figure 6 shows an SAP process chain which, once finished, triggers an IBM RPA bot. Let’s dissect the IBM RPA jobstream on HWA.

Figure 6. IBM RPA job execution flow

1. The first job is a restful job type, using the tenant ID as an HTTP header. The body content type is x-www-form-urlencoded. Note that we can pass the username and password as parameters, so they’re protected by HWA.

Figure 7. IBM RPA login job

1. The second job triggers the IBM RPA bot, which uses the workspace tenant and process ID. They can be received by calling the workspace and account endpoint. Since they are static, there’s no need to create jobs for them.
2. Notice that the Bearer token is received from the result of the first job “LOGIN_TENANT”, with it, we can authorize the RPA API and run the Bot.

Figure 8. IBM RPA bot job trigger

1. An ID is returned as a result of the bot being triggered. We’ll use the ID to check the bot status and leverage the output conditions to check whether it has the string “done” (so we can mark the job as successful). If it’s not done, we’ll wait for two minutes and then check again by re-running the WDG-PROCSTATUS jobstream.

Figure 9. Check RPA bot result

On the IBM RPA user interface under manager workflows we can confirm that the step TheOneAndOnlyJC was completed (Execution status = Done).

Figure 10. IBM RPA execution flow

As shown, HWA can integrate and interconnect multiple systems, including robotic process automation, with minimal glue code between them. If you’re connecting HWA with RPA or any other application, please do send a message here or on LinkedIn.