ServiceGrid Article - Cisco ServiceGrid Release Notes V8.0

From DocWiki

Revision as of 09:50, 11 February 2016 by Gpheiroi (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Introduction

Cisco ServiceGrid is an integration platform in the cloud for IT service management. It provides a scalable, highly secure, and faster way to integrate with everyone in your service ecosystem, and also meets your business requirements. It creates operational efficiencies that save you time and money, while simplifying the formation of your ecosystem so that you can collaborate faster.

This document describes the key features associated with the Cisco ServiceGrid Release 8.0.

This document contains the following sections:

  • Release Dates
  • System Requirements
  • New and Enhanced Features in Cisco ServiceGrid Release 8.0
  • Important Notes
  • Limitations and Restrictions
  • End-User License Agreement
  • ServiceGrid Documentation
  • Support Information
  • Related Articles

Release Dates

The Cisco ServiceGrid functions of the Release 2016 (Version 8.0) are available on January 24, 2016 to all customers using the Cisco ServiceGrid main platform SDCALL (sdcall.solvedirect.com) and January 31, 2016 to all customers using the platform SJC1 (sjc1.solvedirect.com).

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.

System Requirements

Cisco ServiceGrid Online application (Portal, SD2) is a web-based application and hence is accessible using a browser. The B2B connection uses the ITSM connection capabilities of the customers.

Table 1 Browser-Policy

Browser Class

Browser

Properties

1

Mozilla Firefox

(last two major versions)

Google Chrome

(last two major versions)

Internet Explorer 11

  • Complete availability of product and application features (technician calendar, HTML-editor, and so on).
  • Graphical presentation (CSS layout).
  • No open browser-related know errors.

2

Internet Explorer 10

  • Limited availability of product and application features.
  • Limited graphical presentation (CSS Layout).
  • There may be browser-related bugs/known errors.


The following browser versions were tested for Release 8.0 with respect to the browser classes:

  • Mozilla Firefox v41, v42
  • Internet Explorer v10, v11
  • Google Chrome v46, v47

NOTE: The Active SLA feature should be used with the most recent versions of all browsers provided in Browser Class 1 in Table 1, and while using Internet Explorer, “compatibility mode” must be deactivated.

New and Enhanced Features in Cisco ServiceGrid Release 8.0

The following features and enhancements are provided in Cisco ServiceGrid Release 8.0:

  • Rest APIs
    • Enhancements in Ticket APIs
    • Ticket History API
    • Ticket Events API
  • Mutual Authentication
    • Allowing Configuration of Certificates from UI
    • Administering Certificates
    • Assigning Certificates to System User
    • Assigning Certificates to Service Definitions
    • Handling Chain Certificates
    • Deleting Certificates
  • Bridge and Portal Enhancements
    • Display Bridge Status
    • Testing JavaScript Templates
    • Template Administration Enhancement
    • Defining Policy for Tickets API

Rest APIs

Enhancements in Ticket APIs

From release 8.0, all Tickets APIs are enhanced with the ability to filter date ranges on appropriate date fields. The date range filters such as “from” and “to” time intervals are defined for all list returning GET methods. For example, TicketList, HistoryList, and EventList. This new feature allows queries that can specify a range up to a date, from a certain date, or the range between two values.

Example Queries:

tickets/?openTimeUtc=ge=2012-01-01 12:00 or

tickets/?ge(openTimeUtc, 2012-01-01 12:00)


Both of these queries are equal and are supported. Here the 'ge' refers to greater equal, so the above queries will filter for all tickets with a openTimeUtc 
value equal to and greater than 2012-01-01 12:00


tickets/?openTimeUtc=le=2012-01-01 12:00 or

tickets/?le(openTimeUtc, 2012-01-01 12:00)


Both of these queries are equal and are supported. Here the 'le' refers to less equal, so the above queries will filter for all tickets with a openTimeUtc 
values up to and equal to 2012-01-01 12:00.


tickets/?openTimeUtc=ge=2012-01-01 12:00&openTimeUtc=le=2012-02-02 12:00 or

tickets/?ge(openTimeUtc, 2012-01-01 12:00)&le(openTimeUtc,2012-02-02 12:00)


Both of these queries are equal and either syntax is supported. The above queries will retrieve filter for all tickets with openTimeUtc 
values greater or equal to 2012-01-01 12:00 and less than equal to 2012-02-02 12:00. 

To be able to use this API, a valid access token must be fetched through the endpoint “/ws/rest/oauth/token”. For more details on this API, see Rest API documentation.

Ticket History API

In release 8.0, this is a new resource of the ServiceGrid REST services. This will be introduced using the GET method that will allow you to fetch all history records of one ticket or to fetch the detail of a single history record of a ticket. This API is useful if you want to build your own user interface for ticket management based on ServiceGrid data.

The following table provides the details of this API:

Method

API endpoint

Description

Get

/v1/ticket/{ticketId}/history/

This method is used to list all history records of one ticket. The id of the ticket is defined within the resource.


/v1/ticket/{ticketId}/history/{eventId}

With this method, one single history record of a ticket can be pulled. Both the id of the ticket and the id of the history record (eventId) are defined within the resource.


Example request for getting all history records of one ticket:

curl -i -H "Authorization: Bearer {auth-token} -H "Content-Type: application/json" -X GET https://{host}/ws/rest/v1/tickets/{ticketId}/history

To be able to use this API, a valid access token must be fetched through the endpoint “ws/rest/oauth/token”. For more details on this API, see Rest API documentation.

Ticket Events API

This is a new resource of the ServiceGrid REST services. This will enable the GET method to pull all new tickets and all ticket updates (“Ticket Events”) from ServiceGrid for a certain time frame. This API can be used if a B2B connection to a partner system is built using REST APIs. This API enables partners to catch all new tickets and all ticket updates that occurred within the requested time frame.

The following method is provided by this API:

Method

API endpoint

Description

Get

/v1/ticket-events/

This method is used to list all tickets and ticket updates and can be filtered with query parameters.


Example request for catching all events between 2015-12-23 08:10 and 08:15:

url -i -H "Authorization: Bearer {auth-token}" -H "Content-Type: application/json" -X GET 
https://{host}/ws/rest/v1/ticket-events?limit=20&editTimeUtc=gt=2015-12-23%2008:10&editTim eUtc=le=2015-12-23%2008:15'

NOTE: Spaces must be replaced with “%20” as in “2015-12-23%2008:15”, because they are not allowed within URL.

If there are more than 20 records available, you can pull the other pages using the next-link, which is provided in the link section of the response. A next-link is available as long as further records can be pulled with these filter parameters.

"_links" : [ {
"rel" : "prev",
"method" : "GET",
"href" :
"https://{host}//ws/rest/v1/ticket-events?since_id=200532291&max_id=999999999&limit=20&edi
tTimeUtc=gt=2015-12-23%2008:10&editTimeUtc=le=2015-12-23%2008:15"
}, {
"rel" : "next",
"method" : "GET",
"href" :
"https://{host}//ws/rest/v1/ticket-events?max_id=200532267&limit=20&editTimeUtc=gt=2015-12
-23%2008:10&editTimeUtc=le=2015-12-23%2008:15"
}, {
"rel" : "list",
"method" : "GET",
"href" :
"https://{host}//ws/rest/v1/ticket-events?limit=20&editTimeUtc=gt=2015-12-23%2008:10&editT
imeUtc=le=2015-12-23%2008:15"
} ]

To be able to use this API, a valid access token must be fetched through the endpoint “/ws/rest/oauth/token”. For more details on this API, see Rest API documentation.

Mutual Authentication

Allowing Configuration of Certificates from UI

In release 8.0, a new functionality is added in the ServiceGrid Portal UI to allow users with the administration privileges to configure SSL certificates out of the ServiceGrid UI.

Mutual authentication or a two-way authentication of client certificates refers to two parties authenticating each other at the same time. In terms of technology, it refers to the clients or users authenticating themselves to a server, which in turn authenticates itself to the user in such a way that both the parties are aware of the other’s identity.

Mutual SSL provides similar capabilities as SSL, with the addition of authentication of the clients, using digital signatures. When mutual authentication is used, the server would request the client to provide a certificate in addition to the server certificate issued to the client.

Mutual authentication is typically used when an additional level of security is required on top of a simpler and less secure password based authentication.

Administering Certificates

Starting release 8.0, a new function “Certificate Administration” is available within the Service Portal of Cisco ServiceGrid. This new function can be added through the context menu “New Function” in the Service Portal.

New function certs.png


This new function “Certificate Administration” provides you all the capabilities to administrate SSL certificates within ServiceGrid for inbound (incoming message traffic from a partner environment towards Cisco ServiceGrid) and outbound (outgoing message traffic from Cisco ServiceGrid towards a partner environment) connections.

Certs admin overview.png


The following main functions can be performed within this new function:

  • Upload public and private keys of certificates in standard base64 encoded PEM format.
  • Upload and parse certificates (For example, validate certification authority, certificate chain, and so on).
  • Upload a private key to an existing certificate.
  • List view of all uploaded certificates.
  • Assign a certificate to a company and a system user.
  • Edit basic fields of an uploaded certificate.
  • Delete a certificate after verifying that it is not assigned to a user or a service definition.

NOTE: Currently systems users, which are configured to use mutual authentication through SSL certificates, are not allowed to use alternative authentication methods such as OAuth2 or a password based authentication. In other words, mutual authentication users cannot use the ServiceGrid RESTful APIs until these APIs are enabled for SSL based authentication.

As a first step, the SSL certificate must be uploaded within the “Certificate Administration” as described in the following procedure:

Step 1: Click the Add button. A popup window appears.

Step 2: Select the option Browse from the popup window.

Step 3: Select the SSL certificate and click OK. This will upload the SSL certificate into Cisco ServiceGrid.

Cert upload.png


As a second step, basic fields such as “Name” and “Description” must be filled out and a Company must be assigned to this SSL certificate configuration. Automatically, the SSL configuration will be flagged as “Active”.

Company.jpg

The details of the SSL certificate can be seen in the section “SSL” Certificate:

  • Serial Number—calculated number issued by the certification authority.
  • Valid from - Valid to—validity period of the certificate.
  • ASN1—formal representation of the certificate content in ANSI standard.
  • PemBase64—base64 encoded content in PEM format.
  • Issuer—identifier of the certificate issuer.
  • Subject—identifier of the certificate owner.
  • FingerPrint—calculated hash sum to identify the content of the certificate.

Ssl certificate.png


Assigning Certificates to System User

For all inbound connections (incoming message traffic from a partner environment towards Cisco ServiceGrid) a SSL certificate must be assigned to a system user to enable a certificate based authentication. The SSL certificate can be associated with a system user by clicking the “Assign User” button. After assigning a system user, all the incoming message traffic applicable for this assigned user will use the SSL based certificate authentication.

Assign user.png


Assigning Certificates to Service Definitions

For all outbound connections (outgoing message traffic from Cisco ServiceGrid towards a partner environment) SSL certificates must be assigned to a Service Definition, which is pointing to a partner environment through a web service URL. The SSL certificate can be associated with a Service Definition by clicking the “Assign Service Definition” button. After assigning a Service Definition, all the outgoing message traffic linked to this Service Definition will use SSL certificate based authentication.

For outgoing SSL certificates, the validity period of these certificates can be defined. A “used from” and “used to” date must be defined. These dates should match with the expiry date of the certificate and their duration should lie within the validity period of this certificate.

NOTE: This feature is especially useful when certificates are uploaded prior to the period they are used for the authentication.

Adding service defintion.png

If a SSL certificate is setup properly for outgoing message traffic, the configuration must consist of a public and private certificate part. The private key can even be added later by pressing the menu button “Upload private key” or the certificate already contains a private key part from the beginning.

Edit cert.png


The read only check box “Private Key” indicates that the SSL configuration is containing a private key. The check box “Allowed for outgoing” must be marked before a Service Definition can be assigned to the SSL certificate. This check box can be only selected, if the SSL configuration contains a public and private key part.

If the read only check box “Certification Authority” is checked it indicates, that the certificate has been issued by a certification authority.

Handling Chain Certificates

From release 8.0, users can view all chain certificates in the section “certificates detail”. Users can click the “Certificate Chain Detail” link to display the “read only” details of a certificate. The certificate will be validated during the uploading process. An error will be displayed, if the chain is not valid or the uploaded file format will not be supported.

NOTE: Only the PEM format will be supported within release 8.0.

Cert chain.png


Deleting Certificates

To be able to delete existing SSL certificates, they first must be unassigned from the user for incoming message traffic and unassigned from a service definition for outgoing message traffic. A certificate can be deleted/unassigned from a user by clicking the “Unassign user” menu button. To delete a certificate, which has been assigned to a service definition, following actions must to be performed:

Step 1: Click the “Assign Service Definition” button. The following screen appears.

Delete service definition linkage.png


Step 2: Click the Delete button to delete the certificate from the service definition.

Bridge and Portal Enhancements

Display Bridge Status

Starting release 8.0, a new column “Status” has been added to the Service Definition list to indicate a more detailed view of the actual status of an outgoing B2B interface through a Service Definition. The status of outgoing B2B interfaces will be represented by the three colors of a traffic light signal.

Servicedefinition status.png

The three states are defined as follows:

  • Green—indicates that the Service Definition is set up properly and the bridge is running correctly.
  • Yellow—indicates that all assignments to a message trigger or communication have been set up properly, but one of these assigned items is currently not set to active.
  • Red—indicates that a mandatory assignment to a message trigger or communication is currently missing.

Template Administration Enhancement

Starting release 8.0, an “Apply” button is available. The users can click the “Apply” button to apply first the settings and then click the “Save” button to save the applied settings.

Apply button.png

NOTE: Only when the users are editing existing template entities, this new button will be displayed.

Defining Policy for Tickets API

Starting release 8.0, a ticket processing policy can be defined for the POST and PATCH methods of the Tickets API to set the default values and to check for the mandatory fields of a send message.

This ApiPolicy can be defined under Company / Setups / CallSystems / [CallSystem] / CallSetups / Ticket: ApiPolicy. Within the “CallSetups > Ticket: ApiPolicy”, it can be defined which fields should be mandatory (MAND) and which fields should be defaulted (DV), with a free definable string.

Policy.png


NOTE: In the example, the field “ShortDescription” and “Description” are mandatory fields and for the fields “Category1”, “Category2” and “ExTableValues/Field5”, default values have been configured. For the field “Category1”, the default value “Software” has been defined.

Default values define.png


To use the API Policy, it must be assigned to a “CallState” under Company / Setups / CallSystems / [CallSystem] / Workflow / CallStates. After the API Policy has been associated to the CallState, it will be visible in the CallState list.

API policy.png

NOTE: In this example, the policy “policy_test” has been defined for the callstates, “Level 1: Incident Created” and “Level 2: Incident Customer Replied”.

The policy will be applied as defined below:

  • When a ticket is set to a CallState for which a policy has been defined, the policy will be loaded.
  • All the mandatory fields are checked and default values will be applied.
  • If a mandatory field has not been provided, the request will be rejected and an error message will appear indicating the missing fields.
  • If a field is not being sent within the request, for which a default value has been defined, then the default value from the policy will be picked. If the field is sent within the request, then this value will be used instead of picking the default value from the policy.

NOTE: In our example, the incoming request got rejected, because the field “description” has been defined as a mandatory field.

{

"shortDescription": "shortDescription", "contract": {"shortName": "PolKiel-INC" },

"contractElement": {"shortName": "INC-Software" }, "providerTicketId": "23233473847834"

} 

Apply policy.png


{

"shortDescription": "test shortDescription", "description": "test description", "contract": {"shortName": "PolKiel-INC" },

"contractElement": {"shortName": "INC-Software" }, "providerTicketId": "23233473847834"

}


NOTE: In our example, now the incoming request will be processed correctly. Also, it is visible within the synchronous response that our defined default values have been applied for the fields “category1”, “category2” and “extended.field5”.

NOTE: If a policy has not been assigned to a received CallState, the Tickets API will be working with its default behavior.

Important Notes

For all customers running their own infrastructure or using a Cisco Partner infrastructure, customers need to contact their implementation partner on the specific release date of the Cisco ServiceGrid 8.0 deployment.

Limitations and Restrictions

The requirements mentioned in Browser Class 1 in “System Requirements” section provide the minimum system requirements for Cisco ServiceGrid.

End-User License Agreement

All new functions and modules are installed on the corresponding platforms. New functions and modules, which are part of the general update are available to all customers of that platform. Some of the new functions and modules must be licensed before they are used in customized systems.

ServiceGrid Documentation

Table 2 ServiceGrid Documentation


ServiceGrid DocWiki

ServiceGrid DocWiki manuals, Implementation Guides, and Release Notes Archive:

http://docwiki.cisco.com/wiki/ServiceGrid

ServiceGrid Support Community

Announcements, Release Notes, Support Forum, and Blog:

https://supportforums.cisco.com/community/119 33756/cisco-servicegrid


Support Information

Table 3 Support Information


Cisco Support

email: tac@cisco.com

Phone: http://www.cisco.com/en/US/support/tsd_cisco_world wide_contacts.html#telephone

Web: www.cisco.com/support

Customer/Partner Maintenance Announcements

servicegrid-support@cisco.com

Support Reference Guide

www.cisco.com/web/services/acquisitions/downloads

/solvedirect-tech-support-reference-guide.pdf


Related Articles



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 8.0

Rating: 0.0/5 (0 votes cast)

Personal tools