[midPoint] multivalue attribute updating

[Samuel Harmon]

We decided the JSON path is probably the right way to go(it should fix
the problem, and is more readable and extendable in the future). We've
now added JSON-ified versions of our address attributes to our DB view
and got them set up inbound. That seems to be working ok, but I'm now
running into problems getting the outbound provisioning based on these
to work.

my postalCode expression is here:
https://gist.github.com/sdh7/8ac071d5c169554d1315c6cc60e76d58

and with the cwruEduPersonOffCampusOfficeAddress JSON set to empty
(i.e. {"line1": "","line2": "","locality": "","state":
"","postalCode": ""} and cwruEduPersonLocalAddress JSON set to
something expected {"line1":"an address","line2":"some
more","locality":"Cleveland","state":"OH","postalCode","44106"}

I get a "Text must not be null or empty in expression in mapping in
outbound mapping for attribute" error- I think I'm doing the null-safe
operator right, but I suppose I must not be...

On Tue, Nov 30, 2021 at 3:11 PM Ethan Kromhout via midPoint
<midpoint at lists.evolveum.com> wrote:
>
> Hi Sam,
>
> Have you tried or considered using a JSON string rather than delimited
> approach? I've used that for cases where I need one attribute on a
> resource to bring in multiple name value pairs.
>
> So you end up with something like {line1=line1_value,line2=line2_value
> ... } Then I use a short block of Groovy to parse out what I need in the
> resource configuration. I can pass on an example of that Groovy if it
> would be useful.
>
> Not sure if I'm on the right track, and I haven't run into exactly your
> issue, but thought I'd pass on the idea.
>
> Ethan
>
>
> On 11/30/21 14:06, Samuel Harmon via midPoint wrote:
>
> > We're pulling in address information from a database (using a
> > ScriptedSQL resource) as colon separated strings (i.e.
> > line1;line2;city;state;postalCode)- this is then split into a
> > multivalue attribute in midPoint which is then provisioned out to
> > LDAP/AD attributes using some complicated rules about address
> > precedence and suppression, and for most uses this is working
> > properly.
> >
> > We've run into an issue when the address field in the database
> > changes. Right now, when a new address comes in, its split-out
> > components just get appended to the multivalue attribute after the old
> > values, so the old address information keeps getting provisioned out
> > and the new is ignored.
> >
> > I tried setting the predefined "all" set option on the attribute in
> > the database resource to try to fix this. When I attempted to
> > reconcile an affected user, it then removed the old values, but ended
> > up scrambling the order of the updated values, which causes all of the
> > downstream provisioning to have incorrect values (city going into
> > postalCode, etc.).
> >
> > Has anyone run into issues like this before? Any thoughts on how to
> > maintain the order of attribute multivalues when updating them?
> >
> > Sam Harmon
> > Case Western Reserve University
> > _______________________________________________
> > midPoint mailing list
> > midPoint at lists.evolveum.com
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.evolveum.com%2Fmailman%2Flistinfo%2Fmidpoint&data=04%7C01%7C%7C5ea1ba0f2cfc44237c4608d9b43484e4%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637738959935820990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ahhb%2B19aGgPVZ6KCxq86ZvU0MvXv%2B%2FIz1XCCgu%2Bva6g%3D&reserved=0
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint