Teneo Developers

Share to

Transaction

When a user asks a question, the bot responds; we refer to this process as a transaction, but a transaction is more than that. A transaction records the entire process of how the bot came to respond the way it did. More specifically, a transaction holds everything that happens from the point that a user input is received to the time the bot's response is returned.

Transactions contain the following components:

  • Transaction properties
  • A list of events of the following types:
    • Request
    • Path
    • Response

Common transaction properties include:

PropertyDescription
t.idUnique identifier for transaction, actually the session ID appended with the transaction index
t.durationThe amount of processing time from the beginning to the end of the transaction
t.indexThe index of the transaction, starting with '0' for the first transaction
t.timeA timestamp for the transaction

Referencing transaction properties

Referring to transaction properties in queries needs to be done with a transaction prefix. So if you want to view transaction IDs associated with a particular user input, you would reference the ID as transaction.id or t.id for short. The index property t.index is also useful in locating consecutive transactions, as it will be demonstrated further on in this page.

Note: the transaction ID is the session ID with the number of the transaction appended as a suffix. So if the session ID is B436C752217057D239BD04B5E55FDFF3 the transaction ID of the initial transaction is B436C752217057D239BD04B5E55FDFF3_0 and so on.

Referencing multiple transactions

For cases where it is often necessary to refer to multiple different transactions in a query. Instead of using the t.index you can add an additional identifier to distinguish the references like numbers, e.g. t1.index, t2.index, etc.

This kind of notation is fundamental to Teneo Query Language, so it is important to understand exactly what the identifiers mean. If you refer to properties of t1, e.g. t1.id and t1.index, the concerned properties must come from the same transaction. If you use t1.id and t2.index in your query, the concerned properties do not have to come from the same transaction, but they may.

The numbers in the identifier has nothing to do with order of occurrence. Think of the identifiers as symbolic names. Using t1 and t2 in a query can have the following options:

  • t1 does not have to be the first transaction in the session
  • t2 can occur before t1
  • t1 and t2 may not be consecutive
  • t1 and t2 can be the same transaction
  • t1 and t2 can be different transactions

You can, however, add additional constraints to your query to assure that 't1' and 't2' do have specific locations in the session relative to each other. This table shows some ways to do it:

Transaction identifiersConstraintMeaning
t1, t2t1.id != t2.idt1 and t2 must be different transactions
t1, t2t1.index == t2.index - 1t2 must immediately follow t1
t1, t2t1.index < t2.indext1 must occur sometime before t2

Let us look at some simple queries for this brief session. There are two transactions, the first with index '0', the second with index '1': TQL - Short Session

If we run a query using 't1' and 't2' to list pairs of indices in that session, Teneo Query Language tries to fit 't1' and 't2' to all the possible permutations: TQL - Permutations

By adding a constraint to the query at the end of the query — will return a more meaningful result:
TQL - Query

This is just to demonstrate that the identifier used for the transaction is independent from the transaction's actual location in the session. Teneo Query Language simply finds a way to match them in any way possible to the transactions that make up the session.