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 Discover, 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.
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 Discover. For examples, see Example message: Raw request body and Example message: Formatted request body.
Example message: Raw request body
The [RequestBody]
following
information includes a sample raw request, which contains a set of
JSON messages.
- 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":"12.1.0.0","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://hclswtech.com/store/",
"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 Discover, the raw request is stored in
the [RequestBody]
section of the request, which is viewable through
Request View in Replay.
Example message: Formatted request body
When the JSON messages are received, Discover 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 Replay.
Click to view expanded example messages.
{
"version": "12.1.0.0",
"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://hclswtech.com/store/",
"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.
- Data that is defined at the same level as
messages
(such asserialNumber
ortimezoneOffset
) is considered environmental data.
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.
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://hclswtech.com/store/
",
"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.