| Subcribe via RSS

SailPoint IIQ: BuildMap – I Told You So :-)

Okay, here’s an article I wasn’t planning on posting, but based on some feedback I received privately via email, I thought I would throw this one example out there. Sometimes the simplest and unlikeliest of examples can tell you a whole lot about the plumbing of a product such as Sailpoint IIQ. Concerning my most recent post on SailPoint IIQ Build Map rules, this next exercise I think will fit the bill of being quite revealing even though simple and extremely unlikely to mirror real world.

I Told You So :-)

In my last post, I indicated that Build Map rules (as well as other rule hooks in Sailpoint IIQ) do not care what you are doing inside them, in general. In the case of the Build Map rule, I stated that Sailpoint IIQ does not do a single thing to validate your code. It does not validate it against your application schema; it’s trusting you 100% to wire your build map rule to your schema in the right way — 100%. The only thing Sailpoint IIQ does do is map fields from your build map into a resource object (later in aggregation processing) that matches the schema, which is a short way of saying…

(1) If you don’t provide a field from your return map that matches the application schema, that field in the schema will be blank (or null), and…

(2) If you provide a field from your return map that does NOT match the application schema, that field in the build map will be dropped.

That’s it. The rest is up to you and here’s a very small example that in my mind pretty much demonstrates everything about how build map rules work.

Setting This Up

Let’s set this up. Try this in your development sandbox. First, create a plain text file that has nothing in it but one number per line — lines numbered from say 1 to 25. Nothing else. This is easy to setup on the Linux command line. (For you Windows peeps, I’m sorry to say it may be just as easy to jump into NotePad and bang out 25 lines by hand! :-( :-))

$ perl -e 'for (1..25) { print "$_\n" }' > dummy25.txt

More »

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