Discussion:
Multiple value mapping with single value.
(too old to reply)
ramesh kopparapu
2017-06-11 21:28:34 UTC
Permalink
Raw Message
Hi,

This is in ISIM.
I've a file with orphan ids and corresponding UserIDs

The logic is to find OrphanID DN and add a new attribute called owner and set UserId Dn to the owner.


I've retreived OwnerDN but the problem is there are multiple Orphans with same IDs. So I've collected them into array of DNs

Now, How to update them with OwnerID??

My flow is as follows

Feed -> ReadMappings (CSV)
Data Flow -> OwnerLookup (LDAP Lookup to fetch the Owners DN)
-> OrphanLookup (LDAP Lookup to fetch the Orphan's DN)

Following is the snippet for multiple Entries hook.

(I'm trying to update it in the same hook. But the issue is there's no owner attribute to update, it needs to be added)


// Get all the multiple entries and store them in an array

//var ldapconn = UpdateOwner.getConnector();

dn_arr = [];
var thisEntry = thisConnector.getFirstDuplicateEntry();
while (thisEntry != null)
{
//task.logmsg(thisEntry.getAttribute("$dn"));
dn_arr.push(thisEntry.getAttribute("$dn"));
thisEntry = thisConnector.getNextDuplicateEntry();
}
work.setAttribute("dnarray",dn_arr);

for (i in dn_arr )
{
//thisEntry.add
var theCriteria = new com.ibm.di.server.SearchCriteria("$dn",61,"dn="+dn_arr[i]);
//ldapconn.addAttributeValue()
try {
thisConnector.getConnector().modEntry(work,theCriteria);
task.logmsg("Entry Updated "+ dn_arr[i]);
}
catch (Ex)
{
task.logmsg("Error updating this entry");
task.logmsg("ERROR : "+ Ex.getMessage());
task.dumpEntry(work);
}
}


Please let your suggestions flow.

Thanks.
Franzw
2017-06-12 09:49:43 UTC
Permalink
Raw Message
Post by ramesh kopparapu
Hi,
This is in ISIM.
I've a file with orphan ids and corresponding UserIDs
The logic is to find OrphanID DN and add a new attribute called owner and set UserId Dn to the owner.
I've retreived OwnerDN but the problem is there are multiple Orphans with same IDs. So I've collected them into array of DNs
Now, How to update them with OwnerID??
My flow is as follows
Feed -> ReadMappings (CSV)
Data Flow -> OwnerLookup (LDAP Lookup to fetch the Owners DN)
-> OrphanLookup (LDAP Lookup to fetch the Orphan's DN)
Following is the snippet for multiple Entries hook.
(I'm trying to update it in the same hook. But the issue is there's no owner attribute to update, it needs to be added)
// Get all the multiple entries and store them in an array
//var ldapconn = UpdateOwner.getConnector();
dn_arr = [];
var thisEntry = thisConnector.getFirstDuplicateEntry();
while (thisEntry != null)
{
//task.logmsg(thisEntry.getAttribute("$dn"));
dn_arr.push(thisEntry.getAttribute("$dn"));
thisEntry = thisConnector.getNextDuplicateEntry();
}
work.setAttribute("dnarray",dn_arr);
for (i in dn_arr )
{
//thisEntry.add
var theCriteria = new com.ibm.di.server.SearchCriteria("$dn",61,"dn="+dn_arr[i]);
//ldapconn.addAttributeValue()
try {
thisConnector.getConnector().modEntry(work,theCriteria);
task.logmsg("Entry Updated "+ dn_arr[i]);
}
catch (Ex)
{
task.logmsg("Error updating this entry");
task.logmsg("ERROR : "+ Ex.getMessage());
task.dumpEntry(work);
}
}
Please let your suggestions flow.
Thanks.
This is not how ISIM works - if you want to adopt account externally (and not through the standard Adoption policy) then you must use the ISIM apis. The adopt() method is on the ISIM AccountEntity object : https://www.stephen-swann.co.uk/javadoc/sim6.0/com/ibm/itim/dataservices/model/domain/AccountEntity.html

Basically this means that you will have to construct your AccountEntity from and AccountSearch.lookup(<dn>) which takes and DistinguishedName object as argument - which again means you have to construct that from the string DN you have....

You should not do that this through ldap changes - this is not supported.

HTH
Regards
Franz Wolfhagen
ramesh kopparapu
2017-06-12 11:30:16 UTC
Permalink
Raw Message
Post by Franzw
Post by ramesh kopparapu
Hi,
This is in ISIM.
I've a file with orphan ids and corresponding UserIDs
The logic is to find OrphanID DN and add a new attribute called owner and set UserId Dn to the owner.
I've retreived OwnerDN but the problem is there are multiple Orphans with same IDs. So I've collected them into array of DNs
Now, How to update them with OwnerID??
My flow is as follows
Feed -> ReadMappings (CSV)
Data Flow -> OwnerLookup (LDAP Lookup to fetch the Owners DN)
-> OrphanLookup (LDAP Lookup to fetch the Orphan's DN)
Following is the snippet for multiple Entries hook.
(I'm trying to update it in the same hook. But the issue is there's no owner attribute to update, it needs to be added)
// Get all the multiple entries and store them in an array
//var ldapconn = UpdateOwner.getConnector();
dn_arr = [];
var thisEntry = thisConnector.getFirstDuplicateEntry();
while (thisEntry != null)
{
//task.logmsg(thisEntry.getAttribute("$dn"));
dn_arr.push(thisEntry.getAttribute("$dn"));
thisEntry = thisConnector.getNextDuplicateEntry();
}
work.setAttribute("dnarray",dn_arr);
for (i in dn_arr )
{
//thisEntry.add
var theCriteria = new com.ibm.di.server.SearchCriteria("$dn",61,"dn="+dn_arr[i]);
//ldapconn.addAttributeValue()
try {
thisConnector.getConnector().modEntry(work,theCriteria);
task.logmsg("Entry Updated "+ dn_arr[i]);
}
catch (Ex)
{
task.logmsg("Error updating this entry");
task.logmsg("ERROR : "+ Ex.getMessage());
task.dumpEntry(work);
}
}
Please let your suggestions flow.
Thanks.
This is not how ISIM works - if you want to adopt account externally (and not through the standard Adoption policy) then you must use the ISIM apis. The adopt() method is on the ISIM AccountEntity object : https://www.stephen-swann.co.uk/javadoc/sim6.0/com/ibm/itim/dataservices/model/domain/AccountEntity.html
Basically this means that you will have to construct your AccountEntity from and AccountSearch.lookup(<dn>) which takes and DistinguishedName object as argument - which again means you have to construct that from the string DN you have....
You should not do that this through ldap changes - this is not supported.
HTH
Regards
Franz Wolfhagen
Oh..!!! Thanks for the information Franz. Frankly I didn't know that.

Is it possible if you can brief me why it's not supported thru ldap changes?? As in, I mean that all I was thinking that I need to change the DN of the account and move it to ou=accounts and add owner attribute to the
entry that should suffice. I'm not able to understand why it's not supported.
Franzw
2017-06-13 06:29:41 UTC
Permalink
Raw Message
Post by ramesh kopparapu
Post by Franzw
Post by ramesh kopparapu
Hi,
This is in ISIM.
I've a file with orphan ids and corresponding UserIDs
The logic is to find OrphanID DN and add a new attribute called owner and set UserId Dn to the owner.
I've retreived OwnerDN but the problem is there are multiple Orphans with same IDs. So I've collected them into array of DNs
Now, How to update them with OwnerID??
My flow is as follows
Feed -> ReadMappings (CSV)
Data Flow -> OwnerLookup (LDAP Lookup to fetch the Owners DN)
-> OrphanLookup (LDAP Lookup to fetch the Orphan's DN)
Following is the snippet for multiple Entries hook.
(I'm trying to update it in the same hook. But the issue is there's no owner attribute to update, it needs to be added)
// Get all the multiple entries and store them in an array
//var ldapconn = UpdateOwner.getConnector();
dn_arr = [];
var thisEntry = thisConnector.getFirstDuplicateEntry();
while (thisEntry != null)
{
//task.logmsg(thisEntry.getAttribute("$dn"));
dn_arr.push(thisEntry.getAttribute("$dn"));
thisEntry = thisConnector.getNextDuplicateEntry();
}
work.setAttribute("dnarray",dn_arr);
for (i in dn_arr )
{
//thisEntry.add
var theCriteria = new com.ibm.di.server.SearchCriteria("$dn",61,"dn="+dn_arr[i]);
//ldapconn.addAttributeValue()
try {
thisConnector.getConnector().modEntry(work,theCriteria);
task.logmsg("Entry Updated "+ dn_arr[i]);
}
catch (Ex)
{
task.logmsg("Error updating this entry");
task.logmsg("ERROR : "+ Ex.getMessage());
task.dumpEntry(work);
}
}
Please let your suggestions flow.
Thanks.
This is not how ISIM works - if you want to adopt account externally (and not through the standard Adoption policy) then you must use the ISIM apis. The adopt() method is on the ISIM AccountEntity object : https://www.stephen-swann.co.uk/javadoc/sim6.0/com/ibm/itim/dataservices/model/domain/AccountEntity.html
Basically this means that you will have to construct your AccountEntity from and AccountSearch.lookup(<dn>) which takes and DistinguishedName object as argument - which again means you have to construct that from the string DN you have....
You should not do that this through ldap changes - this is not supported.
HTH
Regards
Franz Wolfhagen
Oh..!!! Thanks for the information Franz. Frankly I didn't know that.
Is it possible if you can brief me why it's not supported thru ldap changes?? As in, I mean that all I was thinking that I need to change the DN of the account and move it to ou=accounts and add owner attribute to the
entry that should suffice. I'm not able to understand why it's not supported.
ISIM does a lot of internal caching when it manipulates the ldap records through the EJB. And that cache will not be updated if you go to the ldap directly.

You can argue with that kind of caching - but that is how our development has decided to improve performance of the application.

So - if you want to be sure that your system is consistent always use the APIs - there is no guarantee that ldap changes on a running system will work and you may crate inconsistencies in the data view.

Regards
Franz Wolfhagen
yn2000
2017-06-13 14:31:20 UTC
Permalink
Raw Message
Hahaha… good cop message, let me be the bad cop delivering the message bluntly, as I am not IBMer anyway.

I used to call ‘the action to change TDS directly’ as ‘hacking’, and as far as I know, ‘hacking’ method is not supported by IBM, period. This can be explained more in legal matter (read: money matter) rather than technical matter. For example: Do you know that attribute ‘owner’ is not actually the original design? If I remember it correctly, it was introduced in ITIM v5.0. So, if you just put the relation only on attribute ‘owner’, then some of the functionality based on the old code is broken, then does it mean IBM is ‘liable’ to fix your code? What if IBM uses a different attribute in the future? How many other external codes that IBM has to fix/support then? Therefore, IBM limits the support only to the code that they have control over and ‘recommend’ not to touch the underlying TDS design. In other words, it also means that your company cannot sue IBM, if one day IBM change the underlying TDS design and your code broke (read: too costly to fix, because it is already part of a complicated processes). In fact, if you are a consultant, and you dare to introduce unsupported avenue in your solution, then your customer can sue you, especially if one day your code broke and IBM refuse to help your customer for free, just because it is not part of the supported agreement.

Yes, I dramatized the example, but I hope the message is clear, which is, you have to ‘legally’ protect yourself if you dare to introduce ‘hacking’ method into your solution. I guess you hate me know, but somebody need to remind this line, considering that ‘hacking’ has become a common practice now.
Rgds. YN.
Franzw
2017-06-14 10:57:03 UTC
Permalink
Raw Message
Post by yn2000
Hahaha… good cop message, let me be the bad cop delivering the message bluntly, as I am not IBMer anyway.
I used to call ‘the action to change TDS directly’ as ‘hacking’, and as far as I know, ‘hacking’ method is not supported by IBM, period. This can be explained more in legal matter (read: money matter) rather than technical matter. For example: Do you know that attribute ‘owner’ is not actually the original design? If I remember it correctly, it was introduced in ITIM v5.0. So, if you just put the relation only on attribute ‘owner’, then some of the functionality based on the old code is broken, then does it mean IBM is ‘liable’ to fix your code? What if IBM uses a different attribute in the future? How many other external codes that IBM has to fix/support then? Therefore, IBM limits the support only to the code that they have control over and ‘recommend’ not to touch the underlying TDS design. In other words, it also means that your company cannot sue IBM, if one day IBM change the underlying TDS design and your code broke (read: too costly to fix, because it is already part of a complicated processes). In fact, if you are a consultant, and you dare to introduce unsupported avenue in your solution, then your customer can sue you, especially if one day your code broke and IBM refuse to help your customer for free, just because it is not part of the supported agreement.
Yes, I dramatized the example, but I hope the message is clear, which is, you have to ‘legally’ protect yourself if you dare to introduce ‘hacking’ method into your solution. I guess you hate me know, but somebody need to remind this line, considering that ‘hacking’ has become a common practice now.
Rgds. YN.
No no - you are completely right - there are "official" truths and reality :-) I really enjoy your sense of keeping us honest.

I am not going out and try to move people into something that will hurt them later - if something is a onetime exercise your choices may be different.

Regards
Franz Wolfhagen

Loading...