Purpose
Recently a number of nice Enterprise Widgets have been presented here on SDN mostly showing us techies some relevant system information or allowing us to interact with the system to query some information. But what about our managers? Don't they want to have some useful widgets on their desktops besides their sudoku and weather widgets? Well here you are. Your generic KPI speedometer widget. Turn the desktop of your PC into your Enterprise Radar Cockpit and see all your relevant performance indicators at one glance. Any system. Real time.
Prerequisites
The widget shown will run on an actual Yahoo Widget Engine. The widget retrieves it's data from data sources by means of (simple) web services, so every platform supplying a web service runtime supporting SOAP will suffice. For ABAP backends this means 6.40+.
The speedometer widget
The widget resembles a classical speedometer design showing the actual value of a certain parameter. The parameter is queried at a customizable refreh rate directly from the relevant data source. All the data source system has to do is to implement a certain WSDL as follows:
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions targetNamespace="urn:sap-com:document:sap:soap:functions:mc-style"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:sap-com:document:sap:soap:functions:mc-style"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:sap-com:document:sap:soap:functions:mc-style"
targetNamespace="urn:sap-com:document:sap:soap:functions:mc-style"
elementFormDefault="unqualified" attributeFormDefault="qualified">
<xsd:element name="ZtwSpeedo">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ParameterName" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ZtwSpeedoResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="MaxGauge" type="xsd:string"/>
<xsd:element name="MinGauge" type="xsd:string"/>
<xsd:element name="ParameterUnits" type="xsd:string"/>
<xsd:element name="ParameterValue" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="ZtwSpeedo">
<wsdl:part name="parameters" element="tns:ZtwSpeedo"/>
</wsdl:message>
<wsdl:message name="ZtwSpeedoResponse">
<wsdl:part name="parameters" element="tns:ZtwSpeedoResponse"/>
</wsdl:message>
<wsdl:portType name="ZTW_SPEEDO">
<wsdl:operation name="ZtwSpeedo">
<wsdl:input message="tns:ZtwSpeedo"/>
<wsdl:output message="tns:ZtwSpeedoResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ZTW_SPEEDOSoapBinding" type="tns:ZTW_SPEEDO">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="ZtwSpeedo">
<soap:operation soapAction=""/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ZTW_SPEEDOService">
<wsdl:port name="ZTW_SPEEDOSoapBinding" binding="tns:ZTW_SPEEDOSoapBinding">
<soap:address location="http://the_server_url:8000/sap/bc/srt/rfc/sap/ZTW_SPEEDO?sap-client=200"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
As one can see from the WSDL, the service is supposed to accept an input parameter ParameterName and returning the return parameters MaxGauge, MinGauge, ParameterUnits, ParameterValue. Obviously the data source system is responsible for the calibration of the speedometer by means of MinGauge and MaxGauge, in the above screenshot seen as 10 and 40. The variable input parameter allows one service to return different KPIs.
The implementation in ABAP
In our ABAP backend we follow an inside-out approach to create a webservice for the widget to use. First we create a function module using input and output parameters according to the above WSDL (and our implicite knowledge on how the web service wizard will convert parameter names)
FUNCTION ZTW_SPEEDO.
*"---- ----------------------------------------------------------------- *"
*"Lokale Schnittstelle:
*" IMPORTING
*"VALUE(PARAMETER_NAME) TYPE STRING
*" EXPORTING
*" VALUE(PARAMETER_VALUE) TYPE STRING
*" VALUE(MIN_GAUGE) TYPE STRING
*" VALUE(MAX_GAUGE) TYPE STRING
*" VALUE(PARAMETER_UNITS) TYPE STRING
*"---- -----------------------------------------------------------------
case parameter_name.
when 'TEST'.
parameter_value = '20'.
min_gauge = '10'.
max_gauge = '40'.
parameter_units = 'U/min'.
when 'ADMISSIONS'.
select count(*) from nfal into parameter_value
where erdat >= sy-datum.
min_gauge = '0'.
max_gauge = '100'.
parameter_units = 'Admissions/Day'.
when 'ORDERS'.
select count(*) from n1corder into parameter_value
where erdat >= sy-datum.
min_gauge = '0'.
max_gauge = '100'.
parameter_units = 'Orders/Day'.
when others.
parameter_value = '0'.
min_gauge = '0'.
max_gauge = '100'.
parameter_units = '[1]'.
endcase.
ENDFUNCTION.
The function module does some query depending on the input parameter and returns the expected values (the examples 'ADMISSIONS' and 'ORDERS' are from the healthcare industry solution so you have to adjust those queries to your needs). Of course, there's no limit to the logic for calculating your KPI here as long as you return one parameter per when-statement in the end. The calibration parameters should be set statically to some reasonable values according to performance or other business expectations. The last step ist to run the web service wizard and release it for the SOAP runtime.
Customizing the widget
Start the widget, right click on it and set some customizing settings.
The dialog should be self-explaining. You have to tell the widget the service's base URL, your credentials, which parameter you want to query and finally what caption you want to have on your widget. Immediately after you save your settings, the widget will make it's first attempt to connect to the specified service. If the widget is unable to connect to the service you will get an error message like the one in the following screen
In this example we get a 504 error, which points to some proxy problem.
Multiple instances
'Well' you say, 'nice, but what a cool key performance indicator must that be, being sufficient to jugde my enterprise's state in solitude?'. You might be trying to load a second instance but that doesn't work. But here comes the simple trick: copy the .widget file to a new name in your widgets directory, start this copy and you'll see that it tells you that you haven't used that widget yet. Do your customization as explained above and you'll get this
The Enterprise Radar Cockpit
Now that we know that we can create a number of instances of the KPI Speedometer, we can go out to all of our SAP and legacy systems, tell the responsible people to implement that trivial web service and get back to us with the connection parameters once done. If there are slight adoptions necessary to the widget, it can easily be decompiled and those adoptions can be programmed in the file main.js. Once our services and adoptions are in place our Enterprise Radar Cockpit might look like this:
A Little Drawback and Hacker Challenge
Each instance of the KPI speedometer widget consumes abbout 10MB of memory. i have been testing and trying with a number of widgets but wasn't able to find out what causes that memory consumption. Moreover I didn't understand at all what determines the memory consumption of any widget. To me this looks some kind of random but this may well be attributed to my know-how.
So, maybe someone has a spare minute and debug it and find a way to reduce the memory consumption. Although some OS vendors force us to buy 4 gig minimum machines I think it's strange that 10 widgets in the cockpit consume 100MB of memory.
Apart from that, have fun with the KPI Speedometer widget, downloadable here.
6 Comments