I have requirement in SM7.11 where in my clients wants to track updates made in any field of a configuration item to be saved somewhere .
We have around 10000 CI, we need to keep track of all the updates made to any of the fields of this 10000 CI . EX
If i change serial no of a Ci its should be saved that operator X has changed the value of serial.no of CI 10. If i change HDD Size of a Ci its should be saved that operator X has changed the value of hdd of CI 25.
Regards Praveen V
-- Say " Cheers! " by clicking Kudos Star on the left .
Basicly you can set an audit for the device table and track on all the requered fileds in it. Though the view of the result of Audit is not very nice. Try it and you will understand is this enough for you or not.
First, as has been said, using the audit table and auditspecs is the easiest way to track who updates which attributes at what time. There's very little code involved.
The other fields you mentioned - the historic changes, pending attribute changes, etc - that is specifically for an integration with Change Management and the uCMDB. When the uCMDB pushes data into Service Manager, it creates records in the dataModEvent table when an attribute's value in the uCMDB is different from that value in HPSM. On Change records, users can perform a similar function and explicitly call out which attributes they are changing on a CI, and what the new values should be. When the uCMDB push happens, the system validates these new values and updates the CI. So unless you're planning to implement an integration with the uCMDB, that feature isn't going to help you much.
So, back to auditing.
There are two ways to set up auditing. One is via a trigger record, and one is via a formatctrl record. I forget how it's set up OOB and I no longer have easy access to an OOB 7.x system, so here's both ways. Check which is set up, or use whichever you'd like.
On the formatctrl record for the CI type you're tracking, or on the 'device' master formatctrl record itself, in the subroutines section, there should be something like this:
The other way is through a trigger record. Use Database Manager and search for the 'triggers' table. On the device table (or the specific joinXXX table) make a record like this:
Trigger Name: after.update.device.audit
Table Name: device
Trigger Type: 4 - After Update
Either one of those will trigger a call out to the RAD application involved with generating your audit records. Once that is set up, you simply have to create an auditspec record for the table, listing out what are the fields to monitor. Use Database Manager and search for the 'auditspec' table. For example, to trigger an audit record for the joincomputer records to track changes to serial.no. and subtype, make a record like the following:
Unique A: logical.name
Field Name -
Once that is done, any time the record is saved, the system checks (either via formatctrl or trigger record) the auditspecs record for this file, and generates an audit record if the values in those fields have changed.
As Vadim stated, viewing the audit data isn't easy. The format of the record list doesn't display everything you'd like it to, and you kind of have to dig to get the data you want. So, I built a little something that makes it easier.
See attachment. Comments and questions are welcome.