Support

Introduction and concepts

This document provides comprehensive information about the introduction and concepts around Nexthink Chatbot SDK, its API and use cases. The information contained herein is subject to change without notice and is not guaranteed to be error-free. If you find any errors, please report them to us via Nexthink Support Portal. This document is intended for readers with a detailed understanding of Nexthink technology.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Concepts and general architecture

The purpose of the Nexthink Chatbot SDK is to provide smart diagnosis and automatic resolution of IT issues. This is accomplished by creating an abstraction layer in front of Nexthink that any chatbot vendor can integrate via a standard REST API.

Concepts

Intent

This is a general chatbot term referring to the employee’s intention. When an employee types “I have no (disk) space left in my computer,” the chatbot recognizes whether the input demonstrates an intent after processing it with natural language processing (NLP).

Natural Language Processing (NLP)

This is the algorithmic process that utilizes AI to translate a large amount of human language into a well-defined intent and to generate natural language from a given response. This activity is performed within the chatbot.

Conversational flow

This is a decision tree used by the chatbot to perform tasks such as retrieving more information from the employee or accessing external back-end servers. In general, the entry point is a given intent extracted from the NLP component.

Topic

This is a part of the configuration that represents a use case related to an intent within Chatbot SDK. It generally contains:

  • Diagnosis: a list of conditions to match (for example, free space < 10%)

  • Remediation: list of remote actions to launch if the diagnosis conditions match (for example, clean recycle bin)

Catalog

This is a collection of topics provided by Chatbot SDK. The collection has been created by analyzing Nexthink historical data about common device issues. Additionally, custom topics can be created by extending or changing the existing templates.

Nexthink Chatbot SDK general architecture

Chatbot SDK is an extra component of Nexthink’s core product and aims to add Nexthink intelligence to any chatbot. In order to achieve this objective, a REST API is provided that is accessible via a new endpoint.

Chatbot SDK is composed of several microservices which run as docker containers. The main functionality provided by Chatbot SDK:

  • Isolates internal Nexthink components.

  • Manages the chatbot authentication to access the REST API.

  • Identifies devices used by a particular employee and provides timing information about the last activity of the employee, such as employee interaction with the mouse or the keyboard.

  • Provides diagnosis and remediation to the chatbot in order to make decisions based on a specific topic and device. For example, this can occur when triggering remediations via the Chatbot SDK.

  • Caches information locally that is retrieved from Nexthink Engines in order to improve the response time. This information is updated via a scheduled discovery process.

High-level architecture

Basic diagram flow

The following scenario illustrates a typical conversation between the employee and a chatbot integrated with Nexthink Chatbot SDK to solve an issue with Outlook.

  • The chatbot receives a complaint from the employee about Outlook not working properly.

  • The chatbot translates several inputs from NLP into an existing intent.

  • The specific intent is the entry for a conversational flow that comprises one or several Nexthink topics that can solve the issue.

  • Chatbot SDK learns which devices are affected based on the user id.

  • Once the device has been identified, Chabot SDK engages the topic that refers to Outlook issues

  • Nexthink Chatbot SDK analyzes all the configured diagnoses in the topic and returns the existing problems to the chatbot, which in this case are Outlook crashes. It reports two potential solutions:

    • Cleaning the local OST files

    • Removing non-standard plugins detected by Nexthink

  • The chatbot parses this information and presents the available options to the employee.

  • The employee chooses to clean the local files and the related remediation action reported by Nexthink is called through the API for Nexthink Chatbot SDK to launch a remote action.

Basic diagram flow

To report the status of the remote action execution, which can take up to 2 minutes, it is recommended to use an ITSM ticket. We recommend leaving the task of creating tickets to the chatbot if it is capable of doing so.

  • (Optional) By performing a call to Chatbot SDK, the chatbot will be able to report the execution result back.

Third-party chatbot requirements

To integrate Nexthink Chatbot SDK with a third-party chatbot, the chatbot must support the following:

  • Authentication and authorization of the employee: the chatbot is responsible for authenticating and authorizing the employee. The user identification must be shared with Chatbot SDK through the Nexthink user identifier based on the Nexthink data schema.

  • Integration capabilities with a REST API and the ability to process answers in JSON format

    • Authentication to connect to the REST API is based on an API key exchange

Conversational flow definition to call one or several Nexthink topics which have been given an intent and decision making based on the answers

  • Transformation of Chatbot SDK responses to natural language to render a proper answer to the employee

  • Chatbot ability to configure timers to wait up to 1 minute for diagnosis results in some cases

Topics

A topic is a part of the configuration in the Chatbot SDK, where a list of diagnosis and resolution options are listed. It is usually related to high-level employee issues such as PCSlow or OutlookIssues to simplify the integration on the chatbot side.

The chatbot only needs to know the available topics in Chatbot SDK and call them with the REST API. Refer to the REST API for more information.

Topic content

  • Every topic has a version and a list of diagnoses to check.

  • A diagnosis can be performed by either requesting information via an NXQL query or by triggering a remote action.

    • In some cases, it can be left empty if there is no automatic way to fix it, for example, a battery with bad health. This could be used to open an incident or to route to a Live Agent on the chatbot side.

    • It is recommended to substitute the use of remote actions as a diagnosis with an NXQL query that retrieves the same information that the remote action provides. This means that the remote action must be first executed in the device for the information to be available. Thus, the administrator will be responsible for scheduling the necessary remote actions. This configuration is used to shorten the time it takes to receive an answer about a certain diagnosis from the chatbot. When a remote action has been previously launched, the chatbot will be able to access the necessary information more quickly than if the remote action is executed in real-time. This approach only makes sense for certain remote actions, as the information provided is not purely real-time. Therefore, gathering data on a daily basis would be enough for this use case.

    • When the topic is retrieving remote action information via NXQL queries, it is recommended to validate the remote action status by adding a “where” clause in the query itself in order to check the Execution Status.

  • A diagnosis has a condition to match, for example, Used Disk Space > 85% The correct clause can be either a single element or a literal expression. In the first case, declaring either a single word or a number is allowed, and in the second case, a string composed of two or more words is allowed.

Example: OutlookIssues pseudo-code

Purpose: Detect and fix the most common Outlook issues

Issue1: Outlook crash

Code
Diag1: check crashes  
RA1: reset OST

Issue2: Outlook offline

Code
Diag2: check Outlook is offline 
RA2: set Outlook online

Issue3: Outlook outdated version

Code
Diag3:  check Outlook version 
RA3: Trigger GPO update

Use cases

This is an initial list of topics available in the out-of-the-box catalog:

  • Outlook Issues – related to outdated versions, Outlook offline

  • Health check – related to PC health (disk space, battery, …)

  • L1 Checklist – L1 Scores related to PC health like CPU, disk space, office365 status, etc.

  • PC Slow – related to disk space, start-up apps, etc.

  • Skype for Business – related to Skype for Business health

  • OneDrive Issues – related to OneDrive common errors and installation

  • OneDrive Installation – checks if OneDrive is installed. It can be installed if required.

  • Print Issues – resets the print spooler

These out-of-the-box use cases can be extended by adding new topics configuration.

Chatbot Integration and REST API

Nexthink Chatbot SDK offers a standard REST API following the OpenAPI v3.0 standard.

Chatbot SDK Authentication

The authentication required for a chatbot to integrate with Chatbot SDK is API Key based.

Usage of the API key

  • At any time, you can use a unique valid API Key.

  • The Chatbot will need to use the key as an authentication method by adding an HTTP extended header "X-API-key:” in every REST API call.

Generation of the API Key

Internally, the API key is generated based on the Nexthink user and password configured during the Chatbot SDK installation process. For this reason, the recommended way to integrate a chatbot is to use a Nexthink user with a fixed password dedicated for chatbot integration.

Every time the Nexthink password or user is changed in the .env, the key needs to be regenerated and updated in the chatbot. This can be done with a scripted approach.

This generated key needs to be shared with the chatbot integrator.

For more information about how to generate the Key, refer to the Authentication page.

Limitations

Nexthink Chatbot SDK is not part of the official cloud offering at this point. This means that, although it can be configured to interact with Nexthink Cloud deployments, Chatbot SDK itself still needs to be deployed and installed as part of the on-premises infrastructure of the client.

Last updated

Was this helpful?