In Tealeaf, the workingset of events is the set of all event firings that were triggered at any time during the session up until the present time. Some captured values may not be recorded for an event; captured values are typically a subset of the workingset.
During the session, each time that an event is triggered, the detected value for the event is stored in memory. However, this value may not be the value that you specified for recording. For example, an event that is configured to record the first value may be triggered six times during a session.
The purpose of the working set is to provide access for other events to values other than the tracked value. By default, events that reference other events use the latest tracked value of the other events. For example, if Event 1 is used by Event 2, Event 2 uses the latest tracked value of event 1 by default. However, you may want Event 2 to use a different instance value of Event 1. In this case, you would reference a value from Event 1's workingset.
- Referencing workingset values requires editing Event 2 in Advanced Mode.
WorkingSet, Tracked Occurrence, and Building Block Events can be thought of as follows:
- WorkingSet - The value of an event when it fires.
- Tracked Occurrence - A instance of the workingset, that is, first, last, or every. This instance is the one that recorded and available for basic reference by other event-related objects.
- Building Block Events - An event whose tracked instance is not searchable or reportable.
Example - workingset versus tracked values
In this example, you defined Event 1 to fire on every hit and track the last value. It is searchable & reportable.
In the table below, you can see the values for Event 1 in a five-hit session:
| Hit | Event 1 |
|---|---|
| 1 | A |
| 2 | B |
| 3 | C |
| 4 | D |
| 5 | E |
Values A through E for Event 1 are the workingset for Event 1.
However, if you added Event 1 to a report, the report shows only 1 instance of Event 1 with a value E. Because the event is defined to track the last value, value E appears in the report.
Example - referencing events in Basic Mode (tracked values) versus Advanced Mode (workingset values)
In this example, you define the following events in Basic Mode.
- Event 1 fires on every hit, tracks the last value, and is not searchable & reportable.
- Event 2 fires whenever Event 1 fires and Event 2's value is the value of Event 1. Event 2 tracks all instances and is searchable & reportable.
In the table below, you can see the values of these two events in each hit of a five-hit session:
| Hit | Event 1 | Event 2 |
|---|---|---|
| 1 | A | A |
| 2 | B | B |
| 3 | C | C |
| 4 | D | D |
| 5 | E | E |
Because Event 1 is not searchable & reportable, it cannot be added to a report. It can only be used by other events, such as Event 2. Event 1 is a building block event.
Because Event 1 is set to track its last value, Event 1's value changes each time that it fires. Since Event's 2 value is the value of Event 1, the value of Event 2 also changes each time Event 2 fires.
If you add Event 2 to a report, there would be five instances of Event 2. The instances would have the values A, B, C, D, and E respectively since those were the value of Event 1 when Event 2 fired.
Using a similar construction, you can report on building block events.
If you were to modify Event 2 in Advanced Mode, you can require that Event 2 use the first instance of Event 1. In this case, adding Event 2 to a report shows 5 instances of Event 2, all containing the value A. Event 1, the building block event, still contains the five separate values.
| Hit | Event 1 | Event 2 |
|---|---|---|
| 1 | A | A |
| 2 | B | A |
| 3 | C | A |
| 4 | D | A |
| 5 | E | A |