[
https://issues.apache.org/jira/browse/NIFI-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18067787#comment-18067787
]
Richard Scott commented on NIFI-15737:
--------------------------------------
Thanks for the comment [~exceptionfactory] — I agree the UpdateAttribute
processor is foundational, so any changes need to be carefully considered.
>From a user experience standpoint, my intent is for this to be introduced as a
>new, explicit option within the Advanced Rules configuration, alongside the
>existing FlowFile Policy options (use original, use clone). This means there
>would be no change to the current default behavior or to how existing flows
>operate today.
The idea is simply to provide an additional, opt-in way of evaluating rules for
cases where ordered, dependent updates are helpful, while keeping the current
behaviour unchanged for existing use cases, and I’m happy to refine the UX
further based on feedback before moving toward implementation.
> 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)
