I am able to view my robotic workgroup/workbasket and the work objects queued in it with the Management Console, and my VM which has Pega Robotics Runtime 8.0.1061.0 installed on it is able to register a new robotic operator ID on the server instance in the same workgroup/basket and shows as Healthy/Running. When the heartbeat triggers on the VM and it attempts to pickup work, the output window for Robotics Runtime yields "RoboticsApiHelper.GetNextWorkItem - No work to do."
Tracing the API requestor on our server shows that the request being sent in has property pxReqPathInfo with value "/api/v1/assignments/next". This causes a failure in step 5 (java) of activity Assign-acquireWorkObject due to no assignment existing with an ID == 'next'. Activity acquireWorkObject gets called by pzGetAssignmentDetailsInternal (Pega-API: 07-10-17 on our 7.2.1 server).
By comparing to a Pega 7.3 server where we have RPA working, I noticed that activity pzGetAssignmentDetailsInternal was changed in Pega-API: 07-10-27 to include a when-condition on the first step (when param.ID == 'next') to call pzOpenNextAssignment and, in turn, pzHandleRoboticPull.
This ruleset version of Pega-API (07-10-27) did not come in on the working server until the Pega 7.2.2 upgrade... But according to the link above, RPA should be compatible with 7.2.1. So with this context in mind, I have a few questions:
Is there a different hotfix not mentioned above that needs to be applied to a Pega 7.2.1 instance to handle RPA? (presumably one that brings in Pega-API 07-10-27?)
Or, is there a way of getting the api request to pass in an actual ID instead of the 'next' value that it is currently passing (perhaps a specific version of Robotics Runtime or a different way of invoking the RoboticsApiHelper)?
Or, is there some additional configuration I may have missed or done improperly which is causing the API error described above?
Or, is this portion of RPA not compatible with Pega 7.2.1, and we need to upgrade?
Thoughts and suggestions would be appreciated! This is a critical piece of the project we are building, but we want to avoid upgrading to 7.2.2 at this time due to an existing application that has been released to production on this server.