- UNIFYBroker Forum
- UNIFYBroker/Aurion
-
Questions
Aurion security user writeback fails for user ID field values with common prefix
At my customer site their Aurion instance is configured with security user "UserID" field values which are populated from the user's AD sAMAccountName (username) field. Their usernames have values like "jsmi" (for John Smith) and "jsmi1" (for Jane Smith).
When writing data back for a user like "jsmi" the following error is logged by UNIFYBroker and the update isn't actioned in Aurion:
20230725,04:16:00,UNIFYBroker,EntitySaver,Error,The entity jsmi (3a657f98-06df-47e0-b0d8-bfd0c19b250b) for the adapter Aurion Security User (c5460bd3-0167-4290-a2a0-180f8632a474) failed to update for the following reasons: Aurion API error -1: Cannot identify an unique Aurion User from User Match Value,Normal
It appears the issue here is that the Aurion API is unable to identify a single unique security user to update, when there is another user whose UserID starts with the same value (i.e., jsmi1).
Is there some other way to configure UNIFYBroker so that it can successfully update my customer's Aurion security user data?
Answer
Hi Adrian,
I'm not sure how the Aurion SEC_USER_UPDATE API call is handled under the covers in terms of finding a match for the value. The UNIFYBroker Aurion connector just exports the connector User schema field into the USER_MATCH_VALUE API field on the outgoing call. We don't do any data manipulation or changes on the outgoing call - simply enforce the field doesn't exceed the 255 character limit dictated by the API and then send it on the outgoing call.
The first I heard of the possibility that the Aurion API was doing a 'contains' rather than an 'equals' comparison was on a recent UNIFYConnect customer you were working on (back in late Feb this year) - you mentioned that you were working directly with Aurion to understand the problem. Were you able to gain any information from them at that point?
I'm not sure there's anything that can really be done in the configuration or even as a product patch, as the issue seems like an Aurion issue more than anything. I'm not sure if there's any Aurion logs or information that can be used to try and confirm what the API is actually doing?
The only thing I can think of (which is an extremely ugly workaround and I'd imagine a last resort) would be to append a constant value at the end of the UserId field. So rather than "jsmi" it might be "jsmi-CONSTANT". That way when "jsmi1" exists in Aurion, it would look like "jsmi1-CONSTANT" which would mean a 'contains' operation on the Aurion side wouldn't see it as a duplicate. I'm not sure of the flow-on impacts (if any) this would have in the Aurion environment, as I'm not clear on what that field is used for internally.
I've now confirmed that the behaviour I reported above isn't actually happening - I misinterpreted what I was seeing. The true root cause of the error is a link mapping passing a changed UserID value to the Aurion connector, which meant that it was passing a UserMatch value that didn't exist to the API.
Customer support service by UserEcho
I've now confirmed that the behaviour I reported above isn't actually happening - I misinterpreted what I was seeing. The true root cause of the error is a link mapping passing a changed UserID value to the Aurion connector, which meant that it was passing a UserMatch value that didn't exist to the API.