Thwaitesy
1 Copper

ViPR SRM Integration with BMC Remedy

Jump to solution

Please help me to find how we integrate the ViPR SRM with BMC Remedy, My Client is specifically looking at high level steps involved in this integration.

Labels (1)
Tags (2)
1 Solution

Accepted Solutions
Thwaitesy
1 Copper

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

Thanks for your response, I appreciate it.

Thought I would share with the community another response I received.

See below further information relating to SRM and/or SAS integration with Remedy.

First point of clarification:

·         EMC ViPR SRM (SRM) can forward information to BMC Remedy to open events and/or populate a CMBD.  This is one-way integration.

·         EMC SAS (Service Assurance Suite) includes a full event management & correlation system and can enable bi-directional integration with Remedy.

·         SAS is very tightly integrated with SRM, and if SAS is in place, SAS would be used as the primary point of integration to Remedy.

Responses below are focused on the EMC ViPR SRM integration with Remedy as per requested.

Event Integration

Events coming out of SRM are defined in the alerting engine, which can output the details in a number of forms, namely SNMP traps, emails, log messages, or calling an external script.

On the Remedy side, there are a number of APIs available to use, see https://communities.bmc.com/docs/DOC-17512

The most robust method would be to create an external script to consume a web service API published on the Remedy side to allow SRM to raise incidents. The steps to do this are as follows:

Ensure the alerting modules in SRM are installed, including the backend, frontend, and ensuring that all collectors are set to forward collected data through the Alerting connector to the backend.

Ensure a set of alerts in SRM are defined as required (customer requirements on what they want to raise as incidents feeds in here).

On the Remedy system, ensure that a web service has been published that SRM will be able to consume. This will likely be custom development on Remedy side if they haven’t already done web service integrations to some other tool, but if they have done this before it’s possible we could reuse what they have. Remedy resources from the customer required here.

Ensure connectivity is in place between SRM and Remedy so that the web service is accessible, including any authentication and/or certificates required for secure connection, firewall rule change control, etc..

Develop a standard event template in SRM for use the output of the alert definitions that includes all the appropriate properties and values such that a Remedy incident can be created with valuable information for the operators to action. This template should be built in a somewhat generic fashion so that all types of alerts/events from SRM can raise incidents, as per the customer requirements in step 2. This is essentially a data mapping exercise between SRM and Remedy.

Create an external script that SRM can call, that will take all of the output from the alert template as described in step 5, and using that information consume the Remedy web service as described in step 3 so that an Incident can be raised.

There are other alternatives here, the most likely being using pure Java in the external script called by RM and the Java API in Remedy - this method is almost identical to the above description, just replace “web service” with “Java API". It will basically come down to the developer choice and the preferred support from the client or partner (

A further alternative is to use an inbound email integration on the Remedy side with the alerts in SRM using an email template in step 4 above, this method is generally seen as less robust than either java or web service methods, but may be lower cost and swifter to implement.

CMDB Integration

The easiest method for CMDB integration is to use a JDBC data source in Remedy/Atrium to query the SRM database to extract the device information. This information can then be manipulated natively in the BMC tools to create the configuration items. The steps for this would be as follows:

Create the user information in the SRM databases that the BMC solutions will use to access the data (by default only other SRM servers can connect).

Ensure connectivity between the systems (firewall rule change control, etc.).

Data mapping exercise between SRM and CMDB to determine the following:

Device class mapping between the systems, the CMDB class schemas are unlikely to align on their taxonomy

Field mapping for each of the device classes identified in the above

Potentially mapping of relationships between devices, if topology for them is available in SRM

Create the JDBC data sources in the BMC tools to extract the devices, properties, and relationships identified in the above. It’s possible that different data source configuration will be required per device or relationship type, as the queries required to stitch the information together can get a bit convoluted if there’s a lot of fields that need mapping. Remedy resources from the customer required here.

Create any data manipulation or transformation workflows in BMC tools to process the collected data from the above step.

Please note that there are a few assumptions above and without having detailed requirements of exactly the outcome needed.

The key thing is that we have worked with other customers to integrate SRM/SAS/Watch4net with Remedy in a number of different ways. Each is very much dependant on the customers need and internal resource skillset.

0 Kudos
5 Replies
macgaver1
1 Nickel

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

Hi,

  integration of SRM with ticketing system is simple. When you configure your alerting rules (from Administration-->Alerting), you can use the action called "External Process". This action can be configured with precise CLI parameters.

Here a generic example of script and rules (images).

The Example Script content (it’s in fact just one line, but there is comments):

#!/bin/sh


####################################################################################################################

# Simple Example for EMC M&R Custom Action Script

# Alerting

#

# EMC M&R Alerting parameters for the Action type "External Process":

#     Script Path Example: /opt/APG/Backends/Alerting-Backend/Default/scripts/NOTIFY.sh

#     Command Parameters : HighUtilization,PROP.'device',PROP.'devtype',PROP.'parttype',PROP.'part',TMST,VALUE

#

# Example of line added to the output file by that script

# when using entry point with that filter: devtype=='VirtualMachine' & parttype=='Processor' & part=='System'

#

#     "17/10/2014 09:28:59" OPENTICKET: VirtualMachine <W4N-DL-TEST1> HighUtilization(261.0%) on Processor System

#

####################################################################################################################


echo "$6 OPENTICKET: $3 <$2> $1($7%) on $4 $5" >>/tmp/ExternalProcessExampleScript.out

Example output going in that file:

"17/10/2014 09:33:59" OPENTICKET: VirtualMachine <W4N-DL-TEST4> HighUtilization(811.0%) on Processor System

"17/10/2014 09:33:59" OPENTICKET: VirtualMachine <"W4N-QL-C56-64-Test-F (DHCP)"> HighUtilization(86.0%) on Processor System

"17/10/2014 09:33:59" OPENTICKET: VirtualMachine <"Analytics VM"> HighUtilization(80.0%) on Processor System

"17/10/2014 09:38:59" OPENTICKET: VirtualMachine <"W4N-IL-YANNICK-1 (lglbf013) - 10.247.77.13"> HighUtilization(81.0%) on Processor System

"17/10/2014 09:38:59" OPENTICKET: VirtualMachine <"W4N-QL-C56-64-Test-F (DHCP)"> HighUtilization(84.0%) on Processor System

"17/10/2014 09:38:59" OPENTICKET: VirtualMachine <"Analytics VM"> HighUtilization(81.0%) on Processor System

simple-alerting-rule.png

0 Kudos
Thwaitesy
1 Copper

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

Thanks for your response, I appreciate it.

Thought I would share with the community another response I received.

See below further information relating to SRM and/or SAS integration with Remedy.

First point of clarification:

·         EMC ViPR SRM (SRM) can forward information to BMC Remedy to open events and/or populate a CMBD.  This is one-way integration.

·         EMC SAS (Service Assurance Suite) includes a full event management & correlation system and can enable bi-directional integration with Remedy.

·         SAS is very tightly integrated with SRM, and if SAS is in place, SAS would be used as the primary point of integration to Remedy.

Responses below are focused on the EMC ViPR SRM integration with Remedy as per requested.

Event Integration

Events coming out of SRM are defined in the alerting engine, which can output the details in a number of forms, namely SNMP traps, emails, log messages, or calling an external script.

On the Remedy side, there are a number of APIs available to use, see https://communities.bmc.com/docs/DOC-17512

The most robust method would be to create an external script to consume a web service API published on the Remedy side to allow SRM to raise incidents. The steps to do this are as follows:

Ensure the alerting modules in SRM are installed, including the backend, frontend, and ensuring that all collectors are set to forward collected data through the Alerting connector to the backend.

Ensure a set of alerts in SRM are defined as required (customer requirements on what they want to raise as incidents feeds in here).

On the Remedy system, ensure that a web service has been published that SRM will be able to consume. This will likely be custom development on Remedy side if they haven’t already done web service integrations to some other tool, but if they have done this before it’s possible we could reuse what they have. Remedy resources from the customer required here.

Ensure connectivity is in place between SRM and Remedy so that the web service is accessible, including any authentication and/or certificates required for secure connection, firewall rule change control, etc..

Develop a standard event template in SRM for use the output of the alert definitions that includes all the appropriate properties and values such that a Remedy incident can be created with valuable information for the operators to action. This template should be built in a somewhat generic fashion so that all types of alerts/events from SRM can raise incidents, as per the customer requirements in step 2. This is essentially a data mapping exercise between SRM and Remedy.

Create an external script that SRM can call, that will take all of the output from the alert template as described in step 5, and using that information consume the Remedy web service as described in step 3 so that an Incident can be raised.

There are other alternatives here, the most likely being using pure Java in the external script called by RM and the Java API in Remedy - this method is almost identical to the above description, just replace “web service” with “Java API". It will basically come down to the developer choice and the preferred support from the client or partner (

A further alternative is to use an inbound email integration on the Remedy side with the alerts in SRM using an email template in step 4 above, this method is generally seen as less robust than either java or web service methods, but may be lower cost and swifter to implement.

CMDB Integration

The easiest method for CMDB integration is to use a JDBC data source in Remedy/Atrium to query the SRM database to extract the device information. This information can then be manipulated natively in the BMC tools to create the configuration items. The steps for this would be as follows:

Create the user information in the SRM databases that the BMC solutions will use to access the data (by default only other SRM servers can connect).

Ensure connectivity between the systems (firewall rule change control, etc.).

Data mapping exercise between SRM and CMDB to determine the following:

Device class mapping between the systems, the CMDB class schemas are unlikely to align on their taxonomy

Field mapping for each of the device classes identified in the above

Potentially mapping of relationships between devices, if topology for them is available in SRM

Create the JDBC data sources in the BMC tools to extract the devices, properties, and relationships identified in the above. It’s possible that different data source configuration will be required per device or relationship type, as the queries required to stitch the information together can get a bit convoluted if there’s a lot of fields that need mapping. Remedy resources from the customer required here.

Create any data manipulation or transformation workflows in BMC tools to process the collected data from the above step.

Please note that there are a few assumptions above and without having detailed requirements of exactly the outcome needed.

The key thing is that we have worked with other customers to integrate SRM/SAS/Watch4net with Remedy in a number of different ways. Each is very much dependant on the customers need and internal resource skillset.

0 Kudos
BenimusIQ
1 Nickel

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

If anyone has questions about the above response posted by Thwaitesy, please let me know as I was the one who wrote it.

We have experience integrating EMC SAS/SRM/ViPR tools with a number of different service desks for events/incidents (including suppression during change windows) and CMDB federation.

Thanks

Benjamin Johns

iQ Consult

0 Kudos
cincypiper1
1 Nickel

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

I'm a customer and we are a BMC Remedy house as well.  I will be following this thread very closely and see if the code posted above is applicable in our environment.

Please keep me in the loop!

0 Kudos
Julio3
1 Copper

Re: ViPR SRM Integration with BMC Remedy

Jump to solution

Hi Benjamin

this is Julio Gomez SE for BBVA in Spain.

I need your support in a deal we are working on.

BBVA has a complete BMC Suite.

We are currently using Event alerts from our arrays using SNMP Traps ;-((

BBVA is working in a new project for Capacity plan, events, alerting, etc... They are using from BMC the TCO tool (BMC TrueSight Cpacity Optimization).

Do you have any experience about the integration from BMC TCO with our ViPR SRM Suite.????

If So, can we share the way to deploy IT... what king of services, sizing for SRM, and other aspecto I forget

More or less we should have to include 25 VMAX arrays, 10 VNX arrays, 8 Data Domain, etc... This is only in Spain. BBVA has presence in LATAM and US also.

Keep in mind that they don not have ViPR SRM installed, we are irking on it in parallel to this protect

Any help will be very appreciate for us.

Thanking in advance

JC

0 Kudos