Absent Member.
Absent Member.

Driver Health stats and practices

Ok, first let me state that I'm well aware of the disappointingly little
functionality, usefulness, and minimalistic capabilities of the whole
driver health functionality in IDM. That being said I'm trying to make
the best of it, instead of custom writing a whole different replacement.
All the conditions around driver cache statistics (Driver in Cache
Overflow, Newest, Oldest, Total Size, Unprocessed Transactions) are
pretty straight forward and where it gets that data from is pretty
obvious (the driver cache). However, the cache statistics only apply to
the subscriber channel operations. A seemingly good reference for driver
health would seem to be Transactions History and Available History,
coupled with publisher heartbeats (triggered by the driver) and
subscriber heartbeats (submitted by the health job). Heartbeats are
necessary to ensure the driver is still functional even when there's no
synchronized object updates.
Here's my question though: does anyone know where the driver health job
gets the Transactions History and Available History data from? There are
attributes on the driver such as DirXML-PersistentData (on the driver)
along with DirXML-LastLogTime and DirXML-StatuLog attributes on the
publisher and subscriber channels which store event information but
based on my testing where I clear out or modify these attributes it's
apparent that these aren't the only things referenced by the driver
health job. Does anyone know where specifically driver health gets
Transaction History stats for conditions such "subscriber pre-output
transformations", "publisher command results", "publisher post input
transformations", etc?
Also, another thing I'm trying to do is force the driver health to fail
somehow if I detect certain conditions via policy. I'm doing this
primarily to detect loss of connection to the remote loader but there's
other times I'd like to trigger a degraded health condition as well.
This is another shortcoming of driver health in that the remote loader
could be completely down yet the publisher and subscriber heartbeats
work fine so driver health doesn't change from green. Perhaps someone
has other ideas for a way in that a down remote loader could trigger
degraded driver health. One thing to keep in mind with all this is that
in most IDM implementations just trying to rely on object updates
passing throught the driver is unreliable as there are many time periods
where there is little to no other activity. Another approach could be to
use a scripted utility to update specific objects in both the IDV and
connected systems to force driver traffic but this is pretty intrusive
and would like to avoid that if possible.
Thank you in advance for your thoughts, suggestions, and (hopefully)

pcook's Profile: https://forums.netiq.com/member.php?userid=429
View this thread: https://forums.netiq.com/showthread.php?t=47530

Labels (1)
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.