Enriching the event

The event can be enriched with data from BMC PATROL, from the BMC Atrium CMDB, or from both. The module first determines whether the event is a PATROL event. If yes, the module launches a subworkflow, Get PATROL Annotation Data, to connect with the host from which the event originated. See the following figure:

Get PATROL Annotation subworkflow



The Get PATROL Annotation subworkflow runs a series of checks against the PATROL parameter values to retrieve additional diagnostic information from the PATROL agent event that originally generated the triggering event. (For setup guidelines, see Configuring the PATROL Agent to include annotation data.)

With the newly obtained PATROL diagnostic information now in message format, the workflow continues by updating the original event definition with the new information.

The Get Configuration Item subworkflow checks whether the BMC Atrium CMDB is enabled, as shown in the following figure:

Get configuration item



If yes, this subworkflow tries to match the reconciliation ID contained in the mc_smc_id slot of the incoming event with the corresponding configuration item in the BMC Atrium CMDB. If it finds a matching configuration item in the BMC Atrium CMDB, it creates an incident in the incident management system and associates the incident with the configuration item in the BMC Atrium CMDB. The event is enriched with the incident and configuration item data.

If the mc_smc_id slot of the incoming event is empty or if the configuration item cannot be found in the BMC Atrium CMDB, the subworkflow creates or updates the incident. The event is updated with the incident information and with the message that the configuration item is not found.

Processing incidents

Incident processing takes as inputs the triage results, the workflow type, and the event data. As outputs, it generates incident status information and enhanced event data. The Incident Management subworkflow enriches an existing incident--the incident ID being contained in the event definition--or creates a new incident consisting of the following details

• Incident ID
• Event type
• Configuration item to be associated with the incident

Incident processing takes two paths. If the incident is automatically created by Integration for BMC Remedy Service Desk and incorporated into the event, then BMC Atrium Orchestrator obtains the incident ID from the event. If the event management system is not integrated with BMC Remedy Service Desk, BMC Atrium Orchestrator creates the incident and adds the incident ID to the event action result.

The Incident Management subworkflow runs checks whether the incident management system is integrated with Integration for BMC Remedy Service Desk. If yes, it extracts the Integration for BMC Remedy Service Desk incident ID from the incoming event and verifies whether the incident ID resides in the incident management system.

If the incident and event are already integrated through the Integration for BMC Remedy Service Desk, the workflow uses an event query to extract the incident ID from the original event and to add it to the triage data in the workflow.

Otherwise, the workflow tries to extract the incident ID from the event's Action Result mc_parameter slot. See the following figure:

Incident processing



If the incident ID cannot be found, then the workflow creates a new incident. If the incident ID is found, but the incident has been closed, the workflow also creates a new incident in the incident management system. When creating a new incident, this subworkflow uses the following parameters to capture the required BMC Remedy incident values:

• event-summary (from event data)
• workflow type (from event data)
• first name (from Query User Information subworkflow)
• last name (from Query User Information subworkflow)
• default status (from the Incident_Management module)
• default service type (from the Incident_Management module)
• default impact (from the Incident_Management module)
• default urgency (from the Incident_Management module)
• default source (from the Incident_Management module)
• CREATE (string value representing type of action)

default reported status reason (from the Incident_Management module)

• incident instance id (from Extract Incident Template ID subworkflow)

If the workflow retrieves an open incident, it updates the triage data of the incident description in the incident management system. If the BMC Atrium CMDB is enabled and integrated with the BMC IT Service Management system, it also associates the configuration item from the BMC Atrium CMDB to the incident.

The enrichment of the incident ID and its association with the configuration item mark the end of the triage phase of this process. The workflows have sorted and processed the incoming event, adding requisite information to enable remediation processing: configuration item details, PATROL annotation data, and event and incident enrichment.

If it is a triage-only workflow, the process is over.

The remediation phase consists of change management, in which a change request is created and associated with the incident and configuration item, and the actual remediation, in which specific remediation commands are initiated and performed via tasks.

Processing change requests

The Change Management subworkflow takes as input the host connection details from the credential store module, the triage status (if available), the workflow type, and the event information. It generates the following output: change ID, action results, configuration items, and task IDs

The Change Management subworkflow first checks whether the change is an emergency or a normal change. It then launches the Create Change subworkflow, as depicted in the following figure:

Create change process



Create change process (continued)



Create change process (continued)



The Create Change subworkflow extracts the change template ID. If it retrieves the template ID, it launches the Get Configuration Item subworkflow and searches for the CI details. If it retrieves the CI details, it forwards them to the Create Change subworkflow to create a new change.

After obtaining the configuration item details and assigning the change values, the Create Change subworkflow creates the change ticket. It uses the following parameters to contain the change information:

• change request type (from event data)
• event summary (from event data)
• workflow type
• first name (from Query User Information subworkflow)
• last name (from Query User Information subworkflow)
• change default status (from Change_Management module)
• change default impact (from Change_Management module)
• urgency mapping (from Runbook_Defaults module)
• change default risk level (from Change_Management module)
• dataset id (from configuration items/dataset-id)
• CI name (from configuration items/name)
• reconciliation-id (from configuration items/reconciliation-id)
• CREATE (string value representing type of action)
• company (from Query User Information subworkflow)
• company location (from Query User Information subworkflow)
• change timings (from Change_Management module)
• change default change type (from Change_Management module)
• change instance id (from Extract Change Template ID subworkflow)

After creating the change ticket, the Create Change subworkflow associates any related incident ID with the change ticket information. By using the change ID, it retrieves the tasks associated with this change from the Task Management system. It updates the task with the details of this particular change. The tasks identify the remediation actions. When the remediation is complete, the task is closed. The corresponding change, incident, and event records are updated.