There are two concepts that need to be understood here: SessionClock and
type declaration.
SessionClock is the clock of the session. You can use a realtime clock
for your session, or any other session clock implementation. At this moment
we only provide a realtime one, and a PseudoClock (meaning it is a clock
controlled by the application code). We can add heartbeat clocks and any
other implementations of the session clock interface, but they are not
there.
When developing unit tests for instance, I imagine you will always use
PseudoClock, because the test controls the clock and make sure the rules are
behaving accordingly.
The other concept is type declaration. When you declare a type as an
"event", you can optionaly tell the engine what field in that type is used
as timestamp. If you don't, the engine will assign to the event the
timestamp of the session clock in the momment the event is inserted into the
engine.
declare CreditAuthorizationRequest
@role( event )
@timestamp( datetimeOfRequest )
end
For your case, you can either tell the engine to use a specific
timestamp attribute when running the batch autorizations at the end of the
date, or use the PseudoClock, setting it to the appropriate time, before
inserting each event. There are semantic differences in both approaches, so
you need to look at the whole of your scenario to decide what is more
appropriate to you.
Ok, can someone help translating this into a users manual? ;) Or
examples?
/me back to docs
Edson
2009/2/2 John A Thompson <fly.yamaha(a)gmail.com>
Edson,
I'm very interested in fusion. I'm looking at it using it for fraud
detection in a credit card authorization system.
Quick question - can the time of facts be asserted? I'm thinking around
how to handle testing, and business requirements of batch authorizations.
(where 3rd parties send in batch at the end of the day)
Thanks!
JT
On Mon, Feb 2, 2009 at 3:30 PM, Edson Tirelli <tirelli(a)post.com> wrote:
>
> Do you know the concept of sliding time windows? Meaning you define a
> time interval, for instance the last 30 seconds, so at time T30, the window
> contains anything that happened between T1 and T30. At T31, it forgets
> anything that happened on T1 and the window now contains everything from T2
> to T31, and so on.
>
> So, think about sliding windows as a filter.
>
> StockTick( symbol == "RHAT" ) over window:time( 60s )
>
> The pattern above will match all StockTicks whose symbol is RHAT and
> that happened in the last 60 seconds. Since time is continuous (unless you
> use a pseudo clock that you control manually), events will age and fall
> outside the boundary of the window (in this case, older than 60 seconds).
> When that happens, they will expired and will no longer match.
>
> Once a regular activation is created, it will remain in the agenda
> until it is fired. Even if the event expires before the activation is fired.
> The only "special case" for this are the aggregations, that are constantly
> updated and at fire time, will contain the current result.
>
> Over is just the keyword used to introduce behaviors of a pattern, like
> time windows, length windows and so on. Hopefully docs will contain a better
> explanation.
>
> []s
> Edson
>
>
> 2009/2/2 Trägenap <traegenap(a)ttc-informatik.de>
>
>> I hope you will not be interrupted by too many postings....
>>
>> but -sorry- what is the result of
>>
>> StockTick( symbol == "RHAT" ) over window:time( 1h30m15s )
>>
>> ?
>>
>> a) all StockTick Entities which has symbol "RHAT" at some point during
>> the time period? In other words: are StockTicks included where symbol had
>> changed for e.g. within the first 30 minutes?
>>
>> b) all StockTick Entities which have symbol "RHAT" when rule fires?
>>
>> What means "over"? Is the rule allowed to fire after period of
1h30m14s,
>> is this right?
>>
>>
>> Thanks
>> Thorsten
>>
>>
>> Edson Tirelli schrieb:
>>
>>>
>>> I started writing fusion docs a couple days ago. You can follow the
>>> progress through hudson builds or checking out the source code from svn.
>>>
>>> Regarding your question, clock ticks are an abstract concept that
>>> depends on the clock implementation you are using. Since I wrote the test
>>> case you saw, I added support for proper time units, and as so, I recommend
>>> you use them. So, if you want to create a sliding window of 1 hour 30 min
>>> and 15 seconds, for instance, just do:
>>>
>>> StockTick( symbol == "RHAT" ) over window:time( 1h30m15s )
>>>
>>> I did not wrote that part of the docs yet, and in case anyone want to
>>> help, it would be most welcome.
>>>
>>> []s
>>> Edson
>>>
>>> 2009/2/1 Trägenap <traegenap(a)ttc-informatik.de <mailto:
>>> traegenap(a)ttc-informatik.de>>
>>>
>>> Hi,
>>>
>>> 2 questions:
>>>
>>> 1. I want to start a ruleflow-group for e.g. only once a day? I am
>>> not interested in the pattern matches during the complete day, just
>>> interested in the result of the single computation. My
>>> ruleflow-group is ordered using a salience, the final/last rule
>>> should be processed once a day, repeating at the next day, and so
>>> on...
>>>
>>> I found the example like this
>>>
>>> StockTick( symbol == "RHAT" ) over window:time( 60 )
>>>
>>> (...that happened in the last 60 clock ticks...)
>>>
>>> What is declared as "clock ticks"?
>>>
>>>
>>> 2. I guess that drools fusion can solve my problem, is some more
>>> detailed doc available at this moment? (more than the ´pure´
>>> headlines containing doc I found everywhere?)
>>>
>>> Thanks for advice, including just giving keywords!
>>>
>>> Thorsten
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>
>>>
>>> --
>>> Edson Tirelli
>>> JBoss Drools Core Development
>>> JBoss, a division of Red Hat @
www.jboss.com <
http://www.jboss.com>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>>
>> --
>>
>>
>> *Gesprächspartner:*
>>
>>
>>
>>
>>
>> *Datum:*
>>
>>
>>
>>
>>
>> *Inhalt:*
>>
>>
>>
>>
>>
>> *TODO:*
>>
>>
>>
>>
>>
>> *Rückmeldung bis:*
>>
>>
>>
>>
>>
>> *Absender:*
>>
>>
>>
>> TT
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @
www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @