The trace endpoint is designed to enable developers to trace or observe conversational history, where history is represented as fine-grained and low-level actions. This endpoint will be invoked at the end of each event which EBA proccesses. Developers will find two parameters associated with the input for this action:
version – an integer counter representing the current version of your conversation’s state. Each event which EBA processes will increment this counter. The start event is version 1, with subsequent events or questions incrementing this value.
actions – a list of actions detailing the operations EBA committed in order to process the current event. Note that actions here do not denote semantic actions, although some actions will be the result of semantic actions. Rather, these are the machine level actions which EBA commits in order to construct your conversational state or information space.
Each action is composed of the following properties:
name – the name of the action, e.g. common:ShowDataMessage@a6f8bbf0links – a list of links between nodes, where each link contains an id as well as meta data pertaining to its associated nodesnodes – a list of nodes, where each node encodes various low level data, e.g. concepts, data, tokens, etc.time – an optional metric denoting the POSIX timeAdditionally, developers should note that, given that this endpoint is about observing data, it carries a read-only semantic. Consequently, the output generated by this action is not used in any processing. There is no strict interface requirement on what can be returned from this action, as its value is effectively discarded. In the case of short term storage, one must also note that this endpoint is processed asynchronously. Consequently, there is no garuntee that something written to short term storge will be available in time for a later action. We do not recommend developers to implement any write behavior in this endpoint, except to pass data to external systems over the network.
edit this article