Integrate ITSI with BMC Remedy
Integrate BMC Remedy with IT Service Intelligence (ITSI) so you can create and update incidents in a Remedy system from ITSI, either through episode actions or through automated action rules in aggregation policies. Splunk ITSI has built-in integrations with 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.
|BMC Remedy||You must have BMC Remedy version 9.1 or later.|
|ITSI role||You must have the itoa_admin or role to set up the integration with BMC Remedy.|
|Splunk Add-on for Remedy||You must have the Splunk Add-on for 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. 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 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 ticket aren't reflected in ITSI. To configure a bidirectional integration, see the next section.
Set up a bidirectional integration with BMC Remedy
A bidirectional integration exchanges data between your ITSI instance and BMC Remedy 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. See Overview of the Common Information Model for an introduction to the data models and information about the fields used.
Configure the incident data input
Follow the below steps to configure the incident input in Splunk Add-on for BMC Remedy :
- In Splunk Web, select the Splunk Add-on for BMC Remedy icon in the Apps sidebar.
- Select the Inputs tab to navigate to the Splunk Add-on for BMC Remedy inputs configuration.
- Select Create New Input to create a new input for incidents.
- 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,
key2'="value2"'. By default, no qualification parameters are applied.
Index The index where the input form data is indexed. The default index is main.
- Select Add.
- 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 events and sends an event to the itsi_tracked_alerts index each time an update is made. The correlation search also maps BMC Remedy fields to the CIM fields. For more information, see Ticket management in the Common Information Model Add-on Manual.
BMC Remedy Bidirectional Ticketing correlation search is disabled by default. To enable it, perform the following steps:
- From the ITSI main menu, go to Configuration > Correlation Searches.
- Enable the
BMC Remedy Bidirectional Ticketingcorrelation 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/.
[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
Configure action rules to sync BMC Remedy ticket fields
To configure aggregation policy action rules that update the fields in the ITSI episode when they change in Remedy follow these steps:
- From the ITSI main menu, go to Configuration > Notable Event Aggregation Policies.
- Open an existing custom notable event aggregation policy that creates episodes you'll send to Remedy.
To use the bidirectional integration, you must create a custom aggregation policy instead of using the default aggregation policy.
- Go to the Action Rules tab.
- Select Add Rule.
- Select the Remedy incident associated with the episode has from the If drop-down list. This option only appears if you installed the CIM and the Splunk Add-on for Remedy.
- Build out your aggregation policy so that each important change in Remedy has an action rule that updates the corresponding episode in ITSI. For example, the action rules for state changes might look like this:
- Repeat these steps for each aggregation policy you want to integrate with Remedy.
Test the integration
To test the integration to make sure you configured the fields correctly follow these steps:
- 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.
- Go to your Remedy 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.
- 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.
After you set up a bidirectional integration, any BMC Remedy 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:
|Link multiple episodes to a single Remedy incident||The Remedy incident link is added to each episode. If you update the Remedy incident, the changes apply to each linked episode. If you update multiple episodes, the most recent change takes precedence. For example, if a Remedy 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 incidents||A link to each Remedy incident is added to the episode. If you update the episode, the changes apply to each linked Remedy incident. If you update multiple Remedy incidents, the most recent change takes precedence. For example, if an episode is linked to Remedy 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 incidents
To configure aggregation policy action rules to create and update Remedy incidents when certain conditions are met. follow these steps:
- Within ITSI, go to Configuration > Notable Event Aggregation Policies.
- Open the aggregation policy you want to integrate with Remedy.
- Go to the Action Rules tab.
- Select Add Rule and configure trigger conditions for when to create a Remedy incident:
- Select Configure to configure the following fields:
Filed Description Correlation ID Unique Correlation ID for Remedy 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 for you.
Summary A description of the incident. Configuration Item
The associated configuration item for the Remedy incident.
Impact The impact of the Remedy incident. Urgency The urgency of the Remedy incident. Status The status of the incident. Select Resolved if you want to immediately resolve the Remedy 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.
- Optionally, configure additional action rules to update the Remedy incident status when the corresponding ITSI episode changes. For example, create an action rule to change the Remedy 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 incident
To update a previously-created Remedy 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 incident runs multiple times on the same episode, the existing incident is updated each time. The same thing happens if you unlink a Remedy incident and then run the Create Remedy incident or Remedy Incident Integration Using Rest API action a second time. This occurs because the correlation ID used to create the Remedy incident is the itsi_group_id of the episode.
Integrate ITSI with ServiceNow
Integrate ITSI with Splunk On-Call (VictorOps)
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.14.0 Cloud only, 4.14.1 Cloud only, 4.14.2 Cloud only