Release Notes for Cisco ServiceGrid 8...2 Release Notes for Cisco ServiceGrid 8.0 Introduction Introduction Cisco ServiceGrid is an integration platform in the cloud for IT service

Release Notes for Cisco ServiceGrid 8.0

Release: Cisco ServiceGrid Release 8.0Release Date: January 24, 2016

Cisco Systems, Inc.www.cisco.com

Introduction

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, page 2

• System Requirements, page 3

• New and Enhanced Features in Cisco ServiceGrid Release 8.0, page 4

• Important Notes, page 20

• Limitations and Restrictions, page 20

• End-User License Agreement, page 20

• ServiceGrid Documentation, page 20

• Support Information, page 21

• Related Articles, page 21

Release DatesThe 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.

2Release Notes for Cisco ServiceGrid 8.0

System Requirements

System RequirementsCisco 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.

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.

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.


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

– 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 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 ortickets/?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 ortickets/?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:00ortickets/?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.


https://us1.solvedirect.com/ws/#!/OAuth/authorize


The following table provides the details of this API:

Example request for getting all history records of one ticket:

curl -i -H "Authorization: Bearer {auth-token} -H "Content-Type: application/json" -X GEThttps://{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.

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.




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:

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&editTimeUtc=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&editTimeUtc=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&editTimeUtc=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.

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.




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.

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.



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.

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



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.



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.



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.

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 clicking the menu button “Upload private key” or the certificate already contains a private key part from the beginning.



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

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 be performed:



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

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 outgoing B2B interfaces through a Service Definition. The status of an outgoing interface will be represented by the three colors of the traffic light signal.

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.

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.

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.



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.

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 follows:

• 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"}



"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

Important NotesFor 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 RestrictionsThe requirements mentioned in Browser Class 1 in “System Requirements” section on page 3 provide the minimum system requirements for Cisco ServiceGrid.

End-User License AgreementAll 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/11933756/cisco-servicegrid


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

https://supportforums.cisco.com/community/11933756/cisco-servicegrid

Support Information

Support Information

Related Articles• APIs in Cisco ServiceGrid

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Release Notes for Cisco ServiceGrid Release 8.0

© 2016 Cisco Systems, Inc. All rights reserved.

Table 3 Support Information

Cisco Support email: [email protected]

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

Web: www.cisco.com/support

Customer/Partner Maintenance Announcements

[email protected]

Support Reference Guide www.cisco.com/web/services/acquisitions/downloads/solvedirect-tech-support-reference-guide.pdf

21© 2016 Cisco Systems, Inc. All rights reserved.

http://docwiki.cisco.com/wiki/ServiceGrid_Article_-_APIs_in_Cisco_ServiceGrid

http://www.cisco.com/go/trademarks

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html#telephone

www.cisco.com/support

www.cisco.com/web/services/acquisitions/downloads/solvedirect-tech-support-reference-guide.pdf

Documents

Release Notes for Cisco ServiceGrid 8...2 Release Notes for Cisco ServiceGrid 8.0 Introduction Introduction Cisco ServiceGrid is an integration platform in the cloud for IT service