Discussion:
Custom ITIM adapter Modify Operation
(too old to reply)
Matt som
2012-01-10 14:16:16 UTC
Permalink
Raw Message
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.

The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.

For example, lets consider a user named as Todd Jones.

If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
alchemisx yep
2012-01-18 21:42:28 UTC
Permalink
Raw Message
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.

For the help, look at what iTIM is sending based on the following:

In iTIM look at the modify values of the account and see what is set
as changed and unchanged.

Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
TDI. I did this:

// List all attributes and their values
var attrnames = work.getAttributeNames();
for ( i = 0; i < attrnames.length; i++ ) {
var attr = work.getAttribute ( attrnames[i] );
task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}
}


Take a good look at this line:
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));

Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.

If the attribute is changed it sends the original value with a
"delete" Operational Value. And then sends the new value with the
operational value of "add".

If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).

The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value. So, I compensated this by adding pre-
execute logic that handles it to my liking:

Note: work.getAttribute("thisFAC") is attribute loop's attribute
name. I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.

var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );

for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}


if (attr.getValueOperation(0) == "delete")
{
task.logmsg("Found an entry tagged for deletion!");
//Clean the value
var attr = work.getString("thisFAC");
attr = attr.trim();

//skip the rest of this connector
system.ignoreEntry();
} else if (attr.getValueOperation(0) == "") {
//No Changes
system.ignoreEntry();
}

In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on. Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.

There may be a more elegant solution but it's worked for me.

Hope this helps, I know I've bashed my head on this problem for a few
weeks.

-rsxdc5
alchemisx yep
2012-01-18 21:45:04 UTC
Permalink
Raw Message
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
 var attrnames = work.getAttributeNames();
 for ( i = 0; i < attrnames.length; i++ ) {
    var attr = work.getAttribute ( attrnames[i] );
    task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
    for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
    }
 }
    task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value.  And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value.  So, I compensated this by adding pre-
Note:  work.getAttribute("thisFAC") is attribute loop's attribute
name.  I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
        {
        task.logmsg("Found an entry tagged for deletion!");
        //Clean the value
    var attr = work.getString("thisFAC");
    attr = attr.trim();
        //skip the rest of this connector
        system.ignoreEntry();} else if (attr.getValueOperation(0) == "") {
        //No Changes
        system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on.  Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Small typo, I meant skip the connector's operation using
system.ignoreEntry(), not "skipping the entire entry".

Apologies,

-rsxdc5
Magesh Bothaguru
2012-01-19 15:56:15 UTC
Permalink
Raw Message
Post by alchemisx yep
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
 var attrnames = work.getAttributeNames();
 for ( i = 0; i < attrnames.length; i++ ) {
    var attr = work.getAttribute ( attrnames[i] );
    task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
    for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
    }
 }
    task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value.  And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value.  So, I compensated this by adding pre-
Note:  work.getAttribute("thisFAC") is attribute loop's attribute
name.  I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
        {
        task.logmsg("Found an entry tagged for deletion!");
        //Clean the value
    var attr = work.getString("thisFAC");
    attr = attr.trim();
        //skip the rest of this connector
        system.ignoreEntry();} else if (attr.getValueOperation(0) == "") {
        //No Changes
        system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on.  Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Small typo, I meant skip the connector's operation using
system.ignoreEntry(), not "skipping the entire entry".
Apologies,
-rsxdc5- Hide quoted text -
- Show quoted text -
I did this to fix mine.

function getNewValue(attributeName)
{
var attributeValue = work.getAttribute(attributeName);
if (attributeValue == null)
{
return null;
}
else
{
var myValue = attributeValue.toString();
return (myValue.substr(myValue.indexOf("|")+1));
}
}
var newValue = getNewValue("cn");
if (newValue != null)
{
ret.value = newValue;
}
return;

Thanks...
Magesh Bothaguru
2012-01-20 13:55:59 UTC
Permalink
Raw Message
Post by Magesh Bothaguru
Post by alchemisx yep
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
 var attrnames = work.getAttributeNames();
 for ( i = 0; i < attrnames.length; i++ ) {
    var attr = work.getAttribute ( attrnames[i] );
    task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
    for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
    }
 }
    task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value.  And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value.  So, I compensated this by adding pre-
Note:  work.getAttribute("thisFAC") is attribute loop's attribute
name.  I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
        {
        task.logmsg("Found an entry tagged for deletion!");
        //Clean the value
    var attr = work.getString("thisFAC");
    attr = attr.trim();
        //skip the rest of this connector
        system.ignoreEntry();} else if (attr.getValueOperation(0) == "") {
        //No Changes
        system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on.  Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Small typo, I meant skip the connector's operation using
system.ignoreEntry(), not "skipping the entire entry".
Apologies,
-rsxdc5- Hide quoted text -
- Show quoted text -
I did this to fix mine.
  function getNewValue(attributeName)
  {
  var attributeValue = work.getAttribute(attributeName);
  if (attributeValue == null)
  {
  return null;
  }
  else
 {
 var myValue = attributeValue.toString();
 return (myValue.substr(myValue.indexOf("|")+1));
 }
 }
 var newValue = getNewValue("cn");
 if (newValue != null)
{
ret.value = newValue;}
return;
Thanks...- Hide quoted text -
- Show quoted text -
I have another question. The custom oracle adapter that I am building
is for entering rows in an oracle table and it doesn't have to do
anything with change password. But when I change the password for a
user who has this service, I get an error for this oracle service. I
don't want change password operation for this service. Do you have any
idea what I need to do on this service for not processing change
password operations?

Thanks
n***@gmail.com
2013-06-18 09:05:08 UTC
Permalink
Raw Message
Post by Magesh Bothaguru
Post by Magesh Bothaguru
Post by alchemisx yep
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
 var attrnames = work.getAttributeNames();
 for ( i = 0; i < attrnames.length; i++ ) {
    var attr = work.getAttribute ( attrnames[i] );
    task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
    for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
    }
 }
    task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value.  And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value.  So, I compensated this by adding pre-
Note:  work.getAttribute("thisFAC") is attribute loop's attribute
name.  I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
        {
        task.logmsg("Found an entry tagged for deletion!");
        //Clean the value
    var attr = work.getString("thisFAC");
    attr = attr.trim();
        //skip the rest of this connector
        system.ignoreEntry();} else if (attr.getValueOperation(0) == "") {
        //No Changes
        system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on.  Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Small typo, I meant skip the connector's operation using
system.ignoreEntry(), not "skipping the entire entry".
Apologies,
-rsxdc5- Hide quoted text -
- Show quoted text -
I did this to fix mine.
  function getNewValue(attributeName)
  {
  var attributeValue = work.getAttribute(attributeName);
  if (attributeValue == null)
  {
  return null;
  }
  else
 {
 var myValue = attributeValue.toString();
 return (myValue.substr(myValue.indexOf("|")+1));
 }
 }
 var newValue = getNewValue("cn");
 if (newValue != null)
{
ret.value = newValue;}
return;
Thanks...- Hide quoted text -
- Show quoted text -
I have another question. The custom oracle adapter that I am building
is for entering rows in an oracle table and it doesn't have to do
anything with change password. But when I change the password for a
user who has this service, I get an error for this oracle service. I
don't want change password operation for this service. Do you have any
idea what I need to do on this service for not processing change
password operations?
Thanks
This code is really worth for my requirement and it is working perfectly.

Thanks Everyone.
SourabhM
2013-06-21 08:18:20 UTC
Permalink
Raw Message
Post by Magesh Bothaguru
Post by Magesh Bothaguru
Post by alchemisx yep
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
 var attrnames = work.getAttributeNames();
 for ( i = 0; i < attrnames.length; i++ ) {
    var attr = work.getAttribute ( attrnames[i] );
    task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
    for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
    }
 }
    task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value.  And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value.  So, I compensated this by adding pre-
Note:  work.getAttribute("thisFAC") is attribute loop's attribute
name.  I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
      task.logmsg( "      Value " + j + ": " + attr.getValue ( j ) );
      task.logmsg("       Operation Code is "  +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
        {
        task.logmsg("Found an entry tagged for deletion!");
        //Clean the value
    var attr = work.getString("thisFAC");
    attr = attr.trim();
        //skip the rest of this connector
        system.ignoreEntry();} else if (attr.getValueOperation(0) == "") {
        //No Changes
        system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on.  Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Small typo, I meant skip the connector's operation using
system.ignoreEntry(), not "skipping the entire entry".
Apologies,
-rsxdc5- Hide quoted text -
- Show quoted text -
I did this to fix mine.
  function getNewValue(attributeName)
  {
  var attributeValue = work.getAttribute(attributeName);
  if (attributeValue == null)
  {
  return null;
  }
  else
 {
 var myValue = attributeValue.toString();
 return (myValue.substr(myValue.indexOf("|")+1));
 }
 }
 var newValue = getNewValue("cn");
 if (newValue != null)
{
ret.value = newValue;}
return;
Thanks...- Hide quoted text -
- Show quoted text -
I have another question. The custom oracle adapter that I am building
is for entering rows in an oracle table and it doesn't have to do
anything with change password. But when I change the password for a
user who has this service, I get an error for this oracle service. I
don't want change password operation for this service. Do you have any
idea what I need to do on this service for not processing change
password operations?
Thanks
You can create a changePassword workflow at account profile level and by pass the change password extension or you can also handle at custom adapter level by skip entry in AL used by change password.
Ayush Priyamvad
2017-07-25 01:51:11 UTC
Permalink
Raw Message
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
var attrnames = work.getAttributeNames();
for ( i = 0; i < attrnames.length; i++ ) {
var attr = work.getAttribute ( attrnames[i] );
task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}
}
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value. And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value. So, I compensated this by adding pre-
Note: work.getAttribute("thisFAC") is attribute loop's attribute
name. I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
{
task.logmsg("Found an entry tagged for deletion!");
//Clean the value
var attr = work.getString("thisFAC");
attr = attr.trim();
//skip the rest of this connector
system.ignoreEntry();
} else if (attr.getValueOperation(0) == "") {
//No Changes
system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on. Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Thanks a ton. It's been 5 years since this post but probably the most useful post on custom adapters :). I had worked on this a few years ago and lost the code so this your post is an excellent reference point. IBM still hasn't appeared to document this anywhere!
Ayush Priyamvad
2017-07-25 01:55:26 UTC
Permalink
Raw Message
Post by alchemisx yep
Post by Matt som
I have a strange issue with the Modify operation of a Custom Adapter
that I am building. New account provisioning works and delete
operations works fine but not the modify.
The probelm I have is when I update an account on ITIM it will not
update the attributes in the managed system, but it does update them
in the ITIM account object. If I update the values again, it actually
takes the old entity values and sends those to the managed system to
be updated instead of the new values.
For example, lets consider a user named as Todd Jones.
If I change the last name of the user to Johnson, then ITIM account
object (custom adapter service account information) will have the
updated Todd Johnson value but the managed system will still remain as
Todd Jones. Again if I change the last name of the same user for the
second time to James, then ITIM account object will have Todd James
but the managed system gets updated to Todd Johnson. Have anyone seen
this issue before. I don't know what and where is the problem. Please
help.
This was the interesting bit I learned the hard way in iTIM.
In iTIM look at the modify values of the account and see what is set
as changed and unchanged.
Now in the adapter put in a code at the beginning of the entire
operation as a script component that labels what is being sent to
// List all attributes and their values
var attrnames = work.getAttributeNames();
for ( i = 0; i < attrnames.length; i++ ) {
var attr = work.getAttribute ( attrnames[i] );
task.logmsg( "Attribute: name = " + attr.getName() + ", #values =
" + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}
}
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
Reason being is that iTIM sends the original value to TDI to do work
but with a flag associated.
If the attribute is changed it sends the original value with a
"delete" Operational Value. And then sends the new value with the
operational value of "add".
If the attribute is unchanged it sends the original value with no
operational value (or "" as I found).
The thing is TDI doesn't care (necessarily) what the value is, it just
does work based on the value. So, I compensated this by adding pre-
Note: work.getAttribute("thisFAC") is attribute loop's attribute
name. I'm doing this for many attributes individually, but it can be
consolidated into a smaller subset of loops, nevertheless, you'll see
what I'm getting at.
var attr = work.getAttribute("thisFAC")
task.logmsg( "thisERNurse has #values = " + attr.size() );
for ( j = 0; j < attr.size(); j++ ) {
task.logmsg( " Value " + j + ": " + attr.getValue ( j ) );
task.logmsg(" Operation Code is " +
attr.getValueOperation(j));
}
if (attr.getValueOperation(0) == "delete")
{
task.logmsg("Found an entry tagged for deletion!");
//Clean the value
var attr = work.getString("thisFAC");
attr = attr.trim();
//skip the rest of this connector
system.ignoreEntry();
} else if (attr.getValueOperation(0) == "") {
//No Changes
system.ignoreEntry();
}
In this occurrence, if the attribute is labeled as delete or null ("")
then skip the entire entry and move on. Otherwise it will evaluate to
"add" and do the add operation as I've defined in the connector.
There may be a more elegant solution but it's worked for me.
Hope this helps, I know I've bashed my head on this problem for a few
weeks.
-rsxdc5
Thanks a ton for the clear and precise explanation. It's been 5 years but this post is still an excellent reference :)
Loading...