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:
| Property | Description |
|---|---|
| t.id | Unique identifier for transaction, actually the session ID appended with the transaction index |
| t.duration | The amount of processing time from the beginning to the end of the transaction |
| t.index | The index of the transaction, starting with '0' for the first transaction |
| t.time | A 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.
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 identifiers | Constraint | Meaning |
|---|---|---|
| t1, t2 | t1.id != t2.id | t1 and t2 must be different transactions |
| t1, t2 | t1.index == t2.index - 1 | t2 must immediately follow t1 |
| t1, t2 | t1.index < t2.index | t1 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':
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:
By adding a constraint to the query at the end of the query — will return a more meaningful result:
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.