This topic has 2 replies, 2 voices, and was last updated 3 years ago by 
-
Posts
-
We have a android client application that has been registering identities in OpenIDM 5.0 using email address for the first and last name fields of our managed objects. Now we have to fix this to remove the email information from those fields (leaving the other fields alone). I’m looking for suggestions for approaches to fix the data, which currently stands at around 200k affected identities.
Some of the approaches that I’ve been thinking about are:
1. Fix the data in Postgres. I can write a update query that finds the affected records, and updates the managedobjects.fullobject field. I’m concerned, however, about going behind IDM’s back and updating Postgres. Does incrementing the _rev field of the managed object help with any potential issues of this approach?2. Generate cURL commands to patch the affected identities. Very easy, but concerned about performance of updating 200k identities.
3. Custom endpoint – I can write a custom endpoint that takes a list of objectIds and performs openidm.patch commands.
Option #2 and #3 are less desirable because they require synchronous updates one identity at a time. I’d prefer to do some sort of bulk update if possible.
Thoughts on the safest, and quickest ways to perform these updates.
Thanks,
Chris Sanchez
Hi Chris,
regarding option 1: don’t get the fullobject and the properties-table out of sync. And don’t forget about possible policy-settings which OpenIDM would enforce but go unchecked if you change the repository directly.
I’d prefer option 2, but keep in mind that every modification will trigger a sync for all mappings defined from managed/user to their designated target systems. In my environment (>40 mappings) that would really slow down the update process and I would probably disable all syncing, run the curl commands (which will have optimal performance), reenable syncing and trigger reconciliations for all targets.
Regarding 2 and 3 I don’t see a reason not to have several curls run in parallel on different sets on users.That said, the discussion regarding the best way to solve your problem will probably take longer than just running your curl-command. ;-)
Option 4 would be to create a temporary table containing the correct data, add it as a resource and create a mapping to update your managed/user. I really think that would be faster than curl, but the same consideration about disabling syncing while updating managed/user would still apply.
Yours,
Patrick.
You must be logged in to reply to this topic.
