Code: InternalServerError(500), Content: System.Threading.Tasks.Task`1[System.String] when running OpenSpan
Hello,
I am having trouble reconnecting to my robot in the console. When I run OpenSpan Runtime, it quickly closes and it gives me the error in above. I am able to retrieve the json file containing case data using my credentials but when I try it with the robot's credentials, it gives the 500 server error. Is it something with the privileges? Also, does RPA still need to be set to true even though the robot has already been registered to the console?
Thanks in advance!
UPDATE 05152018:
This could be due to the robots not making any cases. I can only retrieve case data of the cases I created as well as another worker. So if the robot didn't make any cases, its not going to extract anything. How can I fix it so that it pulls all cases?
***Edited by Moderator Marissa to update SR Details***
Accepted Solution
Health First
US
Hi!
Turns out that because the robot was taking in multiple cases the first time my automation ran, it would get held up and not shut down properly. So the robot was still ready to take cases even though the runtime was not running which is abnormal (Proper shut down should have the robot's state as "Stopped"). If you try to re-establish that connection again, Pega realizes that the robot is already there, not register the robot, and quit the runtime.
The solution was to delete the registered robot operator ID, make the automation event link asynchronous (so that for every case it processes it has its own thread to work on), clean, rebuild, and deploy the project.
Another thing to note is that I am using Robot Manager Version 1 and Robotics Studio 1058 which are the first iterations of robotics.
Thanks,
Sam
Pegasystems Inc.
US
I don't believe this is a credentials error, which would usually show a 401 or 403 error. A 500 error is a little generic but it usually points to an error in configuration, either with Runtime or in your pega applicaton.
Some of the things that could cause this error: Decision table not set up correctly, the 'Require authentication' in Service package -> api is not checked, the generated Operator ID has the 'operator is available to receive work' box unchecked.
There could be other causes, so if the suggestions above are not the issue, please open a Support Request so that the issue can be investigated.
Health First
US
Hello,
An SR was put in for this issue. While I am waiting to get this problem solved, I have a few questions. Are the ProcessStaleRobots and RoboticAssignmentProcessing agents mandatory? The application I made is apart of an organization so making changes to these agents may affect the other applications. If anyone is working with Robot Manager Version 1 and Pega Robotics Studio 1058, could you tell me what changes to which configuration files I should make? There may be an attribute I am missing and since these versions make big differences, I may be following the wrong formats. I will follow up on the solution when the time comes. Thanks!
Accepted Solution
Health First
US
Hi!
Turns out that because the robot was taking in multiple cases the first time my automation ran, it would get held up and not shut down properly. So the robot was still ready to take cases even though the runtime was not running which is abnormal (Proper shut down should have the robot's state as "Stopped"). If you try to re-establish that connection again, Pega realizes that the robot is already there, not register the robot, and quit the runtime.
The solution was to delete the registered robot operator ID, make the automation event link asynchronous (so that for every case it processes it has its own thread to work on), clean, rebuild, and deploy the project.
Another thing to note is that I am using Robot Manager Version 1 and Robotics Studio 1058 which are the first iterations of robotics.
Thanks,
Sam
Pegasystems Inc.
US
Thanks @SamL84 for sharing your resolution! I've marked it as the Correct Answer should other users have the same question!