ViPR SRM Integration with BMC Remedy

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.