There's another form of accumulate that lets you use collectList (or
collectSet) to accumulate any object collection, even in parallel to
count. But if you want the facts themselves, you might use "collect"
in the first place.
-W
On 06/12/2013, IK81 <ml(a)kofler.me> wrote:
Ahh... nice solution. Perhaps I was simply thinking too complicated.
Works fine.
There's however one thing that does not work with the accumulate for
me.
>>>> Number( intValue == 3 ) from accumulate(
>>>> Event( $i : id, code == "ABCD") over window:time( 5m
),
>>>> count( $i ) )
In all my other rules I retrieve the events that caused my rule to via
via the kcontext.getMatch().getObjects(). In this case I just get a
number object with value 3. Seems to be appropriate since I am matching
against that number. But how can I get the ids of those three events
that caused my rule to fire?
Thanks,
Ingo
On 2013-12-05 09:40, Wolfgang Laun wrote:
> What about
>
> rule cleanup
> when
> $d: Device( $id: id )
> not Event( id == $id )
> then
> retract( $d );
> end
>
> -WL
>
> On 05/12/2013, IK81 <ml(a)kofler.me> wrote:
>> The devices may come and go and there may be several hundreds of
>> them.
>> They are stored in a database.
>>
>> Currently, I feed the events into the knowledge session and trigger
>> an
>> EJB call (instead of the simple System.out.println I used in the
>> example
>> below) and pass the device id. The EJB does the rest and looks up
>> the
>> device and related information from the database. If the id is
>> unknown,
>> this call is just a NOOP.
>>
>> Currently the knowledge session and the database need no
>> synchronization. I just wanted to avoid this in my design, but now
>> it
>> seems to be necessary just for this group-by issue. I can imagine
>> that I
>> can also insert the fact using a rule that matches if I get an event
>> for
>> a currently unknown device (i.e., having no fact for it in the
>> session),
>> but how to clean up the facts if a device disappears. This @expires
>> annotation is only valid for events afaik.
>>
>> Are there really no alternatives for this group-by instead of having
>> the fact?
>>
>> Ingo
>>
>>
>> On 2013-12-05 06:52, Wolfgang Laun wrote:
>>> Why is it "not practical" to add a fact for a device? You
don't
>>> have
>>> to do this up front; they may come and go, dynamically.
>>>
>>> -W
>>>
>>>
>>> On 05/12/2013, IK81 <ml(a)kofler.me> wrote:
>>>> Hi,
>>>>
>>>> I am trying to figure out a rule for matching an incoming sequence
>>>> of
>>>> events, but so far I was not really successful. Basically, I want
>>>> to
>>>> process events from devices. Every event has a timestamp (long),
>>>> an
>>>> id
>>>> (a UUID string), a deviceId and an error code (both are strings).
>>>>
>>>> What I want to have is a simple rule that fires, if a single
>>>> device
>>>> reports a certain error code (e.g. ABCD) 3 times within 5 minutes
>>>> (i.e.,
>>>> getting 3 such events within 5 minutes). So far, I suceeded in
>>>> counting
>>>> the ABCD error codes in the time window as follows:
>>>>
>>>>
>>>> rule "Detect 3 occurrences of code ABCD for a certain device"
>>>> when
>>>> Number( intValue == 3 ) from accumulate(
>>>> Event( $i : id, code == "ABCD") over window:time( 5m
),
>>>> count( $i ) )
>>>> then
>>>> System.out.println("Raise alarm");
>>>> end
>>>>
>>>> This first attempt does not distinguish which device sent the
>>>> error
>>>> code. But how can I express to fire only if the events share the
>>>> same
>>>> deviceId? I found many solutions that use a fact (e.g., a device
>>>> fact)
>>>> to group by the device and do the accumulation. I successfully
>>>> implemented the group-by using the following when-part of the
>>>> rule.
>>>>
>>>> when
>>>> Device($deviceId : id)
>>>> Number( intValue == 2 ) from accumulate(
>>>> Event( $i : id, deviceId == $deviceId, code ==
"ABCD")
>>>> over
>>>> window:time( 5m ),
>>>> count( $i ) )
>>>> then
>>>>
>>>> Adding a device fact is however not practical in my case. Are
>>>> there
>>>> any
>>>> alternatives for expressing this group-by?
>>>>
>>>> Thanks,
>>>> Ingo
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users