UiPath Connector - Nobody wants to wait. Or do they?

Dalton_Ruer · Sep 2, 2022 8:59:03 AM

The Qlik Application Automation team just keeps creating cooler and cooler connectors and blocks for existing connectors. Like recently when they added a "Run Job and Wait To Finish" block for the already existing UiPath Connector. After all we all love to wait.

NOT!

So why on earth would they mess with the perfection they already had, "Start Job" and move on?

If you have a User Attended type process on the UiPath side, then clearly starting and moving on is a perfect fit. You don't want to wait hours for a user to come back for lunch and provide some input. Just move on.

Well it turns out that not all use cases are are well suited for an asynchronous, just move on" kind of implementation. Say my use case for example. I wanted to capture analyst insights in a Qlik Sense application, store their insights into an Inphinity Form, take action on those insights and then RECORD THE RESULT OF THE ACTIONS. {See the related content below for more information}

Well now instead of starting a UiPath job, and wondering for all eternity if it was successful, I can wait for the results to be returned. The really good news I only have to wait long enough to test my Qlik Application Automation workflow, and from then on the engine will wait, and not me. 😊

Run Job And Wait to Finish vs Start Job

Being saavy you might have guessed that the key difference between the two blocks was the ability to define a wait time. After all, if it's going to be synchronous, we better be able to specify the period of time that we are willing to WAIT. Below you can see that in addition to providing the needed JSON Input Data so that UiPath has what it needs,I have also defined a Timeout value of 30 seconds. Obviously you should select the timeout lengtht that is appropriate for your UiPath processes.

Viewing the Output

If you have watched any of my Qlik Application Automation videos you know that I'm really really really big on using an Output block to see results, variables and pretty much anything that moves. If you didn't already know that, I just told you.

I need that trail to understand what exactly is going on. This new block is no exception. So of course after executing the block I wanted to see the output from it directly.

Too cool. Now I can get the State value and know if the process was Successful, or if it Faulted. And I can also, and of course this is the important part for my use case ... GET THE VALUES RETURNED AS OUTPUT PARAMTERS from my UiPath process.

But wait there's more! If you act in the next 30 minutes, or use the slider on the right, you will see that there is even more. What type of UiPath runtime was used? What host machine name did the Orchestrator actually run the process on? Come on, I could have a full audit of the actions taken if I want them. The block returns it all. You gotta be loving that.

Failures

Of course we assume our UiPath jobs will always be successful and they likely will be. Until the first day of our much needed vacation when a failure could occur. Maybe a password we are using in a script got changed. Maybe a website got blocked by our companies new VPN rules. Maybe ... you get the drill.

The nice thing about this block, and the way UiPath works, is that if the job fails we will get a Faulted value for the State.

What if there is an actual error thrown. Say we are asking UiPath to do work in Service Now, but there is no connection to Service Now to utilize? Yep we get that returned to us as well.

Nothing wrong with assuming the jobs will always be successful. Butjust for fun go ahead and implement a Condition block anyway. Simply checking that the State returned is Successful. Then process the results in any way you wish, and be sure to do something in the No block as well like notifying someone.

Processing the Output Arguments

The real gold for my specific use case, and perhaps yours, is in the Output Arguments that are returned by UiPath. In my case it is the SAP Ariba Confirmation number for the cases it creates, and the Service Now incident numbers that are created. I need to document those so that I know what actions were taken for which insights.

As you can see above the Output Arguments are actually like a list of argument name and value pairs. So the first thing we need to do is utilize a Qlik Application Automation convert function to explode the arguments into a list. I only have 2, but you might have 100. Notice the last image shows the exploded list being assigned to a variable.

Of course we will check that with an output block:

Rats! The values in my list have some garbage characters in them. The first parameter has the { at the front, and the last parameter has the } at the end. Both have double quotes in them etc. All I want is the WS9398403 and the 93849083. How can I process that? One way is to simply use a combination of Qlik Application Automation functions RegExReplace and Remove.

{remove: {regexreplace: {$.UiPathReturnValues[0][0]}, "[^\w\s\-_]", ""}, 'AribaConfirmation'}

{remove: {regexreplace: {$.UiPathReturnValues[0][1]}, "[^\w\s\-_]", ""}, 'SNIncident'}

What if you have more than 2 Output Arguments? Simply follow that syntax for as many arguments as you have just keep incrementing the second counter:

{$.UiPathReturnValues[0][2]

Summary

Easiest summary ever. Your willingness to wait a few seconds (and read this post) has now provided you with the results of the actions your UiPath process performed, so that they can now be recorded/audited.

UiPath Connector - Nobody wants to wait. Or do they?