Determining the Leading System Attributes

[ken_halvorsen2]

Hi All

We are just installing Identity Management 7.2 and I'm preparing for the intitial load of one of our 9 ABAP systems, but I'm having difficulty with the term Leading System and it's meaning.

Section 3.4.5.1 - Determining the Leading System for Attributes notes that this step is very important and if we don't specify the leading system per attribute correctly attributes could be over written from other systems, leading to unexpected results.

I'm definately unclear with this concept. For example we plan on connecting IdM to 9 different systems (3 - Dev, 3 QA & 3 Prod), each having different User master data and privileges.

Is this section asking me to determine which of these 9 systems is going to be the Leading System, meaning all of the other 8 systems might have their User data overwritten by this systems, or is it asking for of the 9 systems, which is the Leading system, the Source or the IdM system?

Ken

[Former Member]

Hi,

it's a simple concept really. The leading system is the system where the data (=users and their attributes) is coming from. Most likely, none of your ABAP systems will be the leading system.

Sometimes there is a HR system or AD system where you get the data. Then that system becomes the leading system. If this is not the case, then IDM normally becomes the leading system. You maintain your data in IDM and let IDM distribute the data to the connected ABAP systems.

The point of IDM is to have the data synchronized. This works best if all your users have the same login name on all systems. If not, then this becomes very hard. Their SAP roles (=IDM privileges) can and most probably will be different but not attributes like last name or email address..

[ken_halvorsen2]

Thanks Sietze

This helps make thing clearer. At the moment we're using a CUA system, but anticipate moving over to IdM to manager the other Systems User authorizations centrally.

Yes the User's have the same Login ID's, but have different authorizations in each of the systems. For example BWD (Dev) -> BWT (Test) - BWP (Prod), CRD -> CRT -> CRP & R3D -> R3T -> R3P all have the same User ID to log in with, but each have different passwords and authorizations.

The Plan was to delete 1 system at a time from the existing CUA system and Add it to IdM. But as I read the instructions I got worried that After I did the Initial Load from BWD, I would not want the BWD authorizations over written by BWT's initial load by having the IdM as the leading System.

Are there any precautions I should look out for before trying to load the second systems data? (Although I haven't gotten the initial load finished yet. I'm having problems there.)

[Former Member]

The authorisations are not a problem - they aren't overwritten.  The data that will get changed is user info (the fist name will be the one from the most recently loaded system).

You can set a leading system on an attribute (in the properties iirc) and that data will be authoritative for that attribute.

For example:

First Name has HR as a leading system.  IDM will reject any update from another system unless HR doesn't have data.  If data is changed to something else in another system, IDM should overwrite it.

Leading systems can be set at an attribute level.  Do not get caught into thinking that the entire object must come from one system.  For example, email address will almost certainly have AD/Exchange as a leading system (if thats your email system).

Peter

[Former Member]

Hello Ken,

the section you mention points towards writing your data model down.

The privileges are written like PRIV:ROLE:%$rep.$NAME%:<Name of the priv>. So there is no mix up possible.

Before the intial load takes place I would recommend to have a deeper look at the data model of

the "normal" attributes. Using an excel file in which you put all systems (IdM, SAP system 1, SAP system 2, ... SAP system 9) in the columns and all attributes names (firstname, lastname, phone) in the rows.

If you fear to overwrite data in one of the systems you could also use more than one attribute for each attribute. Meaning this: In addition to the standard MX_PHONE_PRIMARY you could use something like ISV_PHONE_%$rep.$NAME%. Using the multivalue additional attributes would also be possible, but you would have to use something like a "repository prefix" for each value to determine the correct value.

So if a phone number in system B shall not be overwritten by system A you now have two phone attributes. Or three, four, ...

Yet, this leeds to some scripting and adapting of the provisioning (some hints: one task per repository, switch task needed, built your own provisioning folder, original taks should be copied not changed). But this is just normal in the SAP IdM.

I hope this helps a bit.

Best regards

Dominik

[ken_halvorsen2]

Thanks Dominik

Each of the Target systems will (and should) have the same User ID information (names, phone numbers etc.), and if not it would be ok to over write.

My concern was more that I don't want the individual systems authorizations over written.

For example we have 3 landscapes - BWD (Dev) -> BWT (Test) - BWP (Prod), CRD -> CRT -> CRP & R3D -> R3T -> R3P each system has the same User ID to log in with, but each have different passwords and authorizations.

I'm concerned that the different system authorizations would get over written during the Initial Loads from the subsequent systems.