Of course, a custom processor can create any attribute, including an
"external id field." I don't think it can "lose" the original uuid
since, if it attempts to reset it, the action will be quietly ignored
(Mark).
Note that uuid figures prominently in the display of provenance--in my
mind
Hmm,
I've seen this come up a few times now I wonder is there need for a rename
of the uuid field and a creation of an external id field?
Edward
On Tue, 18 Jul 2023, 20:53 Lucas Ottersbach,
wrote:
> Hey Matt,
>
> you wrote that both `Session.create` and `Session.clone` set a new FlowFile
>
That was impression as well. Thank you for the quick response and the
clarification.
Best regards
Lucas
Mark Payne schrieb am Di., 18. Juli 2023, 21:56:
> Lucas,
>
> You cannot control the UUID. It’s automatically generated by the
> framework. If you attempt to use
Lucas,
You cannot control the UUID. It’s automatically generated by the framework. If
you attempt to use ProcessSession.putAllAttributes or
ProcessSession.putAttribute, it’ll ignore the “uuid” key.
Thanks
-Mark
> On Jul 18, 2023, at 3:51 PM, Lucas Ottersbach
> wrote:
>
> Hey Matt,
>
>
Hey Matt,
you wrote that both `Session.create` and `Session.clone` set a new FlowFile
UUID to the resulting FlowFile. This somewhat sounds like there is an
alternative way where the UUID is not controlled by the framework itself?
I've got a different use case than Russell, but was wondering
In general I recommend only sending on those attributes that will be
used at some point downstream (unless you have an "original"
relationship that should maintain the original state with respect to
provenance). If you don't know that ahead of time you'll probably need
to send all/most of the
I have a custom processor, /SplitHl7v4Resources/, that splits out
individual FHIR resources (Patients, Observations, Encounters, etc.)
from great Bundle flowfiles. So, for a given flowfile, it's split into
hundreds of smaller ones.
When I do this, I leave the existing NiFi attributes as they
