Integrate ITSI with BMC Remedy or BMC Helix

Integrate BMC Remedy or BMC Helix with IT Service Intelligence (ITSI) so you can create and update incidents in a Remedy or Helix system from ITSI, either through episode actions or through automated action rules in aggregation policies. Splunk ITSI has built-in integrations with the Remedy incident management system.

For an overview of all ticketing integrations available for ITSI, see Overview of episode ticketing integrations in ITSI.

Set up the integration

Perform the following steps to set up a basic integration with BMC Remedy or BMC Helix.

Prerequisites

Requirement	Description
BMC Remedy or BMC Helix	You must have BMC Remedy version 9.1 or later, or Helix versions 19.02, 20.02, 20.08 and 21.3.04.
ITSI role	You must have the itoa_admin or role to set up the integration with BMC Remedy or BMC Helix.
Splunk Add-on for BMC Remedy	You must have the Splunk Add-on for BMC Remedy version 2.0 or higher.

Install and configure the Splunk Add-on for BMC Remedy

Install the Splunk add-on for BMC Remedy on your Splunk instance. The add-on is required to send ITSI episodes to BMC Remedy or BMC Helix. Download the app from Splunkbase. See Set up the Splunk Add-on for BMC Remedy for set-up instructions.

To set up a bidirectional integration, you have to set up the Splunk Add-on for BMC Remedy configuration using Rest API. See Set up the Splunk Add-on for BMC Remedy Using Rest API.

Test the integration

You're now ready to start creating Remedy or Helix incidents from ITSI. Go to Alerts and Episodes in ITSI. Select and episode, then select the Actions menu. If you configured the integration correctly, the option to Create Remedy incident or Remedy Incident Integration using Rest API appears in the list of actions.

To create an incident, see Create a ticket in Remedy and follow the steps.

The default integration is unidirectional, so updates to the Remedy or Helix ticket aren't reflected in ITSI. To configure a bidirectional integration, see the next section.

Set up a bidirectional integration with BMC Remedy or BMC Helix

A bidirectional integration exchanges data between your ITSI instance and BMC Remedy or BMC Helix so that when you make an update to a Remedy ticket, the episode information is also updated within ITSI.

The following diagram shows how ITSI uses the Common Information Model (CIM) to update an episode:

Install the Common Information Model

ITSI leverages the Ticket Management data model in the Splunk Common Information Model (CIM) to normalize your data, using the same field names and event tags for equivalent events from your external ticketing system. See Ticket Management in the Common Information Model Add-on Manual.

This normalization enables you to create action rules for fields like priority, severity, and state without having to remember what they're called in BMC Remedy or Helix. See Overview of the Common Information Model for an introduction to the data models and information about the fields used.

Install the Common Information Model Add-on (CIM) from Splunkbase. To determine the correct version to install, see ITSI compatibility with other apps and add-ons in the Install and Upgrade Manual.

Configure the incident data input

Follow the below steps to configure the incident input in Splunk Add-on for BMC Remedy :

1. In Splunk Web, select the Splunk Add-on for BMC Remedy icon in the Apps sidebar.
2. Select the Inputs tab to navigate to the Splunk Add-on for BMC Remedy inputs configuration.
3. Select Create New Input to create a new input for incidents.
4. On the Add Remedy Input screen, enter information in the required fields:

   Field	Description
   Name	A unique name for the input.
   Account	The account configured using the Rest API.
   Interval	Data input collection interval
   Form to collect data from	The Remedy form name.
   Time field of the form	The default time field of forms is Last Modified Date.
   (Optional) Query Start Date	Start date from which the input needs to be collected.
   (Optional) Included Properties	Properties from the form that you want to include
   (Optional) Excluded Properties	Properties from the form that you want to exclude
   Qualification parameters	Provide qualification parameters as key-value pairs to fetch only selected data from the form. For example, 'key1'="value1"' AND key2'="value2"'. By default, no qualification parameters are applied.
   Index	The index where the input form data is indexed. The default index is main.

5. Select Add.
6. In the Status column select the toggle to enable the input.

Enable the BMC Remedy Bidirectional Ticketing correlation search

ITSI includes a BMC Remedy Bidirectional Ticketing correlation search that queries BMC Remedy or Helix events and sends an event to the itsi_tracked_alerts index each time an update is made. The correlation search also maps BMC Remedy or Helix fields to the CIM fields. For more information, see Ticket management in the Common Information Model Add-on Manual.

The BMC Remedy Bidirectional Ticketing correlation search is disabled by default. To enable it, perform the following steps:

1. From the ITSI main menu, go to Configuration > Correlation Searches.
2. Enable the BMC Remedy Bidirectional Ticketing correlation search.

(Optional) Specify the index to use for available fields

When you configure action rules in the next step, ITSI prepopulates all possible fields and values from the main index. If your data is in a different index, you can specify which index ITSI uses to populating these fields.

Open or create a local macros.conf file at $SPLUNK_HOME/etc/apps/SA-ITOA/local/.

Under the itsi_event_management_remedy_incidents stanza, specify the index in the definition setting. For example:

[itsi_event_management_remedy_incidents]
args =
definition = index=myspecialindex sourcetype=remedy:incident

(Optional) Specify the source indexes

If you have more than one source index for the ticketing event, update the BMC Remedy Bidirectional Ticketing correlation search and remove the first parameter so that it would look like this:

| `itsi_bmc_bidirectional_ticketing(90,itsi_tracked_alerts)`

Additionally, update the macro:

1. Open or create a local macros.conf file at $SPLUNK_HOME/etc/apps/SA-ITOA/local/.
2. Under the [itsi_event_management_remedy_incidents] stanza, specify the index in the definition setting. For example:

   [itsi_event_management_remedy_incidents]
   definition = sourcetype=remedy:incident index=myspecialindex1 or index=myspecialindex2
   

Configure action rules to sync BMC Remedy or BMC Helix ticket fields

To configure aggregation policy action rules that update fields in an ITSI episode when these fields change in Remedy or Helix, follow these steps:

1. From the ITSI main menu, select Configuration then Notable Event Aggregation Policies.
2. Open an existing custom notable event aggregation policy that creates episodes you'll send to Remedy.

   To use the bidirectional integration, create a custom aggregation policy instead of using the default aggregation policy.

3. Select the Action Rules tab.
4. Select Add Rule.
5. Select the Remedy incident associated with the episode has or the Helix incident associated with the episode has from the If drop-down list. This option only appears if you installed CIM and the Splunk Add-on for BMC Remedy or BMC Helix.
6. Create your aggregation policy so that each important change in Remedy or Helix has an action rule that updates the corresponding episode in ITSI. For example, if the Remedy incident associated with the episode has an In Progress status, then change the ITSI episode's status to Resolved.
7. Repeat these steps for each aggregation policy you want to integrate with Remedy.

Aggregation policies can't update closed episodes. However, action rules can update the Status, Severity and Owner fields of closed episodes for bidirectional events generated by BMC Remedy or BMC Helix. Action rules also can't make the episode active again, but only updates the fields.

Test the integration

To test the integration to make sure you configured the fields correctly follow these steps:

1. Go to Alerts and Episodes and link an episode created by the aggregation policy you just configured to an incident in Remedy. For steps to link a ticket, see Link a ticket.
2. Go to your Remedy or Helix incident and update one of the field values for which you created an action rule. For example, change the ticket status from New to In Progress.
3. Go back to Alerts and Episodes in ITSI and confirm that the corresponding field was updated within the episode. The field might take several minutes to update.

Bulk linking behavior with bidirectional ticketing

After you set up a bidirectional integration, any BMC Remedy or BMC Helix tickets linked through the link ticket action has bidirectional functionality enabled by default. For more information, see Link a ticket.

The following table describes how updates occur with a bidirectional integration:

Action	Behavior
Link multiple episodes to a single Remedy or Helix incident	The Remedy or Helix incident link is added to each episode. If you update the Remedy or Helix incident, the changes apply to each linked episode. If you update multiple episodes, the most recent change takes precedence. For example, if a Remedy or Helix incident is linked to episodes A and B, and you change A to Resolved and B to In Progress, the incident's final status is In Progress.
Link a single episode to multiple Remedy or Helix incidents	A link to each Remedy or Helix incident is added to the episode. If you update the episode, the changes apply to each linked Remedy or Helix incident. If you update multiple Remedy or Helix incidents, the most recent change takes precedence. For example, if an episode is linked to Remedy or Helix tickets A and B, and you change A to Resolved and B to In Progress, the episode's final status is In Progress.

Automatically create Remedy or Helix incidents

To configure aggregation policy action rules to create and update Remedy or Helix incidents when certain conditions are met. follow these steps:

1. Within ITSI, go to Configuration > Notable Event Aggregation Policies.
2. Open the aggregation policy you want to integrate with Remedy or Helix.
3. Go to the Action Rules tab.
4. Select Add Rule and configure trigger conditions for when to create a Remedy or Helix incident:
5. Select Configure to configure the following fields:

   Filed	Description
   Correlation ID	Unique Correlation ID for Remedy or Helix incident. You don't need to provide a correlation ID. If you provide an ID, it's ignored. ITSI handles associating the episode with BMC Remedy or BMC Helix for you.
   Summary	A description of the incident.
   Configuration Item	The associated configuration item for the Remedy or Helix incident.
   Impact	The impact of the Remedy or Helix incident.
   Urgency	The urgency of the Remedy or Helix incident.
   Status	The status of the incident. Select Resolved if you want to immediately resolve the Remedy or Helix incident upon opening it.
   Status Reason	The status reason is for informational use and doesn't affect how the application behaves.
   Work Info	Keep notes about the work that you perform on the incident or pass information to colleagues also working on the incident.

6. Optionally, configure additional action rules to update the Remedy or Helix incident status when the corresponding ITSI episode changes. For example, create an action rule to change the Remedy or Helix incident urgency to Low if the ITSI episode severity is less than or equal to Normal.

For more information about configuring action rules, see Configure episode action rules in ITSI.

Update a Remedy or Helix incident

To update a previously-created Remedy or Helix incident, follow the steps in Automatically create Remedy incidents as if you were creating a new incident, but only populate the fields in the form that you want to update. For example, if you only want to update the incident's urgency, only populate the urgency field and leave the rest blank.

When an action rule to create a Remedy or Helix incident runs multiple times on the same episode, the existing incident is updated each time. The same thing happens if you unlink a Remedy or Helix incident and then run the Create Remedy or Helix incident or Remedy or Helix Incident Integration Using Rest API action a second time. This occurs because the correlation ID used to create the Remedy or Helix incident is the itsi_group_id of the episode.