Global scripts

Global scripts are created and managed at the solution level. In the main solution window, click the Solution tab, then choose Globals on the left and choose the in Scripts tab. There you will find multiple fields where you can add your scripts. Where you add your script not only determines when it is executed but also which data your script can access. There are two 'levels': Session and Engine.

Global Scripts

Session

Session scripts can be executed at various moments in a session. These scripts have read and write access to session data (like global variables or the input of the user). They are connected to a particular session.

Begin dialog

Scripts here will be performed once, at the start of each session. This script is commonly used to perform tasks that need to happen at the beginning of each and every session. For example, you might use this script to check if a certain paramater was included in the first request.

Depending on how this session began, the next script to execute will be either the New session script or the Timed out session script.

New session

This script runs following the 'Begin Dialog' script, but only if the request did not contain session a session ID. The absense of a session ID in the request tells engine it should start a new session and exectute this script. This script is not commonly used. You should only use it if you explicitly want it to only run at the start of a new clean session.

Timed out session

This script runs following the 'Begin Dialog' script, but only if the request did contain a session ID but the corresponding session was expired or is unknown. In this case engine will assume the session was timed out. Engine will start a new session and execute the Timed-out sesison script. You should only use this script if you explicitly want it to only be executed for timed out or resumed sessions.

As said, at the start of a session, engine will always run the Begin Dialog script and then either run the New session script or the Timed out session script.

More details on sessions can be found in the Session Management paragraph in the 'Deploy your bot' section.

Pre-processing

The pre-processing script is executed on each transaction, before engine does any processing of the input. This means you can manipulate the user input string before it is tested against flow triggers or transitions. A more common use of the pre-processing script is to access other elements of the incoming http request. For example, it is very commonly used to store values of url parameters in global variables:

if (engineEnvironment.getParameter("channel")) {
    channel = engineEnvironment.getParameter("channel")
}

Pre-matching

Scripts here are also executed on each transaction. They are run before engine tests the user input against flow triggers or transitions, but after the sentences in the user input are separated for processing (sentence segmentation) and after the input is separated into words (tokenization). This script is not commonly used.

Post-processing

Post-processing scripts are executed after your solution has created a response, consisting of the output text, output URL, emotion and output parameters. It is commonly run scripts that depend on the results of the flow processing, right before the final response is returned. It can also be used to change the response data. For example:

if (channel == 'slack' && _.getOutputURL()) {
    _.setOutputText(_.getOutputText() + '\nMore details: ' + _.getOutputURL())
}

End dialog

Scripts here will be performed once, at the end of each session. It could for example be used to write session details to an external system or to close database connections.

On top

On-top scripts will be executed whenever a flow becomes the top flow on the flow stack (either by being triggered or by regaining the top position after being interrupted by the triggering of another flow).

On drop

These scripts will be executed whenever a flow is finished and the task is removed.

Engine

Engine scripts are only executed when a solution is loaded by engine (typically when the engine is started) or when a solution is unloaded (typically when the engine is stopped). These scripts are not connected to a particular session. This means you can't directly use session specific data (like global variables) in these scripts. You can however pass on the EngineAccess and EngineEnvironment objects to the classes' methods defined here.

Solution loaded

This script runs once when the solution is loaded into the engine's memory. It very commonly contains utility classes that are used throughout the solution. For example, you could add a class here that offers various string manipulation methods.

Solution unloaded

This script runs once directly before the solution is unloaded. It's not a commonly used script.

Script execution order

A diagram outlining the order in which Teneo executes scripts (and other tasks) can be found in the reference section: Input processing path.

Was this page helpful?