cancel
Showing results for 
Search instead for 
Did you mean: 

IDM Initial Load from HCM very slow

GH00
Explorer
0 Kudos

Hi Experts,

We are loading users from HCM into IDM 8.0 sp6 via VDS. The process is taking a very long time. We have 7500+ users and 400+ business roles. The business roles were all created before the HCM load started.

We have a pass that matches users to business roles during the HCM Staging job so users will be provisioned to each of the 10 ABAP systems with their required access.

My question is... why is it taking so long? During the HCM load - which took about 4 days - we were provisioning users at a rate of about 1 user to 1 system every 5-10 minutes (we expect we have 58,000 of such provisions to make). We thought it would speed up when the HCM load was finished and all 4 dispatchers could be used to provision to the ABAP systems.

It did speed up a bit - we are now getting one user to all systems every 5 minutes but we have done less than 2000 users in 10 days.

When we look at the Job Log it shows the 'Time Used' to be typically small - 5s for the majority of them - but the time between jobs is in minutes. And we noticed that when the same user has multiple privileges on the same system this can make a difference (241 seconds to provision 4 privileges for example).

One other things that I think is a side effect, is that we cannot use the Web UI to display any users. We get a 500 error whenever we select an ID to display.

I should point out that I have played a lot with the dispatchers and jobs. Based on some OSS Notes I found I set one of the dispatchers to handle housekeeping etc and excluded it from running any jobs. The other dispatchers I set to run only select jobs - no job would be set to multiple dispatchers. That didn't seem to have any impact over this past weekend so now 3 dispatchers are running all jobs and one is handling housekeeping etc.

We have all components on the same system. We are running with an ASE database. DBAs say that the DB is running fine.

Any suggestions would be welcome.

richard_pietsch
Active Contributor

Hi there,

I would like to share some of my experiences with the performance topic... We had similar problems during the last IDM GoLive. We had to transfer around 12.000 personnel numbers from HCM to IDM, process them according to the defined rules, distribute the information across the SAP backends (40 repositories) and maintain the info type back in HCM.
The first run was cancelled after we observed severe performance issues. The LDAP transfer itself was not a big problem; it finished after 40min. But the IDM processing took so much time, around 45sec per personnel number. We had a time window of max. 4 hours..

What we did for optimization:
- optimized DB settings, parameter changes, increased processes, scheduled creation of table and index statistics
- setup one IDM dispatcher handling the HCM processing, another one for the provisioning to the backends
- limit the logging on each process step and on dispatcher level; it was set to "Info" which creates lots of logs we do not need, so we increased it to show warnings only - therefore we also cross-checked the custom scripts for uInfo/uWarning functions
- the "max concurrent rt engines" and "max loops for rt engines" parameters for dispatcher also affected our overall performance as IDM created lots of java processes that nearly "killed" the system (and database). On IDM side there were so many procsses consuming CPU & memory so the server was fully exhausted; on the other side the DB could not handle the requests anymore. We now found a good value for concurrent engines (together with the DB processes).
- We also reviewed the attributes assigned to the SYSTEM-privilege, per default lots of unneccessary attributes were assigned with the result that IDM triggers lots of provisioning tasks that were not helpful; the number of attributes were decreased to 15 I guess..
- did some changes in the IDM process logic that handles the personnel numbers (validation, writing to SAP master, post processing,...).


Doing so, we could optimize the avg runtime to 2-5sec per personnel number.

However, the best way we could handle the data was changing the HCM process. We make use of the delta function in RPLDAP_EXTRACT_IDM. Via implementation HR_LDAP_EXTRACT_PA relevant personnel numbers are marked for transfer to IDM via table HRLDAP_PERNR as soon as the HR department does some changes. We have another small Z* report running in HCM that also checks for relevant personnel numbers. All of them are stored in table HRLDAP_PERNR. Each hour the delta extraction to IDM is running; so we have max. 10-20 personnel numbers in each run to process which has no performance impact at all. Also, the changes and user information are available within a short period of time.

Regards, Richard

Accepted Solutions (0)

Answers (4)

Answers (4)

superberater
Newcomer
0 Kudos

Hi Graham, can you give me more details for performance settings? we have the same problem.

thanks in advance

GH00
Explorer
0 Kudos

We have managed to get our load down from over 3min per record to under 12s per record.

That's 8s to provision 10 ABAP systems and 3s to provision AD.

Most of this was a result of changes made by the DBAs. We are using ASE DB and we found that we have an 8 core system but only 1 core was being used by our dispatchers. The others were handling other tasks. Once we switched to the 8 cores you can imagine the increase we got. That got us under 30s total which we could live with, but the Basis and DBA teams did quite a lot of work with us as we did test loads and, like I say, managed to get it down to under 12s. If anyone is interested in the details I can see if I can post them.

gowri_rabendran
Explorer
0 Kudos

Hi Richard,

Are you able to provide further details on your changes you made as I am experiencing similar situation, though mine is taking around 10-12 seconds per record. Which I believe is still very slow for an IDM system.

ivan_petrov
Active Participant
0 Kudos

Hi Graham,

It look like your problem is not related to HCM transfer, or at least not only to it. You are trying to look at a lot of processes at once and I think this isn't the right approach to solve the case. You should start tackle the issues bit by bit.

So my advise is a s follows:

Start with HCM transfer only - which means that you should stop all other processes, assignments or what so ever. Just create some users from HCM to Main ID Store with no any other extras and check the time.

if you have problem here, that means that you have maybe network issues, or the problem is in the DB. But do not continue with the next step without solving issues on this one.

Next step - if you solved all issues from the first step now try to do assignments of the users only in one ABAP system and check the speed again. If you have issues - again it can be either a network problem, ABAP system can be overloaded, it might be DB issue or it can be IDM configuration issue (i.e. check the grouping setup of access provisioning). Again don't go for the next step before you solved all issues here.

Next step - provision to multiple ABAP systems - if all the issues on previous step has been fixed, the most probably here we are talking for IDM configuration issue. Either in the dispatchers, or in the IDM it self. You should have in mind that IDM standard configuration does the provisioning to the same type of backend systems in queue and not in parallel. This means that IDM is trying to execute all the tasks for one system, before it goes for another. May be this is one of the reasons why it works so slow for you. Of course there is a way to make these processes to work in parallel, but it is a bit tricky and in some cases it might lead to unpredicted results, so it should be done with care.

Also last but not least if you don't have a lot of experience, don't play with dispatchers too much, because the results might be even worse than the current.

Regards,

Ivan