[rules-users] Implementation of my use case - what am I doing wrong?
Wolfgang Laun
wolfgang.laun at gmail.com
Sun Sep 22 12:05:50 EDT 2013
On 22/09/2013, Elran Dvir <elrand at checkpoint.com> wrote:
> Thanks for the response.
>
>>Computationally, during the evaluation of the temporal operators.
>>Why would you want to do this? (My advice to replace the temporal operators
>> by the equivalent expressions was meant as a debugging aid, to show you
>> where the problem with this constraint is.)
> So if changing the condition to use startTimeStamp and endTimestamp caused a
> compilation error, How can I debug my problem? What is the equivalent of
> "(this meets $ce || this during $ce || this metby $ce)" without my own
> startTimeStamp and endTimestamp fields?
>
So I'm quoting my reply from an earlier mail
<quote>
> Elran Dvir <elrand at checkpoint.com> wrote:
>
> 2) When I tested it with matching data, rule "Create Port Scan Event -
> update" was never fired. When I replaced "(this meets $ce || this during $ce
> || this metby $ce)" with "this after $ce.getStartTime() , this before
> $ce.getEndTime()" everything worked fine.
> Why?
Just take the constraints and replace the temporal operator by its
definition in the "Fusion" manual and use a little elementary math:
A meets || A during B || A metby B
becomes
abs( B.startTimestamp - A.endTimestamp ) == 0 ||
B.startTimestamp < A.startTimestamp && A.endTimestamp <
B.endTimestamp || abs( A.startTimestamp - B.endTimestamp ) == 0
becomes
...
</quote>
Did you overlook the "use a little elementary math"? YOu'll have to
provide the values for start and, given the duration (zero,
presumably) the end time. If B has a duration of 0, there's no way the
second term can ever be true. And if A has a duration of 0 too, A and
B must have the same timestamp in order for the other terms to be
true.
Note that "debugging" was meant to be done offline ;-)
> > - Why do you use this complex declare?
> > @timestamp( timestamp ) @duration( duration )
> > is sufficient.
>
> I want to protect the fields from being set outside their designated
> functions .I simplified it a bit in my correction.
I don't know of any danger of your field being set outside their
designated functions by simply writing the field name between the
parentheses.
-W
More information about the rules-users
mailing list