Event recorder
The 'Event recorder' is an analysis and debugging tool that records the events triggered by the current session and checks the association criteria.
Recorded entries are temporary test sets and can also be loaded as such in the test mode of an event handling (ribbon function 'Load recorded event').
The 'Event recorder' can be called via the main menu as well as via a ribbon function in the event handling overview.
Functions
Recording is started via the Start function.
The recording can be interrupted at any time, all previously recorded entries will be retained.
Via Stop, the recording is stopped and all entries recorded so far are discarded.
►NOTE◄ Recorded entries are retained as long as the user is not logged out.
When a recording is active, all events and data context checks made since the start of the recording are automatically loaded into the overview:
Recorded entries are temporary test sets and therefore also have the same columns as the overview test-sets.
Explanation of the columns:
Name: The name of the event/'Object of the data context' or matches: 'Object of the data context' for data context checks (Evaluate association criteria).
Object of the data context: 'Object ID': 'Object type' of the object that is currently in the data context.
Test-Set type: The type associated with the test set (event handling or association criterion) for which the entry is suitable as test data.
Record timestamp: The time of the recording (by default, this is sorted in descending order). Tip: For the display of seconds or even milliseconds, the date format can be adjusted accordingly in the list settings.
ID: A temporary Entry ID (hidden by default).
Basically, two types of entries are distinguished: events and the evaluation of association criteria (matches). If an entry is selected, the initial event variables and the input object can be viewed as XML.
►NOTE◄ The recorded entries are snapshots at the time of the triggering events or a data context check (matches). Any event handlings are only triggered afterwards. These are also not listed here and of course neither are the changes of variables or data in the input object.
Examples of use
Example 1: Pressing the 'New' ribbon button in the overview of a business object
In a shipment overview, 'New' is clicked while the 'Event recorder' is in record mode.
Immediately after being pressed, the 'Event recorder' records two entries (see screenshot above). The first entry 'matches' shows that the association criteria for a new shipment object (ID: 0) have been re-evaluated. This makes sense, because it was necessary to check which form should be loaded to process the new shipment.
The second (selected) entry shows that the 'New' event was triggered with a new shipment object (ID: 0). The Input value tab reveals that the input data for the event treatments is actually a completely empty shipment object. A look at the Variables tab also shows which variables are initially available in event handlings:
For example, it can be seen without further background knowledge that a variable '$viewName$' exists, which reveals from which view the event was triggered.
In the example above, this would be a separate shipment overview named 'All'.
Example 2: Triggering a custom action event via form behaviour
Often the behaviour Dispatch custom action event (Form designer) is used to trigger events in forms, which then receive data from the form. In order to be able to check this data interface, the 'Event recorder' is the suitable tool of choice.
The following example form is given (data fields correspond to the labels):
When clicking the EVENT button the custom action event 'HANDLE_PORTAL_DATA' is triggered. The value of the clicked trigger is passed as the variable 'value'. Independent of a configured event handling, the form can now be tested with the 'Event recorder' started.
A click on the EVENT button creates the following entries:
Clearly visible now is the entry 'Custom action event', which shows that the event 'HANDLE_PORTAL_DATA' was triggered without a business object as input data (null) for the event handlings. A look into the Variables tab shows that the passed form data is passed as 'formData' variable to the event handlers. Directly below this, the 'value' variable also appears with the data of the 'Clicked' trigger, which actually corresponds to 'true' for a button element.
The second entry (matches) makes it clear that after the custom action event was called, the data context and thus the association criteria were re-evaluated, since the data in the context could potentially have changed.