[rules-users] Implementation of my use case - what am I doing wrong?

[Wolfgang Laun]

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