That would require that the OUTER_AAE is aware of the filtering. We would prefer if all customization/filtering/etc. could be done in the INNER_AAE which is the declared extension point.
In the worst case, we'd probably opt to move the FILTER from to the OUTER_AAE entirely and make filtering a default option. My assumption would be that the OUTER_AAE should not have a problem if the INNER_AAE drops anything if INNER_AAE declares outputsNewCases=true. But obviously that assumption is wrong - I/we just don't get why. Cheers, -- Richard On 06.09.2015, at 17:14, Eddie Epstein <[email protected]> wrote: > How about the filter adds a FeatureStructure indicating that the CAS should > be dropped. > Then when the INNER_AAE returns the CAS, the flow controller in the > OUTER_AAE > sends the CAS to FinalStep? > > Eddie > > On Sun, Sep 6, 2015 at 11:08 AM, Richard Eckart de Castilho <[email protected]> > wrote: > >> Eddie, >> >> we (Torsten and I) have the case that a reader produces a number of CASes >> and we want to filter out some of them because they do not match a given >> criteria. >> >> The pipeline/flow structure we are using looks as follows: >> >> READER -> OUTER_AAE { AEs..., INNER_AAE { FILTER }, AEs..., CONSUMER } >> >> READER, OUTER_AAE, AEs and CONSUMER are assumed to be fixed. >> >> INNER_AAE is meant to be an extension point and the FILTER inside it >> is meant to remove all CASes that do not match our criteria such >> that those do not reach the CONSUMER. >> >> So we do explicitly not want certain CASes to continue the processing path. >> >> -- Richard >> >> On 06.09.2015, at 17:04, Eddie Epstein <[email protected]> wrote: >> >>> Richard, >>> >>> In general the input CAS must continue down some processing path. >>> Where is it stored and what triggers its continued processing if it is >> not >>> returned? >>> >>> Eddie >>> >>> On Sun, Sep 6, 2015 at 10:28 AM, Richard Eckart de Castilho < >> [email protected]> >>> wrote: >>> >>>> Hi Eddie, >>>> >>>> in most cases, we use process(CAS) and in such a case what you describe >>>> is very logical. >>>> >>>> However, when setting outputsNewCases to true, doesn't the contract >> change? >>>> My understanding is that processAndOutputNewCASes(CAS) is being >>>> used and in such a case. Why shouldn't it be ok that the iterator >>>> returned by processAndOutputNewCASes does not contain the input CAS? >>>> >>>> Cheers, >>>> >>>> -- Richard >>>> >>>> On 06.09.2015, at 16:21, Eddie Epstein <[email protected]> wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> FinalStep() in a CasMultiplier aggregate means to stop further flow >>>>> in the aggregate and return the CAS to the component that passed >>>>> the CAS into the aggregate, or if a child-CAS, passed the child's >>>>> parent-CAS into the aggregate. >>>>> >>>>> FinalStep(true) is used to stop a child-CAS from being returned >>>>> to the component. But the contract for an AE is CAS-in/CAS-out, >>>>> which means a CAS coming into an AE must be returned. >>>>> >>>>> Eddie >>>>> >>>>> On Sun, Sep 6, 2015 at 9:59 AM, Richard Eckart de Castilho < >>>> [email protected]> >>>>> wrote: >>>>> >>>>>> Hi Eddie, >>>>>> >>>>>> ok, but why can input CASes created outside the aggregate not be >>>> dropped? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -- Richard >>>> >>>> >> >>
