Aurion Security User update - USER_MATCH_VALUE expected
IdB 5.0.4, Aurion Connector v5
The Aurion Security User Import worked perfectly. I am now trying to export changes in the Status value back to Aurion and I get the error "USER_MATCH_VALUE expected" reported as an export error back to the MIM Sync service. There is nothing in the IdB logs (on Verbose setting - I haven't tried Diagnostic).
It sort of sounds like maybe the User_Id value is not being sent to Aurion along with the update - however User_Id is populated in the connector, and it came from the connector import, so is definitely what Aurion has.
Exports were working in the IdB 3 solution. Does v5 do something different? Is there anything that has to be changed in Aurion to support updates?
Answer
Hi Carol,
It's referring to the missing user id, which is the user field for the security user connector. This hasn't changed in v5.0. Try adding a new connector and running the schema provider again to see the correct list of fields.
Thanks.
HI Adam. This is a brand new connector - it was not migrated or anything. I did load the default schema and what came in from the connector was User_Id. Are you say that is wrong and I should rename it?
I just refreshed the schema and it's definitely User_Id that I'm getting back, with no "User" in the list.
Which one did you run? Default Security User schema has these fields:
- User
- OsUserId
- Name
- PersonNumber
- Status
- PasswordExpired
- ExternalMailType
- EmailAddress
- MessageGroupCode
I click "Request Schema" and after several minutes it gives me this:
User_Id
Email_Address
OS_User_Id
Password_Expired_Flag
Person_Number
User_Name
User_Status
I had to do that schema attribute mapping thing but I did not change the names at all. Would it help if I did?
The drop down needs to be changed from Query fields to Default Security User schema.
Another question - if I remove the "Query fields" schema and replace it with the Default schema - will imports stop working?
Yes it is. The reason they have their own schema providers is that the query response names don't necessarily match the API names, so some mapping needs to be done between them (the mapping settings). When first developed the decision was made to go with the API names as "authoritative" and map back to query names, which results in the schema provider having to be different. It does mean that what you describe is an annoyance, but on balance it is better than had it been done the other way around.
Right so what I need to do is use the Default schema and then map to the names being used by the Aurion query?
BTW it could be good to change the way the Request Schema works - it launches straight into getting it from the Query so very easy to miss that there is another option.
Agree, that would make sense. I'm not actually sure what determines the order, but I'll take a look.
Thanks.
It's the order that the schema providers are added to the connector engine. I've made the change and it'll be in the next release.
Just hit exactly the same issue - so I went back to the doco https://unifysolutions.jira.com/wiki/display/IDBAUR50/Connectors to work out what the mapping section of the connector does and I can find no reference to it :(
If I use the schema I get from the query I can import users, if I use the default I cannot. Is there a document somewhere that states (with examples) what needs to go in the mapping table?
Customer support service by UserEcho
Hi Carol,
It's referring to the missing user id, which is the user field for the security user connector. This hasn't changed in v5.0. Try adding a new connector and running the schema provider again to see the correct list of fields.
Thanks.