Skip to Content

SAP IDM 8.0 Dispatcher Tuning

Hi IDM Gurus,

We are using SAP IDM 8.0 to provision users to SAP Gateway application which needs users to be provisioned asap. Right now, during testing, it takes up anywhere between 20 to 40 seconds before the user is created in SAP backend. But that is considered a significant delay. Can I reduce this time to 10 to 25 seconds max?

I have only one dispatcher setup at the moment. I can set up more dispatchers but concerned about database deadlocks like in 7.2 world. If you have more than one dispatcher in your environment, how is your experience in terms of performance and any unforeseen issues?

Also, from previous experience, if IDM has to create multiple users, it will collate all the information and provision all users at once which may take even several minutes to provision. I have other asynchronous tasks that depend on users to be available in SAP system which might fail. How to avoid this situation? I want one task to be executed per user

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Best Answer
    May 06 at 08:36 AM

    Hi Jaya,

    As per my experience, two dispatchers should be fine, one dspatcher should be used for only provisioning jobs and another dispatcher should be used for housekeeping and non provisioning jobs (on demand/schedule).

    For faster execution of jobs, set the value as 10 for Max Concurrent RT Engines & Max Loops For RT Engines. I think this should be working, if not need to make changes to the custom parameters available under the Dispatcher->General ->Advanced section

    I am not sure, that it is possible to execute the connector tasks individually for each user

    May be you can try to set Privilege Grouping Policy (MX_PRIV_GROUPING_RULE) to -1 or other values available under the repository constants.



    Add comment
    10|10000 characters needed characters exceeded

    • I've seen some deadlooking here and there since moving to MS SQL some years ago, but not extensive (and for the most part resolved with the second try).

      And it helps to have 2 running in case one decides to take a break. ^^ That has happened twice since upgrading to 8.0 last November. So I take the occasional lockup in exchange for some dispatcher redundancy.