Avoiding big bang update of clients for BI 4.2 Support Pack 4
In my blog about updating to BI 4.2 Support Pack 4, I mention there is a gotcha caused by the crypto libraries being updated. This means that you have to update your server and clients all in one go, since an older client technically can’t connect to a newer server. You can’t get away with an unsupported workflow where you could update the server first and then gradually update the clients over time. In this blog I share a theoretical solution. It is completely unsupported and untested but it could be a workaround this problem.
I wrote:
Any client ‘less than’ BI 4.2 Support Pack 4 connecting to a server ‘greater than or equal’ to BI 4.2 Support Pack 4 will not work. This isn’t supported, but many organisations update the server first (rule 1 above) and the later update the clients. So for a short period of time, the clients are one (or two) Support Pack versions lower than the server. Whilst not supported, with BI 4.2 SP4 this really won’t work meaning all server and all clients must be updated to the same version in one go. No gradual update for clients. Once you’re on BI 4.2 SP4 then future updates, to say BI 4.2 SP5, it should work again, but unsupported as usual!
Although completely unsupported there could be a way to allow your old clients (less than BI 4.2 SP4) to communicate with a BI 4.2 Support Pack 4 server!
This has not been tested or validated by SAP in anyway whatsoever, so anything I mention here and you do is completely at your own risk! It’s therefore even more important to do a backup before you replace files!
Copy these 3 files from a BI 4.2 Support Pack 4 machine to your older BI 4.2 Support Pack 3 machine: <INSTALL_DIR>\SAP BusinessObjects Enterprise XI 4.0\java\lib\bundles
-
com.businessobjects.bcm.jar
-
com.businessobjects.boesdk.jar
-
com.businessobjects.corba.jar
Doing so will replace rsa, bcm, sdk, corba jars and this should, at least in theory, allow an old client to connect to a BI 4.2 SP4 server.
Did I mention this isn’t supported and that this hasn’t been tested or validated by SAP in any way?! You do this at your own risk.
If you do decide to give this a go, please do post your feedback to let other customers know if it worked for you or not. Please post the product versions you used.
Matthew (@MattShaw_on_BI)
Hi Matthew,
good to know we may need this in the near future.
Is there a similar approach for changing the WebI Java Certificate without the need to patch your BIP?
https://launchpad.support.sap.com/#/notes/2448936
Regards,
Michael
Hello Michael, not as far as I'm aware. Regards, Matthew
I got some help from this post to solve my Java standalone application logging to the SAP server with 4.2 SP4 patched. And I would like to share some of my experience for other people reference.
For a Java standalone app, you need to upgrade to following Java libraries, you can get these JAR files from the SAP SP4 installation folder.
— these files are new files:
======
Then you use the following code sample to logon the SAP server.
Many thanks for sharing. I'm sure other customers will find this information very useful. Thanks again, Matthew
Matt -
Thanks for posting this "unsupported hack" to solve a pretty-serious real-world problem.
Is there any way that we can get the feedback to the product team that this kind of thing should "NEVER happen again'...?
Seriously, did the Platform Product Team even white-board a method for the Change-Management model for conducting an UPGRADE IN-PLACE on a Clustered BO-BI 4.2 platform (DEV / TEST / UAT / PROD & PROMOTION) with Thousands of deployed Desktop-Clients, and dozens of 3rd Party SDK tools and Custom .NET apps...?
Customers can spend years making BOBJ a "Central Reporting Hub" for a Complex, Multi-Source, Multi-Client environment....and the expectation that they can "flip-a-switch" everywhere / all at once is totally unrealistic.
Here endeth the rant,
Mark