locked
What causes "completed-transient-object" error, and how to eliminate it?

    Question

  • Hi,

     

    I've been preparing to do fix some problems in our ILM that are occurring due to import mismatch, as discussed here:

     

    http://social.technet.microsoft.com/Forums/en/identitylifecyclemanager/thread/ca6cf8ee-dfef-42af-8222-a73e4b4f7fbf

     

    So, I was testing the changes in one of our test environments, and after making the changes, deleted the CS and then did full import then full synch.

     

    The code changes (adding the timestamp to the date attributes before exporting) appeared to have worked, but I noted that we're now getting "completed-transient-object" errors.  The run history doesn't list any objects, but just shows status of "completed-transient-object".

     

    So, I've been doing some research on this error.  From what I've read, what causes the error is:

     

    "When an object is imported to the connector space that has the same distinguished name attribute as an existing connector space object but a different anchor attribute, the existing connector space object is marked as transient."

     

    I'm trying to "understand" exactly what the cause of this error is, in reading, and re-reading the descriptions of the error, I'm kind of unclear about what is meant by the "distinguished name attribute".  

    I understand what the "anchor attribute" is in an MA configuration is, because I select that attribute in the MA configuration, but I don't remember having to, or being able to, designate a specific attribute as "the distinguished name attribute".

     

    I guess that mentally, I've always thought, apparently mistakenly, that the Anchor in an MA IS "the distingushed name attribute". 

     

    Having said that, I guess that I won't be able to really understand this error (and what causes it) until I understand what "the distinguished name attribute" in the MA is vs. "the Anchor".

     

    Thanks,

    Jim

    Thursday, July 07, 2011 12:14 AM

All replies

  • Hi,

     

    Having some time to think about when we started seeing these errors, I think that it happened after we:

     

    - Deleted one of our Oracle MA CSes

    - Did a Full Import (stage only) - to try to prevent duplicate rows being created in the Oracle table

    - Ran our daily run

     

    i.e., we neglected to run a Full Synch after the delete/full import.

     

    Would that sequence of operations cause these/such errors?  I'm pretty sure that we've done similar things (well, maybe not) in the past, but only started seeing the errors today.

     

    Also, I'd still really appreciate an explanation about the question about what "the distinguished name attribute" is, because I was thinking that another possible cause of the problem is that in this particular database, we KNOW that there were a bunch of duplicate rows from someone previously deleting the CS and then running a synch without a Full Import, and, unfortunately, we aren't being allowed to delete all the rows in the table and let ILM re-provision it.

     

    Thanks,

    Jim

    Thursday, July 07, 2011 4:54 AM
  • The DN sometimes looks like the anchor but really isn't, like in the case of the Active Directory MA.  The DN may be something like "CN=jdoe,OU=Employees,dc=test,dc=local" but the hidden anchor is actually the GUID.

    Was provisioning disabled in ILM when you deleted the Oracle MA CS?  I've never tried a CS deletion with provisioning enabled.  When all the connectors are deleted, I'm curious as to whether that would trigger the provisioning code to fire and perhaps the connector space was quietly repopulated behind your delete with a whole new set of objects ready for export. Perhaps the deltas that you ran afterward caused some pending exports to be queued up, instead.

    If your provisioning code assigns a temporary GUID as the anchor, but the Oracle system assigns a real one that gets imported and replaces the random GUID, that might explain how the description of the error you found came to be applicable.  You had at least some pending exports in the connector space with random GUIDs, and you imported all the objects from Oracle with real anchor values.  For awhile there were duplicates and nothing really tied them together.  A full sync should clean that up.

     

    Thursday, July 07, 2011 9:01 PM
  • The DN sometimes looks like the anchor but really isn't, like in the case of the Active Directory MA.  The DN may be something like "CN=jdoe,OU=Employees,dc=test,dc=local" but the hidden anchor is actually the GUID.

    Was provisioning disabled in ILM when you deleted the Oracle MA CS?  I've never tried a CS deletion with provisioning enabled.  When all the connectors are deleted, I'm curious as to whether that would trigger the provisioning code to fire and perhaps the connector space was quietly repopulated behind your delete with a whole new set of objects ready for export. Perhaps the deltas that you ran afterward caused some pending exports to be queued up, instead.

    If your provisioning code assigns a temporary GUID as the anchor, but the Oracle system assigns a real one that gets imported and replaces the random GUID, that might explain how the description of the error you found came to be applicable.  You had at least some pending exports in the connector space with random GUIDs, and you imported all the objects from Oracle with real anchor values.  For awhile there were duplicates and nothing really tied them together.  A full sync should clean that up.

     

    Chris,

     

    Here's more detail about our configuration for the MA in question:

     

    1) It's an Oracle MA

    2) For Anchor, we have designated a field in the Oracle table, say, DSTNM as the Anchor for the MA.  In our Provision(), when a new connector to the Oracle table is created, the code in the MV Extension populates something like "csentry.DN = mventry("nameAttr")", and DSTNM is flowed out to from the same MV attribute, "nameAttr".

    3) The table has an auto-incrementing (via a trigger in the table) field, PersonId.

    4) All flows in the MA are export flows, except there's one import flow, from the [Oracle] PersonId ==> [MV] PersonId.

     

    So, with the above, I'm still kind of unclear about what "the distinguished name" attribute is, in this case, since we don't get to designate any such thing in the MA configuration.  Is this "distinguished name" attribute which is referred to in the various descriptions of the "completed-transient-objects" error something that gets automatically chosen by the MA itself?

     

    For your questions:

     

    - No, provisioning was not disabled when we deleted the CS data.  When we do a CS delete, ILM doesn't show anything in the run history (I've always wished that ILM would at least add an entry in the run history when a CS is deleted, but that's a different story).  Plus, after we did the CS delete, I did a search on the CS, and it showed "0" objects, so I don't think that the Provision() code was called when the CS was deleted.  That would have been pretty "scary" if it does something like that :)...

    - From earlier threads here, what we do with the Oracle MA CSes in cases like this is that we always (a) delete the CS, then (b) do a Full Import, before doing anything else with the MA (esp. any synchs), if it's an Oracle-type MA.  Per earlier threads, this is because if don't do the Full Import before any synchs, the MA ends up creating new/duplicate rows in the Oracle table the next time an Export is run.

    - For your last paragraph:  No, the provisioning code doesn't assign a temporary GUID for the Anchor.  Per what I described above, when the Provision is done, it does something like:

     

    csentry.DN = mventry("nameAttr").value

     

    The MV "nameAttr" typically has a string that is similar to a samAccountName, i.e., a short user name.

     

     

    I did more testing with this MA today:

     

    - I searched the CS after adding <transient> to the displayed columns, and found that there are ~35 objects in the CS that are transient.

    - I tried:

         o Full Import - Didn't change anything in the CS

         o Full Synch - Didn't change anything in the CS

         o Delete CS, Full Import, then Full Synch - Didn't change anything in the CS

     

    Man, those "transient" objects are REALLY stubborn :(!!

     

    On a side note, I did some sqlplus queries on the Oracle table, and indeed, found that in the table itself, the users that are showing as transient in the MA have multiple "duplicate rows".

     

    Although we won't be allowed to drop all the rows in this table (because it contains data that we don't flow from ILM), I did do a test, where I manually deleted both rows of one user that were duplicated.  I then did a Full Import, and then searched the CS, and there was one less transient object.

     

    I'm probably being repetitive, but I know what the Anchor is (that DSTNM field in the Oracle table), but I don't know what "the distinguished name" attribute is in this MA, and it seems that until knowing which attribute that is, it'll be hard to figure out how to try to eliminate this problem.  For example, if I knew which field that was, maybe I could use sqlplus to push in a value, or something like that?

     

    At this point, it seems we're kind of stuck with these transient objects, since we can't delete the rows in the table?

     

    Jim

    Thursday, July 07, 2011 11:49 PM
  • Jim,

    For the dn in your provisioning, you should just assign a GUID using something like:

    csentry.DN = ManagementAgent.EscapeDNComponent(System.Guid.NewGuid().ToString)

    When you do this, you don't need to supply the real anchor attribute for your Oracle object. On import, as you have an anchor that is created by Oracle, it will imported and correclty assigned.

    You'll find some example in the developer help that comes with ILM (search for "Connected Data Sources that Generate the Anchor Attributes" to find the article).

    At this stage, I would clear out the Oracle CS again after disabling provisioning. I would then import the Oracle CS and make all objects join existing MV objects. After you are sure everything is correclty matched up, you can then re-enable provisioning.

    Paul.


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM
    Friday, July 08, 2011 9:26 AM
  • Jim,

    For the dn in your provisioning, you should just assign a GUID using something like:

    csentry.DN = ManagementAgent.EscapeDNComponent(System.Guid.NewGuid().ToString)

    When you do this, you don't need to supply the real anchor attribute for your Oracle object. On import, as you have an anchor that is created by Oracle, it will imported and correclty assigned.

    You'll find some example in the developer help that comes with ILM (search for "Connected Data Sources that Generate the Anchor Attributes" to find the article).

    At this stage, I would clear out the Oracle CS again after disabling provisioning. I would then import the Oracle CS and make all objects join existing MV objects. After you are sure everything is correclty matched up, you can then re-enable provisioning.

    Paul.


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM

    Hi Paul,

     

    I will try the steps you described in your last paragraph today.

     

    But, I wanted to clarify something I said earlier.  In the Oracle table, only that PersonId field is a auto-incrementing automatically created number created by a trigger in the database.  The DSTNM field in the table is just a VARCHAR field, and the MA configuration has the Anchor set to the DSTNM field.  I'm saying this because the Anchor (the DSTNM) is not "created by Oracle", but rather, it is set in the MV Extension code from a MV attribute.

    In the MA Attribute Flow, we do have an import flow on the PersonId field (to [MV] personid), and the flow also has an export flow ([MV] personid ==> [Oracle] PersonId), but I don't think that we actually do anything with that attribute in our code.

    Jim


    Friday, July 08, 2011 11:56 AM
  • Jim,

    I see the issue.

    You shouldn't assign the DN at all in this type of scenario. You only set the value of the anchor attribute itself in your provisioning code. So, forget about the article I mentioned, this is really only applicable when the anchor is created by Oracle, in which case you cannot set the anchor because you don't have it and therefore you supply a DN to allow created of your CS object.

    The last paragraph I mentioned above, I would still execute (clear the Oracle CS ...)

    Paul


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM
    Friday, July 08, 2011 1:55 PM
  • Jim,

    I see the issue.

    You shouldn't assign the DN at all in this type of scenario. You only set the value of the anchor attribute itself in your provisioning code. So, forget about the article I mentioned, this is really only applicable when the anchor is created by Oracle, in which case you cannot set the anchor because you don't have it and therefore you supply a DN to allow created of your CS object.

    The last paragraph I mentioned above, I would still execute (clear the Oracle CS ...)

    Paul


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM


    Paul,

     

    I wanted to recap what we have, and then confirm my understanding of what you said in the 2nd paragraph above:

    - In the Oracle MA configuration, we have the DSTNM field in the Oracle table designated as the MA Anchor.

    - In the MV Extension part that provisions to the Oracle, we have something like:

    If connectorCount = 0 Then
      rdn = mventry("someMVattribute")
      dn = oracleMA.EscapeDNAomponent(rdn)
      csentry = oracleMA.Connectors.StartnewConnector("person")
      .
      .
      csentry.DN = dn
      csentry("DSTNM").Value = dn.ToString
      .
      .
    
    


    When you said "You shouldn't assign the DN at all", did you mean that we should not have that line:

      csentry.DN = dn


    Are you also saying/thinking that that (having that "csentry.DN=dn") line is what is creating those transient objects in the Oracle CS?

     

    Jim

    Monday, July 11, 2011 7:07 PM
  • Probably yes, Jim. I have never gone so far to write a specific dn (except a GUID as described above) to an MA different from an LDAP-style MA.

    You should indeed not have the line containing csentry.DN = dn.

    If the DSTNM column is the unique index (or anchor in ILM-speak) of your table, then having the line csentry("DSTNM").value = mventry("someMVattribute").value is sufficient (instead of the value method, you can also use the StringValue method).

    Did you somehow copy the code you currently have from your AD MA?

    Paul.


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM
    Monday, July 11, 2011 7:23 PM
  • Probably yes, Jim. I have never gone so far to write a specific dn (except a GUID as described above) to an MA different from an LDAP-style MA.

    You should indeed not have the line containing csentry.DN = dn.

    If the DSTNM column is the unique index (or anchor in ILM-speak) of your table, then having the line csentry("DSTNM").value = mventry("someMVattribute").value is sufficient (instead of the value method, you can also use the StringValue method).

    Did you somehow copy the code you currently have from your AD MA?

    Paul.


    Paul Loonen (Avanade) | MCM: Directory 2008 | MVP: ILM


    Hi,

     

    Re. your last question/sentence:  No, I didn't accidentally copy the code from the AD MA but it may be that one of my predecessors did.  Actually, this code has been in-place in the MV Extension for probably 4+ years (way before my time).

     

    Jim

    Monday, July 11, 2011 8:34 PM
  • Hi,

    So I'm trying what Paul and Chris (earlier) suggested, i.e.:

     

    - Disable provisioning

    - Clear Oracle CS

    - Do Full Import

    I'm searching the Oracle MA CS as the import is running, and I already see user objects that are marked "<transient>" in the CS.

    In other words, the user objects in the Oracle CS are being marked as <transient> during the Full Import run, and not by any kind of synch-type run.

    Also, since this time, I ran the Full Import with the Provisioning disabled, it doesn't appear that new objects are being created because of the CS delete operation.

    So, it looks like I'm still stuck with these <transient> objects :(...

    Jim

     

    Monday, July 11, 2011 9:12 PM
  • Hi,

    So I'm trying what Paul and Chris (earlier) suggested, i.e.:

     

    - Disable provisioning

    - Clear Oracle CS

    - Do Full Import

    I'm searching the Oracle MA CS as the import is running, and I already see user objects that are marked "<transient>" in the CS.

    In other words, the user objects in the Oracle CS are being marked as <transient> during the Full Import run, and not by any kind of synch-type run.

    Also, since this time, I ran the Full Import with the Provisioning disabled, it doesn't appear that new objects are being created because of the CS delete operation.

    So, it looks like I'm still stuck with these <transient> objects :(...

    Jim

     

    Hi,

     

    I've been thinking about this some more :(...

     

    My impression from this discussion, and from the testing I did, is that the MA itself is populating the <dn> attribute in the Oracle MA CS when it does the import.

     

    Based on the description of what a "transient object" is (more than one object with the same "anchor" but with different "distinguishedname" (aka <dn>) attributes IN THE CS, I think that the reason that we're getting some small number (~35) is because of the order of the duplicate rows in the actual Oracle table, and the order that the Oracle MA is bringing them into the CS.

     

    If that's the case, then it looks like the only way to eliminate the transient objects will be to:

     

    - Find the "duplicate" rows in the actual Oracle table

    - Delete one of those rows

    - Clear the Oracle MA CS

    - Run Full Import, then 

    - See if I get the transient objects still.

    I don't yet know what the <dn> attribute values are.  I'm going to try to some CS searches tomorrow with the <dn> and DSTNM attribute columns selected for display, and will try to see what those look like, and am expecting to see two objects in the CS that have the same DSTNM, but different <dn>.

     

    Will post back.

     

    Jim

     

    Tuesday, July 12, 2011 5:31 AM

  • Hi,

    So I'm trying what Paul and Chris (earlier) suggested, i.e.:

     

    - Disable provisioning

    - Clear Oracle CS

    - Do Full Import

    I'm searching the Oracle MA CS as the import is running, and I already see user objects that are marked "<transient>" in the CS.

    In other words, the user objects in the Oracle CS are being marked as <transient> during the Full Import run, and not by any kind of synch-type run.

    Also, since this time, I ran the Full Import with the Provisioning disabled, it doesn't appear that new objects are being created because of the CS delete operation.

    So, it looks like I'm still stuck with these <transient> objects :(...

    Jim

     

    Hi,

     

    I've been thinking about this some more :(...

     

    My impression from this discussion, and from the testing I did, is that the MA itself is populating the <dn> attribute in the Oracle MA CS when it does the import.

     

    Based on the description of what a "transient object" is (more than one object with the same "anchor" but with different "distinguishedname" (aka <dn>) attributes IN THE CS, I think that the reason that we're getting some small number (~35) is because of the order of the duplicate rows in the actual Oracle table, and the order that the Oracle MA is bringing them into the CS.

     

    If that's the case, then it looks like the only way to eliminate the transient objects will be to:

     

    - Find the "duplicate" rows in the actual Oracle table

    - Delete one of those rows

    - Clear the Oracle MA CS

    - Run Full Import, then 

    - See if I get the transient objects still.

    I don't yet know what the <dn> attribute values are.  I'm going to try to some CS searches tomorrow with the <dn> and DSTNM attribute columns selected for display, and will try to see what those look like, and am expecting to see two objects in the CS that have the same DSTNM, but different <dn>.

     

    Will post back.

     

    Jim

     

    Hi,

     

    Actually, changing what I said above:  I don't think that there's an easy way to search for the dupe users in the CS, because we don't know what the RDN would be that we'd be looking for, since we don't know what the <dn> that the MA is assigning is :(...

     

    Jim

    Tuesday, July 12, 2011 5:35 AM
  • We use an Oracle MA as the authoritative 'source' for our person data, using the company assigned "EMPLOYEE_ID" (a 9 digit number) as the "anchor" attribute for the MA, ILM seems to automatically flow csentry(<dn>) <- EMPLOYEE_ID -- I certainly don't have a data flow defined for assigning "EMPLOYEE_ID" to "<dn>".  In other words, the DN for the Oracle MA connector space becomes whatever you have assigned as the 'Anchor' for the MA.  Whatever you use for the 'Anchor' value in your Oracle MA should be something that is assured not only to be a unique value, but one that will not change.

    Ed


    Ed Bell - Specialist, Network Services, Convergys
    Wednesday, July 13, 2011 3:13 PM