Skip to Content

Testing Dispatchers

I like indicators.  Back in the day, I was a huge fan of External Modems (I think I just dated myself 😆 ) I liked hearing the “negotiation” sounds when a connection was being made and then seeing the little lights blink as data “flew” over the wire.

That preference has never changed.  Any time that I can see raw data, I prefer it  Fortunately IDM gives us the ability to see the engine at work through the Dispatcher Test mode which I’ve discussed before.

Dispatchers can always be placed into Test Mode even if they are set as services.  Just make sure that you Stop the service first.

test btn.png

Once you do this a Command Shell Window (or as we said way back when “DOS”) that looks something like this:

basic disp.png

Don’t worry that the display doesn’t change, that’s normal. It will change soon enough. The following screenshot shows what happens when a job is run:disp in action.png

So you can see that things are definitely happening now! To see more or less, adjust the Log level in the Dispatcher properties:

debug options.png

Enjoy testing your Dispatchers!

You must be Logged on to comment or reply to a post.
  • Hello Matt,

    nice blog once again! 🙂 I didn’t use the test mode so far, but it will definitly come in handy. ^^

    Is the logging you see in the DOS-window written into a file somewhere? Or can you just look at it during the runtime test? For error hunting I’d find it easier to sift through a text-file or something similar than to look at that block of information in the command window. It’s always looking a bit messy there.




    Back in the day, I was a huge fan of External Modems (I think I just dated myself 😆 ) I liked hearing the “negotiation” sounds when a connection was being made and then seeing the little lights blink as data “flew” over the wire.

    I myself never had a modem, since I grow up without a pc and when I got my first internet connection it was already DSL. But that sound you describe was and always will be for me the “science fiction”-sound. Because it always ment futuristic/modern to me. ^^ I would like it as a ring tone for my phone, when I think about it now…

    • Steffi, that’s an interesting question. I suppose one could modify the dispatcher batch file to pipe the output to a file, but I think that would cancel out the on screen display.  I’m going to have to check with others on this one.


      • Great, I’d appreciate it if you could look into that. When the window is cramped full of information it would definitly help to have it stored into a file somewhere so you could work with something like a search. 🙂

        Thank you!

        • Steffi,

          I checked with my sources and they did confirm that the easiest way in test mode is just to open that “DOS” prompt and enter dispatcher_service_<name>.bat file in the \usr\sap\IdM\Identity Center\Service-Scripts and start it using “test > overnighttest.log” as parameters.

          However if you’re using a more recent build of IDM, look in the Management Node of the MMC console and see if you have a Dispatcher log there.  You’ll also note that you can save that output to a file so if there’s a process you’d like to monitor / debug, clear the log, run the task or job and then save it to a file!

          • Thank you for looking into it, Matt! 🙂 That sounds like a good method to get the log I want.

            We’re on 7.2 SP7 since last week, so I have the dispatcher log, but see nothing in there yet. I have to look at the configuration to see what’s missing there. Found it! Log level was on “Error” for my housekeeping dispatcher. ^^

            And I forgot about the possibility to save logs. D’oh. Haven’t used that ever (after finding and testing it a year or so ago).

  • The melody of a connecting Modem is also burned in my brain 😉

    Although I cannot understand the “happening things on DOS screen” it’s also good to know how to display it.

    Thx Matt.

    • Nicolas,

      The output used to be a little more useful (you could see Job IDs and what not to know what was being fired)

      This has been changed for various reasons, I’ll be doing some more research to find out what we can do with this information in the future.


      • Hi Matt,

        I’m wondering if you could provide me with some advice. I have installed IdM on SQL Server with sqljdbc drivers and JRE 1.6 but everytime i go to test the dispatcher it just hang saying ‘Cleaning relevant semaphores’ and when I look in the dispatcher it showing errors with the following descriptions:

        Error reading global constant MX_MAX_CONCURRENT_RUNTIME_ENGINES. Using default = 9999

        Error reading global constant MX_GUI_URL_PREFIX. Using default = http://localhost:50000

        Error reading global constant MX_TRACE_ENTRY. Using Default =

        Error reading global constant MX_TRACE_RT. Using Default = false

        The log just keeps filling up the dispatcher log. I suppose i could delete the entries from disptacher_log table?

        I just want to know if the dispatcher is working or not? I expected a message to be displayed once it had been tested in the cmd prompt.

        Many thanks, Matt

        • Hi Matt!

          The dispatcher should be running.

          You can easily address those messages by creating those global constants in the MMC.  Let me know if you have any questions.



  • Hi Matt,

    I’m having a problem when i test my dispatcher, below error is showing up.

    Exception on thread:IDS_DispThread-CFG_RELOAD-de

    fault_disp_1:Dispatcher configuration default_disp_1 already in use! Check the S

    ESSIONID field!

    java.lang.Exception: Dispatcher configuration default_disp_1 already in use! Che

    ck the SESSIONID field!






    [25.11.2014 14:19:07-317] – 1 – Thread:IDS_DispThread-CFG_RELOAD-default_disp_1

    – non-restartable thread has died -> exiting …

    Thread:IDS_DispThread-CFG_RELOAD-default_disp_1 – non-restartable thread has die

    d -> exiting …

    Is this normal?


    • Hi Ian,

      I haven’t seen this one before.  But here’s where I would look to troubleshoot:

      1. Stop all dispatchers (I’m assuming there are no working ones)

      2. Go to the service scripts folder, move / delete all dispatcher related files (.bat, .sh, .prop)

      3. Check your Java settings and classpath.

      4. Make sure that your database, runtime, and designtime components all are at the same version and service pack. Uninstall/reinstall or update the database as needed.

      5. Create a new dispatcher

      6. Run in test mode.

      Hopefully this will fix it, if not, you’ll need to open a support ticket.

      As an extreme option you could also uninstall/install the database, but I’d only do this for a SBX/DEV environment where you have not done too much yet.


    • Most likely it means that the dispatcher is already running, perhaps as a service or on another host. Stop the dispatcher service before running the dispatcher in testmode.