Share via

FIM 2010 R2: Using FIM to Synchronize User Data with HP Service Manager 9 (SM9)

  • Article

Introduction

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.

SM9 Overview

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.

Sync data with SM9

Sync with the Contctsm1 table. Sync the following attributes

CONTACT_PHONE

EMAIL

USER_ID

DEPT

TITLE

MANAGER

 

  1. Do not sync first name, last name, it can potentially break the SM9 system. We have discussed the importance of first name, last name.
  2. Use the FIM database management agent to make the connection. You can use the Oracle DB MA or the SQL DB MA, most likely the SM9 backend will be the Oracle DB.
  3. If any custom attributes are created to sync data make sure that HP SM9 SME is engaged so that the appropriate store procedures are updated.