There is much confusion within the market place around the correct update process for updating from BI4.0 to BI4.1, or from BI4.0 to BI4.2. or from BI 4.1 to BI 4.2. (any BI4.x to any BI4.x)
The situation is made worse by common misunderstandings resulting in huge amounts of unnecessary “update effort”. This is in addition to BI4 repositories becoming corrupt and all the pain of sorting that out.
Sadly there are two tiny, but pretty significant documentation “bugs” which exacerbate the confusion.
This blog will address these common misunderstandings. We’ll also talk about those very important documentation ‘bugs’. But first let’s start with how you should update from BI4.0 to BI4.1
BI4.0 to BI4.1/BI4.2 strongly recommended update process
The update to BI4.1 (or BI 4.2) from BI4.0 is the same process as applying a Support Pack. I.e. just apply the ‘patch’ software to update from BI4.0 to BI4.1. There is no need to install BI4.1 on a new machine, nor is there a need to move, or copy content from one repository to another. Indeed it’s vital that the CMS System Repository database is updated as part of the update process.
You can update from any version of BI4.0 to any Support Pack version on BI4.1 or BI4.2 directly. There is absolutely no need to go ‘via’ any particular version (unlike XI3 Service Pack updates). I’ve created KBA 1909881 note to explain in more detail. Updating from BI4.1 to BI4.2 is the same, just apply the Support Pack.
Misconception: To save disk space a full install is needed
Many organisations perform a full installation of the ‘next’ product version to avoid too much disk space being consumed. However a full installation is not needed to recover disk space consumed by installing Patches or Support Packs over and over again.
Older Patches and Support Packs can simply be uninstalled. Select the ‘older’ product version from ‘Programs and Features’ and select ‘uninstall’. The installer will very cleverly remove the old product from the cache saving disk space. How cool is that! Don’t remove the original base install as that will remove the entire product.
Misconception: Full install is needed for new features
If you want to use of the expanded set of ERP Drivers available in this release, you will need to perform a full install.
You must do a full installation to get the new features
We’re sorry for the confusion and we’re busy correcting the guide for the next release.
When the update is applied, only the existing software components are updated. All new features for those existing components will be updated. Any new components available will not be installed. To install new components, simply modify the original base installation and select the new components to install. The patch installer even provides a friendly reminder to do just this at the end of the update.
The list of additional components between BI4.0 SP2 and BI4.1 SP1 is:
- Servers – Platform Services – Sybase SQL Anywhere Database
- Servers – Platform Services – RESTful Web Service
- Servers – Platform Services – Insight to Action Service
- Developer Tools – SAP BusinessObjects Semantic Layer Java SDK
- Database Access – DataDirect ODBC
- Database Access – SAP HANA
- Database Access – SAPBW64
- Database Access – SAPERP
- Database Access – XML WebServices
- Database Access – OData
- Database Access – Hadoop HIVE
- Database Access – dbase
The list of additional components between BI4.2 and BI4.2 SP5 is:
- Administration Tools – Automation Framework
- Administration Tools – Promotion Management Wizard
- Database Access – CMS DB Driver
If you’re connecting to BW using the ‘old’ UNV BAPI connectivity, then you’ll benefit from installing SAPBW64 for improved data retrieval performance. See KBA 1930558 for more details. This note also shows the user interface for modifying the original base installation and selecting new components.
Why is installing a ‘full’ install such a bad idea for updating?
Due to one or both of the above misconceptions, many organisations install a ‘full’ installation on another machine and then either ‘move’ the content to it, or they re-point the new ‘full’ installation to the ‘old’ existing repository.
There are two main reasons these workflows are such a bad idea:
1) Misconception: Best way to move entire Repository content in one go, is with Promotion Management
Moving the complete content between two BI4 repositories in one go is not easy if you use the wrong tool. Many attempt to use Promotion Management but struggle since it’s simply not designed for this task.
Promotion Management is intended for a relatively small number of objects at a time since the primary use case for Promotion Management is to promote ‘developed‘ content from Development into Test and then Production. The tool for example doesn’t promote the following because these items fall outside of that use-case:
- Users (that only have a 3rd party alias) and all their favourite/inbox content
- Setup of 3rd Party authentication
- Promotion Jobs themselves
- Authentication setup/settings
- Server group to server relationships
- Applications (or application Settings)
- License Keys
These are already good reasons not to use Promotion Management since manual effort is required to ‘recreate all these’, additionally:
- Since Promotion Management is a web based tool when a large number of objects are defined within a Promotion Management Job ‘web timeouts’ occur creating or managing the job.
- The ‘Check_out’ folder used for the integration with the Version Management System requires a little planning. See KBA 1802390
For the overwhelming majority it’s quite unnecessary to perform a ‘full’ installation, but for those that do and need to move the complete contents between two repositories it’s actually so much easier if the correct method and tool is used: Copy the CMS Repository database and FRS file system and point the ‘other’ installation at the copied content. You need to be sure you’re using the same Operating System, ‘install path’ and exactly the same product version. For very thorough and detailed steps you can follow the instructions within the Administration Guide Chapter 14 “Copying your Business Intelligence platform deployment”. We’d prefer for you to use a firewall to stop the two installations from clustering with each other but if you can’t, use the workaround in KBA 1275068 with caution (I really don’t want to promote removing rows from the CMS database but it is a good workaround!)
There are plans to improve the performance for creating and importing Promotion Jobs containing a large number of objects in BI4.1 Support Pack 2. We’ll have more details on that nearer the time. The recommendation now and for the future, is to use the LCM command line interface to create and import large jobs, since there will be no web based timeouts. However the recommendation will remain that Promotion Management should not be used to copy the entire contents from one repository to another, or use it as a sole backup mechanism.
2) Misconception: Repointing a newer Product Version to an older Repository version is valid
The best way to explain a commonly misunderstood workflow is by example: Let’s say you have installed BI 4.0 Support Pack 6 and all your content is held within it. You’ve installed BI 4.1 Support Pack 1 on a completely new machine which you want to ‘migrate’ content to. You then stop the BI4.0 machine (Step 1) and point the BI4.1 machine at the CMS database (and FRS file-store) the BI4.0 machine used to use (Step 2).
However this workflow is not supported and you’ll run in a whole manner of issues, including but not limited to:
- HTTP 500 and ‘null’ pointer exception when logging into Central Management Console for the first time
- CMS process does not start
- “?????? dummy ?????” placeholders appear within the User Interface rather than the correct name
- Missing Applications, Application Settings, Security rights, icons
- ‘Old’ Applications, Application Settings, Security rights do not work as expected and cause various errors.
Why? Because when you update to a new version (Minor or Support Pack level) you not only update the software on the disk, but you also update the repository with ‘default objects’ (called DFOs). These DFO’s define ‘object types’ such as a ‘folder’, ‘user’, ‘application’ and just about anything the BI Platform hosts. Many ‘got away’ with this workflow in XI3.1, but this only because there were hardly any new or updated ‘default objects’ introduced in Service Packs in XI3, unlike BI4.
I’ve created KBA 1882363 to explain this in more detail with resolutions.
Feel free to post your feedback here or via Twitter (@MattShaw_on_BI); I’d very much welcome questions/comments to ensure a smooth update to BI4.1/BI4.2
(This blog updated to additionally refer to BI4.2, since the same applies for an update to BI4.2 as it does for BI4.1)