[
https://issues.apache.org/jira/browse/NIFI-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18067765#comment-18067765
]
David Handermann commented on NIFI-15737:
-----------------------------------------
Thanks for describing this potential change [~mcducks01].
The Advanced Rules for UpdateAttribute have functioned the same way for quite
some time, so any substantial change along these lines requires both
implementation and user experience consideration.
Before proceeding to implementation, can you outline how this could work from a
user experience perspective? In particular, covering compatibility with
existing configurations, and intuitive behavior of the proposed functionality
would be very helpful. Getting those elements aligned first will help prior to
reviewing code changes.
> UpdateAttribute: Add Sequential Evaluation Mode for Advanced Rules
> ------------------------------------------------------------------
>
> Key: NIFI-15737
> URL: https://issues.apache.org/jira/browse/NIFI-15737
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Richard Scott
> Assignee: Richard Scott
> Priority: Minor
>
> h2. *Motivation*
> The *UpdateAttribute* processor Advanced UI evaluates all rules against the
> original set of FlowFile attributes. Attribute updates made by one rule are
> not visible to subsequent rules during the same evaluation.
> This limits support for {*}incremental or dependent transformations{*},
> requiring:
> * loopback patterns
> * multiple processors
> * complex Expression Language
> These approaches introduce unnecessary complexity and reduce flow readability
> for what is conceptually a single logical operation.
> h2. *Proposed Enhancement*
> Introduce an optional evaluation mode:
> *Sequential Evaluation*
> When enabled, Advanced rules are evaluated in configured order. If a rule’s
> condition matches, its updates are applied immediately and become visible to
> subsequent rules during the same FlowFile evaluation.
>
> h2. *Example Use Case*
> h3. Scenario: Aggregating a total from optional attributes
> Attributes:
> room.rate = 200
> room.service = 35
> in.room.entertainment = 15
> late.checkout = <not set>
> h3. Example
> Assume the following incoming attributes:
> Rule 1
> Condition: always true
> hotel.bill.total = 0
> Rule 2
> Condition: room.rate exists
> hotel.bill.total = ${hotel.bill.total:plus(${room.rate})}
> Rule 3
> Condition: room.service exists
> hotel.bill.total = ${hotel.bill.total:plus(${room.service})}
> Rule 4
> Condition: in.room.entertainment exists
> hotel.bill.total = ${hotel.bill.total:plus(${in.room.entertainment})}
> Rule 5
> Condition: late.checkout exists
> hotel.bill.total = ${hotel.bill.total:plus(${late.checkout})}
>
> Evaluation result:
>
> After Rule 1: hotel.bill.total = 0
> After Rule 2: hotel.bill.total = 200
> After Rule 3: hotel.bill.total = 235
> After Rule 4: hotel.bill.total = 250
> Rule 5 skipped because late.checkout does not exist
> Final hotel.bill.total = 250
> This enables a natural, incremental approach to attribute transformation
> within a single processor, eliminating the need for loopback patterns and
> significantly improving flow clarity and maintainability.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
