0
Answered

Writeback MOBILE_PHONE not working for an Aurion Person Connector

Adrian Corston 10 months ago in UNIFYBroker/Aurion updated by Matthew Davis (Product Manager) 10 months ago 20

In my UNIFYConnect config the MOBILE_PHONE value isn't being written back to Aurion successfully.

The relevant connector config is:

In the customer's Aurion report the mobile phone field is called 'Contact_Mobile_Phone' so a mapping is necessary.  Import is working correctly, but the field is not updated in Aurion on export.

Here is the rest of the relevant config:

Adapter Transform (to remove underscores from the field name)

Link Mapping

Locker Entity

After a connector Import the Contact_Mobile_Phone field is set to the old value from Aurion as expected.  After a Baseline Sync on the link the value in the connector is changed to '0418 999 999' temporarily, but then reset back to the old value from Aurion after the next connector Import, showing that the value has not been updated in Aurion.

What is causing the writeback to fail and how do I get it to work?

Under review

Hi Adrian,

The schema value for mobile phone will need to be "MobilePhoneNo" in line with the Default Person Schema to allow write-back to occur for that field. 

You can use the mapping to map a report field to a schema field - you should use this to map your Contact_Mobiler_Number to MobilePhoneNo.

See Aurion Person Connector / UNIFYBroker knowledge / UNIFY Solutions for some more information on it.

Thanks Matt.

Based on what I think you want me to do I've changed the config as follows:

This has caused the following error to now happen when I run Baseline Sync on the link:

What is causing that error ("Specified argument was out of the range of valid value. Parameter name: value")?  The MobilePhoneNo field is not being updated in the connector now.

Can you confirm the data steps you ran after changing the schema? (imports/clears)

Connector Import All
Link Baseline Sync

Hi Adrian,

Check the values for those phone number fields. They cannot be any longer than 14 characters, nor can they be null

Correction, they can be null, just not empty or over the length limit

Thanks Beau.  I have added pre-processing to make sure the MobilePhoneNo field is no longer than 14 characters and the error has gone away.

However, I am still seeing the original problem - the export phone number values aren't being saved by Aurion.  When I run a link Baseline Sync there are no errors in the log, and the connector entity updates.  But after the next connector import the value reverts to its old value.

What's the next step to debug this?

Everything with the connector looks fine. I'd say the issue may lie with the Aurion query being used. The field names and query mappings you're using would suggest you're not using the standard user query. Could this query not be configured correctly? Perhaps the mobile phone field being updated isn't the one being used in the query as Contact_Mobile_Phone?

Check the raw output of the query in the Aurion GUI and ensure that the correct value is being returned as Contact_Mobile_Phone. Also make sure that the updated phone number value hasn't been updated in a different field than expected.

The report ("UNIFY_EMPLOYEES") is available in the UNIFY Aurion instance, which I don't have access to as I'm not in the Brisbane office.  Is there someone there who could log on and find out what the source of that report field is?

Hi Beau,

I've just reviewed the report definition with the customer.  The field in the report is:

T000F320_CONTACT_MOBILE_PHONE.T000_WAMI

Is that field corrrect?

Here are the permissions assigned to the UNIFY service account in Aurion:

As you can see, EMP_UPDATE_PERS is Permitted.

So as far as I can tell both the Aurion configuration and the UNIFYBroker configuration are both correct, but the write-back isn't working.  Can you tell me what to check next?

Could provide a standalone program which attempts to update the mobile number on a test user via the API, so we can identify if the problem lies on the Aurion side or the UNIFYBroker side?

Hi Adrian, 

Is the mobile write-back functional in Dev or is it also broken there too? It'd be good to get it resolved there to know how to carry over to the customer environment if it's not working.

Hi Matt, write-back for MobilePhoneNo doesn't work in DEV either.

Write-back for ContactPhoneNo works fine in both DEV and TEST.

Hi Adrian,

T000F320_CONTACT_MOBILE_PHONE.T000_WAMI does not map to MobilePhoneNo (MOBILE_PHONE) on the EMP_UPDATE_PERS API call.

MOBILE_PHONE appears to map to T000F155_MOBILE_PHONE.T000_WAMI 

To update CONTACT_MOBILE_PHONE attribute, the API expects WORK_MOBILE - which is a semi recent addition to the API and not something the release version of the connector supports. I'll got a patch for a previous customer which has support for this field, i'll get that deployed to DEV for you.

You'll need to use the schema field WorkMobilePhoneNo, so you'll want to use the schema mappings to map your report field to this:


Thanks Matt.  Please deploy the patch to the TEST environment as well for this customer.

Hi Adrian,

The patch has been deployed to both Dev and Test

Hi Matt,

I added WorkMobilePhoneNo to the schema, but it doesn't appear in the Query mapping table for me to assign the report field Contact_Mobile_Phone to it.

How can I get it to appear there?

I tried adding WorkMobilePhoneNo via Add Field, Add Row to Schema, and Request Schema (where WorkMobilePhoneNo didn't appear for the Default Person schema).  None of them resulted in it appearing in the Query mapping table.

Would it help if I asked the customer to change the report field names to match the API field names to avoid using mappings altogether?

There's a known issue ( https://unifyvoice.userecho.com/en/communities/6/topics/3579-aurion-schema-mappings-generic-connector ) with the Aurion connector regarding adding field mappings after the fact.

I can add them in the config for you, or you can get the report changed to match the schema field name if that's possible in dev and test.

I have updated the report definition with the customer.

I have confirmed the patch works.