Skip to Content

This blog does not describe differences between IdM 7.2 and 8.0. There is another blog post, analyzing the differences already available here.

Considerations

Generally, we can divide IdM into two objectives to be upgraded:

  1. The IdM data (like users, authorization objects and their relations)
  2. The IdM configuration (like jobs, provisioning framework, UIs)

In comparison to the upgrade from 7.1 to 7.2, the structure of the IdM data did not really change from 7.2 to 8.0. Hence, the modification of the data is only mandatory if a data cleanup is required and the upgrade project would be utilized to clean up the data. If a data cleanup is required, you can follow the steps described in the official help for this approach. In most of the cases, this is not mandatory or too cost intensive and therefore, modification of data will not be considered in the following upgrade approach.

Why this blog

The upgrade approach for a real upgrade described in the official help page (Upgrading Entire Existing System) would lead you to a stage where you run 7.2 configuration on an 8.0 platform. You would not use the newest provisioning framework and hence not be able to apply future releases of things like new connectors. I personally would call it a 7.2 compatibility mode, but not a full 8.0 upgrade.

This blog is created to describe a path to a full 8.0 upgrade and help you to understand the required efforts.

General approach

The data will remain in the system without modifications. Only the configuration will be upgraded.

This are the steps to be followed:

  1. Copy your current development system into a new system (if you want to keep a 7.2 development system as support system for the existing 7.2 implementation, otherwise you can skip this step)
    1. Connect new target systems to that development system
  2. Execute the standard upgrade procedure as described in official help documentation here.
  3. Now you have one package with all your 7.2 configuration inside the 8.0 system (7.2 compatibility mode), which will most probably not work as it refers to things like global constants and such.
  4. Import SAP standard configuration packages for 8.0 and perform basic configuration steps.
  5. Copy your custom configuration from the 7.2 package into 8.0 packages you create.
    1. Consider your transport strategy. Packages can only be transported as one, hence everything put into a package should be something to be transported at once. This could be a connector, custom forms or the approval workflows for example.
    2. There will be no global scripts anymore in 8.0. The global scripts that are still required should be copied into 8.0 packages. If a script belongs to a certain package it should be created in there. If not create a core package for scripts that are required globally (scripts such as z_uIS_setValue).
    3. When copying UI forms with post execution processes, such processes will not be copied with the form. The process has to be copied manually and relinked afterwards inside the 8.0 package.
    4. Jobs can be copied, but it is required to check the whole content of the jobs, as the former global scripts have to be relinked to package scripts and some configuration might not run on 8.0 (like usage global constants).
    5. Create custom connectors as copies from 8.0 configuration packages in customer namespace and adapt those.
  6. Switch repository types for your existing repositories from 7.2 types (created by upgrade procedure) to 8.0 types.
    In tab System Configuration of admin UI (https://<host>:<port>/idm/admin) the repositories can be switched from old repository type to a new one (the custom or standard 8.0 repository type).
    Before you can do this, you have to disable the current repository.
    The obsolete configuration will remain in a repository with the name <reponame>_OLD, which can be deleted immediately afterwards.
  7. Delete the 7.2 configuration package.
  8. Test the whole configuration.
  9. If a QA system is available, perform the upgrade on the QA system.
    1. Perform initial upgrade procedure (step 2).
    2. Import the standard configuration packages and perform initial configuration steps.
    3. Transport the custom configuration packages from the dev to QA system.
    4. Switch repository types and cleanup 7.2 data like described in steps 7 and 8
  10. Test the solution on QA system.
  11. Perform upgrade on production system, by following the same steps as on QA system.

 

Steps 7 and 8 are basically your go-live on the production system. As the new forms will be imported into the system and the repositories will be switched from 7.2 types to 8.0 types, the system is completely running on 8.0 configuration.

 

Due to the manual effort in step 6 – where all the custom configuration has to be re-implemented and the necessity for very detailed testing, the costs for a complete upgrade are often at least 50% of the initial project efforts.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply