Question
Pegasystems Inc.
JP
Last activity: 17 Jan 2020 14:59 EST
RPAService unable to start Runtime
Version Info: Studio and Runtimev19.1.13 on Windows 10, RMv8.2.2 on Platform 8.2.1,
Problem: Able to login a remote runtime machine, but runtime doesn't start.
Here is what I have found so far from RPAService.log files:
1. Login is successful (Refer attached RpaService.log_.1.txt)
2. Task addition for Domain/RuntimeUser as defined in CredMgr successful. (Refer attached RpaService.log_.1.txt)
3. On the time mentioned in 2 above, another RPAService.log file (refer RpaService.log_.txt attached) is created, with Interactive Domain and User as defined in CredMgr with Error in Pega.RpaService.Loader.LoaderProgram.Main as given below:
Error | 02:22:47.650 午後 | 1 | MTA | Loader | 値を Null にすることはできません。
パラメーター名:path1
System.ArgumentNullException: 値を Null にすることはできません。
パラメーター名:path1
場所 System.IO.Path.Combine(String path1, String path2)
場所 Pega.RpaService.Loader.LoaderProgram.Main(String[] args)
Thereafter the heartbeat log is added every 45 seconds.
Version Info: Studio and Runtimev19.1.13 on Windows 10, RMv8.2.2 on Platform 8.2.1,
Problem: Able to login a remote runtime machine, but runtime doesn't start.
Here is what I have found so far from RPAService.log files:
1. Login is successful (Refer attached RpaService.log_.1.txt)
2. Task addition for Domain/RuntimeUser as defined in CredMgr successful. (Refer attached RpaService.log_.1.txt)
3. On the time mentioned in 2 above, another RPAService.log file (refer RpaService.log_.txt attached) is created, with Interactive Domain and User as defined in CredMgr with Error in Pega.RpaService.Loader.LoaderProgram.Main as given below:
Error | 02:22:47.650 午後 | 1 | MTA | Loader | 値を Null にすることはできません。
パラメーター名:path1
System.ArgumentNullException: 値を Null にすることはできません。
パラメーター名:path1
場所 System.IO.Path.Combine(String path1, String path2)
場所 Pega.RpaService.Loader.LoaderProgram.Main(String[] args)
Thereafter the heartbeat log is added every 45 seconds.
I have no memory of explicitly mentioning the Runtime.exe filepath in any of the configuration files. but I think that the error is due to the filepath not set.
Anyone having faced this issue already?
Pegasystems Inc.
US
Pegasystems Inc.
JP
Thank you for your insights Rushabh!
I have tried changing the ScheduledTaskStartBoundary value. I increased it to upto 2 minutes, but to no avail. The error remains the same.
As for Synchronization Engine related suggestion, here's what I have in my environment.
The target terminal has studio installed (and hence Synchronization Engine can not be installed on it) but we are trying (and hoping) to make use of the Runtime.exe that comes with it. I have done this exercise with my previous team using RMv6.x successfully. Of course, Synchronization Engine didn't exist then.
I am currently in process of uninstalling the Studio on my target terminal and installing the runtime with Sync. engine. Will update if things work thereafter.
May I request you to help me understand the following:
1. Is it then true that target terminals with Studio installed can not be used as remote terminals which can be Started from RM screen? And how not having Synchronization Engine on Studio-based terminals hampers them from remotely starting via RM?
2. What role does Synchronization Engine play in the remote login sequence?
Thank you,
Best regards,
Mangesh
Pegasystems Inc.
US
Hello Mangesh,
To answer your questions,
It is true that Studio Runtime cannot be started from the Robot Manager Dashboard. The Start command issued by the Robot Manager is handled by the RPA Service which requires Synchronization engine. This should not hamper any features of the Studio environment as that environment is intended for the development of a solution while the Start/stop/Schedule feature of the Robot Manager is so to decide when a robot should be running and under which workgroup.
The purpose of the Synchronization Engine is to ensure the running runtime version matches the deployed package version ensuring compatibility. This should not be an issue for the Studio runtime environment as it should already match the package version. Hence, the Synchronization engine feature is not necessary for Studio installs.
The only other reason I can think of why Robot runtime didn’t start successfully in RpaService.log_.1.txt scenario is may the loading of runtime package took additional time than the default timeout.
Try this step:
Hello Mangesh,
To answer your questions,
It is true that Studio Runtime cannot be started from the Robot Manager Dashboard. The Start command issued by the Robot Manager is handled by the RPA Service which requires Synchronization engine. This should not hamper any features of the Studio environment as that environment is intended for the development of a solution while the Start/stop/Schedule feature of the Robot Manager is so to decide when a robot should be running and under which workgroup.
The purpose of the Synchronization Engine is to ensure the running runtime version matches the deployed package version ensuring compatibility. This should not be an issue for the Studio runtime environment as it should already match the package version. Hence, the Synchronization engine feature is not necessary for Studio installs.
The only other reason I can think of why Robot runtime didn’t start successfully in RpaService.log_.1.txt scenario is may the loading of runtime package took additional time than the default timeout.
Try this step:
- Open Robot Manager dashboard
- Navigate to Robots tab
- Click on the assigned workgroup of the Robot Runtime
- Under the Package section, click on the Pencil icon (PackageSection.png)
- Modify the seconds field to a value that should be more than Robot runtime takes to load a package (ExpectedLoadTimeScreen.png)
- A good start would be with 120 seconds
- Click Save button
Hope this helps!
Thanks
Pegasystems Inc.
JP
Dear Rushabh,
Thank you for the detailed response. Helps understanding many things. I will try the suggestions once we are back in office (currently there is a holiday week in Japan.)
Best regards,
Mangesh
Pegasystems Inc.
JP
Hello @rushabh Shah
I have reconfigured my environment. Subsequently, I upgraded to 19.1.22.
Upon installing Synchronization engine, and setting up the runtime properly I am now able to
1. Remotely login to the Runtime terminal
2. Start Runtime
3. Load the package (haven't yet set the package server, and hence using StartupProject)
4. Run the automation and poll for next assignment.
5. Remotely shutdown (i.e. log off) from the terminal (This was working before)
Thank you for the help.
There was an error though when I had enabled Synchronization Server connectivity during Sync. Engine installation. I have attached the screen-shot. I haven't yet set up the Sync. Server, and hence the error I think. However, what I could not figure out is:
1. Where is this error logged? I understood that error is in the Updater to stage, as upon clicking OK button, Runtime was launched successfully. So I was checking the Updater log as well as PackageDownloader log, but could not find it. My bad, I had not changed the roll-up parameter to more than 1.
Eventually, I uninstalled and reinstalled everything, and did not enable Server connectivity in Sync.Engine installation, which solved (?) the problem, .but it will be good to know where does error get logged.
Hello @rushabh Shah
I have reconfigured my environment. Subsequently, I upgraded to 19.1.22.
Upon installing Synchronization engine, and setting up the runtime properly I am now able to
1. Remotely login to the Runtime terminal
2. Start Runtime
3. Load the package (haven't yet set the package server, and hence using StartupProject)
4. Run the automation and poll for next assignment.
5. Remotely shutdown (i.e. log off) from the terminal (This was working before)
Thank you for the help.
There was an error though when I had enabled Synchronization Server connectivity during Sync. Engine installation. I have attached the screen-shot. I haven't yet set up the Sync. Server, and hence the error I think. However, what I could not figure out is:
1. Where is this error logged? I understood that error is in the Updater to stage, as upon clicking OK button, Runtime was launched successfully. So I was checking the Updater log as well as PackageDownloader log, but could not find it. My bad, I had not changed the roll-up parameter to more than 1.
Eventually, I uninstalled and reinstalled everything, and did not enable Server connectivity in Sync.Engine installation, which solved (?) the problem, .but it will be good to know where does error get logged.
2. Apart from above, even when things are running, I can see the following error in PackageDownloader log after Robot authentication:
Error while reading Etag for file 'C:\ProgramData\Pegasystems\RuntimeConfig.xml', will request new file from server.
Error while getting etag from server: 'WebException: Response Code 'NotFound'. Response Content Type 'text/html;charset=UTF-8'. Response Body 'Resource not found'. Friendly Message 'リモート サーバーがエラーを返しました: (404) 見つかりません'.'. Server Url: '/PRRestService/robotics/v1/runtimeconfigs'.
I have not provided the server Url in configuration file, so reason behind 404 error is obvious. What I want to know is what is this etag which the program is trying to find? I have attached the log file in question as well.
Pegasystems Inc.
US
For point 1, When exactly did the error occur? Did it occur during installation of Synchronization engine? Did it occur when running the pega loader?
For point 2, you can disregard the error. In v8.3.1 of Robot Manager, Runtime can use the RuntimeConfig.xml defined from the Robot Manager Dashboard. Since, you are on a version lower than that it doesnt find the resource at the endpoint where it expects to the get the RuntimeConfig.xml .
Pegasystems Inc.
JP
Hello @rushabh Shah
I understood the explanation for Point 2. I and will check it once I upgrade RM to 8.3.1.
As for point 1, the error used to occur right before Runtime would start, but I am unable to pinpoint the timing as its nowhere logged unfortunately.
I have tried regenerating the error, but somehow it hasn't been recurring. Although, I could verify that enabling/disabling Sync. Server connectivity during Sync Engine installation has nothing to do with the error with the help of following:
1. I have reinstalled and have enabled the connectivity with default values, i.e. Product Repository URL as https://localhost:5001/api/v1/, Local Service Port as 9000, etc. It gave no error, although the updater stage took a lot longer, due to which the SendCommandStatusActivate failed. Mitigated by increasing the Package Expected Load time value on RM (60 sec -> 180 sec.) as suggested by you earlier as well as in the log, and it worked.
2. Modified the UpdaterConfig.xml with 'wrong' values for Product Repository URL and Local Service Port which were the ones when I had gotten the error, restarted the service, and retried starting the VM from RM. It worked, and was rather quick, since the Updater module ended fairly quickly owing to the erroneous values as mentioned above. The Updater log file did have similar error as before, but I did not receive any error pop-up.
Hello @rushabh Shah
I understood the explanation for Point 2. I and will check it once I upgrade RM to 8.3.1.
As for point 1, the error used to occur right before Runtime would start, but I am unable to pinpoint the timing as its nowhere logged unfortunately.
I have tried regenerating the error, but somehow it hasn't been recurring. Although, I could verify that enabling/disabling Sync. Server connectivity during Sync Engine installation has nothing to do with the error with the help of following:
1. I have reinstalled and have enabled the connectivity with default values, i.e. Product Repository URL as https://localhost:5001/api/v1/, Local Service Port as 9000, etc. It gave no error, although the updater stage took a lot longer, due to which the SendCommandStatusActivate failed. Mitigated by increasing the Package Expected Load time value on RM (60 sec -> 180 sec.) as suggested by you earlier as well as in the log, and it worked.
2. Modified the UpdaterConfig.xml with 'wrong' values for Product Repository URL and Local Service Port which were the ones when I had gotten the error, restarted the service, and retried starting the VM from RM. It worked, and was rather quick, since the Updater module ended fairly quickly owing to the erroneous values as mentioned above. The Updater log file did have similar error as before, but I did not receive any error pop-up.
I tried with an older version project, as I have a feeling that it might have occurred while verifying Robot Runtime Version, which is the stage prior to Runtime startup. But even that did not yield the error.
I believe I will not invest anymore efforts in regeneration, unless the error occurs anytime again.
Thank you for your insightful comments all along.
Pegasystems Inc.
US
If it was right before the runtime starts, it would have probably created a fallback log under %programdata%\pegaystems. If you do face the issue again, it would be best if handled by the GCS team via creating a SR.
Hello Mangesh,
The RpaService.log_.1.txt logs doe show that logging was successful, and runtime was scheduled to start at 2019/12/18 14:22:47. The only reason I can think of it not starting at that point is machine was busy performing its startup activity denying/delaying the schedule request. By default, RPA Service schedules runtime to run fifteen seconds after a successful login. You can configure the time by modifying the ScheduledTaskStartBoundary key value in RPAService.exe.config. The location of the config file should be C:\Program Data\Pegasystems\Pega RPA Service.
Note: You will need to restart PegaRPA Service after a change in the RPAService.exe.config file.
The exception in the RPAServicelog.txt is thrown when the RPA Service cannot find the Pega.Loader.exe. This executable is part of the Synchronization engine install. Were you trying to use the RPA Service with Pega Robot Studio? If so, that is not a supported configuration.
Thanks