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
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@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!
JTOn Mon, Feb 2, 2009 at 3:30 PM, Edson Tirelli <tirelli@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
Edson2009/2/2 Trägenap <traegenap@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:
2009/2/1 Trägenap <traegenap@ttc-informatik.de <mailto:traegenap@ttc-informatik.de>>
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
rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org> JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
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 mailing list
rules-users@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users