8.0 Upgrade Approach – Best Practices

[normann]

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.

[former_member256680]

Very good Blog Norman !!

[brandonbollin]

Very helpful. As an IDM consultant, I haven't had to do an upgrade from 7.2 to 8.0 yet but I know my day will come. I do have one question though.

In step 5.3 - You point out that post executing processes do not carry over. This is something I'm struggling with in a current project I'm in. We're installing IDM 8.0 fresh but I'm used to 7.2, wherein you can have a UI task and, once submitted, action tasks inside it that then handle further processing. Now, forms are separate from processes and I haven't been able to figure out how a process can kick off as a result of a form being submitted *AND* maintain the context.

For example, we created a UI form that creates a new MX_PERSON entry. We do not want the user to have the ability to set the MSKEYVALUE so upon submit, we let IDM set a default value, i.e. MX_12345. After that record is created, we want to use a script with uIS_SetValue to assign the MSKEYVALUE based on some rules. In v7.2, we'd simply have action tasks nested inside our UI task and do the job. Now, we cannot do that.

We tried placing our process in the Result Handling tab for On Submit or On OK status and the process indeed kicks off but inside the script in the process that's been called, if we try to refer to attribute values from that new MX_PERSON record, they aren't there, i.e. var firstName = Par.get("MX_FIRSTNAME") or %MX_FIRSTNAME% in the destination tab. They just return empty strings and not the value of MX_FIRSTNAME from the newly created MX_PERSON record.

The workaround we did was to create an MX_PERSON Master Task and placed that on the Add entry process inside the entry type configuration and an entry script to check if the new MX_PERSON task was created via UI or via HR system input. If created by UI, we assign MSKEYVALUE, otherwise uSkip. Still, I really don't like this approach.

How can we have processes kick off and maintain context as a result of a form submit?

[normann]

Hi Brandon,

generally you should use the setting "Execute Process on Submit" in tab "Result Handling" of the form definition for that. That should be exactly the same as having the process linked after the form in 7.2 and for my customers it works well. This is also where the process would end up when upgrading existing 7.2 configuration.



Did you try that?

Regards

Norman

[brandonbollin]

That is in fact exactly what I was doing but it wasn't working. In the process that we linked there, we had an entry script that went something like this:

var idStore = uGetIDStore();
var mskey = Par.get("MSKEY");
var fName = Par.get("MX_FIRSTNAME");
var lName = Par.get("MX_LASTNAME");
var result = "";
var isResult = "";

We then assign first initial and all of the last name to the result variable, or first two initials, or more if necessary, if that was already taken and then try to assign that to MSKEYVALUE.

isResult = uIS_SetValue(mskey, idStore, "MSKEYVALUE", result);

This would error as all the Par.get variables were blank strings. I discovered this when I slotted in some uWarning messages to see what my variable values were.

uWarning("Value of fName: '" + fName + "'");
uWarning("Value of lName: '" + lName + "'");

In the log file, I'd see my leading string, "Value of..." but nothing inside the single quotes. What could I have been doing wrong?

[former_member453487]

Good article 🙂