Configuring auditing for a class
You can use the BMC Atrium CMDB Class Manager to configure auditing for a class and specify which attributes in that class are included in an audit.
Creating or modifying classes process
Auditing changes to instance data
You can keep a history of changes to instance data, which is called auditing. You enable auditing on a per-class basis, and you select which attributes trigger an audit and which are written as a result. An audit is triggered when an instance is created or deleted or when the value of one or more selected attributes changes as the result of an instance being modified. The new value must be different from the existing value to trigger an audit. Copying the same attribute value does not trigger an audit. For example, during reconciliation, a merge activity replaces the existing 348981 value for the
SerialNumber attribute with 348981. This does not change the value and does not trigger an audit.
- By default, no classes in the data model are configured for auditing. Select an auditing strategy wisely, limiting class auditing to business-critical situations. As the number of classes with auditing increases, system performance might slow.
- Auditing a class does not invoke auditing of an attribute. If you want to enable auditing in the class manager but have no attributes configured then audit records will not be generated. You must either enable auditing for an attribute on the class that owns the attribute or on the class itself, and not on both.
BMC_BaseElement being a master class, will not have any class level auditing enabled on it. However, attribute level auditing will be enabled for BMC_BaseElement and then enabled at a specific class. For example BMC_ComputerSystem class would be enabled for attribute auditing that is set to be audited at the BMC_BaseElement class.
BMC_BaseElement is not a data container and has no relationship mapping, hence auditing BMC_BaseElement may not be of much use. You can enable auditing at a specific class level.
For more information, see:
- Audit types in classes
- Attribute audit options in classes
- Types of auditing for detailed information about auditing, including recommendations
- Viewing instance history in BMC Atrium Explorer
To configure auditing for a class
- In the Class Manager, right-click on the class to open a class for editing.
- In the General tab of the CI Class dialog box, expand the Auditing section.
- In the Audit Type field, select Copy or Log, as described in Audit types in classes.
- If you selected Log auditing, enter the name of the log form in the Audit Log Form field, or accept the default form name, CMDB:DefaultAuditLog.
This form stores log entries for this class. If the form that you specify does not exist, it is created automatically.
- In the Qualification field, type a qualification to specify which instances of the class are audited.
For example, the following qualification specifies that only instances in the BMC.ASSET dataset are audited:
'DatasetId' = "BMC.ASSET"
If you want all instances to be audited when they are created and deleted and when a selected attribute is changed, leave this field blank.
- Click the Attributes tab.
- Select an attribute that you want to be included in audits and click Edit.
- From the Audit Option menu, select an option for this attribute, as described in Attribute audit options in classes.
- In the Attribute dialog box, click OK.
- Repeat step 7 through step 9 for each attribute that should be included in audits.
- In the Class dialog box, click OK.
- In the confirmation dialog box, click OK.
Audit types in classes
You can specify the following types of audit when modifying a class:
- Copy — Creates a copy of each audited instance. When you enable Copy auditing for a class, each BMC Remedy AR System form pertaining to that class is duplicated to create audit forms that hold audited instances. This includes forms from superclasses, because they hold data for instances of their subclasses.
- Log — Creates an entry in a log form that stores all attribute values from the audited instance in one field. When you enable Log auditing for a class, you specify the name of the log form to use. If this form does not already exist, it is created automatically. You can use the same log form with multiple classes.
You cannot use Log auditing above Copy auditing in the inheritance tree. This means that if you already have Copy auditing enabled for a class, you cannot enable Log auditing for any of its superclasses, and if you already have Log auditing enabled for a class you cannot enable Copy auditing for any of its subclasses. This is due to the structure of audit forms. For more information about audit forms, see Types of auditing.
Attribute audit options in classes
Using the following attribute audit options to specify which attributes trigger an audit and which are written during an audit:
- None — Changes to this attribute do not trigger an audit. NULL is written to this field in the audit form in a Copy audit, and nothing is written to the Log field in a Log audit. This option is the default.
- Audit — When the value of this attribute changes, an audit is triggered and the attribute value is written to the audit form or log form. When another attribute triggers an audit, this attribute is not written.
- Copy — Changes to this attribute do not trigger an audit, but the attribute value is written to the audit form or log form when another attribute triggers an audit.
- Audit & Copy — When the value of this attribute changes, an audit is triggered. This attribute value is written to the audit form or log form in any audit, regardless of whether its value changed.
As long as there is at least one
Audit & Copy attribute for a class, a Create or Delete operation triggers an audit regardless of the values of such attributes.
Audit & Copy attributes are all written during such an audit.