ServiceGrid Article - Cisco ServiceGrid Release Notes V6.11

From DocWiki

Jump to: navigation, search

Contents

Overview

These Release Notes document describes the details of the new functions and features introduced with the new Version 6.11 of the Cisco ServiceGridTM platform.
The described functions are implemented with the Fall Release 2014 on October 26th.

Release Notes V6.11

This document describes the new functions of the Cisco ServiceGrid application as introduced in the Fall Release 2014 / Version 6.11.

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 small use cases, the benefits of the new functions.
  • Describes how existing functions are extended or changed.

Release Dates

The Cisco ServiceGrid functions of the Fall Release 2014 (Version 6.11) are available on October 26, 2014 Sunday afternoon to all customers using the Cisco ServiceGrid main platform (sdcall.solvedirect.com).
This release is in production on the Cisco ServiceGrid support platform from October 26th 2014.
All customers running their own in house infrastructure, or using a Cisco partner infrastructure will receive the release on a later date. These updates will take place after the update of the Cisco ServiceGrid main platform. Contact your implementation partner for the date of your update.

Availability and licensing of new functions and modules

With the update, all new functions and modules are installed on the platforms.
New functions and modules which are part of the general update are available to all customers of that platform.

  • Some functions are automatically available to all users.
  • Some functions or modules must be configured or activated first.
  • Some of the new functions and modules might be licensed separately before being used in customized systems.

Summary

The following is a summary giving a brief insight into the new functions introduced with the 6.11 release.
Cisco ServiceGrid Portal

  • Performance improvements of tickets lists
  • Usability improvements of message rules administration
  • “Forgot password” function

Cisco B2B Connection

  • Maintenance mode for web service bridges
  • Handling messages rejected due to a maintenance window

Cisco ServiceGrid Portal

Forgot Password Feature

Reason

In earlier releases of Cisco ServiceGrid, if a user forgets his password, the user should contact his administrator to reset the password.

How does it work?

Starting this release, the user can also reset the password using the “Password Reset” functionality, provided this functionality is enabled for the user. To reset the password, the user should click the link “Forgot your password” on the login page. The password reset form is displayed.

Image01 6.11.png

In this form, your login name must be entered. If an email address is defined for your user, an email is sent to you.

Enabled Password Reset

If the feature “Password reset” is enabled for your company, the email will contain a reset password link.

You've requested a password reset.

The link below will direct you to a form where you can set your new password:

https://sdcall.solvedirect.com/portal/templates/forgotPassword?t=zZP3xK7hHAt8wVkXfHcRy0xChbobHxQMx3pNBoa13hAMEcjEbtmnzioFahvUuBDMEehomQr9SlCCJJ80F6ejkg==

Please contact your administrator, if you haven't initiated this process!

Thank you, ServiceGrid Support Team


This link is valid for one hour.
After clicking the link in the email, the form to enter your new password is displayed.
Image02 6.11.png

After entering the new password, you will be logged in automatically if the new password matches the password policy of your company.

Password Reset feature is disabled

If the feature “Password Reset” is disabled, you cannot change your password by yourself. You will get information that you should contact your administrator to change your password.

Thank you for your request to reset your password.
Your Administrator doesn't allow Users to reset their own passwords at this time.
The Administrator has received your request and will be contacting you shortly to assist you with resetting your password.

Thank you, ServiceGrid Support Team

Additionally, an email is sent to the administrator to inform that you need a new password.

The user with the eMail address harry.helpman@ric.com requested a new password for at1.solvedirect.com.

Please initiate the reset password process.

Thank you, ServiceGrid Support Team


Setup

In the password policy of the company, it can be defined whether a user is able to reset his password.

Image03 6.11.png

Performance Improvements of Ticket List

Reason

Based on which fields are used, the ticket list might be slow until the result is displayed. To reduce the time until the user gets the result on the screen, a new display mode has been implemented.

How does it work?

Starting this release, the ticket list can be displayed in list mode only. This means that neither children nor history records are displayed. This mode is similar to the list mode of the SD2 ticket list.
To switch between these display modes, a third view button has been added.

Image04 6.11.png

  1. Simple List: Only the current ticket record is displayed
  2. Tree: Children can be displayed, if available
  3. History: History can be displayed, if available

A user can change the default view mode by creating a user specific filter. The current selected display mode is stored as additional parameter of a filter.
Additionally, if tree or history mode is activated and if a ticket has children or history records, the calculation of the symbol is done in a second request so that the initial ticket is displayed before.

Setup

Which display mode is used by default can be defined in the setup master data.

Image05 6.11.png

If “ShowHistory” (1) is activated, the ticket list will be displayed in “History” mode. If “Tree” is selected as default view (2), the list will be displayed in “Tree” mode. For all other options, the list will be displayed in “List” mode. The option “graphic”, “table” and “template_link” are ignored for portal ticket lists.

The visible display mode buttons can be customized by these 3 checkboxes:

  • ListLink (3): activates List button
  • TreeLink (4): activates Tree button
  • HasHistoryChoice (5): activates History button

Usability Enhancements Message Rules Administration

Reason

To enable an administrator to work more efficiently, some functions or information are now available additionally on a higher level of the message rules function.

Faster Assignment of Existing Communication to aTrigger

From this release, an existing communication can be assigned to a message trigger without opening the detail form of the message trigger. A new function “Assign Communications” has been added to the communication split button on message trigger level.

Image06 6.11.png

Parameters of Triggers Displayed in the Trigger List

All parameters of a trigger are displayed in the message trigger list. Therefore, it is not needed to open the detail form of the message trigger to see which parameters are defined for a trigger.

Image07 6.11.png

Opening Template History from Message Rules Tree

In earlier releases, the history of a template could only be displayed using the split button of the XSL field within the detail form of the template. Starting with release 6.11, a further function “Template History” has been added to the template split button on template level so that it is possible to open the template history directly from the message rules tree.
Image08 6.11.png

Additional Columns in List of Service Definitions

Now it is visible in the list of service definitions, if response filter are defined for a service definition and the date of the next maintenance window for this service definition.

Image09 6.11.png

B2B Connections

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.

Handling Messages Rejected due to a Maintenance Window

Reason

In the first implementation of the maintenance window, customizing the needed message rules was required to process rejected messages within the workflow of the partner. Therefore, it was necessary to do this for each connected partner separately.
With this change, these settings should be done only once on the same side on which the maintenance window is defined.

How does it work?

If a message has been rejected due to a maintenance window, it will be processed by the system like an inbound message from that partner. This means that a call update will be executed and a new ticket history record will be created.

Setup

To be able to process a rejected message as inbound transaction, an inbound message rule must be created:

  • Inbound message trigger
  • Inbound communication

                - The type of this communication is “WebService REST/SOAP outbound”.
                - The service definition, which has defined the maintenance window, must be defined as sender for this inbound communication.

  • Inbound template

This is the rejected message which should be processed by the inbound template:

<reject outboundCallId="200033391">
     <consumed>Y</consumed>
     <rejectReason>MaintenanceMode</rejectReason>
     <message>
           Message rejected - maintenance mode with behavior &apos;rejectt&apos; enabled
     </message>
</reject>

Example of an inbound template:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/reject">
<CALL>
    <Calls.SDCallID>
         <xsl:value-of select="@outboundCallId"/>
    </Calls.SDCallID>
    <Calls.Remarks>
         <xsl:value-of select="rejectReason"/>: <xsl:value-of select="message"/>
    </Calls.Remarks>
    <CallStates.ShortName>Rejected</CallStates.ShortName>
</CALL>
</xsl:template>
</xsl:stylesheet>

Browser Policy

There are three browser classes defined:

Browser Class
Browser
Properties
1
Firefox (last 2 major Versions)

Google Chrome (last 2 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 error.


Following browser versions were tested for Release V6.11 in accordance  with the Browse classes:

  • IE11, IE10, IE9
  • Firefox V30-V32
  • Google Chrome V35-V37


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.11
















Rating: 0.0/5 (0 votes cast)

Personal tools