Introduction and concepts
Last updated
Was this helpful?
Version 6.30
Last updated
Was this helpful?
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.
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.
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).
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.
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.
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)
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.
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.
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.
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.
To integrate Nexthink Chatbot SDK with a third-party chatbot, the chatbot must support the following:
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
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.
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.
OutlookIssues pseudo-codePurpose: Detect and fix the most common Outlook issues
Issue3: Outlook outdated version
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.
The authentication required for a chatbot to integrate with Chatbot SDK is API Key based.
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.
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.
This generated key needs to be shared with the chatbot integrator.
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.
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 Chatbot SDK offers a standard following the OpenAPI v3.0 standard.
For more information about how to generate the Key, refer to the page.
