Certification Audit Logics

Audit Results are created for each audit executed on records that matched the selection (see matching conditions in Initial Certification Audit Run).

The result's state can be certified or failed. A Follow-On Task is created for each ‘failed’ Audit Result record.

Initial Certification Audit Run

Validating specific CMDB tables for anomalies.

The Service Operation CMDB Compliance Audit starts to run on the CI Relationship table (cmdb_rel_ci), but only on specific records with matching conditions as follows:

• Parent AND child CI classes are supported classes, including extended tables as follows:
  slot (cmdb_ci_container_slot), subslot (cmdb_ci_container_subslot), card (cmdb_ci_interface_card), interface (cmdb_ci_ni_interface), telco equipment (cmdb_ci_ni_telco_equipment), IP switch (cmdb_ci_ip_switch), and IP router (cmdb_ci_ip_router).

  Note:

  These properties can be configured via sn_tsom_core.audit.* system properties.
• Parent OR child is created or updated by Discovery (discovery_source = SG-Altiplano, ServiceNow). Audit uses its own filter mechanism that applies on equipment Cis. Default filter is “discovery_source CONTAINS TSOM"
• Parent AND child life-cycle Stage is Operational.
• The CI Relationship Type is Contains::Contained By.
  Note:

  This property can be configured in the sn_tsom_core.audit.relationship_types system property.

Subsequent Certification Audit Runs

Follows the same logic as the Initial Certification Audit Run, but with the following additional matching selection criteria:

The timestamp in the Updated field in the CI Relationship table, or the timestamp in the Updated field of a Parent CI, or the timestamp in the Updated field of child CIs is later than the timestamp in the ‘Last run date’ field in the Telecom Discrepancy Audit (this means that there was a change since the last audit).