This is part of the SAP BI Version Management blog series. My previous blog was about the need for version management in SAP BI and some advantages of using it. This blog will explain the basic workflow of SAP BI version management and the terminologies/options used within it.
Overview of Terminologies and Options
CMS version of the report is the current active version in the CMS DB / SAP BI repository. When a developer saves the report, CMS version will be generated. In other words, when a user executes the repot in Launchpad CMS version will be executed. There will be only one copy of a particular object in CMS and it is called as CMS version. When a developer saves his changes on an existing report that is added to VMS, current CMS version will be over-written with new version and version number will be incremented by 1
VMS version of the report is the version that is last checked-in to the version management system. When a new report is added to Version Management System (VMS), it is considered as first check-in and VMS Version 1 and any further check-in(s) will increment VMS version by 1. Unlike CMS, VMS can store multiple versions of the report and this helps us to revert to earlier version when needed.
Add to VM
Add to Version Management is the first step towards initiating version control. When an object is added to version management, it will store a copy of the current CMS version in the Version Management system. CMS version and VMS version will be set to 1. Once this step is completed, changes to CMS version can be stored as a copy in version management.
Check-in is the process of saving the current CMS version as a copy in to the VMS. When a change is saved in the CMS, CMS version of the object will be updated. However, VMS version will not change. Performing a check-in will save the current CMS version as the new VMS version. However, version management will retain copies of old VMS versions.
Get Latest Version
This option performs the reverse of check-in. When Get latest version is executed, latest copy of the VMS version will be used to over-write current CMS version. In other words, all changes made to the report will be lost and it will be replaced with last stable version stored on the VMS
Create copy is more like “Branching” done is software development. When create copy is performed, another copy of the report is created from the latest VMS version. However, when creating a copy, CMS version number and VMS version numbers won’t be updated in the VMS. Newly created report will not be part of the VMS and “Add to VM” should be performed separately to manage versions of the copied report.
As the name implies, history option will show the whole history of the report and all versions in the VMS system. From the history option, it is possible to get a checked-in version, export a copy and get a copy of the report.
View Deleted Resources
This option allows admins/developers to recover deleted reports/objects. However, that object should have been added to VM before and when deleted from CMS, a copy can be restored from VMS. This option is different from “Recycle Bin” option and has some advantages compared to it
Lock and Unlock help admins/developers to prevent unwanted check-in to the VMS system. When an object is locked, new check-in(s) (or) Copy cannot be done. Unlock will enable the check-in/copy options.
Delete option will remove the report from VMS. CMS version of the report will remain in SAP BI repository and that will not be removed. Removing the object from VMS will remove all VMS versions and CMS version will be retained. Object removed from VMS can be added to VMS again using “Add to VM” option.
Let us now look at the VMS basic workflow…
- User creates a report and saves it to CMS/SAP BI Repo – Active version of report is generated
- From Version Management, object will be added to VMS
- A copy of the report will be stored to Version Management and CMS version/VMS version will be set to 1
- User makes some changes to the report and saves it to CMS again
- CMS version will be updated; however, VMS version will remain the same.
- Now the developer/admin can check-in the new CMS version to VMS – VMS version will be updated
- Now CMS will hold only version 2 (active version), however VMS will hold version 1 and 2
This concludes the description of VMS terminologies, options and workflow. We will be looking at more Advanced topics in the upcoming blogs of this series…