A Forum reader recently asked:
"I see all this stuff on Cool Solutions about the Loopback driver. I got to my driver list in IDM 3.5.0 and I don't see Loopback driver anywhere - but the documentation does talk about Loopback driver. So how/where does one find and set up the Loopback driver?"
And here's the reply from Rob Schneider ...
You're not the first with this problem.
About the Loopback Driver
In the "olden days" it was called the "Move Proxy" driver, yet referred to everywhere as the LoopBack driver. Now in Designer 2.1, I see it is there under the Service drivers, and LoopBack, Manual Task, and Null all qualify as "loopback" drivers. Heck, you can use an eDir driver to do loopback - so really, the fact that Novell named a driver for this is part of the issue.
Basically, a loopback driver is any driver that you program to respond to an event by taking action against the Directory that is the source of the event. That said, use the Loopback or Null drivers, since they come with less built-in "junk" that you have to "undo" to make it work.
The Loopback driver basically needs Subscriber event transforms, all acting
on the Source directory (remember, there is NEVER a Destination object,
attribute, etc.) and a rule that vetos everything. Sometimes this is found in the
Event Transform, but depending on how you process events, it can also be in
the Command Transform of the Subscriber.
Why a loopback driver? These reasons immediately come to mind:
1. (Obvious) You need to take action against the source directory.
2. An event occurs that can be sourced in any number of other drivers. Why write code in every driver when you can put a single piece of code in the loopback driver to catch that event, regardless of where it was initially
3. You need a cozy place to consolidate all of this type of rules, rather than having it spread out in the subscriber channel of multiple drivers (which is where and how I did it, before I realized I was doing loopback and that there was a loopback driver.)
4. I'm sure there are more reasons ...
Further best practice - check out Novell's IDM Resource Kit, which has a model of the "dream" IDM environment, including the use of 3 loopback drivers for different business processes. It makes good sense.
Suppose that when you create a new user, you want to create the full name
automatically - and if you change a user, it will change the last name as well.
Here's the rule I have for that purpose, as a headstart. The actual rule you implement will depend on your "standard" for full name. This rule assumes full name means Given Name <space>Surname.
<description>Construct Full Name from Given Name and Surname</description>
<comment xml:space="preserve">The Given Name and Surname are used to set the
full name whenever the attributes are set or modified.</comment>
<if-operation mode="case" op="equal">add</if-operation>
<if-operation mode="case" op="equal">modify</if-operation>
<if-op-attr name="Given Name" op="changing"/>
<if-op-attr name="Surname" op="changing"/>
<do-set-src-attr-value name="Full Name">
<token-src-attr name="Given Name"/>
<token-text xml:space="preserve"> </token-text>