[rules-users] Re: scheduled starting of a ruleflow-group / drools fusion docs
John A Thompson
fly.yamaha at gmail.com
Tue Feb 3 09:26:19 EST 2009
Thanks Edson. I think I follow you. In my example, I will always have the
transaction timestamp. In the case of the batch transactions, I still get
the transaction time, I just might get the data a few hours later. I should
be good if I use the transaction time for @timestamp.
Cool stuff.
I still have a lot to learn here, but ping me off line about how I can help
with the documentation.
Thanks,
JT
On Mon, Feb 2, 2009 at 6:32 PM, Edson Tirelli <tirelli at post.com> wrote:
>
> 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 at 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 at 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 at 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 at ttc-informatik.de <mailto:
>>>>> traegenap at 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 at lists.jboss.org <mailto:rules-users at 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 at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090203/6eed7849/attachment.html
More information about the rules-users
mailing list