SM9 is arguably one application that it is challenging to obtain good information on the internal workings of the application. There isn’t much information in the public domain, no end point mappings or API sets for other applications to connect and from
my research close to nothing on making a FIM connection. I recently had to setup a FIM connection to SM9 and I will share my experience with you, hopefully this wiki article will be a starting point and if you have more information, update the wiki article.
While there is limited SM9 technical documentation, I have interacted with SM9 administrators and studied the SM9 database infrastructure and I was able to get a high level understanding of how the system works.
It is a non-relational database. So you have a set of tables unconnected by design but logically connected. What I mean is that they are connected in the code since there are queries that join different tables. Let’s take for example, the
office address of a user, there is a user info table which you would think contains the office address of the user, but when you go to the GUI interface, the address is pulled from another table in the query that shows it on the screen.
There is what I would describe as the closest to a central user table called the contacts table name is “Contctsm1”. It has users’ information name, employeeID, department etc. Many queries reference this table for many user attributes. A key identity field
in the Contctsm1 table of the SM9 application is the Operator_ID. It would be nice if this Operator_ID was the identifying attribute in ALL SM9 tables but it is not as we will discuss later. It would also be nice if the Operator_ID is the same as the accountname
or Active directory logon-id, this would make system connection to AD easier in the future. The company though should have a “well-formed” identity program in place and must have set this up when SM9 was deployed. You may find the Operator_ID is very different
from the Windows ID.
It has many component parts, asset management, Helpdesk ticketing etc. And the fact that it is not a relational design means a change at some point can break another.
The Identifying attribute for a user or key for many of the tables and the whole system is the name fields. Yes, the last name and first name. And so when you have 50 Tom Smiths it becomes a challenge, especially when FIM or other systems are using employeeID
as the identifier.
When a new user is created in SM9, there is a provisioning program, of course aware of the different rules in the system, which creates the new user in the different tables. It is not like say provisioning in AD or a conventional directory system when provisioning
is done in one system location. Like I said at the beginning it is non-relational so you have a semi-independent tables. This makes setting up FIM to do new user provisioning a challenge.