In part 1 I discussed why customers “bother” to upgrade their current Visualization Solutions by Nakisa (VSN) applications. In part 2, I discussed what you should know beforehand so that the environment is ready to install the upgraded VSN applications.
In this, the third and final part, I will discuss how to go about carrying out the upgrade and what the challenges are as well as ways to address and manage them.
I’ll deal with each of the 8 steps in the process, starting with some good practice … backing up!
1. Backup
For pre-3.0 versions, you will have to do this manually by zipping the contents of the directories below “Admin_Config”. For 3.0 versions onwards the AdminConsole provides a backup facility. To use the backup facility, login to AdminConsole and identify the configuration builds you wish to retain. Load each build in turn into the AdminConsole and once loaded locate the “Export Changes” button (top right). Click the button and when prompted enter a name for your build. The AdminConsole will then create a ZIP file which you can then download from a link presented by the AdminConsole. Save the file somewhere safe. Do not save it to a location below the application root directory as this will be removed then you carry out the un-deploy step of the implementation.
Also, ensure you have a copy of the licence “serial” file stored safely (this is found in the application’s XML directory).
2. Check the Pre-Requisites
Ensure that the hardware and software prerequisites are in place (refer to the Master Guide PDF for the product version and my previous blog).
3. Identify Whether to Upgrade or Re-Implement the Configuration
There has never been an automated upgrade process for VSN applications. Mostly this is related to the re-engineering that has taken place at certain points along the product’s development.
However, as of 3.0, the product introduced the concept of a “.delta” structure where all client specific configurations are stored. The introduction of the “.delta” concept has made it easier to upgrade a build within the same product and service pack version (for example on the advice of SAP Support to address a product issue). A SAP knowledge base article exists (1584574 - FAQ: How to implement the latest build for Nakisa) to explain this process and you will notice the similarity with my advice below although I introduce a further check step.
If you are changing service pack or product version then you first need to consider whether to import your existing (exported) VSN configuration into the new version or re-implement your VSN configuration changes into a copy of the standard VSN configuration build for the new product.
Most VSN applications don’t have the different build variations that have evolved with the product versions in the same way as OrgChart, so the table of options for non-OrgChart applications is pretty simple:
Current Version | 4.0 |
1.1 | Re-implement |
2.0 | Re-implement |
2.1 | Re-implement |
3.0 | Re-implement |
3.0 SP1 | Re-implement |
3.0 SP2 | Re-implement |
3.0 SP3 | Re-implement |
| 4.0 | Upgrade* |
| 4.0 SP1 | Upgrade* |
*Upgrade with caution
OrgChart presents a greater range of options as it has a variety of builds over different product versions. My recommendation is based on the master build you are currently using, the current application version and the target 4.0 or 4.0 SP1 build (type) you wish to upgrade to. If you are already on 4.0 SP1 and simply updating your build version level then you can upgrade (with caution - see below).
Current Version | Target 4.0 or 4.0 SP1 build->
Current “Master” Build | SAP_Live_RFC | SAP_Staged |
1.1 | All | Re-implement | Re-implement |
2.0 | All | Re-implement | Re-implement |
2.1 | All | Re-implement | Re-implement |
3.0 | SAP_Live | Re-implement | Re-implement |
SAP_DB2, SAP_MaxDB, SAP_Ora, SAP_Sql | Re-implement | Upgrade* | |
3.0 SP1 | SAP_Live_2 | Re-implement | Re-implement |
SAP_Ora, SAP_Sql | Re-implement | Upgrade* | |
3.0 SP2 | SAP_Live_2 | Re-implement | Re-implement |
SAP_Staged | Re-implement | Upgrade* | |
3.0 SP3 | SAP_Live_2 | Re-implement | Re-implement |
SAP_Live_RFC | Upgrade* | Re-implement | |
SAP_Staged | Re-implement | Upgrade* |
*Upgrade with caution
Note: You can ascertain your current master configuration build type for 3.0/4.0 products by opening the ZIP file you created using “Export Changes” and reading the contents of the file “masterBuild.sys”. The ZIP file contains a directory (named for the build) at the root level within the zip; the masterBuild.sys file is located within this directory and may be viewed using a text editor.
As you can see, quite often the best way to upgrade is to by re-implementing your requirements on the new application version. If this is the method you choose then, of course, you will find it highly beneficial to have your old configuration (and hopefully the documentation from your original project) as reference.
If your build is suitable for upgrading then you should be aware of why you can’t assume that simply importing your existing (exported) configuration into the new application version is a safe approach … and this warning can equally apply when simply updating the build version within the same product version and service pack level. I’ll explain why ….
Why does Conflict Occur?
The “.delta” file concept is great at isolating customer specific changes, but there is a risk that in an upgrade these customer specific changes override standard application changes. This occurs because of the order that configurations are loaded when you load a build in the AdminConsole. When you load your own build, the application loads the master build configuration on which your build is based, then any add-ons enabled for that build and finally it loads the “.delta” changes.
So to give an example, let’s take the OrgChart configuration of analytics. For the “Live” build the default configuration for how analytics are generated can be found in the standard build configuration file:
..\root\.system\Admin_Config\SAP_Live_2\Analytics\Counts.xml
When you configure this (e.g. to disable certain analytics), you will have created this file:
..\root\.system\Admin_Config\__000__BUILD\.delta\Analytics\Counts.xml
Note: This is in the .delta of your own configuration build (called simply “BUILD” in the example above).
When you next load the build via the AdminConsole, the application loads the standard build Counts.xml file and then it replaces it with the .delta version of Counts.xml from your build, so you end up with the value you configured -> great!
However, when upgrading your application version then an update may have occurred to the standard file; perhaps to enhance the feature or correct a product bug.
For example, between OrgChart 3.0 SP2 builds 255 and 263, a bug fix was introduced that amended Counts.xml to ignore empty positions from demographics. I could cite other examples (introduction of case sensitive searching in staged builds for example). So if you had simply exported your existing build, updated your application and imported your configuration you will have bypassed this change without any notification … and you’d still be seeing empty positions in demographics and searching would be case sensitive!
How do I manage these conflicts?
Where is SPAU, I hear you ask! Unfortunately neither SAP nor Nakisa provide a tool for finding and managing conflicts. However all is not lost, as you can approach this methodically.
Firstly what you are really trying to ascertain is whether the contents of your exported ZIP file conflicts with changes in the new application version. If you don’t have a large amount of files in your ZIP then you can use tools, such as DiffMerge, to compare “your” version of a file to the “new” standard file.
Doing a compare of Counts.xml in my previous example above shows the change clearly:
These types of tools are also useful for managing (merge/ignore) the changes into your version of the configuration file. Applying this technique, you can produce an “upgraded” version of the configuration build, as a ZIP file, ready for importing safely to your upgraded application.
I’d recommend working with an experienced VSN consultant during this process … a few hours from them could save you (and SAP support) a lot of time hunting down a “phantom bug”. As a warning, SAP support will (rightly so) ask you to demonstrate that any bug can be replicated on the standard “master“ build. If you have a conflict that you have not managed, then your bug won’t be in the standard build and you will then need to investigate and resolve the configuration issue yourself.
It happened to me once and it was frustrating to discover it was a change introduced by a product update conflicting with a configuration change I’d done previously in the AdminConsole … and I had thought I was upgrading safely!
4. Un-Deploy Your Existing Application(s)
Warning: As of this step, your application will not be usable until you complete the upgrade.
For SAP NW versions of VSN applications, use the Deployment Guide to un-deploy the current application version. I strongly recommend using the command line approach detailed (in the VSN 4.0 Deployment Guide) as I have found it more reliable than the NetWeaver Developer Studio method. Using the command line method, the un-deploy should take approximately 1-2 minutes.
5. Deploy the New Application(s)
For SAP NW versions of VSN applications, use the Deployment Guide to deploy the new VSN software component archive (SCA) using Java Support Package Manager (JSPM).
6. Apply the Serial File
When you access the application’s AdminConsole for the first time after deploying, you will be asked to upload the serial file (that you backed up earlier). Again, this process is documented in the VSN Deployment Guide.
7. Import your Upgraded Build
Load the AdminConsole and at the configuration builds list, select the option to “Browse”. Locate and select the ZIP file for the upgraded build you wish to import. Next select “Import Build”, give the build a suitable name and click “Import” to have AdminConsole extract the configuration into a new folder structure (on the server).
8. Load, Publish and Test
Select and Load your build into the AdminConsole. Once it has been loaded, click the Publish button to make your build active. Finally, test it!
Summary
That concludes series of blog posts on why and how to upgrade any VSN application from any previous version to the current 4.0 SP1 version. I hope you’ve found the series useful and that as a result you and your organisation have chosen to take advantage of the latest and greatest VSN features.
Thanks to my colleague at ROC, millard.stephen for sense checking my blog posts in this series before I published.
- SAP Managed Tags:
