| Subcribe via RSS

SailPoint IIQ: Rule Modeling in Real Java :-)

I’ve been sitting on this article and concept for months and have had others ask me about it via email — whether I’ve ever done something like this before — and well… here it is.

Tired of No BeanShell Coding Validation!

It turns out I was sitting around in my hotel room in Bangalore on India Independence Day last year, whacking away on some client code, doing some data modeling using CSV. I had a somewhat involved BuildMap rule I was working on and I was getting a null pointer exception I simply could not find. A few hours and one simple coding mistake later, once discovered, I was finally on my way. But it was really discouraging to know that if I had been coding in Eclipse, the coding mistake would have been spotted immediately.

The next thought I had was actually two-fold. While I have at times actually written test straps in real Java using the Sailpoint IIQ Java libraries (ie. jars) and dropped my BeanShell code into procedures to instantly validate the syntax, I have also wanted at some point in time to be able to simulate or partially simulate rule modeling and data modeling outside of Sailpoint IIQ using Java I had complete control over writing and executing.

So on this particular day, being particularly irked, I decided to combine those two wishes and see what I could do about having a place I could not only drop, for instance, BuildMap rule code into Eclipse and instantly validate it, but also execute the code I intended for Sailpoint IIQ against connector sources I also had connected to Sailpoint IIQ (in development, of course!) and see and manipulate the results.

Once I was done iterating my development over a real dataset, I could take my validated Java code, drop it back into Sailpoint IIQ in BeanShell and have not only validated but also working code in Sailpoint IIQ with very little or no modification.

Establishing SailPoint Context

One thing you will need if you want to run your Java code in an actual Sailpoint IIQ context outside of Sailpoint IIQ proper is establishing SailPointContext in your code. This, I will tell you, while not impossible, is not easy to do. You need to implement the Spring Framework and a lot of other stuff. If you are interested in doing this and have access to SailPoint Compass, you can actually read about establishing SailPointContext here4.

Since doing that much work wasn’t something I had the time for doing, almost immediately I decided to implement a partial simulation that would allow me to (1) model and validate my rule and (2) also allow me to model my data very simply and easily without establishing SailPointContext. I could still achieve my goal of iterating the solution to produce validated and working code to drop back into Sailpoint IIQ in this way.

The Code

Amazingly, the code for simulating a BuildMap rule, pointing it to the actual CSV I intend for Sailpoint IIQ, and simulating an account aggregation task is not that complex. Once you have the code, if you understand how Sailpoint IIQ works in general, you could conceivably re-engineer and simulate other segments of Sailpoint IIQ processing or modeling other rule types and.or data outside of Sailpoint IIQ1.
More »

Tags: , , , , , , , ,

Stupid SailPoint Developer Tricks

Hello, mates — as they say Down Under, where I happen to be at the moment on a rather large Sailpoint engagement. It’s been a while, and I’m sorry for that. I keep promising more, new and better content and haven’t delivered.

The last couple of months however have been absolutely crazy and there have been some changes on my end, as you perhaps can see. Now that things have shaped up a bit, maybe I can get back to the business at hand here on the blog, again as I have time.

Stupid Pet Tricks

When I was growing up and in college, a famous comedian became famous (partially) by having a segment on his show called “Stupid Pet Tricks.” Some were hilarious and some… belonged on the 1980’s “Gong Show.” (If you’ve never heard of “The Gong Show,” trust me, you aren’t missing anything).

Since that time, I’ve always thought of various developer tricks in the same light. Some are quite slick and useful and some… really just need to be buried. I’ll leave it to you to decide on this one.

Out of sheer laziness, while onboarding Sailpoint applications that feature a BuildMap rule (eg. BuildMap, JDBCBuildMap, and SAPBuildMap), I sometimes utilize a method for “printing debug statements” that I can see directly and immediately in connectorDebug, without having to jump into or tail the Sailpoint IIQ log or application server logs.

It’s also just a bit less verbose as the Sailpoint IIQ logs typically have a large class identification prefix in front of them, which can get rather cumbersome and make it more difficult to pick out one’s intended debug output.

Plus I hate changing logging levels in log4j.properties even though the Sailpoint IIQ debug page allows me to load a new logging configuration dynamically. In short, I’m just a lazy, complaining type when it comes to Sailpoint IIQ debug statements.

Someone mentioned this would be worth blogging about, so here goes. (At the very least, this is an easy article to write and perhaps will get me back into the blogging swing?!)

__DEBUG__ Schema

Now, I would definitely recommend doing this only on a local or designated sandbox and then making sure you clean up before checking in your code. (You are using some form of source code control for your Sailpoint IIQ development, aren’t you?!)
More »

Tags: , , , , ,

SailPoint IIQ: Aggregating XML

From an answer to a client this morning on aggregating XML in Sailpoint IIQ. I hope this helps others out there:

Regarding your question this morning on aggregating XML… I have seen XML aggregated through the OOTB RuleBasedFileParser connector. That connector requires that a rule be written to run the parser and through that, you could parse and aggregate XML. I mentioned this to one of our Solution Architects after our meeting and he was aware of the RuleBasedFileParser type, but personally felt it was enough work such that you may as well write a custom connector using libraries Java has available to handle XML.

I think between him and me, I would say the following:

(1) From an overall perspective, it’s technically possible using the RuleBasedFileParser connector to aggregate XML.

(2) There may need to be a discussion about the XML in consideration itself to determine the level of complexity of XML coming in, in which case:
(a)…The RuleBasedFileParser may be an adequate choice.
(b)…A custom connector for the XML may be in order.

One other approach could be:

(i) Use a DelimitedFile connector.
(ii) Write a pre-iterate rule leveraging the Java XML classes available to (a) read the XML and (b) create a CSV from the XML for the DelimitedFile connector to consume.
(iii) Use the post-iterate rule to clean up.

As you can see, there is more than one way to skin the XML cat here. This is the case as with most things in Sailpoint IIQ, as I demonstrate in at least one blog post, can be “tricked” in various places into doing what it is you ultimately want it to do.

As with any of this, it’s very common to have to sit down on an engagement and triage between a number of approach options to decide on the best implementation approach. I hope this information helps you with that process.

From the Twin Cities, where we shrug off the second day of Spring with a second helping of Winter, Amigos…

Tags: , , , , , ,

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: , , , , , ,

Google Chrome Natively Supports GreaseMonkey

Have you ever gone to a site and wished you could “tweek” the site to suit your needs a bit better? Or wished it looked or was laid out just slightly differently? Wish you could change the look and feel or create your own theme for it? The content and overall functionality is what you want, but you just want to make a tweek, especially one that suited you personally and you knew would never be requestable or a truly feasible feature to add for everyone?

Well, a while back, when Firefox held the number two spot for all browsers (which it recently has lost by the way, and I think for good reason, though I’ll not get into the whys here), you could accomplish exactly the above if you installed a Firefox extension called GreaseMonkey and held a commanding understanding of Javascript. (And you can still leverage GreaseMonkey if you happen to still use Firefox.)

I don’t have the time here to get into all of what GreaseMonkey can do for you. (Though the capabilities are QUITE extensive; Check that out on your own here.) I just recently had a need to update a site and customize it slightly to suit my needs, and, being pretty much an ardent Google Chrome user now, I decided to look into the possibility of using GreaseMonkey on Google Chrome. GreaseMonkey was fantastic on Firefox and, while I’d not run into a need for it under Google Chrome up until now, I did definitely desire to leverage it suddenly.

Wow, was I ever surprised! Google Chrome actually supports GreaseMonkey scripts NATIVELY. Your GreaseMonkey user script (as they are called) is simply viewed as a Chrome Extension. So all you have to do is write your script, drag and drop it into a Google Chrome window, and viola! You have a custom Chrome Extension or natively supported GreaseMonkey script, however you want to look at it.

It turns out that my personal use case is suitable as a quick demo of just how powerful this feature can be. It turns out I have this nasty habit of entering my timesheet for the week in the wrong week. I do this about 50% of the time, and it’s a real time killer when I do it, because the only way I can correct it is to back out each time entry individually and that takes a number of key clicks and screen changes. What I really need is a quick popup reminder to remind me to enter my time for the correct week when I first get into the initial time entry screen. My use case is as simple as that.

// ==UserScript==
// @name           NetSuite Timesheet Reminder
// @namespace      http://www.TechnologEase.com/GreaseMonkey
// @description    Reminder to fill in timesheets correctly!
// @include        https://system.netsuite.com/app/accounting/transactions/timebill*
// ==/UserScript==

// Just send an alert - that's it!
alert( "Make sure you enter your time for the CORRECT WEEK, Bozo-brain!!" );

Works great. Now next week and every week thereafter, I’ll get a reminder when I first enter the initial time entry screen and that should be enough to save me future headaches. :-)

GreaseMonkey just uses plain ol’ Javascript so, coupled together with something like JQuery and CSS 2 or CSS 3, you can imagine the power this brings to you for any and ALL web sites, if you can harness the power of Javascript for yourself. And Google Chrome supports this natively.

Enjoy!


Related Content

Tags: , , , , , ,

Getting Command Line Options in Ruby

Recently, after many, many years of serious coding in full OO Perl (none of this measly “admin scripting” you see in Perl that is called “Perl” — but real OO app level Perl!! ;-)), I decided to take the full dive into the deep end of the pool with Ruby for my scripting tool of choice.

I had been playing around with Ruby for over a decade having latched on to it right after it came out around the 2000 timeframe. I immediately saw it as an elegant and concise language that lived up to its billing; once I wrapped my head around the syntax and approach, I could write fairly good Ruby code in no time flat. It definitely had its advantages over Perl, in my opinion, being fully OO’d, and still retained from Perl what I liked most about it.

However, I needed to get real work done and my collection and apprehension of the Perl world (read “CPAN modules”) was much more extensive. For most of the early 2000’s, I was doing a lot more custom web development and mod_perl development (for Rodan & Fields as well as other smaller clients for TechnologEase) and was much too hooked on the templating benefits of Template::Toolkit, HTML::Template and Text::Template and well… Ruby just fell to the wayside. I had to get work done and I simply put Ruby back on the shelf and admired it from afar. My tribute to Ruby was to hijack elements of Ruby and bring them over to Perl. One of my favorites was a one-liner exported into every Perl script:

sub puts { for (@_) { print "$_\n" } } ## Print to stdout, Ruby-style

I also had built a small, but very concise framework in Perl for TechnologEase applications I developed while freelancing. This was nothing the size of anything like Catalyst or Moose but it did (and still does) the job, miraculously transforming everything instantly into objects that were easy to use and create. (If you know anything about OO Perl, you know that the OO Perl model is a bit… concocted, shall we say?!) And part of this framework, esp. for writing command line DSLs was a TechnologEase::Options class for… getting, parsing and creating custom class instances of command line options. It worked something like this:

my $options = TechnologEase::Options->new(
   sourcePath => 's:',
   destPath   => 'd:',
   testing    => 't',
   verbose    => 'v',
);

More »

Tags: , , , , , , , ,