Each transaction consists of a collection of events that record everything that happened in the solution from the beginning to the end of the transaction. You can think of events as documenting the path a user input took through the solution to finally arrive at the response. Many of the queries you run using TQL will refer to properties belonging to events.

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 found
  • 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 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: request event

Path event

Next you find path events, which can add up to quite a mass of data. Everything that happens, every script that runs, every flow that was 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 occurred. path events

Let's expand one of the main events and see which properties it contains: example events

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: response event

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:


Just as with transactions, you can choose identifiers to refer to event properties. If we refer to two different properties using the same transaction and event identifiers:

  • t1.e1.userInput
  • t1.e1.pathType

the two properties must belong to the same transaction and event.

If we use different identifiers, such as:

  • t1.e1.userInput
  • t1.e2.pathType

the two properties do not have to come from the same event (but they may).

You can also apply constraints to force events to be consecutive, 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 more frequently used in queries. If you'd like to view all the path types occuring in your solution you can try the 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-scrip 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

Was this page helpful?