Local Web Service

The Virsae Service Management (VSM) Local Web Service is an optional service that runs on the customer collector enabling applications to communicate with Virsae Service Management to pass in alarm and performance information which will then be available through the VSM web portal interface. This includes the capability for an alarm to trigger a workflow that will notify users of the issue which in some instances may not be possible any other way.

Local Web Service is accessible via Service Desk > Equipment Locations > Location >  Network > Local Web Service Configuration.

IVR example

An example of this functionality is an IVR application that is capable of consuming the VSM web service. The IVR applications are designed to interact with a user to collect or provide information, a database that stores the information and a telephone system that is used to transfer the call to a person when required. In many instances the availability and performance of an IVR is not visible to those users supporting it and issues are only identified when customers report it. However in many instances subtle problems in the IVR may never be reported as the customers do not know the expected behavior.

Now the application developer may capture any application errors such as server or telephony resources not being available or application exceptions and pass this as an alarm which will be processed in the same way as any other alarm collected via VSM.

Enabling Local Web Service

The Local Web Service administration page enables you to configure this web service which is disabled by default. To enable the service you will be required to enter a validation key which will be used by the calling application to authenticate itself.

Click the Edit Configuration button to enable or disable the service or modify the validation key.

To enable the service, check the Enabled check box and enter a key that will be used by the developer. Do not change the web service ports unless instructed to by your Virsae Service Management support team.

Create an Alarm Object

An alarm object is a block of information that contains the key details regarding the alarm being raised. You will be asked to supply a unique alarm name, an alarm description and a display name. Once created you will be able to override defaults such as the default severity (2) to another severity using the alarm management page Overriding Alarm Responses.

Note: The alarm name must be unique within Virsae Service Management so it will have the customers name automatically added as a suffix.

More than one alarm object may be created. For example a high severity alarm and a low severity alarm (overriding the default alarm response) enabling standard alarm rules and workflows to use the severity to process the alarm. Or the alarm names themselves may be used in Alarm Rules to determine the workflows to be initiated. However in general only a few unique alarms may be required with additional data such as the IVR script name, calling method or failure being supplied in other alarm fields. Unique alarm names would be useful where you want to treat the alarms differently and the Alarm Rules would check the Alarm Name.

AddAlarm Method

The AddAlarm method is used to add an alarm to Virsae Service Management passing the following parameters.

SetAlarmStatus Method

An alarm may be in one of two states: active or resolved. When an application adds a new alarm an alarm Id is returned. If an application determines an alarm has been resolved then it can set the state of that alarm as resolved. When this occurs Virsae Service Management will remove the alarm from the alarm management panel, workflows that test if the alarm is still active will get a negative response and the alarm will be marked as resolved in associated alarm reports.

The SetAlarmStatus method is called with the following parameters.

Adding an Alarm - Python Example

To use the local web service it must first be enabled and alarms created that you wish to raise via the web service. Finally from within your application you need to consume the metadata WSDL http://[applianceip]:8080/WebServiceProbe/metadata and use the methods required.

Note: The methods addPerformanceData, addNotification and addConfiguration are for future use and should not be used currently.

The following Python example uses the Zeep module to query the Local Web Service WSDL to find the available services and then call the AddAlarm service passing a list of parameters, including the configured validation key. To look at Zeep's interpretation of the WSDL you can run the following command from a command prompt

python -mzeep http://192.168.10.48:8080/WebServiceProbe/metadata?wsdl

The output includes the AddAlarm  information:

Service: WebServiceProbe
Port: BasicHttpBinding_IWebserviceProbe (Soap11Binding: {http://tempuri.org/}BasicHttpBinding_IWebserviceProbe)
Operations:
AddAlarm(alarmName: xsd:string, validationKey: xsd:string, callingMachineName: xsd:string, callingApplication: xsd:string, alarmLevel: ns2:enAlarmLevel, alarmDescription: xsd:string, additionalData: xsd:string) -> AddAlarmResult: xsd:int, alarmIdentifier: xsd:string, alarmAlreadyKnown: xsd:boolean

The Python script to add an alarm is:

import zeep
from zeep import Client

wsdl = 'http://192.168.10.48:8080/WebServiceProbe/metadata?wsdl'
client = zeep.Client(wsdl=wsdl)
responsedata=(client.service.AddAlarm('BHiveTest_AACC Lab', 'validationKey1', 'TestMachine', 'TestApplication', 'Information' , 'TestDescription', 'Data,Some additional data goes here,Data2, and more data here'))
print(responsedata)

The result is:

{
'AddAlarmResult': 0,
'alarmIdentifier': '46b2047f-7495-491c-8aaa-3b22a3eedd39',
'alarmAlreadyKnown': False
}

And in the VSM portal Manage Alarms page you will see the alarm that has been created and if you have alarms escalated via a workflow you will also receive a mobile app notification or email/sms alert.

Right clicking on the alarm and selecting Additional Alarm Data you will be able to view the detail that was passed in when the alarm was raised.