Integration with BMC Remedy
In many IT shops, BMC Remedy is used for managing incidents and changes. This software brings a set of APIs in the form of Web Services that can be used to integrate with other application platforms. These APIs can be used to do the same activities programatically in Remedy usually done by manually otherwise in many instances.
This example shows step by step how to build an interface in SAP PO, to inquire an incident from BMC Remedy system.
Initially we need to find the list of Web Services from Remedy application.
The following link will list the available services:
http://<your remedy server>/arsys/WSDL/protected/list
Our focus in this particular example is the service HPD_IncidentInterface_WS highlighted above. It was chosen to for the simplicity of the scenario but any other service would essentially behave the same way as this is.
The next step is to get the WSDL describes the available methods in this service.
By clicking on the service , the WSDL will be shown on the browser.
Save the XML in to a local folder as a WSDL file. We are going to use the WSDL to build the ESR objects in SAP PO.
First create an external definition and import the WSDL file just saved.
It will have the following methods (or operations):
We are going to pick the 2 services highlighted. They represent the request and the response respectively.
The service will run a query in Remedy to get the details of an incident ticket provided the ticket number.
For example, this is a manual inquiry run in BMC Remedy to show an incident:
As shown below, it would be a straightforward activity to build the ESR object ending with Service Interfaces and Operation Mapping. The message mapping will be one-to-one with same message type used from the External Definition explained above.
The next step is to build the IFLOW object in NWDS.
For illustration purpose the sender is created as a SOAP sender, which can be replaced with any other synchronous sender channel of different types (eg. SOAP, REST, RFC, ABAP Proxy or HTTP).
The SOAP receiver configuration is the tricky one.
Here is the structure of the request/response in ESR:
It only shows the Incident_Number. But if we look at the WSDL there is an authentication information coded in there which will be part of the SOAP Header at run time.
If we can use SOAPUi to build the service, we could see the header clearly as highlighted below.
We need to add the authentication information to the receiver channel.
General section of the receiver channel parameters looks like below. The user / password is your remedy credentials.
To add credentials into the SOAP Header, we are going to use, module AF_Modules/AddSOAPHeaderBean in module parameters.
Here are the Module configuration entries :
Module Key Parameter Name Parmeter Value
0 AuthenticationInfo <userName>user</userName><password>pwd</password>
0 namespace urn:HPD_IncidentInterface_WS
Sender channel is not explained as it is a regular SOAP channel.
Save , activate and deploy the IFLOW.
We can run a test from WSNAVIGATOR.
Cut and paste the WSDL url from run time properties in NWDS for the IFLOW into WSNaviagtor.
This is a simplest case of using Remedy API to query an incident, but given the scope of API list, they can be used for automating incident and change request management.
For example, if there is an error generated from a different platform and if an incident can be created automatically triggered from the error, that will save time for manual attending of reporting the problem. Another example is if there is a need to update the incident or a change request due to status change it can be automatically triggered from the actual status change occurred in the other platform.
It should be noted that if the Remedy system access is restricted from firewalls and proxy servers , it may need adjusted channel parameters to counter those situations.