[
https://issues.apache.org/jira/browse/NIFI-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068566#comment-18068566
]
Richard Scott commented on NIFI-15737:
--------------------------------------
I have implemented the UI and behaviour changes for this in my branch but
wanted to help show how sequential rule evaluation in UpdateAttribute can work
in practice.
The approach introduces {{Sequential}} as a new, explicit option within the
Advanced Rules experience, alongside the existing FlowFile Policy options such
as {{Original}} and {{{}Clone{}}}. This means there is no change to the current
default behaviour for existing flows or users unless this new option is
deliberately selected.
With this implementation:
* A new {{Sequential}} policy is available in the Advanced Rules policy
selector
* Rules are evaluated in order, with later rules able to reference attributes
updated by earlier rules
* A reorder mode is available so users can control execution order where needed
* Matched rule metadata still reflects the rules that were applied, while the
final attribute values reflect the outcome of ordered evaluation
The example shown in the screenshots uses two rules:
* {{room_rate}} checks {{${room:notNull()}}} and updates {{total}} using
{{${total:plus(100)}}}
* {{latecheckout}} checks {{${late:notNull()}}} and updates {{total}} using
{{${total:plus(200)}}}
With {{Sequential}} enabled and both attributes present, the final {{total}}
becomes {{{}300{}}}, since the second rule evaluates against the updated value
produced by the first rule.
This is the type of use case I had in mind for dependent, ordered updates,
where each rule can build on the result of the previous one. The intent is to
provide an additional, opt-in way of evaluating Advanced Rules for cases where
sequential behaviour is useful, while leaving the current UpdateAttribute
behaviour unchanged for all existing use cases.
> 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
> Attachments: Rules.png, basic-menu.png, policy.png,
> result-attributes.png
>
>
> 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)
