ServiceGrid Article - Cisco ServiceGrid Release Notes V6.9

From DocWiki

Jump to: navigation, search

Contents

Overview

This Release Notes document describes the details of the new functions and features introduced with the new Version 6.9 of the Cisco ServiceGrid platform.
The described functions are implemented with the Spring Release 2014 on March 9th.

Release Notes v6.9

This document describes the new functions of the Cisco ServiceGrid application as introduced in the Spring Release 2014, Version 6.9.
Additionally, this document does the following:

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

Release Dates

The following described functions of the Spring Release 2014 (Version 6.9) were available on Sunday afternoon 9th March 2014 to all customers using the Cisco ServiceGrid main platform (sdcall.solvedirect.com). This release is in production on the Cisco ServiceGrid support platform from March 6th 2014. All customers running their own infrastructure (in house) or using a Cisco partner infrastructure will receive the release on a later date. Those updates will take place after the update of the Cisco ServiceGrid main platform.

Get the date of your update from your implementation partner.

Availability and licensing of new functions and modules

With the update, all new functions and modules are installed on all the platforms.

New functions and modules which are part of the general update will be available to all customers of that 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 may need to be licensed separately before using in customized system.

Summary

The following is a summary that gives a brief insight into the new functions introduced with the 6.9 release:
Cisco ServiceGrid Portal

  • Usability enhancements of lists
  • Multiple custom filter for lists
  • Display history of service cases in ticket list
  • Improved portal administration

Cisco B2B Connection

  • Maintenance mode for web service bridges
  • Extended mail attachment processing

Cisco ServiceGrid Portal

Usability enhancements in lists

 

Image001 6.9.jpg


1. Custom filters are available in the Quick Search and more than one can be defined. More details can be found in Chapter 3.2.
2. The custom filter can be reset to its original stored value. More details can be found in Chapter 3.2 / 3.6.
3. A mode selector can be set up to switch between TreeMode and HistoryMode. More details can be found in Chapter 3.3.

This is also available in the Advanced Search:

Image002 6.9.jpg

4. New custom filters can be created in the Advanced Search. More details can be found in Chapter 3.2.
5. When submitted in the Advanced Search, only the current filter choices for the list are submitted, and the choices are not stored in the filter.

To store changes in the Custom Filter, click Save at the top of the Advanced Search window. More details can be found in Chapter 3.2.
6. Clicking on a column header changes the sorting of the list and this is also reflected in the Quick Search. More details can be found in Chapter 3.5.
7. The drop-down box which loads the next X entries of the list, can load either the next 25, 50, or 100 entries. More details can be found in Chapter 3.4.


Image003 6.9.jpg



Multiple custom filters in lists

Reason

Since many users need to use more than one customized filter for their daily work to switch between common tasks, current release introduces a possibility to store up to ten custom filters with a name of up to 20 characters. The Advanced Search panel was modified for this purpose.

How does it work?

In the Advanced Search panel, the original Save & Submit was replaced with Delete and Save buttons.

Image004 6.9.jpg


Buttons are enabled or disabled in the context of the combo box on their left, which contains all possible defined filters, including the default one as default.
Choosing an existing filter (except the default one) enables the buttons, where Delete removes and Save updates this chosen filter. Modifying the name to a non existing one disables the Delete button, while the Save button creates a new filter. Default filter cannot be changed or removed.
If the limited number of filters or filter name length is exceeded, the combo box is marked as invalid (red border) and the tooltip (on mouse-over) shows the problem description.

Image005 6.9.jpg


The user can always submit the filter values with or without saving them, which applies the current criteria to the list and updates on the left panel (Quick Search) in the List window.
The Quick Search panel now also contains the already defined filters for the user to easily switch from one filter to another without going into the Advanced Search panel.

Image006 6.9.jpg


If a change is made directly inside Quick Search, the chosen record inside this filter combo is marked as changed (yellow border and corresponding tooltip on mouse-over). If the user wants to save this changed filter, he can again switch to Advanced Search, give this filter a new or existing name, and save it.

Image007 6.9.jpg

When reopening the list, the last used saved filter will be taken as the default one.

In addition, two more things were changed in advanced search panel:

  1. Changing the visibility of column (for the list) was removed and can be now changed only in the list context menu (clicking arrow in the header of any column of the list, then Columns menu item, then check/uncheck the checkbox).
  2. Renaming of the columns in advanced search panel. This was now moved to the already mentioned context menu as a new feature – a text area where you can change the name directly.

The following screenshot shows the old functionality:

Image008 6.9.jpg

And this is the new functionality:

Image009 6.9.jpg

Display callhistory in ticket list

Reason

To view values of older versions of the ticket (CallHistory) in the Portal, it is necessary to open the CallDetail and view the history in the right frame.
The history entries of tickets are now available in the CallList in order to enable faster access.

How does it work?

When a CallList is configured (through its Setup) for HistoryMode, an expander icon: Image024 6.9.jpg is shown in front of each line which contains a ticket with history entries. Clicking this expander icon opens new lines. Each line shows the values for a history entry of the ticket.
A CallList can be either in HistoryMode or in TreeMode. This means that clicking the expander icon will either open to show lines with history entries or with children. You cannot combine these two modes.

Setup

Existing setup master data features are used to set up the CallList for history view:
To setup the list, follow these steps:
Step 1: Click the name of the Tracking: Calls-List setup which you want to configure
Step 2: Click Change the setup master data to access the general features of the setup.
In the left column, you will find the two relevant checkboxes as highlighted in the diagram below:

Image010 6.9.jpg

  • ShowHistory: When this feature is checked, the CallList will be loaded in HistoryMode; Otherwise, it will be loaded in TreeMode.
  • HasHistoryChoice: When this feature is checked, a mode selector (displayed in the image below) will be shown in the Quick Search and in the Advanced Search.

Image011 6.9.jpg

This selector enables a quick switch from HistoryMode to TreeMode and vice versa. When the HasHistoryChoice checkbox is not checked, the mode selector would not be shown and hence, the portal user cannot change the mode of the list.
The selected mode of the list is stored within the Custom Filter (see Chapter 3.2). In this way, the portal user can overwrite the setup-values for ShowHistory.

Selectable number of fetched records in lists

Reason

Until now, the drop down box which loads the next X entries in every list has retrieved 25 more entries, which can be tedious with very large lists.

How does it work?

The new drop down box is at the same position as the previous one. If the drop down box is clicked by default, 25 more entries are loaded. Additionally, when the arrow is pressed, you can choose to load 50 or 100 more entries.
Image012 6.9.png


One click sorting in lists

Reason

To further improve the usability of the new lists in the portal, a quick sorting feature has been developed in this release.

How does it work?

Clicking the header of a column will lead to sorting of the list automatically by this column in ascending order. The column is also added to the quick filter to reflect the current filtering and sorting state.
Additionally, a small icon will be displayed next to the column header, indicating whether the list has been currently sorted by this column.
Image013 6.9.png

Reset Filter of lists

Reason

With this release, the feature of storing multiple custom filters has been implemented. The reset filter functionality was added alongside this feature, allowing the current filter to be reset to a previously stored state.

How does it work?

Click Reset Filter. Your filter values will be reset to the currently selected filter.

Image014 6.9.png

Improved portal administration

Reason

In an effort to harmonize the features of all lists, portal-style lists have been integrated in portal administration as well.

How does it work?

The following lists have been updated:
Before selecting a role:

  • Setup
  • User

After selecting a role:

  • Setup
  • Users
  • Callactions

These lists now have support for the well-known functions of portal lists such as storing custom filters, quick filtering, advanced search window, dynamically changing the layout, and so on.

A function specifically developed for portal administration is the server-side selection of all records that match some filter criteria. When trying to manage a large number of records, it is not desirable to display all records to be updated in a list. To avoid displaying all records, one can toggle the Select all records button on top of the list. Image015 6.9.png

When using another action of an administration list (for example, Assign to Role), it will be performed for all records matching the current filter criteria.
Selecting some records manually (through the checkboxes besides each record) will de-toggle the Select all records button.


Reload window option in navigation tree

Reason

Every browser offers a refresh functionality (usually by pressing F5), which reloads the whole page. As this feature cannot be effectively used in the portal because of multiple windows that display multiple pages, a refresh functionality for dashboard windows has been implemented.

How does it work?

Right-click an element in the navigation tree and click Reload Window. If the selected element is currently visible in the dashboard, it will be reloaded, which means its initial state will be restored.

Image016 6.9.png

B2B Connections

Extended processing of incoming mail attachments

Reason

Previously, mails received through the organization’s inbox would only show non multipart attachments (in MIME parlance).

How does it work?

The state of only non-multipart attachments being shown by the mails in the organization's inbox has been changed wherein all attachments are now correctly recognized, even if they contain multiple parts by themselves.
Practically, this means that attached mails will now correctly show up as attachments. This occurs when a user wants to send a mail and drags and drops another mail into it. Until now, ServiceGrid would show the attachments contained within the attached mail. With this change, it will show the whole attached mail.
NOTE: The ServiceGrid application is not able to render attached mails within the browser. The users must open the eml files with their email client. This happens automatically when clicking them.

Maintenance mode for webservice bridges

Reason

A webservice bridge connects two endpoints with each other and is responsible for exchanging the data. When one of the endpoints is being maintained, it no longer responds correctly. In such cases, alerts were triggered and human action was needed to check the current situation.
To reduce the need for human interaction, the new Maintenance mode was introduced for webservice bridges. With this mode, the bridge behavior and its reaction to errors can be defined for a specified timeframe (Maintenance window).

How does it work?

A webservice bridge can be put into maintenance mode by defining a maintenance window for a specific timeframe. To do so, the Administrator needs to navigate to the ServiceDefinition of the webservice bridge through the following path:
Basicdata > MyCompany > [Company] > ServiceDefinitions > [ServiceDefinition]

Image017 6.9.png

A new TopFunction Display MaintenanceWindows has been added in the master data main menu in the Servicedefinition. Clicking on it displays a list of all defined maintenance windows for this ServiceDefinition/Webservice bridge.

Image018 6.9.png

When creating a new maintenance window two timestamps and two selectboxes can be defined.
StartTime and EndTime: Define the start and the end of the maintenance window respectively. Only the start time is mandatory. The maintenance mode is endless if no end time is defined. 
Reaction: Defines how a webservice bridge should behave when entering maintenance mode.
Immediate pause: Pauses the bridge instantly.
Delayed pause: Pauses the bridge when the first error occurs. It will be restarted at the given EndTime.
Behavior: Defines how a webservice bridge should behave when in maintenance mode.
Reject: The bridge does no longer accepts messages from the sending endpoint.
Queue: The bridge accepts messages and queues them. When the maintenance window has ended, the bridge tries to deliver the queued messages.
Image019 6.9.png

After a new maintenance window has been created or an existing one has been changed, it is necessary to reload the bridge. This can be done using the Reload Bridge function in the detailed form of the service definition.

Image020 6.9.png

The bridge will be reloaded automatically after the service definition has been saved.

Reject Message Example

When the defined behavior of a maintenance window is Reject, all outbound messages are rejected by the bridge when the maintenance window is active. For each rejected message, a feedback message is created. These feedback messages have to be handled by the ErrorTrigger of the callsystem.
An example of a feedback message is depicted below.

<SD.call>
<Error>
…
<State>Rejected</State>
…
<XMLInfoMessage>
<reject outboundCallId="463957439">
<consumed>Y</consumed>
<rejectReason>MaintenanceMode</rejectReason>
<message>
Message rejected - maintenance mode with behavior 'reject' enabled
</message>
</reject>
</XMLInfoMessage>
…
</Error>
</SD.call>

The following two fields are set as the message has been rejected:
ErrorState: value is set to Rejected
XMLInfoMessage: This XML part contains the following information defined by the bridge:
Consumed: Y
rejectReason: MaintenanceMode
message: message defined by the bridge
By processing a reject message within the template of the error communication, a customer-specific response can be created for rejected messages due to a maintenance window.

The response workout has to be implemented through the Messagerules and needs extended ServiceGrid Bridge Knowledge.

A new communication within the Error Trigger has to be implemented.
You should restrict the send behaviours through the Outbound Templates.

Browser-Policy

There are three browser classes defined:

Browser-
Class


Browser
Properties
1
Firefox (last two major versions)

Google Chrome (last two major versions)

IE11

  • Complete availability of product and application features (technician calendar, HTML-editor, and so on)
  • Graphical presentation (CSS layout)
  • No open browser related known errors
2
IE10
  • Limited availability of product and application features
  • Limited graphical presentation (CSS layout)
  • There may be browser related bugs/known errors
3
IE9
  • Limited availability of product and application features
  • Highly limited graphical presentation (CSS layout)
  • Open browser related bugs/known errors


This release has been tested with the following browser versions in accordance with the browser classes:

  • IE9, 10, and 11.
  • Firefox V25-27
  • Google Chrome V31-33 


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.

Download link: Cisco ServiceGrid Release Notes V6.9


Rating: 1.0/5 (1 vote cast)

Personal tools