IIF() function in Data Prep mapping UI Calculated Field not populating variables as expected.
- January 13, 2024
- 3 svar
- 3760 visningar
Hello,
My XDM schema has a "userId" field that should receive one of three possible ids in the source data payload, based on which source id is available, using the Calculated Fields IIF() function. So if "sourceId1" is available, it should always be used - if "sourceId1" is not available, "sourceId2" should be used, and if both those are not available, "sourceId3" should be used. We are sending data to AEP via the Edge Network Server API and mapping source properties to our schema via the data prep mapping UI.
Source data is structured like this:
{
"xdm": {
"_myorg":
{
"sourceId1": 'aaa',
"sourceId2": 'bbb',
"sourceId3": 'ccc'
}
}
}
The IIF() statement I am trying to use is like this, mapping the result to "userId".
iif(${xdm\._myorg\.sourceId1} == '' || !${xdm\._myorg\.sourceId1} , (iif(${xdm\._myorg\.sourceId2} == '' || !${xdm\._myorg\.sourceId2} , ${xdm\._myorg\.sourceId3}, ${xdm\._myorg\.sourceId2})), ${xdm\._myorg\.sourceId1})
Even when the source properties are definitely in the source payload, data ingestion fails with the following error:
DCVS-1106-400 | 30 | The message cannot be validated because a required property is missing: #/_myorg/mySchema: required key [userId] not found. |
I get the same error even when using a simpler statement that removes the nesting:
iif(${xdm\._myorg\.sourceId1} == '' || !${xdm\._myorg\.sourceId1} ,${xdm\._myorg\.sourceId2}, ${xdm\._myorg\.sourceId1})
I also tried removing the ${} notation and writing out field names like "xdm._myorg.sourceId1" but that didn't work either.
A regular, non-calculated field mapping of "xdm._myorg.sourceId1" to the destination "userId" works just fine, so it doesn't seem to be an issue with the actual data values. All other regular mappings work as well.
Would anyone have some suggestions as to why the above logic causes the mapping to fail? We'd really like to have this conditional logic work on the AEP-side instead of having to update client code to figure out "userId" for us.
Thanks.