Some attributes are not writing to a custom object
The problem I am experiencing is that we have a policy that is creating a new object (using a custom class called OSUappointment). In the log file, we can see all of the attributes being created (using set destination commands). however, randomly, some attributes are not written to the new object.
For example, we have a userID : IDM801803765
An attribute on the userID (OSUflag-WorkdayAppt) is a blob looks similar to this (an XML blob, if you will):
<OSUjobcdJobTitle>Instructor - Practice</OSUjobcdJobTitle>
<OSUpstnWorkTitle>Instructor - Practice</OSUpstnWorkTitle>
<OSUdeptDescription>Nursing | College Administration</OSUdeptDescription>
<OSUlocBuilding>Newton Hall (0275)</OSUlocBuilding>
<SA>1585 Neil Ave</SA>
<OSUcampCountry>United States of America</OSUcampCountry>
A policy in the conversion driver, OSU-sub-ctp-ProcessAppointments, processes this blob. It takes each element of the blob and converts it into a set destination command, so that the document in the driver look like this:
This is just a slice of the entire document. All of the elements in the blob above will be in the document along with several other attributes (OSUidmID, OSUPSemplId, etc...). The file novelTicket.txt is a copy of the log file where the userID, IDM801803765, comes in with the flag OSUflag-WorkdayAppt changing.
In this case, the object being created is of objectClass 'OSUappointment' and the name of the object is 500016140-00086267-Appt. the object itself is a direct create, while the rest of the attributes are created as a "set Destination Attribute Value" (do-set-dest-attr-value). From what I can tell of the log file, all of the attribute go through and are added to the new object... but, randomly, some attribute never seem to make it to the object.
Typically, the follow attribute never make it to the new object (500016140-00086267-Appt)
There are others, but I am going from memory, so I cannot tell for sure what the other are (the above are for sure, though).
We have looked at other drivers that have one or more of the 4 attribute and never make it to see of any of these drives are deleting the attributes, but nothing is deleting these attributes. AND, like I mentioned above, the attributes are random on whether these are on the new object or not. Mostly, these are on the object, but, again, it seems to be random.
Has anyone experienced this before? Does anyone have any ideas what could be causing this? The attached file is a partial log containing the log where one object does not get all of the attributes in the document.
I believe, that you use OSUappointment AUX class
In many cases engine "add" missing AUX class on the fly, but I also see the situation, that it doesn't happen (for unknown reason).
I prefer to add required AUX class names to the objectClass attribute during object creation and didn't take a chance...
Could you check, if you have all required object classes in the objects, that you miss attributes?
You can add a filter that listen on the attributes you are missing and see them created, modified and deleted. Maybe even run this driver alone and see that the attributes are available after your creation process.
These "some" attributes related to OSUappointment class.
Is it AUX or Effective class?
When these attributes didn't survive, do you see proper AUX class in the ObjectClass attribute?
The only two classes that I see are (complete and non-complete objects):
- OSUappointment (Structural)
- Top (Structural)
The "some" attributes are in the OSUappointment class... some of those attributes are in other classes as well.
>An attribute on the userID (OSUflag-WorkdayAppt) is a blob looks similar to this (an XML blob, if you will):
In your current response you mentioned Structural (effective) class.
I understand that you have special OSUappointment objects. Now you have to "link" this OSUappointment object from user object. Is it right?
If it true, I expect to see that your user object also has AUX class, that allow you to add to the user object other attributes.
This is example of ObjectClasses from my typical user object. (sensitive info masked with XXX)
XXXPerson and XXXProvision AUX classes allow to add to user object our custom attributes.
@friedman16, your policy OSU-sub-ctp-ProcessAppointment is creating the new object and attributes that you are looking for, but it is generating multiple events within one document as well as the direct commands. Looking at the example trace you posted I see the following returned after that policy processes the input document:
- direct command 1: add class-name="OSUappointment" dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- direct command 2: add-association dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- event #1: modify class-name="OSUappointment" dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- event #2: modify class-name="User" src-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event #3: modify class-name="OSUappointment" dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- event #4: modify class-name="User" src-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event#5: modify class-name="OSUappointment" dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- event #6: modify class-name="User" src-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event #7: modify dest-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event #8: modify class-name="OSUappointment" dest-dn="osu\vault\resources\Appointment\500016140-00086267-Appt"
- event #9: modify class-name="User" src-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event #10: modify class-name="User" dest-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
- event #11: modify dest-dn="osu\vault\users\IDM801803765"
- event #12: modify class-name="User" src-dn="\IDVAULT-PROD\osu\vault\users\IDM801803765"
In summary it generate 2 Direct Commands, 4 Modify events for the OSUappointment obect and 8 Modify events for the User object. All of that from the three events that went into the Policy. (Note: those three input Modify User events were generated from the original single Modify User event the driver received.) The three input events match output event #6, event #11, and event #12. The entire processing in this policy occurs from only the first input event, or what is now output event #6. As a result of bouncing back and forth creating and modifying the OSUappointment and the User object, that one policy has generated 9 more events before and after what is now event #6. All for two separate objects in your Tree.
If the attributes not written to the OSUappointment object include any of:
Physical Delivery Office Name
Those are all set as part of event #5. In the trace provided, there are no errors returned from that event. Due to the four different events modifying this object, after it is created, I wonder if there is some sort of timing or race condition that has occurred with synchronization between replica servers or other drivers. Without more debugging it is hard to say for sure.
Some thoughts on tracking this down further.
- Review and rework the current logic used to update the user object from the original modify event. There should be no need to create additional separate modify events for that object. You can generally avoid extra events by careful use of references to the current user object. Rather than referencing a local variable with the User DN, use the "current object" property so that the attribute modify is applied to the original event instead of having a new modify event generated.
- Review and rework the current logic that uses action to set attributes before or after the current event being processed. These can generate additional modify events that could otherwise be included in the current "user" modify or the new object being modified. Normally a new object modification would follow the current event being processed. Using 'before' and 'after' will usually result in new events added to the document being processed.
- Consider changing the direct add for the new OSUappointment object to an inline Add event that is after the user event. Then all the set attribute actions for the attributes will become add attributes to the following event and included with the add event to create the new object. This would be a cleaner process and event output. Properly done you should end up with just the existing User modify and a single new object Add event.
- Consider implementing the WatchDog driver to track actual eDirectory events that the engine identifies. That may help identify if attribute updates are getting overwritten by some other action or driver. ( WatchDog Driver v 2.1.0, for IDM - simple reporting of eDirectory events ) You will need to add the specific classes and attributes you want to watch for in your environment to the WatchDog driver's Filter.
- Finally, have a close look at the original user event received by this loopback driver and how much of that really needs to loopback to "update" the existing user object. You can improve the processing and readability of your driver traces by removing attributes or even the original event if it is not required to "loopback" in full.
Hopefully the above is helpful in narrowing this issue down for you.