We would like to offer the following data via webservices to a external application:
- user information (name, phone, email, last HPSM login timestamp)
- computer information of user (computer names, operating system, bit rate etc.)
- assignment groups of user (name of assignment group, group manager, group manager deputy)
It's quite easy to setup a webservice within HP ServiceManager for specific tables. It's just about to create a so called "External Access (extaccess) record for the corresponding dbdict.
After defining the extaccess record a WSDL is automatically generated by HPSM and it will automatically support to retrieve either single records or list of records from the corresponding table.
It's furthermore easy to specify which fields shall be exposed as XML attributes and how those fields shall be labeld.
It's also simple to specify custom actions such as "add", "update", "close". Each action will become a webservice within the WSDL. HPSM will identify the logic to be executed by scanning the so
called State record for the corresponding action name and execute the related Process record.
When planning a webservice interface the counterparts normally start first to define the "contracts".
- Which webservices are needed (Catalog of Webservices)?
- Which attributes does each webservice contain (XSD)?
The goal should be to design the webservices as efficient as possible and limit the number of webservice calls required. Each webservice request and response means overhead and takes time to be
processed. Therefore a webservice should whenever possible and meaningful return all the data required by the consumer in one webservice request. Sounds normal since XML is powerful and can hold
more ore less any data structure.
The problem is that HP ServiceManager is not having a relational data base. Each webservice is dependent on one table and can therefore only expose the fields of the corresponding table.
Looking at the use case it would mean to setup multiple webservices as follows:
- getContact (retrieving data from the contacts table)
- getOperator (retrieving data from the operator table -> last login timestamp)
- getComputer (retrieving data from the device table)
- getAssignmentGroups (retrieving data from the assignment table)
The developer responsible to code the webservice consumer part will be probably having questions and stating: Can't we define one webservice for that? I always need all the data anyways and I
don't understand why we can't include all information at once? Maybe he would propose a XML structure as follows:
It's indeed possible to achieve this in HPSM. Find below an example solution.
3. Create a extaccess record for the dbdict xxWsGetUserData
- ServiceName: xxWebservices
- dbdict: xxWsGetUserData
- Object Name: xxUserData
- Allowed Action: get
- Action Name: Get
- Action Type: Application Pass Through
- Customer Action to Perform: xxWebservice Dispatcher
- Select all the fields defined in xxWsGetUserData
This script library is containing 2 functions.
The function "doAction" is the function which is invoked by the extaction.
Within this "doAction" function I check which webservice and action has been requested and depending on the action another JS function is invoked processing the webservice request (in this case
"getUserData()" which is the second function in the library).
The way I designed it, the dispatcher could be used for many different webservices (maybe a suite of webservices). Based on Webservice & Action the dispatcher is redirecting to corresponding
java script functions.
The example code below is populating the webservice response with some hard coded values.
It's only about to illustrate that we could now select any data from any table in HPSM and use this data to populate any attribute within the webservice response.
Further more it's possible to validate any attribute populated within the webservice request and react upon missing attributes or attributes containing invalid values with custom error messages.
Example with missing parameter (validation failed response):
Example with Success response: