Captain
Captain
185 views

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):
<Appt><Appointment>
<OSUapptPstnNbr>000123456</OSUapptPstnNbr>
<OSUapptActionDt>12/28/2020</OSUapptActionDt>
<OSUapptJobcode>3180</OSUapptJobcode>
<OSUjobcdJobTitle>Instructor - Practice</OSUjobcdJobTitle>
<OSUpstnWorkTitle>Instructor - Practice</OSUpstnWorkTitle>
<OSUapptRecordNum>0</OSUapptRecordNum>
<OSUapptDeptID>CC1234</OSUapptDeptID>
<OSUdeptDescription>Nursing | College Administration</OSUdeptDescription>
<OSUdeptCollege>Nursing</OSUdeptCollege>
<OSUdisasterDesig>Standby</OSUdisasterDesig>
<OSUapptLoc>275</OSUapptLoc>
<OSUlocBuilding>Newton Hall (0275)</OSUlocBuilding>
<OSUdeptIsMedCenter>Y</OSUdeptIsMedCenter>
<SA>1585 Neil Ave</SA>
<PhysicalDeliveryOfficeName>Columbus</PhysicalDeliveryOfficeName>
<S>Ohio</S>
<postalCode>43210-1216</postalCode>
<OSUcampCountry>United States of America</OSUcampCountry>
<OSUcampus>Columbus_Campus</OSUcampus>
<OSUapptEmplStatus>A</OSUapptEmplStatus>
<OSUapptEffdt>10/19/2016</OSUapptEffdt>
<OSUrelationshipStartDate>10/19/2016</OSUrelationshipStartDate>
<OSUapptRegTemp>M</OSUapptRegTemp>
<OSUapptClassIndc>F</OSUapptClassIndc>
<OSUapptStdHours>40</OSUapptStdHours>
<OSUsupervisorID>300001523</OSUsupervisorID>
</Appointment></Appt>

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:

<modify-attr attr-name="OSUapptEmplStatus">
<add-value>
<value type="string">A</value>
</add-value>
</modify-attr>
<modify-attr attr-name="OSUapptEffdt">
<add-value>
<value type="time">1591768800</value>
</add-value>
</modify-attr>
<modify-attr attr-name="OSUapptClassIndc">
<remove-all-values/>
<add-value>
<value type="string">S</value>
</add-value>
</modify-attr>

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)
OSUapptClassIndc
OSUdeptCollege
OSUdeptDescription
OSUapptRecordNum

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.  

 

0 Likes
5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

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?

Captain
Captain

The only mandatory attributes are the CN.  

0 Likes
Commodore
Commodore

Cn is an attribute you were asked about the object classes these missing attributes are in. Are these present?

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.

Best regards
Michiel Los
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

>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.

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?
Captain
Captain

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.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.