Create debug snapshot
Event action – Abstract
Purpose: Generates an arbitrary entry in the Event recorder including a snapshot of the data context.
The Create debug snapshot event action can be used within event handlers to output arbitrary entries in the Event recorder at runtime. With each of these entries, a 'snapshot' (debug snapshot) of the current data context (input value, variables, login request) is recorded. This means that changes to the reference object of the event handler, to value assignments for variables and, if applicable, details of the logon context, can be traced section-by-section or step-by-step in the course of event processing.
The static text entered in the optional Name parameter appears in the Event recorder in conjunction with an attached run index (#0, #1, ...), which is intended to make repetitions of the same entry distinguishable.
Each instance of a Create debug snapshot event action is assigned its own run index. If the Name parameter is the same for two instances, duplicates for the values of the 'Name' column in the Event recorder are to be expected.
►NOTE◄ As long as the Event recorder is not active at runtime, using the Create debug snapshot in event handling does not affect performance.
Example
In an event handling, all company and address attributes of a business object of the shipment type are to be checked for plausibility. To do this, they are passed to a Custom action event as an 'input value' that applies the unified checking logic to each attribute passed. If an address violates one of the rules defined there, the violation is declared either as an 'error' or as a 'warning' by a Mark single run job executed event action, which sets a corresponding flag.
In the course of Tests for the check logic, the Event recorder should be able to be used in order to reconstruct for each checked address of a shipment the result of the plausibility check.
Configuration:
|
The event handling shown on the right defines the procedure by which all company and address attributes of a shipment are subjected to a plausibility check that takes place in another event handling.
The check is followed here by event actions that are intended to make the check result traceable in the Event recorder:
|
|
Runtime example:
The following screenshot shows the chronologically sorted entries in the Event recorder, while checking a shipment with three company and address attributes.
In the list, the first entry with a 'success message' (ADDR_OK) is selected. The Input value tab shows above the list the data of the respective company attribute.
The first entry (TestEvent) marks the beginning of the test. It was created automatically by the system.
Then the following three groups of entries are triggered within the loop. The scheme is always the same:
The 'Check address' custom action event is triggered, which is automatically recorded by the Event recorder.
The debug snapshot with the Name ADDR_CHECK marks the beginning of the evaluation of the flags set by the check.
This is followed by the debug snapshot that is triggered in the passed branch of the case discrimination with the Name ADDR_ERROR or ADDR_WARNING or ADDR_OK.
The run index starting at #0 behind the Name provides information about the 'statistics':
The last entry for ADDR_CHECK has the index 2, so a total of 3 addresses were checked.
The last entry for ADDR_OK has the index 1, so a total of 2 addresses were tested without any results.
The index 0 in the only entry for ADDR_WARNING makes it clear that only for one address the overall verdict 'warnings' was valid.
No errors occurred because no entry with the name ADDR_ERROR was recorded.
►NOTE◄
Since the Name of the entries 'arbitrarily' created here by the Create debug snapshot always starts with the string ADDR, the filter function of the list can be used to display only the relevant history in the Event recorder:
