Share This:

Introduction

I was fortunate today to have a great conversation with a customer about Data Management where they wanted to have better synchronization of their Microsoft Active Directory user and group information with their Remedy implementation.  Because they have some entries/people that turn over and change at a more rapid pace, automating some of this is highly desirable. 

 

To support this endeavor, I discussed some options they have using AI and Data Management.  They are on Remedy 7.6.04, so full-fledged DM is not available and would require some differences from what I'm going to cover here, notably that DM in Remedy 8 would use the staging form instead of targeting the operational form (e.g. CTM:LoadPeople vs. CTM:People, respectively.)

 

My previous blog entry also discussed some topics related to digital certificates.  When using the transformation we are going to discuss here, I will presume that a proper Java keystore for trusting a secured LDAP communication with the Microsoft Active Directory server is already available and installed on the server.

 

Transformation

Remedy 8 ships an two out-of-the-box transformations called LDAP_People and Secure_LDAP_People.  The former is the "easy" LDAP integration that is configued to operate over an unencrypted (aka "plain") LDAP connection.  Most LDAP-enabled directory servers are not operating over unencrypted LDAP (thankfully!) because of the general sensitivity of the information those systems contain.  User names, hashed passwords, group information that may control application entitlements, application attribute data, etc. are all considered PII (personally identifiable information) and should be encrypted, so, secure LDAP (LDAPS) it is.  That means we need to use our Secure_LDAP_People transformation in most cases.

 

The secure and plain versions of the transformations are nearly identical, and with the difference in connectivity aside, require the same information for creating users in Remedy (some required, some optional), so let's see a few key fields:

 

Form Field NameStream Field NameRequired?
CompanycompanyN
ManagerLoginIDManagerLoginN
Local MobilemobileN
Alternate IDobjectGUIDN
Remedy Login IDsAMAccountNameN
Sitel (locality)Y
Last NamesnY
First NamegivenNameY
Corporate E-MailmailN
Local Business FaxfacsimileTelephoneNumberN
Local BusinesstelephoneNumberN






 

There are others (several operational) and many more available on the form, but these are several that are either required or generally found in a directory of people records. 

 

Most of these (the middle column) are very common in directories, but there is one that may not be commonly in place with your directory:  Site=locality.  The value required on the Site field on the CTM:People form is the exact name of a valid Site/Location that you have present in your AR server.  The l(locality) attribute in a directory frequently maps to a city name.  Unless your Remedy SITES are city names, this will require an adjustment. 

 

There are several ways to address this:

  1. Make the LOCALITY attribute in the directory on each user's record hold the expected value for AR,
  2. Make another directory attribute on each user's record hold the expected value for AR and update the transformation to use it,
  3. Modify the transformation (or make a new one entirely) that retrieves the Site data and adds it to the transformation data stream from the directory and populates the form values,
  4. Make sure that Sites/Locations are named after cities, and that you don't expect two sites in the same city.

 

The first of these, making the L attribute hold the expected value is the easiest for the person configuring DM, but not always viable.  Most directory administrators will have that field reserved for other usages, and that's unlikely to change.

 

The fourth one (making Sites/Locations in AR match the city names on people's records) may be similarly untenable, particularly if your Locations have something beyond a city name , such as a building number.

 

The third option, retrieving information from another source system, is a topic I will cover a bit in an upcoming posting. 

 

The second option, retrieving information from another attribute on the user's record and using it instead, is what we'll cover here.

 

Modification

Changing the transformation to get data from another attribute is a rather straightforward exercise. 

 

First, you need to ensure that the correct value is present on the user's record.  For that, you may need to talk to the directory team, or the user provisioning group, etc. about how to get the correct values on the right records.  That process is a bit beyond the scope of this posting, so I will assume that is done and that the information we need is actually on the user's record, but in the attribute physicalDeliveryOfficeName.  This attribute name may be a bit more applicable to our usage, and it is frequently unused in directories, so your directory administrator may delegate it to this usage rather easily. 

 

Next, we need to start modifying the transformation.  This requires the BMC Atrium Integrator Spoon client.  It installs on Windows systems with the AR Suite Developer's Kit.  Check the BMC Support site and EPD for specifics on it.  Keep this client handy if you are going to make changes to transformations.

 

After starting Spoon and connecting to your server, you need to load the transformation (File > Open, locate and select Secure_LDAP_People TRANSFORMATION) and click OK.  You should see something like this when you have it open.  If you see only 2 steps, verify you opened the TRANSFORMATION and not the JOB. 

 

Picture1.png

There are 4 steps in this transformation.  From left to right, they

  1. Look up the user record and retrieve attribute data,
  2. Use the value of the MANAGER field from the first step to look up the login id for the user's manager from their LDAP record,
  3. Gather some DM job-specific variables,
  4. Map the stream data to the AR staging table form and load it to the staging table.

 

When this completes, the LOAD stage of a DM job is finished and the job would advance to the Validate and Promote steps (in Remedy 8).  If using AI directly (e.g. 7.6.04), the job would write directly to the operational table.

 

To retrieve the data from the user record's new attribute, we need to edit the first step (DMT_LDAP_INPUT) to retrieve the additional attribute, either in lieu of or addition to the locality attribute.  By double-clicking or right-clicking and selecting Edit Step on the first step of the transformation, we can make the change.

 

The step edit screen for this is shown.  The variables that will be populated by running the job from DM/AI use the syntax ${Variable_Name}

 

pic2.png

The Fields tab is where we will modify the list of attributes to retrieve and insert into our transformation data stream.

 

pic3.png

This shows the list of attributes to be pulled from the directory (whether or not we use them later in the transaction.)  Moving to the bottom of the list will allow you to add a new row.  In this screenshot, a new data stream attribute (first column) called physicalDeliveryOfficeName will be populated with value found in the attribute from the second column, physicalDeliveryOfficeName .  The data expected will be treated as a String for retrieval and usage.  After adding the new attribute, save the change to return to the transformation canvas.

 

Next, we want to use the new attribute.  Open the AROutput step for editing.  You can see on the General tab that this will send data to the CTM:LoadPeople form.

 

pic4.png

Click Field Mapping  to show the AR fields to data stream. 

 

Find the Form Field entry for Site and note that the Stream Field is currently l (locality).

 

pic5.png

 

Click on the value of the Stream Field to reveal the list of stream field attributes available to this step of the transformation.

 

pic6.png

 

Scroll down and select the new physicalDeliveryOfficeName.

 

pic7.png

Click OK to save the new change and then save the transformation.

 

pic8.png

In this example, we modified the OOTB transformation.  Generally, you should copy the transformation to a new one and modify that one instead.  The new one would not need to be linked to an AI and DM template so DMT:Admin and DMT:User privilged users could run it.  You would either neeed to modify the AI JOB that calls the OOTB transformation, or create a new AI template and DM template to use the new transformation.  In our example here, you could just run the OOTB template to take advantage of the changes you made.  Those changes may be overwritten in a later patch by BMC, so always be cautious when modifying BMC provided objects that are not overlay capable (transformations are not yet overlay enabled.)

 

As for creating a new AI template and DM template from scratch, let's save that process for another time.