Event
Each transaction consists of a collection of events that records everything that happened in the solution from the beginning to the end of the transaction. This is the path the user takes from start until they receive a response. These are referred to as events when writing queries in Teneo Query Language.
A transaction holds these three types of events:
- Request - the call to the bot with the user input and all additional parameters
- Path - the path the user input takes through the solution until a response is received.
- Response - the bot's response along with Output Parameters returned to the user
Properties associated with the set of events include:
- Event properties
- Global variables
- Flow variables
- Metadata (of scope flow or transaction)
- Annotations
- Request parameters
Let's take a look at what happens in our 'Longberry Baristas' solution when the 'User asks about types of coffee that are available'.
Request event
The request is always the first event in a transaction and includes the main properties associated with the request:
Path event
Next, you find path events, which can add up to quite a large number of data. Everything that happens — every script that runs; every flow that is raised, paused, or dropped; every listener, transition, and node reached — is recorded as an event. The new value of any global or flow variable that is assigned during the event is also recorded as part of the event. Events are listed in the order that they occur.
Let us expand one of the main events and see which properties it contains:
Important properties to query might be the flow's name (fname) associated with the "raise-flow" pathType. Note: since fname may be part of many different events, you may want to combine a query of raised flows with pathType == "raise-flow". You can view some sample queries in our set of How to's.
Response event
The last event of a transaction is always the response, which looks something like this:
Referencing event properties
Since events all belong to a transaction, we can reference them in the context of a transaction. So the 'address' of the userInput property could look like this:
t.e.userInput
Just as with transactions, you can choose identifiers to refer to event properties, such as 'e1' and 'e2'. If we refer to two different properties using the same transaction and event identifiers, the two properties must belong to the same transaction and event:
- t1.e1.userInput
- t1.e1.pathType
If we use different identifiers, the two properties is not forced to belong to the same transaction and event.
- t1.e1.userInput
- t1.e2.pathType
You can also apply constraints to specify ordering, transaction, etc:
| Event identifiers | Constraint | Meaning |
|---|---|---|
| t.e1, t.e2 | t.e1.eventIndex != t.e2.eventIndex | 'e1' and 'e2' must be different events in the same transaction |
| t.e1, t.e2 | t.e1.eventIndex == t.e2.eventIndex - 1 | 'e1' and 'e2' must be consecutive events in the same transaction |
| t.e1, t.e2 | t.e1.eventIndex < t.e2.eventIndex | e1 must occur before e2 in the same transaction |
Path types
In the above section we showed you a query looking for a path type of raise-flow. By way of reference, here is the list of path types that are most frequently used in queries. If you'd like to view all the path types occurring in your solution you can try the follwoing query, d t.e.pathType.
| Path type | Meaning |
|---|---|
| flow-trigger | a flow trigger is matched |
| raise-flow | a flow enters the flow stack |
| pause-flow | flow execution is halted/paused |
| continue-flow | flow execution is continued when new input comes in after this flow was paused |
| resume-flow | flow execution is continued after another flow interrupted the execution of this flow |
| drop-flow | a flow is dropped off the flow stack |
| variable-change | a global or flow variables changes value |
| session-script | a global script is executed |
| script | a flow script node is executed |
| flow-script | a flow script (on-top or on-drop) is executed |
| input-processor-results | results of all processors acting in the current input |
| flow-node | a flow link node was executed |
| output | an output node was executed |
| listener | a listener condition was matched and the listener was executed |
| transition | a transition was traversed |