Hi LF,
this feature (not occurrence of an event) can definitely be implemented and
the community is currently working on it. I think that both scenarios
you're describing a legit use cases and Flink's implementation of the not
operator should cover both.
I hope that this feature can be used soon. For a more detailed answer of
Frank's email see [1].
[1]
http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/more-complex-patterns-for-CEP-was-CEP-two-transitions-to-the-same-state-td9046.html
Cheers,
Till
On Sun, Sep 18, 2016 at 7:37 AM, wrote:
> Hi,
>
>
>
> We are also looking for negation (absence of an event) functionality in
> Flink CEP. Something like notFollowedBy/notNext that detects the following
> patterns will be great additions to Flink CEP (other CEP frameworks support
> negation):
> 1. Occurrence of an event (that matches specific criteria) followed by
> absence of an event (that matches specific criteria) followed by another
> event (that matches specific different criteria)
> 2. Occurrence of an event (that matches specific criteria) followed by
> absence of an event (that matches specific criteria) for a specific period
>
> Could this be implemented?
>
> Thank you.
>
>
> - LF
>
>
> --
> *From:* Frank Dekervel
> *To:* user@flink.apache.org
> *Sent:* Friday, September 16, 2016 1:04 PM
> *Subject:* more complex patterns for CEP (was: CEP two transitions to the
> same state)
>
> Hello,
>
> i did some more analysis wrt the problem i'm facing and the flink CEP api.
>
> In order to complete the problem i'm facing using flink CEP i would need 3
> additions to the API (i think). I tried to understand the NFA logic, and i
> think 2 of them should be doable without fundamental changes.
>
> First is to add a "negative" pattern (notFollowedBy / notNext):
>
> Reason is the flow below: i have a start and a termination event, and an
> optional "failure" event in between. i want all succesful termination
> events, so i want to express there should not be a failure event between
> the start and the termination event. Note that there is no "success" event
> in this case on which i could match.
>
> [image: Inline image 1]
>
> To implement, upon checking whether a transition would be possible, one
> would first need to check if it was not already dead-ended by a
> notFollowedBy / notNext. This would add a bit of complexity to the logic
> (when seeing if a transition is valid for a state, first check if on this
> state there was not already a match made to an notFollowedBy/notNext state.
> in that case one would reject the match)
>
> Second is to allow the filterfunction to inspect the partial match made,
> so one would be able to filter based on the already-matched event. Reason
> is the following (hypothetical) example where we would match arrivals of a
> trains in a station. We cannot keyBy train (because the "occupied" events
> of the station don't have train information), neither can we keyBy station
> (as the start of the sequence is outside the station), so we need to add an
> additional condition for the second event: the train number must equal the
> train number of the first one. And in the third event, the station number
> should equal the station number of the second one.
>
> I think this could be accomplished by overloading the where function with
> a second filterfunction variant that takes 2 parameters: the event
> considered + the partial match (as a Map with T the class of the
> event)
>
> [image: Inline image 2]
>
> Third one is - i think - more difficult to accomplish, and that's more
> complex graphs i asked in my original e-mail (eg two states having 2
> transitions ending in the same state).
> The problem here is that it allows one to construct cyclic states, and the
> PatternStream takes a Map as input, which cannot express a state
> occuring twice, neither the order (which event was the first and which
> event was the second). In the problem i'm trying to solve cyclic states are
> not necessary, but i can imagine usecases exist.
>
> [image: Inline image 3]
> I think the NFA implementation would already allow such scenario's but the
> nfacompiler and the CEP api would need changing.
>
> I wonder if the problem i'm facing is exotic (so a custom CEP would be
> more logic) or it is just something that should be implemented in the flink
> CEP. I'm relatively new to CEP, so i cannot compare which other
> systems/implementations. I'd like to try implementing the changes myself
> (at least the first two) after taking some advice here ...
>
> thanks!
> greetings,
> Frank
>
>
>
>
>
>
> On Wed, Sep 14, 2016 at 5:22 PM, Frank Dekervel wrote:
>
> Hello,
>
> I'm trying to model a FSM using the flink CEP patterns. However, there is
> something i can't figure out as all the documentation examples are linear
> (either you go to the single possible next state, either no match).
>
> Suppose that two transitions lead from one state to two different states.
> I gu
