IBM Verify

Ali Malik Gürbüz IBM Champion posted Thu February 20, 2025 01:12 AM

Hello, 

There are mutiple problems I can see, let me try to explain them. 

1.RMI Dispatcher : With 7.2 windows installation, there is a separate service after installation. However even that instalation tries to use the same default ports, so if your Default serveer ( win32_service folder ) was installed as a service, it cannot install when it's running. If you install when it's stopped, it still assigns the same ports, so they can't start at the same time. We found a solution and using it for years, just change ports inside one folder's files. Either win32_service or timsol, solution.properties, activemq.xml and derby properties. You have to change all 1099 to 2099 for example, change derby 1527->2527 or something and change this port references again in solution properties. With this, you can have 2 services, working side by side. You have to edit total 3 files. 

https://www.ibm.com/support/pages/system/files/inline-files/ReleaseNotes-Dispatcher10-10.0.2_0.html according to this, latest dispatcher does not support windows. So your installation may not even come close to the above. 

2. You can open SDI configuration Editor and ran it there. If you designed a brokerage HR , I advise against it. It has many issues. 

3. Well there is nothing set in stone or readily available. If you are familiar with SDI take usual precauitons, (error hooks, system.skipEntry etc) 

Regards, 

Ilona Truba posted Thu February 20, 2025 01:46 AM

Thank you so much! Could you tell me what the issues with the brokerage HR would be, or where i could read about said issues?

Ali Malik Gürbüz IBM Champion posted Thu February 20, 2025 02:04 AM

Hello, 

First of all ; Brokerage is a actually ISIM "account" adapters adapted to governance. When you design a HR in brokerage, it still behaves as an account reconciliation. 

Simply put, if someone is missing at the source, it deletes the person.  If your HR source is a database, imagine if you remove one person's row -> this will trigger Remove User in governance. This may happen as a mistake or a service error if you work with a webservice etc. You may not like this behaviour.

Second: Caching is sometimes troublesome and you may need to reset&sync time to time. This may re-trigger your rules in an unwanted way. 

These are the biggest two concerns that come to my mind. 

Ilona Truba posted Thu February 20, 2025 02:09 AM

Yeah, that does sound troublesome! Thank you, for letting me know :)

Franz Wolfhagen posted Thu February 20, 2025 02:15 AM

The answers from Ali are good - but perhaps not addressing you problem. The port handling when installing multiple SDI instances/version of the same machine is essential alas not very well documented. But I think your problem is more related to doing the install in console mode and maybe not having the correct administrator userrights. That said - you are entitled to have IBM Support helping you (I assume) so if you cannot find out what goes wrong raise a support case.

I can only concur that developing a HR Custom Adapter is not the way forward - if an ootb HR Adapter cannot do the work the best option is to do a full SDI based HRFeed. There are many reasons this is in most cases a better option - from an architectural PoV you want to decouple the Authoritative Source from IGI and ensure that in case of e.g. network problems the system does not start doing unplanned things like deleting identities in your IGI...

In general I would advice against doing this kind of work yourself unless you really need to do many SDI based adapters - use IBM Expert Labs or a business partner for this kind of works as they have experience and knowledge in how to do this...

HTH

Ilona Truba posted Thu February 20, 2025 02:53 AM

The administrator rights shouldn't be the problem but i will check if I'm having more luck with the GUI mode. If I'm still having trouble, I’ll contact IBM Support, thanks for the nudge!

Thanks also for the insight on the adapter vs. feed. I’ll definitely consider changing tactic.

Thanks for the support :)

Mita Mitic posted Thu February 20, 2025 05:23 AM

About SDI and  RMI dispatcher:

It is notorious how IBM neglect documentation for the last, hm, five or six years already.

Anyway,

When you are installing SDI for use with ISIM/ISVG, during installation there is a box that you need not to tick, that asks if you need TDI to run as a service. No, you do not need, since you are going to install RMI dispatcher later, which is actually - TDI service (with prettier name).

If you have installed with TDI service - not a big problem. Actually, you may register many TDI services with one SDI installation, if needed.

As others already mentioned, you need to assure that there is no port conflicts between services (RMI Dispatcher is a service, TDI server that may be created during installation is a service, you may want to create more services...)

Every TDI service has its folder, usually under installation folder of SDI itself, and in there is a file called solution.properties, ant ports are in there. I usually move ports 1099, 1098 to other, for other than RMI dispatcher service, and leave this one with defaults.

Mote:

There is another solution.properties file, in SDI installation folder, where you may also want to move ports, since it is used for Configuration Editor GUI, and server that will be started when you run the GUI.  If it overlaps with some ports of running services (e.g. RMI dispatcher) the server inside GUI will not start.

If you have installed RMI dispatcher, and there is no Windows service, you may want to try adding it manually: Fix ports in other solution properties files, restart other service if you need, and then go with cmd line into folder where RMI dispather has been installed (usually timsol folder, under SDI installation folder), and execute: ibmdiservice.exe -i

This should create windows service.

More at: 

https://www.ibm.com/docs/en/svdi/7.2.0.3?topic=service-installing

Hope this helps,

Mita

Franz Wolfhagen posted Thu February 20, 2025 06:51 AM

Damn - it looks like threading has - again - been removed from this forum....

I am trying the enhance Mita's very good answer a little bit : 

You can install as many SDIs (same or different versions) on the same machine. This is important to separate things that are relying on a single JVM - e.g. if you hav multiple ISVA aka ISAM/ITAM/TAM instances you manage with the ootb adapter they depend on JVM runtime that cannot handle multiple instances - so you would need 2 separate SDI instances.

Also due to the way the SDI class loader (IDILoader - it is documented in the JAVADOC and useful for e.g. finding out where a class is loaded from)  works you may end up in class conflicts that cannot be resolved - so also there multiple SDI installations are the solution.

I normally recommend one SDI per Dispatcher in normal environments - if you for some performance reasons need many instances you COULD have multiple Dispatches that are used for the same adapters and handled by some load balancer - but that will not by you fail over - you will have to have multiple servers for that. 

HTH - and keep the discussion going :-) 

Jason Williams posted Fri February 21, 2025 09:35 AM

All information from Ali and Franz. 

I wanted to share an alternative approach for situations where multiple components rely on a single running JVM, rather than setting up multiple SDI/Dispatcher installations on the same system. If you need to manage separate instances or conflicting JAR files, you could use the Dispatcher Container image (`icr.io/isvdi/verify-directory-integrator-dispatcher:latest`). This allows you to keep JARs isolated within different container images. You can find more details about the V10 Dispatcher Container in this guide: [Dispatcher V10 Documentation](https://www.ibm.com/support/pages/system/files/inline-files/dispatcher10_book_0.pdf).