SOunds good Andy, No biggie, I can keep on truckin' with what we've been doing. Thanx for the insight!
Regards, Dano On Wed, Apr 22, 2020 at 1:38 PM Andy LoPresto <[email protected]> wrote: > Dan, > > Unfortunately I don’t believe there is a way to consolidate this in a > single UA processor because currently the application of the attributes is > not deterministically ordered, so b may not be available when c is > evaluated and applied. The current work around is to use linear dependent > processors as you are doing. I do think this is a valid feature request > that could be introduced in the UA processor without breaking backwards > compatibility if you’re interested in filing the ticket. Changing the > internal data structure of the dynamic properties to be ordered _should_ be > possible, but I think currently the API doesn’t request that order so it > would require a code change there, with a default practice being “order as > received". > > > Andy LoPresto > [email protected] > *[email protected] <[email protected]>* > He/Him > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Apr 22, 2020, at 12:04 PM, dan young <[email protected]> wrote: > > Hello, > > I haven't been able to figure out if this is doable with a single > UpdateAttrbute processor, but is it possible to create an attribute that > references a different attribute you're setting in the same UpdateAttribute > processor? ie. > > UpdateAttribute > a = "foo" > b = "bar" > c = ${allAttributes("a", "b"):join(" _")} > > What I've been doing in the past is just have c in a downstream > UpdateAttribute....wonder if there's a better way of doing this, or maybe > in the Advance section of the UpdateAttribute. > > > Regards, > > Dano > > >
