Polling opinion on a solution design - processing values
returned

All

This is my first post on here. I've previously been getting the good 
word from Eddie and others on the Google Groups mirror.

Using ITIM 4.5.1 and TDI 6.0

I have a new service to manage in ITIM. It requires an Event Listener in 
ITDI with calls to a third party hosted web service to maintain the 
accounts.

On creation of an account for the first time, the web service returns a 
success flag, and a unique object reference ( UUID ) which must be used 
for all further changes to that account. I have to take that UUID and 
populate the TIM account so that future provisioning requests can 
provide the UUID to the web service.

As I'm using a DSML Event Listener, there is no out of the box way of 
updating TIM with the returned value.

So, two ( or three ) approaches come to mind:

Use ITDI to make the web service call. Capture the returned value from 
the web service, and call a bespoke java class which uses the TIM APIs 
to populate the required attribute in the TIM account.

Use ITDI to forward the DSML parameters to a bespoke java class which 
handles the web service call, the TIM API calls and then returns a 
success flag to ITDI which continues processing.

Either of the above approaches but updating TIM via LDAP.

I'd appreciate any thoughts on the above approaches or a simpler method 
if one is available.

Thanks in advance.

Niall,

I think the simplest of all methods would be to use 'event 
notifications' to TIM once the web service call has given you a UUID, so 
that you can update the corresponding TIM account object with that UUID.

The primary goal of the account event notification is to propagate 
account changes made locally into an enterprise account data store to 
ITIM.  Upon reception of this event notification, ITIM will evaluate the 
provisioning policy. This way is an alternative to running 
reconciliations all the time.

ITDI needs to function as a DSMLv2 client in order to initiate identity 
feeds via the JNDI interface and to send account management event 
notifications.  The principle is that same as when TDI is run to perform 
HR feeds into TIM (JNDI connector with the dsml2_event_handler Driver); 
what changes for account event notification is that:
  - the search base of that connector should point to 
dc=<namingContextOfYourServiceInTIM> (for instance: dc=myWSAdapter) 
instead of pointing to dc=hrfeed (for example)
  - the attribute used to search in (link criteria) will have to be the 
same as you defined in TIM as 'naming attribute' (typically eruid, or 
cn, or mail...).

But even if you do so, you will have a problem to use the WS-retrieved 
UUID on subsequent provisionning operations. TIM will send the UUID to 
the provisioning adapter only if its value changes... at least this is 
true of DSML2 adapters. DAML and RMI adapters don't have this problem.

HTH,

Christian

Niall wrote:

> All
> 
> This is my first post on here. I've previously been getting the good 
> word from Eddie and others on the Google Groups mirror.
> 
> Using ITIM 4.5.1 and TDI 6.0
> 
> I have a new service to manage in ITIM. It requires an Event Listener in 
> ITDI with calls to a third party hosted web service to maintain the 
> accounts.
> 
> On creation of an account for the first time, the web service returns a 
> success flag, and a unique object reference ( UUID ) which must be used 
> for all further changes to that account. I have to take that UUID and 
> populate the TIM account so that future provisioning requests can 
> provide the UUID to the web service.
> 
> As I'm using a DSML Event Listener, there is no out of the box way of 
> updating TIM with the returned value.
> 
> So, two ( or three ) approaches come to mind:
> 
> Use ITDI to make the web service call. Capture the returned value from 
> the web service, and call a bespoke java class which uses the TIM APIs 
> to populate the required attribute in the TIM account.
> 
> Use ITDI to forward the DSML parameters to a bespoke java class which 
> handles the web service call, the TIM API calls and then returns a 
> success flag to ITDI which continues processing.
> 
> Either of the above approaches but updating TIM via LDAP.
> 
> I'd appreciate any thoughts on the above approaches or a simpler method 
> if one is available.
> 
> Thanks in advance.
>