ServiceGrid Article - Cisco ServiceGrid Release Notes V5.8

From DocWiki

Jump to: navigation, search



This release notes describes the new functions of the Cisco ServiceGrid  Release Version 5.8. The following items are covered in this document:

  • Outlines the new functions and modules.
  • Gives a brief look into how the new functions are implemented, administered and used.
  • Describes the benefits of the new functions using small use cases.
  • Describes how existing functions are extended or changed.

New Functions in this Release

New functions are introduced in the Summer 2011 Release Version 5.8 on 17th of July 2011 to all customers using the ServiceGrid main platform ( All customers running their own inhouse infrastructure for using a ServiceGrid partner infrastructure will receive the release on a later date. These updates occur after the update of the ServiceGrid main platform. Please contact your implementation partner for the update date.

Availability and Licensing of New Functions and Modules

  • All new functions and modules are installed on the platforms.
  • New functions and modules, which are part of the general update, will be available to all customers of the platform.
  • Some functions are automatically available to all users.
  • Some functions or modules should be configured or activated first.
  • Some of the new functions and modules should be licensed separately before being used in customized systems.


  • Enhancements of ServiceGrid BRIDGE
    • Better attachment handling: Transfer using the core callservice
    • Enhancements of the Webservice-Bridge: Responsefilter, ...
    • New SoapClient for the metro-based webservices
  • Usability
    • Clearly arranged filter panel of lists
    • Magic button is instantly available when a call is created
  • Stability and security improvements
    • Faster CallDetail usage through optimized history display
    • More agile work performance through better control of loaded records in all lists
    • Increased number of Bridge transaction through efficient call update management
    • Optimized memory usage in the online application

New Features and Functionalities


The number of CallHistory entries that are loaded in the CallDetail is limited. Therefore, calls that have been updated often are still shown within a reasonable time.


Performance is drastically reduced when a CallDetail that undergoes frequent updates is opened. This is because at that moment, all entries in the CallHistory connected to the call are loaded in the CallDetail. Opening a call in this way will not only result in a long wait for the those opening the call, but also reduce the performance on the application server ("schu") for all users. Most of the time, only the latest changes to a call are of interest. Therefore, the displayed history entries are reduced to a small number starting from the most recent entry.

How does it work?

The loaded CallHistory entries are limited to ten per default. This can be changed (see Setup). Only the most recent 10 entries are shown, representing the latest changes to the call. A button at the end of the list allows the loading of the entire history. Besides the button, the message "more callhistory records available" is also displayed. If there are less history entries than the limit, the button will not be displayed.

Each time the call is reloaded, the limit is used. On change of the CallHistory setup, the call will be reloaded. Therefore, the new limit is only applied if the entire history has not been loaded yet.



Click on the Change the setup master data from SD.basicdata / MyCompany / [Company] / +Setups / +CallSystem / +[CallSystem] / +CallSetups / +Call.History / [SetupName]. In the line MaxHistoryOnCallLoad, the default value for the history limit can be overruled.Values from 1 to 20 are allowed. If no value is given, the default value of 10 is used on call load.


Additional Remarks

The limit also works in the mobile version. There is no need to set up the limit. If the Call.History setups are not changed, the default value of 10 will be used.


To reduce the number of restarts necessary for the application server (tomcat), some limits have been added to list.


With the growth of the platform, memory usage has also grown. With the release 5.8, some of the most memory-intensive features have been identified and the their usage have been reduced. Most of these reductions are not noticeable to the user since they only impact the inner workings of the application. However, huge lists have also been identified as problems. This leads to the introduction of some limits.

How does it work?

  • All lists will be reduced to 5000 entries. If the list is not filtered or the filter criteria would yield more than 5000 rows, the result is cut after 5000 rows. The message "More than 5000 rows found. Please reduce data size with filters." will be displayed instead of "n [entity] records selected". Downloads (Exports) are not limited.


  • The maximum entries per page have been reduced. A limit of 999 rows that could be rendered per list page already existed. (The limit is set in the setup master data as EntriesPerPage). This limit has now been reduced to 300. In new setups, only values from 1 to 300 are allowed. As long as old setups are not saved, the settings for EntriesPerPage stays the same. However, in the lists, the maximum entries per page will be only 300. If the limit is set to a higher value in the future, old setups that have not been updated will automatically show more entries again.
  • In the history view of device and locations list, only the most recent 10 history entries are shown. If more than ten history versions of the device exists, a button and a are displayed. If the link is clicked, the detail of the device concerned is opened. The entire history of this device is shown.


Responsefilterui 01-21081442.png


No setup is needed for these functions. Maximum number of EntriesPerPage has been changed and will be checked against list setups that are saved.


For pulling and pushing bridges, it is now possible to set action to specific type of responses.


When pushing a message from SD or pulling into SD through WebService bridges, the user desires to specify whether an answer from the target server is meant to be an error or a valid response instead of the current programmatic definition. A common example is, if a target server returns a SOAP Fault in its response: In some cases, this means the message was invalid, that is it would not work on re-delivery; therefore the message can be discarded while another kind of fault may mean that the server is temporarily unavailable, so the message should be redelivered.

How does it work?

1. To every ServiceDefinition from type WebService(PushSoap|PushHttp|PullSoap|PullHttp), it is possible to add responsefilters.
2. The filter is composed of the following fields:

  • Mandatory field 'Sequence number': Determines the order in which the response filters will be executed. First in order will be the filter with the lowest sequence number.
  • A mandatory 'Match' field which defines what kind of response this filter should match. Possible values are:
    • ALL: Matches every response
    • RESPONSE: The filter will match only normal responses
    • ERROR: Only error responses will match with this filter
  • An optional 'HTTP status code' field which defines which status code should be handled by the filter. Valid inputs are:
    • A single number  200
    • An inclusive range in the form of 'A-B', e.g. "200-220" (without the quotes)
    • A mix of both separated by a comma e.g. 200, "300-400, 500-503, 508" (without the quotes).
  • Optional 'HTTP Header Regex' field for matching the HTTP Header.
  • Optional 'Message Regex' field for matching the message itself.
  • A mandatory field 'Action' with following values which will take place if the filter matches a response:

      OK: Response will be delivered to the application, "push from SD" messages are marked as sent.

  • Temporary failure:
    • Generally: Failure notification will be sent to monitoring and to:
        a. Push from SD: Message will be resent later.
        b. Pull from SD: Message will be discarded.
  • Error:
    • Generally: Error notification will be sent to monitoring and to:

          a. Push from SD: Message will be resent later.
          b. Pull from SD: Message will be discarded.

  • Faulty message:
    • Generally: Faulty message notification will be sent to monitoring and to:

         a. Push from SD: The response will be delivered to the application and marked as faulty.
         b. Pull from SD: The response will be discarded.

  • Discard:: The response will be discarded and, for "push from SD", message is marked as sent


Suppose following response filter exists:

Responsefilterui example 01-13124231.png

And the response to a request looks like:

Responesfilterui example 02-13125014.png

The defined response filter will fire because following conditions are all true:

  • Match: The filter matches everything
  • HttpCodeRange: The response falls into the code range (response code was 200)

When will the response filter NOT match the request?

  • Changing the HttpCodeRange to 200; Therefore, it will not be in the correct range...
  • Changing the match field to 'Error'; Therefore, error responses will be matched
  • Adding an HttpFieldRegex which would not match the HTTP Header of the response such as .Content-Type: application/xml. (only reponse with content type application/xml will be matched by this value)
  • Adding an MessageBodyRegex which will not match the message body.

What won't effect the matching in this given case?

  • Changing the match field to 'Response' (the response is a normal response)
  • Adding an HttpFieldRegex or MessageBodyRegex which will match the response


At SD.basicdata / MyCompany / [Company] / Servicedefinitions / [Servicedefinition]', the servicedefinition UI has been extended for managing responsefilters.

Responsefilterui 01-21081442.png

Responsefilterui 02-27133656.png


It is now possible to use the magic button while creating a new call.


There is a need to display external information related to a call while creating it. This is now possible with the magic button which is now available at call creation time. The functionality of the magic button is similar to that in the other call states which means that one click for a search in a wikispace will be performed and the most significant results will be shown. Which values of the call will be used in the search and the significance of the value that is configurable in the SD.dialog module will be explained in the "Setup" section.

How does it work?

If the user has permission to use SD.dialog and has enabled the magic button in the call detail setup, there should be a tab named "wiki" visible.

Magicbuttonnewcall 01-12093906.png

If the tab is clicked, you will be linked to a wikispace and the most relevant information to the call will be visible to the user.


To enable the magic tab in a call detail view, navigate to SD.basicdata / MyCompany / [Company] / Setup / CallSystems / [CallSystem] / CallSetups / CallDetail / [CallDetail]

Magicbuttonnewcall 02-12093934.png
The configuration of the wikispace search is done in SD.cockpit under SD.dialog / WikiSignificance

Magicbuttonnewcall 04-12094437.png


In version 5.8, it is possible to configure a wikispace; therefore there is a submenu entry in SD.dialog.


To allow quick switching between wikispaces, it is now possible to configure them; therefore there is a submenu entry in SD.dialog. The user can define which wikispace should have an entry, the order of the entries, and also the label of the entries.

How does it work?

If the user has the permission to use SD.dialog and must configure a wikispace to be able to use it as a menu entry, then the entry could be found as follows:

Wikispaceswitching 01-12095924.png


To setup this feature please goto,SD.dialog / WikiSpaces / [WikiSpace] / Change master data.

Wikispaceswitching 01-12095924.png

The properties of this feature are:

  • UseAsMenuEntry: This flag indicates whether this wikispace should have a submenu entry.
  • MenuText: The label to use for the submenu entry.
  • MenuSeqNr: The position of the submenu entry order, lowest to highest number first.



In earlier releases, the filter panel of a list was not user friendly as there were many columns with selection boxes having more than one row per user. From release 5.8, it is possible to display only those columns in the filter panel, which can be changed by the user. If read only columns with pre-customized filter values are not displayed, the filter panel will be clearly arranged and offers the user a better overview.

How does it work?

For all columns of a list setup, it is possible to customize if the filter field of this column should be displayed or should be hidden. The new flag HideInFilterPanel has been added to the setup fields. If this flag is activated, the filter of this column will not be displayed. By default, this flag is deactivated.

V5 8hidefilterpanel1a-06103443-800px.png
It is also possible to hide the filter values of all columns and to display only the group-by check boxes.

V5 8hidefilterpanel3-06102849-800px.png


If a column is displayed in the filter panel, it can be customized in the administrator setup. This feature is available for all list setups. This flag can be set in the list or in the detail of the setupfields.

V5 8hidefilterpanel4-06112955-800px.png

V5 8hidefilterpanel5-06112739-800px.png

Additionally this flag can be changed by uploading setupfields.

Filterpanel for Selection of a Contract Element with a Tree

When selecting a contract element by category in a tree, it is now possible to filter the shown elements. It is also possible to define default values for that filter.The filter can be configured by a setup. The setup is chosen for the calldetail field ContractIDProvTree or ContractIDCustTree respectively. Only "CallDetail.ContractElement Setups" can be chosen.

5 8 categoriestreefilter setup-11044303-800px.png

The following characteristics of the chosen setup will apply to the tree:

  • Setup choice selectbox
  • Fields of the setup will be possible filter values
  • Default values for the setup's fields will determine the preselection

The following characteristics of the chosen setup will NOT apply to the tree:
The tree will always only display categories of contract elements, not the chosen fields in the setup.

In the following example, there is a filter without visible preselection. A new setup can be selected; the filter can be hidden to display a filter summary.

5 8 categoriestreefilter treeview-11044639-800px.png

NOTE: The top functions (Back, Expand, and Collapse) are not part of the filter, but are part of the tree.

Attachments in CoreCallService

From this release, it is possible to send and receive attachments in the Core CallService (inbound as well as outbound). The following two snippets show the XML schema of the inbound holder and the outbound holder:

<xs:schema version="1.0" targetNamespace="" xmlns:tns="" xmlns:xs="">
<xs:complexType name="outboundHolder">
<xs:element name="Attachments" type="tns:attachmentsHolder" minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType name="inboundHolder">
<xs:element name="Attachments" type="tns:attachmentsHolder" minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType name="attachmentsHolder">
<xs:element name="FileName" type="xs:string" minOccurs="0"/>
<xs:element name="DataBase64" type="xs:string" minOccurs="0"/>
<xs:attribute name="NR" type="xs:decimal"/>

The only supported encoding for inbound and for outbound attachments is Base64. There is no limit for attachments in the Core CallService, neither in size nor in amount.

HTTP/SOAP-Header Authentication in WebServiceBridge

All ServiceGrid webservices provide one very common possibility for authentication: Authentication through the SOAP body. A sample request could look like the following:

<soapenv:Envelope xmlns:soapenv="" xmlns:brok="">
<soapenv:Header />

With V5.8, ServiceGrid provides two new possibilities for authenticating a user. The server makes the following order in searching for an authorization string:

  1. HTTP Header
  2. SOAP Header
  3. SOAP Body

Authentication through SOAP-Header

When using authentication through the SOAP Header, the user and password combination should be in a special tag. These two tags must be named as username and password respectively. The following snippet shows a sample request:

<soapenv:Envelope xmlns:soapenv="" xmlns:brok="">
<brok:getCall />

This request would result in the same request as in the introduction of this section.

Authentication through HTTP Header

For Authentication through HTTP Header, the common process of HTTP basic access authentication is used. This means that the server expects an additional request parameter called Authorization in the request. As value for this key, the String "Basic" and the Base64 encoded combination of username and password is expected. A sample request (including the HTTP parameters) can look like the following snippet:

Content-type: text/xml;charset=UTF-8
Accept-encoding: gzip,deflate
Content-length: 220
Authorization: Basic ZDNhZG06Kioq
User-agent: Jakarta Commons-HttpClient/3.1
Soapaction: ""
<soapenv:Envelope xmlns:soapenv="" xmlns:brok="">
<soapenv:Header />

Limitation of Number of Callupdates

To reduce the possibility of unwanted loops in message processing, the inbound processor has a security barrier for inbound message processing. As soon as the the bridge should process a message that already has 500 history records, the update is rejected. If the communication has any error triggers configured, an error message is sent containing the limit as well as the actual number of history messages.This limitation is not active for updates in the online interface.

SoapClient for Metro-based Webservices

A new SoapClient for the new metro-based webservices from ServiceGrid is now available. With the SoapClient, it is possible to use our custom and core service through a standalone client.The client will be delivered with a detailed manual and usage guide and can also be adapted to fit special needs or can be used as a reference implementation of a metro-based soap client which can communicate with SD core and custom webservice.

To obtain the new SoapClient, please contact our support.

For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.

For other ServiceGrid Release Notes, go to ServiceGrid Release Notes page.

Rating: 0.0/5 (0 votes cast)

Personal tools