Solution to automatically update bot packages

​@Uzumaki First, ask yourself WHY you want to update the bot packages. When you update the bot packages, you need to retest all bots affected.

Second, your control room administrator already has the ability do to this.

​@Uzumaki No worries. Upgrading bots isn’t like upgrading Windows/macOS or putting the latest update on your Android/Apple phone. No new features will automatically be added to your bot by upgrading its packages.

The way our Control Room and Bot Agent work is that older packages used with older bots are retained on the Control Room. When an older bot runs, the older package is downloaded to the Bot Agent. This ensures the bots continue to run smoothly.

When upgrading, you add a variable to the equation. The change in package could (but rarely does) cause some issues with your older bot. Maybe a function it requires was deprecated and upgrading the package actually broke the functionality of the bot. That’s why you would have to test every bot affected. Honestly, that’s a lot of work for zero benefit.  😅

​@Uzumaki Great question! 

Do you think there are risks involved with leaving certain bots as they are and never updating any of their packages?

My short answer here is “no”. The way the Control Room and Packages are set up, older versions of packages shouldn’t “fall off” or become deprecated. 

Your question about the Java update causing older packages to fail is a little more nuanced. Let’s look at another language that I know and love: PHP. I have source code from 2006 that I wrote in PHP 5 that will not run without refactoring in the current version of PHP (version 8.3 as of this post).

Will the same thing happen with Java and our Packages? Probably not, and due to the way our Packages work, we could easily put workarounds within the Package itself for newer versions of Java.

The difference is how we “compile” your automations on the Control Room before sending them to the Bot Agent for execution. We have that compile step that can bridge compatibility issues, silently implementing workarounds for Java updates.

Your case with SAP and having different package versions is quite exceptional. I didn’t even consider that different package versions of parent and child bots would cause multiple instances of the SAP DLL to be invoked, causing a collision. (I will put in a trouble ticket on this issue just for visibility.) I can’t think of other packages that would be affected in the same way.

Our recommended way of handling this is to not upgrade packages on automations unless necessary to enable new functionality, due to the need for QA testing after the upgrade. Reduces workload on your CoE and your QA groups.