Question
TCS
CA
Last activity: 23 Aug 2018 19:06 EDT
Runtime is not picking up the newer version (sometimes)
Hello team,
We keep the source location as follows.
\\SharedDrive\Folder\ProcessName.OpenSpan
When the runtime is run first time, the source file(s) from this location gets copied over to the "LOCAL" drive as follows.
"C:\Users\<<LAN ID>>\AppData\Local\OpenSpan\8.0\Projects\Project-XXXXXXXXX" and Runtime seem to be using this location for all subsequent runs.
Now, the issue is .....
When we deploy a new version to \\SharedDrive\Folder\ProcessName.OpenSpan we noticed that (sometimes) we need to delete the "LOCAL" folder so it picks up the newer version. It does not happen all the time.
How do we make sure that it picks up the newer version all the time whenever we deploy?
Pegasystems Inc.
US
Assuming you have increased the version number, it should pickup the new version when Runtime is restarted. Make sure that you are placing the full deployment package (both the *.OpenSpan and the *.Manifest files) on your share as well.
TCS
CA
Hi Thomas,
Visual Studio takes care of incrementing the version number after each deployment and we have double-checked it and it's a higher version. However, sometimes it does not seem to pick up unless we delete the local folder.
My query is two-fold.
Sometimes, we have to rollback to a lower version as well. So, when we provide a previous snapshot (that contains a lower version), the same issue exists. Unless we delete the files in the local folder, the run does not seem to pick up the changes at all.
I also have done another testing. I remove the package completely from shared drive (including the folder) and now RuntimeConfig.XML "StartupProject" is pointing to a share drive that does not exist. Yet, when we run the automation, it still works which implies that its running the automation using the files present in the local folder. And also implies that it's not checking if a higher version is present or not.
Standard Chartered Global Business Services
IN
I too have experienced this issue sometimes. The workaround that we do is to delete the local "OpenSpan" folder in the appdata ("C:\Users\<<LAN ID>>\AppData\Local\OpenSpan") using a batch file before starting OpenSpan, so that OpenSpan always retrieves from the shared folder.
Thomas, I also remember that there used to be a property called 'LoodGoodDeploymentPackage' in RuntimeConfig.xml earlier, which we can use to specify whether to use the last good deployed package in case the shared folder is inaccessible for some reason. I'm not seeing this with the newer versions. If this has been removed, any reason why is it so?
Pegasystems Inc.
US
Please add your RuntimeConfig to your post. Also, which version are you running? I tested with 8.0.1082 and am not able to duplicate your results.
TCS
CA
Hi Jeff,
Our current version is version="8.0.1018.0".
Also as I have mentioned, it does not happen all the time. But, when we rollback to a lower version, it is almost every time that we have to clear the "Local" folder first for the runtime to pick up the change from share drive.
Fifth Third Bank
IN
Hi Anil,
Create a shortcut of runtime with argument project="\\server\folder1\folder2\automation.openspan"
it typically looks like below:... C:\Program Files (x86)\OpenSpan\OpenSpan.Runtime.exe project="\\server\folder1\folder2\automation.openspan".
Hope this will help you.
Thanks,
Harish.
Pegasystems Inc.
US
I would recommend moving to a current version. 8.0.1018 was released Dec 3, 2016 - the product has significantly changed since then.