Replies: 4 comments
-
Hi @noamarbel, GoRuels ZEN Engine is primarily focused on stateless decision evaluation. This means that by default, it does not maintain state or remember previous facts between evaluations. Although this is not available out of box, it's certainly something that you can build by using our open source blocks and a database of your choice. (If your end goal is to record inputs, outputs and trace) |
Beta Was this translation helpful? Give feedback.
-
Hi Stefan, thanks for your reply.
Can you give me some idea/direction as to how to go about doing this? I cannot store the incoming events and rerun them, as the rules are long running and there are millions of events a day. What should I store in the db? Can I serialize the rules some how? Basically the rules are A happened then B, then C. Or A, then B 5 times, then C(if c<100), and so on.
Any direction would be greatly appreciated.
Thanks
…--
Noam
________________________________
From: stefan-gorules ***@***.***>
Sent: Thursday, August 15, 2024 10:58:47 PM
To: gorules/zen ***@***.***>
Cc: noamarbel ***@***.***>; Mention ***@***.***>
Subject: Re: [gorules/zen] Incremental facts (Discussion #229)
Hi @noamarbel<https://github.com/noamarbel>,
GoRuels ZEN Engine is primarily focused on stateless decision evaluation. This means that by default, it does not maintain state or remember previous facts between evaluations.
Although this is not available out of box, it's certainly something that you can build by using our open source blocks and a database of your choice. (If your end goal is to record inputs, outputs and trace)
—
Reply to this email directly, view it on GitHub<#229 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAVZEAQ6C5YSOY72DQF2GLZRUB7PAVCNFSM6AAAAABMSWCSBCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZVGIYDCOA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi @noamarbel, Would you be able to describe your use case more in depth? From top of the head, the only 2 pieces of information you need in order to replay the decision (what ran and how):
If it's too much to store every event, you may instead opt for storing a snapshot. You can relationally store the reference to version of JDM Rule along with the optional trace. |
Beta Was this translation helpful? Give feedback.
-
Thanks again Stefan.
The scenario is tracking user input across either a very short time, or a
very long time. A lot of social engineering, bots, and fraudulent activity
can be caught this way. FOr example, doing a password change, followed by a
big purchase, or changing a credit card on an account followed by 5 or more
purchases within 5 seconds to different addresses. Or calling support to
reset a password, followed by a change of personal details a month later
(support is a weak point for social engineering attacks).
As there are millions of transactions a day, I cannot replay them every
time. So I need to cache a state of the rule as it got so far (i.e. some
conditions are met), and when a new event comes in, check the rules again
against the new event. Of course this is done per account, so there can by
many active rules at any given time (number of rules x number of active
accounts).
Does this make sense?
So my question is, is there, or can add a way so I can cache data within
the rule snapshot, and store it, so it remembers it across invocations? Any
other way you can see doing this?
Thanks.
P.S. If you want to take this off-line from the board, let me know what
email to use.
…--
Noam
------------------------------
*From:* stefan-gorules ***@***.***>
*Sent:* Friday, August 16, 2024 6:11:48 PM
*To:* gorules/zen ***@***.***>
*Cc:* noamarbel ***@***.***>; Mention ***@***.***>
*Subject:* Re: [gorules/zen] Incremental facts (Discussion #229)
Hi @noamarbel <https://github.com/noamarbel>,
Would you be able to describe your use case more in depth?
From top of the head, the only 2 pieces of information you need in order to
replay the decision (what ran and how):
1. JDM Rule definition (in JSON format), can be stored in database
2. Event data, can also be stored in database
If it's too much to store every event, you may instead opt for storing a
snapshot. You can relationally store the reference to version of JDM Rule
along with the optional trace.
—
Reply to this email directly, view it on GitHub
<#229 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVZEA2D4YBJUDWPQE3GILZRYJDJAVCNFSM6AAAAABMSWCSBCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZWGAZDKNY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hello,
I am starting to evaluate the use of Zen in my project. Is it possible to build a decision engine where the facts come in one at a time, and the engine remembers the previous facts. This is how the Rete engine works AFAIK.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions