- UNIFYBroker Forum
- UNIFYBroker/Aurion
-
Questions
UNIFYConnect writing back Aurion data to fields that it's not configured to export to
Recently my customer refreshed their TEST HR SOT (Aurion) from PROD. I ran an import to pick up the updated data, but didn't notice that it failed (due to a duplicate value for a key field in the refreshed data). Then I cleared locker data and reloaded it.
Then I ran a baseline sync to write back two fields to the HR SOT. It appears that at this time data on all fields (and not just the write-back fields) of entities in the HR SOT was reverted to pre-refresh values.
Is it likely that when I ran the baseline sync UNIFYBroker/Plus applied the mappings from the outbound link on top of the pre-existing out-of-date connector data, and then overwrote all that old field data back to Aurion, even for fields that are not configured to be written back?
Answer
Hi Adrian,
The Aurion API only supports updating specific fields on the API, separate to the queries being read. Currently, the UNIFY Aurion connector maps all suitable* connector entity fields back to the API call.
* A suitable connector entity field is one where the field schema name matches the name provided by the default schema provider, in line with the appropriate connector documentation (such as Aurion Person Connector / UNIFYBroker knowledge / UNIFY Solutions )
If the appropriate schema field can't be found, then the value isn't set on the outgoing API call. According to the Aurion API documentation, this field would be ignored.
In this case, the baseline sync would have triggered the export operation on the connector for entities, which would have taken the reverse-transformed adapter entity (pre-refresh, as the import failed) and exported any fields that the connector was able to map - which is likely why those values got reverted.
I suspect that if you were to have different connector schema field names for any fields you're not wanting to have exported, and make use of the Query Mappings connector configuration, then only the expected fields would be updated.
We do have an item on the backlog to re-work the Aurion connector, having the connector schema be driven by the query with explicit configuration back to the API operations (rather than the inverse, as it stands currently).
We do also have an item to improve the Baseline Sync to avoid exporting entities when changes haven't been made, but we're working through the implications of that on true-up support (and potentially wouldn't have helped in this scenario if the values you were wanting to export were different already).
Customer support service by UserEcho
Hi Adrian,
The Aurion API only supports updating specific fields on the API, separate to the queries being read. Currently, the UNIFY Aurion connector maps all suitable* connector entity fields back to the API call.
* A suitable connector entity field is one where the field schema name matches the name provided by the default schema provider, in line with the appropriate connector documentation (such as Aurion Person Connector / UNIFYBroker knowledge / UNIFY Solutions )
If the appropriate schema field can't be found, then the value isn't set on the outgoing API call. According to the Aurion API documentation, this field would be ignored.
In this case, the baseline sync would have triggered the export operation on the connector for entities, which would have taken the reverse-transformed adapter entity (pre-refresh, as the import failed) and exported any fields that the connector was able to map - which is likely why those values got reverted.
I suspect that if you were to have different connector schema field names for any fields you're not wanting to have exported, and make use of the Query Mappings connector configuration, then only the expected fields would be updated.
We do have an item on the backlog to re-work the Aurion connector, having the connector schema be driven by the query with explicit configuration back to the API operations (rather than the inverse, as it stands currently).
We do also have an item to improve the Baseline Sync to avoid exporting entities when changes haven't been made, but we're working through the implications of that on true-up support (and potentially wouldn't have helped in this scenario if the values you were wanting to export were different already).