ServiceGrid Article - Cisco ServiceGrid Release Notes V6.4
This Release Notes document describes the new functions of the Cisco ServiceGrid application as introduced in the Winter Release 2012, Version 6.4.
Additionally, it also provides the following features:
- Outlines the new functions and modules.
- Gives a brief look into how the new functions are implemented, administered, and used.
- Describes, in minor use cases, the benefits of the new functions.
- Describes how existing functions are extended or changed.
The following described functions of the “Winter Release 2012” (Version 6.4) were available since Sunday afternoon 16th of December 2012 to all customers using the Cisco ServiceGrid main platform (sdcall.solvedirect.com).
All customers running their own infrastructure (in house) or using a Cisco ServiceGrid partner infrastructure will receive the release on a later date. Those updates occur 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 the platforms.
New functions and modules which are part of the general update will become available to all customers of that platform.
- Some functions are automatically available to all users.
- Some functions or modules have to be configured or activated first.
- Some of the new functions and modules may have to be licensed separately before being used in customized systems.
This summary gives you a brief insight into the new functions introduced by the 6.4 release.
Cisco ServiceGrid Portal
- Redesign of the portal administration.
- Improvements in dashboard, favorites, and search function.
- More functionality and better usability in the portal call-list.
- Additional SD² functions available in SD.portal.
IT Service Management
- Enhancements in parent-child processing.
- Improvements for call processing in SD.mobile.
- Enhance Service Definitions.
Just like SD², the portal can be configured by an administrative user. The administration programs have been redesigned to reflect the common tasks and workflows when configuring the portal.
Several administration programs have been unified into this new portal administration - there is now a central function for portal administration, which contains administrative programs for all aspects of the portal. They use similar paradigms for editing users, setups, and access-rights through roles; hence, users can learn more quickly how to use these programs.
How does it work?
In the new Portal Administration, the following views to the portal are available:
User administration, setup administration, and the portal groups view are presented in tabs, where each tab features a sortable, groupable, and filterable list. It is also possible to hide some columns to get a clear view of the presented data.
Role administration features a whole track of tabs, where a role can be viewed and edited from different angles.
Here, an administrator can create, edit, and delete roles. First, select a role to edit. Alternatively, a new role can be created:
After selecting a role, several tabs specifically for that role are available. There are a user tab, a setups tab and a portal groups tab, which work very similar to the corresponding tabs in the general portal administration: the functions above the lists in the user tab and the portal tab will add/remove that one specific role that was selected at the role list.
Also, there is a tab for assigning default setups to roles. Each role can have a default setup for every available setup type; Additionally, there can be a default call detail setup for each available callsystem. When opening a form in SD² without specifying a setup, the default setup configured for the currently selected role will be used.
There are over 50 setup types which are divided among several subtabs. For each setuptype other than call detail, it is possible to specify at most one default setup, which will be the default setup among all callsystems.
Finally, callactions can also be assigned roles.
When a callaction—userrole—assignment has been done by an administrator, only those callactions which are valid for the current role of the user are displayed in calldetail.
This tab displays all users of an administrator's company in SD². These users can be made portal users by assigning them to a default role. Alternatively, a user will stop being a portal user when their default role is taken away.
When clicking one of the buttons above the list (add role, remove role, and set default role, respectively), a window will pop up to select the roles the action should be performed with. It is also possible to create a new role here.
This tab displays all setups available to the company of an administrator. Similar to the users tab, setups can be connected with roles. When a setup is assigned to a role, it can be used by a user having that role selected.
This tab gives an overview of all available portal groups and the roles they are assigned to.
Administrators that open the portal for the first time will automatically get a Portal Administration function in their top group.
Later, the function Portal Administration can be added to any group by right-clicking on the group in setup mode and selecting New Function..
After opening a window full screen in the portal, it was not possible to go back to the last displayed dashboard. Instead, when the window was closed, an empty dashboard was presented.
Since an empty dashboard serves no real purpose, closing a full screen window will now return the view to the last viewed dashboard.
Until now, all elements of a portalgroup are displayed in the dashboard. With the new release, it is possible that an element can be hidden in the dashboard.
How does it work?
Every window that is opened fullscreen will not have a Close button any more. Instead, these windows will have a Show Dashboard button (which has a restore symbol). Clicking this button will restore the window's original size and show the last viewed dashboard.
In order a specific item should not display (or) to hide a specific item getting displayed on the dashboard you can remove it from the dashboard using the contextmenu of this element in the navigation tree on the left side.
No setup is required.
Improvements in maintenance of my favorites
Users want to clearly and easily see which portal entities are used as favorites. They should be able to remove and add them in different ways.
How does it work?
All entities of the portal – groups and elements – can be marked as favorites. Once marked, they can be accessed from the “favorites area” which opens up in the tree when the favorites tab in the main menu is clicked.
There are several ways to add entities to and remove entities from the favorites. They are shown in the following screenshots.
This also works in the search list.
The favorites can be seen in the favorites area. There they can be removed by right-clicking in the tree.
No setup is necessary. The add/remove functions as well as the favorites area are always available.
Improvements of search function
Since the originally designed SEARCH field/functionality in version 6.2 improvement proposals were collected. Version 6.4, implements some of these and extends the basic implementation.
How does it work?
The current version of Search offers the following improvements:
In the FAVORITES tab, a new group is introduced. This group contains the history of the last 10 search queries.
Queries are ordered in a way, that the latest query made is at the top most entry.
When calling SEARCH from the top group, or from the result window itself, the application navigates to the search history and marks the last query.
The User can recall one of those 10 history queries by clicking the item in the left tree.
- In case of clicking the history entry, the order of the items is not changed. (The 5th entry stays 5th also after the click was made.)
- As the last search query is also displayed in the search field, the user can put it in the most recent position (top of the search history) by submitting it from the search field itself. In this case, the entry is moved to the most recent position.
After submitting a 11th record to the history, the oldest history file is automatically removed. It is possible to remove items also by using right-click and the context menu.
In addition to the above, few more functions are listed below:
- Some minor layout changes have been implemented (column number, column sizes).
- Search also supports last dashboard feature.
- Search supports standard add to/remove from favorites feature (see above).
No special setup is required. Records are queued automatically.
Enhancements of portal call-list
This version of the call list is an enhancement of the version that has been delivered with 6.3. Its main purpose is to support the user in an intuitive and productive way to filter, sort and group calls.
How does it work?
The first improvement is that the user is able to select the type of operator a field has to be filtered with:
The user has several choices to select from:
- IS: The query will search after the exact expression is chosen from the drop-down list.
For example: If “Order” is entered in the textbox, it will find all calls that have exactly that value in the corresponding column.
- LIKE: This operand gives the user the possibility to define wildcards. Wildcards can be set with the “%”-sign (Percent).
For example: “Ord%” will find “Order” as well as “Ordinal”.
- IN: When you are searching with “in” you can define multiple values to search for. It is not possible to put any wildcards here. Values can be separated with the “,”-sign (comma).
For example: “Order, Incident” will find all calls that have Order or incident in the column.
- NULL: This operand does not take care about the value in the text input. It searches for all Calls that do not have a value in this column.
- NOT NULL: This operand does not take care about the text input either. It searches for all Calls with any value in this column.
Depending on the type of column, you can have different types of input fields:
- Text columns have a simple text input field where the user can enter a search string.
- Number fields have two input fields that accept only numbers. The first field is for the lower, and the second field for the upper bound of the number. You can also increase and decrease the number with the up and down arrows on the keyboard, or with the tiny up and down arrows on the right edge of the field. You need not enter both the fields.
- Fields representing a date will have two input fields too. Again, the first input is for the lower bound, and the second input is for the upper bound of the searched values. It is not necessary to enter a date in both the fields. To support the user in entering a date, the user can open a calendar and select one.
- Some fields assist the user in selecting a date by providing all valid values.
- The SdCallId is a special field. It is numeric, but has only one input field. (The assumption was that users want to search for a specific Call, not for a range of Calls.)
Portal supports the user in selecting multiple values from the drop-down lists:
As soon as the user selects more than one value from the drop-down list, the operand automatically changes to IN. If there is only one selected value, the system automatically changes the operand to IS. Furthermore, it enters the values into the textbox. Other improvements affect the advanced search window.
For a description of the basic functionality, refer to the SD Release Notes 6.3 document.
Most of the features of the simple search are also available in the advanced search:
Search Mode/type of operator for text fields, double number field, drop-downs, icons.
Additionally, the logical operator can be chosen in the advanced search. If more than one field is used as filter criteria, you can choose if all calls that conform to at least one criteria (Or) or only those that conform to all of the criteria (And) are displayed. The default selection is And.
Filters can now be saved. They are stored on the user level, meaning that each user can define their own filters. If no filter name is entered, the default filter name custom is used. The current settings in the advanced search window are saved under the filter-name when Save & Submit is clicked.
If you click on Save, the stored filter is not changed. Only the search criteria of the current search are altered. In both cases, the list is submitted and the search performed.
The filter can be deleted with the Delete button right next to it. You can get back to the original filter by choosing default from the filter drop-down list.
Parent-Child relations are displayed by default. A small triangle pointing to the right indicates that a call has children. Clicking this symbol opens this call, and the information for the children is loaded. Calls without children have no symbol.
Children are ignored in the list functions such as filtering, ordering, grouping. Calls may be displayed several timestimes. For example, once at the first level and a second time as child of another call.
To enable the Call List in the new look, choose Portal in the Setup Administration.
As soon as you have selected a setup as well as Portal as the display style, you get a list of fields that are not supported and cannot be displayed.
New options for Switch to SD² function
Already it is possible to switch from the portal to SD². In this case the same menu entry will be activated after logging into SD². With the new options for this function, it is possible to jump directly into a specific menu or program from the portal. The user does not have to select the specific function manually.
How does it work?
If options for main menu and submenu are set in the Switch to SD² portal element, the user will be redirected to this function directly. (But only if he is allowed to use this function in SD².) If the user is allowed to use the selected mainmenu and is not allowed to use the selected submenu the user is redirected to the first visible function within this mainmenu. If the user is not even allowed to use the selected mainmenu the default function will be activated after switching to SD². It is also possible to redirect a user into a toplevel cockpitgroup of SD.cockpit.
In the administration of the portalelement a specific main menu and a specific submenu can be set for the Switch to SD² function.
All toplevel cockpitgroups are available if SD.cockpit is selected as mainmenu.
MyCustomer/MyProvider list as portalelement
Until now a portalelement can be created which displays an organization list. In this list, all organizations will be displayed to which the user belongs to. But it was not possible to display an organization list with all customers or providers of the user as in SD² under the menuentries MyCustomer or MyProvider.
How does it work?
Which organizations will be displayed depends on the option in the portal element:
- MyOrganizations: displays all organizations of the user.
- MyCustomers: displays all customer organizations of the user.
- MyProviders: displays all provider organizations of the user.
After one organization has been selected, the detail form with the masterdata of this organization is displayed. If the organization has been selected in a customer- or provider list, the master data can be changed if this organization belongs to the rootcompany of the user. If the organization has been selected in an organization list, the data of this organization can be changed by the user anyway because this user is a member of the selected organization.
The output of the organization list has to be set in the portal setup when creating a portal element with a setup of the type Administration: Organization-List. The corresponding option has to be selected.
Workflow depending on portal role
In SD², it is possible to define callactions which can only be used by certain permissiongroups and which are not valid for all users. The portal does not use the permission groups, but the roles. Therefore, the need arose to restrict certain actions to certain roles.
How does it work?
If a callaction is assigned to one or more portal roles, this action can only be used by users who work in one of these roles. These callactions are not visible for other users.. A callaction is valid for all users if this action is not assigned to any roles.
In the portal administration in the CallActions tab, the assignment of callactions to roles can be done. With a mouse-click one role will be selected. For selecting more roles use the Ctrl or Shift key. The selection function will be executed for all assigned roles.
Customer/Provider role defined in the portal role
Currently, the user has that role which he has selected at login time to the portal. Compared to SD², the user was not able to switch between customer and provider role.
How does it work?
When logging in to the portal, or when switching the portal role, the user gets that role which is assigned to the user role. If the user wants to switch from customer to provider role or vice versa it is necessary to switch to another portal role.
That means that a user has to be assigned at least to two portal roles for working as customer or as provider.
The customer or provider role can be defined in the administration program of user roles.
Display name of logged user
Until now, the name of the current user could not be displayed in the portal.
How does it work?
The name of the current user is displayed, if a portal element using the function Current User has been created in the topmenu folder.
To display the name of the current user in the top area, the function Current User should be added as portal element to the top menu.
IT Service Management
Enhance Service Definitions
Technical Operations needs information what should be done when a defined bridge does not work. Therefore, the Cisco ServiceGrid PMC or the customer who creates a service definition must fill out the field description and owner with useful information about what to do in case of a problem with the connection.
To make Phoenix Bridges behavior setup for a single service definition, some timeout and threshold fields are added to the setup.
How does it work?
- The owner field should be filled with the person who has detailed information about the bridge setup. This person can be called, when technical operations cannot get the bridge running again.
- The description field is a free form text field that can either contain a text with all contact persons, description of the connection, escalation lists, and so on, or it could also be a link to a Wiki or any website.
- The fields which are needed for the Phoenix Bridge behavior are set to 0 to run the bridge with default settings.
New fields available in outbound messages
Sometimes it is needed in outbound templates to create the outbound message depending on the state of children or sibling calls. Therefore, the most important fields have been added to the outbound fields and can be used in the outbound template. (Children are those calls that have the current call as their parent. Siblings are those that have the same parent as the current call.)
How does it work?
These fields of child calls are available and can be used in outbound templates:
| Label|| InternerFeldName|| Beschreibung|
| ChildID|| /SD.call/Children/ID|| SDCallID of children.|
| ChildRequestType|| /SD.call/Children/RequestTypes/ShortName|| The shortname of the requesttype of child call.|
| ChildRequestTypeName|| /SD.call/Children/RequestTypes/Name|| The name of the requesttype of child call.|
| ChildContract|| /SD.call/Children/Contracts/ShortName|| The shortname of the contract of child call.|
| ChildContractName|| /SD.call/Children/Contracts/Name|| The name of the contract of child call.|
| ChildContractElement|| /SD.call/Children/ContractElements/ShortName|| The shortname of the contractelement of child call.|
| ChildContractElementName|| /SD.call/Children/ContractElements/Name|| The name of the contractelement of child call.|
| ChildCustomerCallstate|| /SD.call/Children/CallStatesCUS/ShortName|| The shortname of the customer callstate of child call.|
| ChildCustomerCallstateName|| /SD.call/Children/CallStatesCUS/Name|| The name of the customer callstate of child call.|
| ChildProviderCallstate|| /SD.call/Children/CallStatesSPR/ShortName|| The shortname of the provider callstate of child call.|
| ChildProviderCallstateName|| /SD.call/Children/CallStatesSPR/Name|| The name of the provider callstate of child call.|
| ChildCustomerPriority|| /SD.call/Children/PrioritiesCUS/ShortName|| The shortname of the customer priority of child call.|
| ChildCustomerPriorityName|| /SD.call/Children/PrioritiesCUS/Name|| The name of the customer priority of child call.|
| ChildProviderPriority|| /SD.call/Children/PrioritiesSPR/ShortName|| The shortname of the provider priority of child call.|
| ChildProviderPriorityName|| /SD.call/Children/PrioritiesSPR/Name|| The name of the provider priority of child call.|
| ChildCustomerSeverity|| /SD.call/Children/SeveritiesCUS/ShortName|| The shortname of the customer severity of child call.|
| ChildCustomerSeverityName|| /SD.call/Children/SeveritiesCUS/Name|| The name of the customer severity of child call.|
| ChildProviderSeverity|| /SD.call/Children/SeveritiesSPR/ShortName|| The shortname of the provider severity of child call.|
| ChildProviderSeverityName|| /SD.call/Children/SeveritiesSPR/Name|| The name of the provider severity of child call.|
| ChildCustomerProblemType|| /SD.call/Children/ProblemTypesCUS/ShortName|| The shortname of the customer problemtype of child call.|
| ChildCustomerProblemTypeName|| /SD.call/Children/ProblemTypesCUS/Name|| The name of the customer problemtype of child call.|
| ChildProviderProblemType|| /SD.call/Children/ProblemTypeSPR/ShortName|| The shortname of the provider problemtype of child call.|
| ChildProviderProblemTypeName|| /SD.call/Children/ProblemTypesSPR/Name|| The name of the provider problemtype of child call|
| ChildCustomerFailureType|| /SD.call/Children/FailureTypesCUS/ShortName|| The shortname of the customer failuretype of child call.|
| ChildCustomerFailureTypeName|| /SD.call/Children/FailureTypesCUS/Name|| The name of the customer failuretype of child call.|
| ChildProviderFailureType|| /SD.call/Children/FailureTypeSPR/ShortName|| The shortname of the provider failuretype of child call.|
| ChildProviderFailureTypeName|| /SD.call/Children/FailureTypesSPR/Name|| The name of the provider failuretype of child call.|
| ChildDescription|| /SD.call/Children/Description|| The description of child call.|
| ChildRemarks|| /SD.call/Children/Remarks|| The remarks of child call.|
| ChildDiagnosis|| /SD.call/Children/Diagnosis|| The diagnosis of child call.|
| ChildSolution|| /SD.call/Children/Solution|| The solution of child call.|
These fields of sibling calls are available and can be used in outbound templates:
| Label|| InternerFeldName|| Beschreibung|
| SiblingSDCallID|| /SD.call/Siblings/ID|| The sdcallid sibling call.|
| SiblingRequestType|| /SD.call/Siblings/RequestTypes/ShortName|| The shortname of the requesttype of sibling call.|
| SiblingRequestTypeName|| /SD.call/Siblings/RequestTypes/Name|| The name of the requesttype of sibling call.|
| SiblingContract|| /SD.call/Siblings/Contracts/ShortName|| The shortname of the contract of sibling call.|
| SiblingContractName|| /SD.call/Siblings/Contracts/Name|| The name of the contract of sibling call.|
| SiblingContractElement|| /SD.call/Siblings/ContractElements/ShortName|| The shortname of the contractelement of sibling call.|
| SiblingContractElementName|| /SD.call/Siblings/ContractElements/Name|| The name of the contractelement of sibling call.|
| SiblingCustomerCallstate|| /SD.call/Siblings/CallStatesCUS/ShortName|| The shortname of the customer callstate of sibling call.|
| SiblingCustomerCallstateName|| /SD.call/Siblings/CallStatesCUS/Name|| The name of the customer callstate of sibling call.|
| SiblingProviderCallstate|| /SD.call/Siblings/CallStatesSPR/ShortName|| The shortname of the provider callstate of sibling call.|
| SiblingProviderCallstateName|| /SD.call/Siblings/CallStatesSPR/Name|| The name of the provider callstate of sibling call.|
| SiblingCustomerPriority|| /SD.call/Siblings/PrioritiesCUS/ShortName|| The shortname of the customer priority of sibling call.|
| SiblingCustomerPriorityName|| /SD.call/Siblings/PrioritiesCUS/Name|| The name of the customer priority of sibling call.|
| SiblingProviderPriority|| /SD.call/Siblings/PrioritiesSPR/ShortName|| The shortname of the provider priority of sibling call.|
| SiblingProviderPriorityName|| /SD.call/Siblings/PrioritiesSPR/Name|| The name of the provider priority of sibling call.|
| SiblingCustomerSeverity|| /SD.call/Siblings/SeveritiesCUS/ShortName|| The shortname of the customer severity of sibling call.|
| SiblingCustomerSeverityName|| /SD.call/Siblings/SeveritiesCUS/Name|| The name of the customer severity of sibling call.|
| SiblingProviderSeverity|| /SD.call/Siblings/SeveritiesSPR/ShortName|| The shortname of the provider severity of sibling call.|
| SiblingProviderSeverityName|| /SD.call/Siblings/SeveritiesSPR/Name|| The name of the provider severity of sibling call.|
| SiblingCustomerProblemType|| /SD.call/Siblings/ProblemTypesCUS/ShortName|| The shortname of the customer problemtype of sibling call.|
| SiblingCustomerProblemTypeName|| /SD.call/Siblings/ProblemTypesCUS/Name|| The name of the customer problemtype of sibling call.|
| SiblingProviderProblemType|| /SD.call/Siblings/ProblemTypeSPR/ShortName|| The shortname of the provider problemtype of sibling call.|
| SiblingProviderProblemTypeName|| /SD.call/Siblings/ProblemTypesSPR/Name|| The name of the provider problemtype of sibling call.|
| SiblingCustomerFailureType|| /SD.call/Siblings/FailureTypesCUS/ShortName|| The shortname of the customer failuretype of sibling call.|
| SiblingCustomerFailureTypeName|| /SD.call/Siblings/FailureTypesCUS/Name|| The name of the customer failuretype of sibling call.|
| SiblingProviderFailureType|| /SD.call/Siblings/FailureTypeSPR/ShortName|| The shortname of the provider failuretype of sibling call.|
| SiblingProviderFailureTypeName|| /SD.call/Siblings/FailureTypesSPR/Name|| The name of the provider failuretype of sibling call.|
| SiblingDescription|| /SD.call/Siblings/Description|| The description of sibling call.|
| SiblingRemarks|| /SD.call/Siblings/Remarks|| The remarks of sibling call.|
| SiblingDiagnosis|| /SD.call/Siblings/Diagnosis|| The diagnosis of sibling call.|
| SiblingSolution|| /SD.call/Siblings/Solution|| The solution of sibling call.|
<call> <id> ... <siblings nr="1"> ... </siblings> <siblings nr="2"> ... </siblings> <children nr="1"> ... </children> <children nr="2"> ... </children> ... </id> </call>
If at least one child field and one sibling field is used in the outbound template, these fields will be added to the outbound XML. This will be shown in the field structure of the master data of the template.
To prevent performance issues in the outbound processing, some limits have been defined:
- Outbound messages using children or sibling data will only be created if the maximum of 50 children or siblings is not exceeded.
- If more than the maximum number of calls are related to the current call, an error will occur during creating of the outbound messages and instead an error message will be sent.
- A maximum of 999 characters will be sent for the fields Description, Remarks, Diagnosis, and Solution.
Predefine setup for creating a parent call
In certain cases, the user must create a parent call during executing a callaction.
How does it work?
If it is customized in the callaction a contractelement- or a device list will be displayed after saving the call. In this list, the contractelement or the device, can be selected for which a parent call should be created.
After selecting the contractelement or the device, the parent call will be created in the background automatically.
This function can be customized in the master data of the callaction. The following two things should be done:
- Activate Create Parent.
- Select a contractelement setup or a device setup.
NOTE: This works only with contractelements, not with service items.
Define start callaction depending on contractelements
Until now, it has only checked if a callaction is valid for a certain contractelement when a call was updated. This validity has been ignored when a new call was created. With this release, the assignments between callactions and contractelements will also be considered by all new call functions which select, directly or indirectly, a contractelement before opening the new call form.
How does it work?
To create a call, start callaction is needed. When the system searches for that callaction and the contractelement is already defined at this time, the start action will only be used if it is valid for this contractelement.
The contractelement can be defined before the startaction will be selected by using the function
- New Call by SLA
- New Call by Device
- New Call by Solution
- New Call by Contract
A callaction is valid for a contractelement if it is valid for the following:
- All contractelements.
- All assigned contractelements and the selected contractelement is assigned to that callaction.
- All unassigned contractelements and the selected contractelement is not assigned to that callaction.
The assignment of contractelements to callaction can be done in the administration of callactions within the callsystems section in SD.basicdata > MyCompany.
The assignment can be changed in the table where the assigned contractelements are displayed.
Enhancements of call processing in SD.mobile
Until now some features of call processing in SD² were missing in SD.mobile. The following functions are available in SD.mobile now:
- Dependencies of extended fields.
- Option HideIfEmpty of setupfields is considered.
- Callactions are only displayed if a mobile calldetail is defined for this action.
- Link on URL fields will be rendered.
How does it work?
All these features will work in SD.mobile in the same way as in SD².
There are no specific settings needed in calldetail setup. If these settings are used in a mobile calldetail setup, they will work in SD.mobile as well.
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.