Through step-based eventing, you can create Tealeaf events of these user interface events that are generated by your rich internet application.

Note: CX UI Capture for AJAX is only available to legacy users.

Note: Step-based eventing requires licensing, installation, and configuration of one of the Tealeaf client frameworks, including CX UI Capture for AJAX, Android SDK, and iOS SDK. These frameworks are required to enable step-based eventing. For more information, contact Professional Services.

On the traditional, HTML-based web, user actions typically trigger a single responding action from the web server. When you click a button, a form is submitted. When you click a link, a new page is loaded. For applications built on this framework, an individual event might occur only once per page.

In rich internet applications, however, this paradigm is altered. Many user interactions on a page do not change the page itself. In fact, a user can complete the same action multiple times. For example, suppose that your web application enables the entry of multiple addresses from a single form. When Submit is clicked, the address data is submitted, and the form is cleared, enabling another entry. In this case, the same event, SubmitAddress, can occur multiple times on the same page. In Tealeaf, you want to be able to track all of these occurrences, instead of just the first one.

Note: A primary usage for step-based eventing is to track events that may occur multiple times on a single page.

In addition to creating events from individual hits, you can also create events from steps, which are individual user actions that are captured from the client application and submitted to Tealeaf by using one of the Tealeaf client frameworks.

• A step can be considered a "subhit" of a hit; a step reflects a discrete, trackable user action, or a server-side action that does not result from a user action (such as a redirect).
• Steps are captured by a client framework, which is bundled together, and submitted as JSON messages to Tealeaf. These messages are then inserted into a designated section of the request of the parent hit.

Step-based eventing enables the capture of multiple events from a single page of your client application.

Creation of step attributes and events is not supported in RTV. In request view, you can review the raw JSON messages in the [RequestBody] section of the request.

You can use RTV to save test TLA sessions, which can be loaded into the Event Tester to use as test data for step-based events.

Definition of a step

A step is a specially-formatted JSON message that is submitted by the Tealeaf client frameworks to represent a session state of a form field.

• Step messages can contain any type of data. The data depends on the specific client framework that is sending the message.
• A step contains UI events from a single session only.
• In Tealeaf, these messages are submitted in JSON format and are not easy to decipher in raw format.

Prerequisites and limitations using for step-based eventing

There are several prerequisites that must be met in order to create step-based events. Use the information here to determine what prerequisites need to be met.

Note: You must be able to configure the capture of the application/json POST data types through the CX Passive Capture Application.

To create step-based events, the following components are required:

Limitations for using step-based eventing

The maximum length for selected values of text for attributes and events is 256 characters.

Note: Distance and Sequence events operate on hits, not steps. As a result, the distance between events on multiple steps of the same hit evaluates to zero`.

Message types

Events that are captured from client frameworks are bundled together and submitted as a set of messages. A message from a client framework is what defines a single step in Tealeaf, which is a single event that is identified and captured by a client framework.

Multiple messages can represent a single action of the visitor. For example, clicking a radio button might result in two messages of different types: one for the click event and one for change event.

Note: If you do not want to double count actions, use both the event type AND the ID/name when you create events for a specific action. If you look only for ID = checkout method for example, then this event fires twice when you only wanted it to fire once.

The volume of messages can depend on the configured logging level, which is defined in the client frameworks.

You can review the raw format of a submitted set of JSON messages and the format in which they are displayed after processing in Tealeaf.

Client framework

• CX UI Capture for AJAX
• Android SDK
• iOS SDK

Example message: Raw request body

The [RequestBody] following information includes a sample raw request, which contains a set of JSON messages.

Note: In the raw request, the following entry is a single paragraph. You cannot use this section to create step-based attributes. While it is possible to create hit attributes from the [RequestBody] section, it is not recommended, as this format might change over time.

[RequestBody]
{"version":"0.0.0.4","serialNumber":1,"sessions":[{"id":"ID14H2M3S663R0.36228193
267311725","startTime":1326837723663,"timezoneOffset":480,"messages":[{"type":2,
"offset":2226,"count":1,"context":{"type":"LOAD","name":"root","renderTime":
2226}},{"type":6,"offset":2230,"count":2,"exception":{"description":"Unable to
get value of the property 'nodeValue': object is null or undefined",
"url":"http://straussandplesser.com/store/js/coremetrics/eluminate.js",
"line":1}},{"type":4,"offset":24878,"count":3,"event":{"type":"click"},"target":
{"id":"[['main'],['DIV',1],['DIV',0],['TABLE',0],['TR',0],['TD',0],['DIV',0],
['P',0],['A',0]]","idType":-2,"type":"A"}},
{"type":2,"offset":24880,"count":4,"context":{"type":"UNLOAD","name":"root"}}]}]}

After the messages were passed through Tealeaf, the raw request is stored in the [RequestBody] section of the request, which is viewable through Request View in BBR.

Example message: Formatted request body

When the JSON messages are received, Tealeaf reformats them into a more legible format, which is listed here.

This information is available at the bottom of the request, which is formatted for view in Request View in BBR.

{
    "version": "0.0.0.4",
    "serialNumber": 1,
    "sessions": [
        {
            "id": "ID14H2M3S663R0.36228193267311725",
            "startTime": 1326837723663,
            "timezoneOffset": 480,
            "messages": [
                {
                    "type": 2,
                    "offset": 2226,
                    "count": 1,
                    "context": {
                        "type": "LOAD",
                        "name": "root",
                        "renderTime": 2226
                    }
                },

                {
                    "type": 6,
                    "offset": 2230,
                    "count": 2,
                    "exception": {
                        "description": "Unable to get value of the property 
                        'nodeValue': object is null or undefined",
                        "url":"http://straussandplesser.com/store/js/
                         coremetrics/eluminate.js",
                        "line": 1
                    }
                },

                {
                    "type": 4,
                    "offset": 24878,
                    "count": 3,
                    "event": {
                        "type": "click"
                    },
                    "target": {
                        "id": 
                        "[['main'],['DIV',1],['DIV',0],['TABLE',0],
                         ['TR',0],['TD',0],['DIV',0],['P',0],['A',0]]",
                        "idType": -2,
                        "type": "A"
                    }
                },

                {
                    "type": 2,
                    "offset": 24880,
                    "count": 4,
                    "context": {
                        "type": "UNLOAD",
                        "name": "root"
                    }
                }
            ],
        }
    ]
}

In the preceding example, the content after the following string is a set of four separate messages:

"messages": [

Each message is demarcated by a set of curly brackets.

Each step message constitutes a single step.

• Step-triggered events can fire per message step.
• In the preceding example, there are four-step messages. As a result, step-triggered events can fire up to four times on this hit.

Note: Each step-triggered event also has access to the hit attribute data of its parent hit and the environmental data included for reference in each step.

When you create step attributes, the value that is extracted is the contents between the colon (:) and the final comma (,) on the line.

Suppose you want to monitor exception messages that are submitted from the client framework. In the example above, the data is in the following area. In the following example, message data that was present in the previous example but is not relevant to the example is replaced with the <omitted> string.

"sessions": [
    {
    <omitted>
            "messages": [
           <omitted>
                {
                    "type": 6,
                    "offset": 2230,
                    "count": 2,
                    "exception": {
                        "description": "Unable to get value of the property
                        'nodeValue': object is null or undefined",
                        "url": "http://straussandplesser.com/store/js/coremetrics/eluminate.js",
                        "line": 1

In the preceding example, you can see that the exception message is stored in the description value. To reference this value in step-based eventing, when you create the step attribute to monitor the above, the node in the tree is referenced by using the following structure:

sessions[0].message.exception.description

The naming structures for the sessions and messages nodes are changed, and the type identifier is omitted.

Note: When you create step attributes through BBR, you use the menu, which automatically pre-populates the attribute with the appropriate reference within the Event Manager. These steps are described later.