Technology and Deployment

Studio Rest API

The Studio Rest API is in Platform version 7.1 expanded with new endpoints to handle Global Scripts and perform actions such as creating/updating/deleting a specific Global Script or update the Global Script Ordering. On top of this are also included endpoints to work with File Resources (create/return/delete/update, etc.) and to export the input processor's settings to create a custom input processor configuration.
Furthermore, the Studio Rest API now also include an endpoint to export a solution as well as endpoints to fetch solution statistics and solution owners; please see the details in the Studio Rest API.

Using an API token for a specific user while the same user is logged-in in the system (i.e. Teneo Studio) is now possible without the latter user being logged out.

Tech Stack

Kafka 3.2.0

Due to the vulnerability CVE-2021-38153, the version of Kafka is raised to 3.2.0.

Note Kafka's server.properties file has been updated, the main change is the timeout in ms for connecting to ZooKeeper which has been increased to 18.000 ms. ZooKeeper's zookeeper.properties file has also been updated, an embedded Jetty based AdminServer was added in ZooKeeper 3.5. AdminServer is enabled by default in ZooKeeper and is started on port 8080. AdminServer however is disabled by default in the ZooKeeper config (zookeeper.properties) provided by the Apache Kafka distribution.

Teneo Learn

Several dependencies used by Teneo Learn are updated to newer versions to mitigate vulnerabilities:

• Spark version 3.3.0
• Jackson version 2.12.3
• Hadoop version 3.3.3
• mLeap version 0.20.0

Due to optimizations in the machine learning algorithm in a third-party library (Spark/MLlib), the models trained with this version of Teneo differ slightly from models trained with previous versions of Teneo. As a result, intent recognition will work slightly differently in solutions depending on the training data and the actual user input.

Others

• Java version raised to 11.0.16+8
• Cassandra, used by Inquire, is raised to version 4.0.5 and requires Java 11 and Python version 3.6 or higher
• Tomcat version updated to 9.0.65

Upgrade to 7.1

File Resources

When upgrading to 7.1, the content ofany File Resource in the Recycle Bin will be lost.

Workaround: prior upgrade, any File Resource in the Recycle Bin that the user wants to keep need to be restored. After the upgrade the files can be re-deleted/moved to the Recycle Bin, if wished so.
Note: the system relies on Stable version, so clients having Stable versions of File Resources in the Recycle Bin have to restore them prior the upgrade, else the behavior will be affected post-upgrade.

Also see Known Issue File Resources in Recycle Bin are lost after Studio upgrade to 7.1

Log data format and TQL queries

There is a breaking change in the logged data between pre-7.1 and 7.1-onwards which can affect TQL queries using the vname

property of global script events (that is, any event of pathType: session-script

). This change affects only global script events, no other event names have been affected. This change affects only TQL queries as no other Platform function has been affected.

The change means that if a solution is republished with no changes, the vname

property in the session logs will have changed from camelCase format to SCREAMING_SNAKE_CASE, for example, beginDialog

will now be BEGIN_DIALOG

(see 3 exceptions below in the conversion table). Additionally, a new field script-event

has been added which contains the previous value of the vname

field - along with a script-id

containing the id (UUID) of the script document.

An example of a query affected by this change may be:

1distribute t.e.sv:s:channel : t.e.pathType == "session-script", t.e.vname == "beginDialog"
2

which would no longer provide the same results and instead would need to be:

1distribute t.e.sv:s:channel : t.e.pathType == "session-script", t.e.vname == "BEGIN_DIALOG"
2

(This is not a likely example as the channel information is normally accessible through the input parameter - this will not have been affected).

The same through Groovy would also be affected:

1session.transactions.each {
2	t -> t.events.findAll { 
3            it.pathType == "session-script" &&
4            it.vname == "beginDialog"
5		}.each {
6			e -> // ...
7	}
8}
9

Where line 4 would have to be:

1            it.vname == "BEGIN_DIALOG"
2

In most cases this will not affect projects in any way.

IF the project uses a TQL query which returns or is constrained by the vname

property of a global script event but the results are used ad hoc, are not required to be comparable across upgrade, or a are stored incrementally over time and not re-queried from Inquire: A change similar to the example above should be made before querying sessions generated by the 7.1 published solution.

In this case (and in any case where the name is not required to match pre-7.1 session for reporting consistency - see below) it is strongly recommended to separate scripts by purpose / concern and rename them according to purpose - for clarity of solution understanding. These purpose driven names (or script ids which are guaranteed not to change) can then be used in the query:

1distribute t.e.sv:s:channel :
2	t.e.pathType == "session-script",
3	t.e.script-id == "9cee6ba0-53f7-47ab-9f34-c6291061b76c" /* Channel Handling - Identify Channel */
4

IF the project uses a TQL query which returns or is constrained by the vname

property of a global script event, AND the query is required to give the same results after upgrade (i.e., for sessions executed before and after upgrade) then mitigating steps are required in the solution before first publishing the solution from Teneo 7.1. This is only needed when the query is (for example) part of a set of queries where the results are directly used for reporting metrics through time and will be executed on sessions occurring before and after first 7.1 publish.

To ensure data consistency across the upgrade, for each global script which is queried in this way the script should be renamed in the solution in Studio according to the following table before first publish. Changing the name as described has no functional impact on the behavior of the solution itself.

Cassandra

As a result of the Cassandra upgrade some upgrade steps are required, please refer to the Upgrade and Migration Plan provided with the 7.1 release.

KI Resolutions