Академический Документы
Профессиональный Документы
Культура Документы
2
Basics and Best Practices
Sathish Rajagopal, SAP
January 30, 2018
PUBLIC
Agenda
Upgrading to BI 4.2 - How to best plan and execute the Upgrade project;
Upgrade strategy
BusinessObjects BI versions and Upgrade paths
Things to do prior and post Update and Upgrade
Product enhancements and how they further improve the Upgrade experience
Key Takeaways and Useful Resources
Q&A
When you are on BI 4.0 or BI 4.1, the process of moving to BI 4.2 is called “in-place” Update.
Because it’s a single step process, you can also call it as “one step upgrade”
Again, there is no need to migrate or move your objects from one system to other. But similar to
applying a patch or support pack, you will apply BI 4.2 on top of your BI 4.0 / 4.1 system
Run the Platform Support Tool to capture the system snapshot and more
Disable system updates such as regular OS, third party components’ update etc.
Review the latest Platform Support document (PAM) to make sure the versions/releases are
supported, including third party software components
If you have add-ons in your deployment, make sure to download and have the required
components ready to move to BI 4.2
Enter the new license key that you received from SAP for the BI 4.2 system
Check and validate to make sure all the required services are running, including by verifying the
corresponding .exes are running ok using task manager
Make sure to check and apply the changes or any customization done previously in system files
such as “server.xml”
Perform random check on authentication, authorization, report access etc. to make sure
everything works fine post update
In addition, it’s also recommended to run tools / utilities like RepoScan, Platform Support Tool to
make sure everything is comparable to prior and post update snapshots
Upgrading from BOE XI 3.1 or BOE XI R2 SP2+ to BI 4.2 is what we call as a two-step process;
▪ Install and configure up your new BI 4.2 system
▪ Move objects from source (3.x or R2) to target (4.2) using Upgrade Management Tool
Understand the value drivers / value proposition in moving to the latest release ( BI4.2) to secure
proper resources and support
Do proper planning and upgrade assessment before executing your upgrade project
Make sure to follow proper methodology for successful completion of your upgrade project
Making sure to learn the new features in Upgrade Management Tool and how it can impact the
overall upgrade process
Revisiting the requirements and accordingly sizing the new BI 4.2 environment is very important
Understand the importance of optimal server configuration (starting with APS , WAS and so on)
Review the security model and learn the differences between release to come-up with proper
implementation plan
It’s recommended to host the Upgrade Management Tool (UMT) on a dedicated server for better
throughput / performance
We did talk about upgrade assessment but it’s worth mentioning again about “content inventory”.
This will significantly help determine to move the right number of objects to BI 4.2
Run a mock test of the upgrade workflow in UMT to accurately estimate the efforts, time and
duration of the upgrade project
Verifying or creating (if security is not migrated) the security model in BI 4.2 landscape
Enabling default system (such as anti-virus) and other operating system updates (that was
paused before the upgrade)
Be familiar of the known issues and perform proper testing and validation before releasing the
new BI 4.2 landscape to end users
– From any BI 4.x to another other BI 4.x (e.g. BI 4.0 SP4 to BI 4.2 SP4)
– Direct update, no need to go via any particular version
▪ Full install is needed when changing Operating Systems or CMS database vendor (not true)
– Repository and Cluster management alternatives are far more suitable
Installed: Installed:
Update Server software before Client software Any BI 4.x SP x Patch x Any BI 4.x SP x Patch x
E.g. BI 4.0 Support E.g. BI 4.0 Support
Pack 5 Patch 3 Pack 5 Patch 3
Client software
Server software Client Software
must never be
(Support Pack or Patch (Support Pack or Patch
applied before
Level) Level)
server software
Installed: Installed:
Any BI 4.x SP x Patch x Any BI 4.x SP x Patch x
E.g. BI 4.0 Support E.g. BI 4.0 Support
Pack 5 Patch 3 Pack 5 Patch 3
Server software
Client Software is on a different
Server software
(Support Pack Level) Support Pack
(Patch Level)
level to the client
software
Each node must go through the update Must never mismatch node and repository version
▪ You must update at least 1 node within the cluster ▪ Can’t just install new software on a new machine and
▪ You must update all(*) other nodes within the cluster point it to an old repository
▪ * You don’t have to update nodes that will be deleted
CMS database
CMS database Version 4.1
Node 2 Node 4
(has a CMS running (does not have a CMS
on it) running on it)
▪ Add-ons must be installed separately
In Parallel In Parallel
Downtime
Rule
Node 1 Node 2
▪ Must be the same version
Windows Windows
Node 3 Node 4
Rule
▪ Must be the same version Node 1 Node 2 Node 3
New Nodes:
▪ Could be a ‘full’ installation and not patched like other nodes
CMS database CMS database
Adding “Node 3” into existing CMS database
▪ Central Configuration Manager: Add Node - Recreate node
▪ Specify exact same name, “Node 3” in this example
▪ Specify new CMS database Node 1 Node 2 Node 3
Merge complete
CMS database contents
Duplicate selective
content
CMS database CMS database CMS database
CMS database
Production Test
First level
▪ Second level
– Third level
✓ Learn the business and technical considerations and review them carefully before starting the
upgrade project
✓ Plan and execute a proper upgrade assessment exercise before kick starting the workflows
✓ Make sure to study the new features/innovations and how they can impact the overall upgrade
project and the proposed new architecture
✓ Don’t forget to follow the important post-upgrade procedures including user training to
proactively communicating the new features/changes to the business and IT teams