| Subcribe via RSS

SailPoint IIQ: The BuildMap Rule Revisited

Well, I’m behind on posting again. Apologies to those following here who I know were looking forward to this particular post which I promised in person to a number of you.

Build Map Rules in Aggregations

The BuildMap Rule… Just what is a “build map rule” exactly? Maybe you’ve used or even written one, but you admit you still really don’t understand what it’s actually doing or how it really works in the case of account aggregations. I actually get that kind of comment all the time, so don’t feel bad. Let’s crack ‘er open and see if we can crystalize the concept of how this actually works. Once the concept is crystal clear, you’ll know exactly when to use it, and your usage of it will be that much more sophisticated and precise.

Hang On… What Is A Map, First Of All?!

Before we get into what a build map rule is, we first need to cover the concept of a “map” to begin. Again, this is a comment I often get as I am on site implementing Sailpoint IIQ for the first time in enterprises — “what is a map?”

Sailpoint IIQ is built using JEE technology. Therefore, it draws from many paradigms within that reference technology platform. A Map object in Java, or just a “map,” is essentially an indexed name/value pair system. Focusing on strings as the map implementation (it’s possible to have other map types in Java, but we’ll forgo that discussion here), a very stripped down version of a map is something like you might find in a configuration or initializer file of some sort:

name=Chris Olive
address=123 Somewhere St.
city=St. Paul
state=MN
zip=55102

This is also known as a key/value pairing because the name on the left hand side can only occur once. If you are familiar with other programming languages, a Java Map is roughly equivalent to what is called a hash in Perl and Ruby, a dictionary in the older Microsoft development parlances (VBScript, etc.), or a dictionary in Javascript (though popularization of Javascript and it’s object orient model extends this scheme into JSON objects, which again we will forgo delving into in depth in this discussion.)

Here are the equivalent “maps” in some of the languages I’ve mentioned above. If you are familiar with all or any of these, then you know what a Java Map (object) is:

Perl:

my $map = {
   name    => 'Chris Olive',
   address => '123 Somewhere St.',
   city    => 'St. Paul',
   state   => 'MN',
   zip     => '55102'
};

Ruby:

map = {
   :name    => 'Chris Olive', \
   :address => '123 Somewhere St.', \
   :city    => 'St. Paul', \
   :state   => 'MN', \
   :zip     => '55102' \
}

Javascript/JSON:

map = {
   "name"    : "Chris Olive",
   "address" : "123 Somewhere St.",
   "city"    : "St. Paul",
   "state"   : "MN",
   "zip"     : "55102"
};

Java (BeanShell):

// Unfortunately, Java doesn't offer a shortcut way of initializing
// a HashMap. I'll just not comment on that here. :-)
//
// Since Java 5, real Java wants these sorts of things "typed" as
// well.  We'll forgo that and do this BeanShell style as per IIQ.
// BeanShell doesn't require type syntax.

import java.utils.HashMap; // Not required in BeanShell
   :
   :
HashMap map = new HashMap();
map.add( "name", "Chris Olive" );
map.add( "address", "123 Somewhere St." );
map.add( "city", "St. Paul" );
map.add( "state", "MN" );
map.add( "zip", "55102" );

Now, that last example looks somewhat familiar if you’d done any writing (or plagiarizing :-)) of Sailpoint IIQ build map rules already. (Funny how in literary circles, plagiarism is very much frowned upon, whereas in IT, it’s very much encouraged, isn’t it?! :-))

So while we’re here, let me just say that the variable name “map” carries no special significance. People tend to name their variables in simple scenarios according to what they are and the variable name could just has easily been “foo” or “frank” — it’s doesn’t matter (other than when you program that way, things get a little unclear fairly quickly.)

So this would do just as well:

HashMap me = new HashMap();
me.add( "name", "Chris Olive" );
me.add( "address", "123 Somewhere St." );
me.add( "city", "St. Paul" );
me.add( "state", "MN" );
me.add( "zip", "55102" );

IIQ Uses Maps EVERYWHERE

So now that you (hopefully) know what a “map” is, then maybe at least the name has suddenly taken on more significance. “Build Map” means… a Java Map object instance (or just a map) is going to be built. “Why” will be explained in just a moment.

The main thing to emphasize here is… Sailpoint IIQ uses maps literally EVERYWHERE. So just get used to it. And that being said, I can’t think of a concept in Sailpoint IIQ that you need to make sure is rock solid any more than the concept of a map. Again, Sailpoint IIQ uses them literally EVERYWHERE.
More »

Tags: , , , , , ,

SailPoint IIQ: Get Your JavaDocs

November 1st, 2012 | No Comments | Posted in IAM Development, Object-Oriented Development

Interestingly, I was on a call this morning with a lot of really smart people, and I was surprised to learn some of them didn’t know that Java documentation on all the internal Sailpoint IIQ Java objects comes bundled with every install of IIQ. All ya gotta do is set a bookmark to a static URL after a Sailpoint IIQ install, and you are good to go.

This means, if you have multiple IIQ versions installed (as I do), then you can get the JavaDocs specific to each one of them with a URL for each version. They are all located at the same URL for each install:

http://your-hostname-here:8080/identityiq/doc/javadoc

If you just happen to have Sailpoint IIQ installed on the same machine you are reading this post on, click here and you should see them. Otherwise, adjust the URL above accordingly if you are reverse proxying your Sailpoint IIQ install or used a different context root for IIQ or what have you.

If you are doing any customization at all of your Sailpoint IIQ installation — be it in Java itself or in BeanShell — this URL will be indispensable for you. Set ‘er up and have fun reading JavaDocs to your children at bed time!

Tags: , , , , ,