IdM Thoughtplace: Doing a LINUX Based Victory Lap

OK, I admit it, when I solve a particularly confounding problem, I like to get up, proclaim “Victory Lap!” and walk around in a small circle (Sometimes two for bigger problems). I think it's important to celebrate development successes particularly when they result in helping to really move progress ahead. I’d like to share with you folks my latest cause for a Victory Lap.

My current project is requiring me to install Virtual Directory Server for HCM and GRC along with an IDM Dispatcher on a Red Hat LINUX server. Now I’ve dabbled with LINUX before and even run it as my personal Operating System once upon a time, but I think it’s safe to say that I was going to learn a bit during this process, and learn I did!

There are two important things to remember about LINUX that trip up someone coming from a DOS/Windows background:

Directories are separated by a forward slash ( / ) rather than the backslash ( \ ) Incidentally, after doing some research I found out that the proper name for these characters are the solidus and the reverse solidus respectively.
Directory names and files are CASE SENSITIVE, which leads to my first big lesson. It seems that the installers for IDM and VDS point to two different paths

IDM Default Path

IDM Default Install Path

Remember, even those two paths have the same basic content; they are different files since the case is different in each path. Personally I recommend using the VDS install path. I don’t know that I have any terribly well-defined reason except for the fact that the VDS configuration has more moving parts in relationship to the Operating System so it seems like it makes more sense not to rock that boat more than absolutely necessary.

For all of that it was an interesting find and one that I’m happy to share, but it was not quite worthy of taking the Victory Lap. The issues that followed on the other hand...

Along with VDS, I also installed a dispatcher for IDM. Pretty standard stuff, generate the dispatcher from the MMC Admin console, move the files over to the LINUX box via SCP, check permissions and then edit them to reflect the new environment. I made the required changes to the shell script and tested the configuration. This brings me to another interesting difference between a Windows implementation and a LINUX implementation:

In a Windows configuration the dispatcher is tested by using the command:

Dispatcher_Service_[Dispatcher Name].bat test checkconfig

however in LINUX all you need to enter is:

Dispatcher_Service_[Dispatcher Name].sh checkconfig

Again, not quite Victory Lap worthy, and regardless, the check came out just fine and the dispatcher fired off without a problem. However that’s when the problems began. While I was able to observe through the MMC console that IDM saw the dispatcher running on the LINUX box, it would not pick up any jobs that I tried to execute through it. Each and every one would eventually time out leaving me wondering why.

I examined all of the settings in the Dispatcher’s shell script and didn’t really find anything wrong; double checked the permissions and those seemed to be fine as well. Eventually I went to look at the Dispatcher’s PROP file. It seemed OK, but what did I know? After much consultation among my fellow IDM experts around the world, one thing stuck out as a piece of advice:

"Since prop file is on UNIX – EVERYTHING has to point to UNIX.”

So I took another look at the files and noticed an entry in the PROP file and saw this:

DSECLASSPATH=%DSE_HOME%/Java/DSE.jar:%DSE_HOME%/Java:%DSE_HOME%/Java/sapjco.jar:C:\\oracle\\product\\10.2.0\\client_1\\jdbc\\lib\\ojdbc14.jar

Hey, what’s with that %DSE_HOME% reference? That’s DOS not LINUX! Made a quick search and replace, %DSE_HOME% for /usr/sap/IdM/identitycenter and everything started working!

So, what were the lessons here?