Overriding the getdate function in rules files

Use this workaround if at least one probe in your environment is set to circular store-and-forward mode, and each probe in the environment sets the LastOccurrence value to the epoch time.

This behavior occurs if the rules file contains the following syntax:

@LastOccurrence = getdate

Important: This solution works only if LastOccurrence is set to the epoch time by the rules file . If you want the LastOccurrence value to be lower for a subsequent event then this solution does not work because it may lead to non-unique combinations of LastOccurrence and ProbeSubSecondId.

About this task

If the rules file sets the LastOccurrence value to the epoch time, events might be assigned inconsistent LastOccurrence values and ProbeSubSecondId values, after the events are processed. This is because the ProbeSubSecondId value is set to the value of LastOccurrence before the rules file is processed.

The following example shows three events that are received over one second. For brevity, the previous 122 events that arrived in the same second are not shown. For illustrative purposes, the events are numbered.

[1] LastOccurrence=10000001, ProbeSubSecondId=123
[2] LastOccurrence=10000001, ProbeSubSecondId=124
[3] LastOccurrence=10000002, ProbeSubSecondId=0

The epoch time changes to 10000002 while event 2 is being processed by the rules file. The LastOccurrence value is adjusted, but the ProbeSubSecondId value is not. The ProbeSubSecondId value that was set before rules file processing is retained. As a result, the LastOccurrence value of event 2 greater than event 1, but the ProbeSubSecondId value is greater than event 3 and any subsequent events. The LastOccurrence values and the ProbeSubSecondId values of these three sample events, before and after processing by the rules file, are shown in the following table.

Table 1. Example that shows how the ProbeSubSecondId value can be set incorrectly after it is processed by the probe rules file
Event	Event before processing by the rules file	Event after processing by the rules file
1	`LastOccurrence=10000001, ProbeSubSecondId=123`	`LastOccurrence=10000001, ProbeSubSecondId=123`
2	`LastOccurrence=10000001, ProbeSubSecondId=124`	`LastOccurrence=10000002, ProbeSubSecondId=124`
3	`LastOccurrence=10000002, ProbeSubSecondId=0`	`LastOccurrence=10000002, ProbeSubSecondId=0`

If event 3, or any subsequent events that are processed by the probe, deduplicate with event 2, the deduplication trigger, the reinsert is cancelled.

Procedure

To resolve this problem:

Put the following snippet of rules file syntax into an include file and include it in all the probe rules files in your environment.
For illustrative purposes, the file is called pssi.include. Put the include at the end of the rules file and ensure that the syntax in the include runs for all events (that is, outside of any conditional statements). The syntax of the include sets the ProbeSubSecondId value based on the LastOccurrence value but after processing by the rules file, so that the ProbeSubSecondId value is adjusted if the LastOccurrence value is changed.
```
# begin pssi.include
if( match( %LastEventTime, "" ) ) {
# Initialise
%LastEventTime=@LastOccurrence
%ProbeSubSecondId=1
}
if( match( @LastOccurrence, %LastEventTime ) ) {
# Event has same LastOccurrence as previous event
# Increment PSSI and assign
%ProbeSubSecondId=int(%ProbeSubSecondId)+1
@ProbeSubSecondId=int(%ProbeSubSecondId)
} else {
# Event has different LastOccurrence to previous event
# Store LastOccurrence value, reset PSSI and assign
%LastEventTime=@LastOccurrence
%ProbeSubSecondId=1
@ProbeSubSecondId=int(%ProbeSubSecondId)
}
# end pssi.include
```

Edit the deduplication trigger as follows:

Locate the section that processes the ProbeSubSecondId value and change it so that it reads as follows.

Make a backup of the trigger before you make any changes.

if( %user.app_name = 'PROBE' )
then
if( (old.LastOccurrence > new.LastOccurrence) or
( (new.ProbeSubSecondId > 0 ) and
(old.ProbeSubSecondId >= new.ProbeSubSecondId) and
(old.LastOccurrence = new.LastOccurrence) ) )
then
cancel;
end if;
end if;

Locate the following section:

set old.ProbeSubSecondId = new.ProbeSubSecondId;

Move this section inside a condition, so that it reads as follows:

if( new.ProbeSubSecondId > 0 )
then
set old.ProbeSubSecondId = new.ProbeSubSecondId;
end if;

What to do next

If you also use the genevent() function to generate new events, then you need to give further consideration to the value of ProbeSubSecondId. If you want events that are generated by the genevent() function to be handled by the same rules as other events, you need to manually assign a ProbeSubSecondId value to genevent() events.

Because genevent() events are sent to the ObjectServer immediately at the point that the genevent() section of the rules file is processed, the genevent() event is sent before the actual event (the actual event is sent only after rules file processing is complete). Consequently, you need to assign a ProbeSubSecondId to the genevent() and then increment the ProbeSubSecondId counter before the rules file completes processing and a ProbeSubSecondId value is assigned to the actual event.

To implement this behavior, put the include to pssi.include in the rules file before each call to genevent(), so that the syntax reads as follows:

include "path/pssi.include"
genevent( target )

If the target table for genevent() does not contain the LastOccurrence or ProbeSubSecondId fields, this include has no effect.

If a field list is provided to the genevent() call, and the target contains LastOccurrence or ProbeSubSecondId fields then specify these fields in the genevent() call, for example:

include "path/pssi.include"
genevent( target, Identifier, $Identifier, ... , LastOccurrence,
@LastOccurrence, ProbeSubSecondId, @ProbeSubSecondId )

Specifying the fields ensures that the values are provided and recorded in case of failover or failback, and the circular store-and-forward file is replayed.