Skip to main content
Kofax

KTA calling long duration RPA / Kapow robots

3026402

Question / Problem: 

Is there a way to test calling long running RPA / Kapow robots from KTA?

Answer / Solution: 

The attached sample KTA process and RPA robot can be used to test calling long running robots from KTA.

KTA process (created in KTA 7.5): RPATimeoutTest.zip

RPA robot (created in RPA 11.0.0.1): WaitRobot.zip

RPA

Wait.robot just takes an input number of minutes to wait and returns the timestamps of the start and end.  To use this, make sure that Wait.robot, WaitInput.type, and WaitOutput.type have been uploaded to the Default project in the RPA Management Console to which KTA will connect.

WaitRobot.png

KTA

First a connection to RPA is needed for each type: .NET and REST.  In the KTA Designer go to Integration > RPA.  Create an RPA configuration with Communication Type set to .NET, named “RPA” and a second configuration named “RPAREST” with Communication Type set to REST.  For the sample process to "just work" these specific names must be used.

Then import the package containing the RPATimeoutTest process.

To create a job to test running the robot in the KTA Workspace, go to Jobs > Create, and select RPATimeoutTest.  Enter the number of minutes that the robot should wait and create the job.  It will first run the robot called with the .NET Communication Type and then run the robot with the REST Communication Type.  The variables in the job show the timestamps both from the process itself, and the ones returned from the robot.

RPATestJobVariables.png

Troubleshooting

REST Timeout

Prior to KTA 7.6 using an RPA activity in REST mode was subject to a non-configurable 100 second timeout.

Starting with KTA 7.6, this is configurable with the KapowRestfulServiceTimeoutMilliseconds setting in the web and core worker config files.  The default value is 300000 (five minutes).

Closed network connections

If a long running robot called from KTA has a network interruption, specific error messages can vary depending on the circumstances.  But as examples, if the connection is forcibly closed on the RPA system, then errors written to the event log by the KTA core worker include the phrase:

An existing connection was forcibly closed by the remote host

If the connection is forcibly closed on the KTA system, then errors written to the event log by the KTA core worker include the phrase:

An established connection was aborted by the software in your host machine

In either case, the KTA job is suspended with a message like this:

Could not receive response from RoboServer.

And in either case, the run of the robot in RPA Management Console recorded the error:

The connection to the client has been lost

Given that network interruptions can happen in many ways under many conditions, messages can differ from what is shown here.

Applies to:  

Product Version
KTA 7.5+

 

 

  • Was this article helpful?