Empty string values in JSON import, are seen as value when disallowing duplicate, causing false errors
Answered
Hi,
We have a few attributes that were created as integers, like the 14 digit PIM Identifier and GTIN. These are not shown as invalid in the UI, but are invalid for business conditions and in JSON exports.
We want to change those to String type, but then we have a new issue, PIM Identifier is generated in Syndigo, so for new items it’s sent empty to Syndigo, in case of JSON imports this is formatted as “” (empty string).
"pimidentifierstring": {
"values": [
{
"value": "",
"locale": "en-GB",
"source": "internal"
}
]
},
The import profiles are setup to disallow duplicate records, both PIM Identifier and GTIN are match sets, if there are multiple records in the JSON import file, with either properties empty, then every record after the first is flagged as a duplicate, and not ingested into Syndigo.
This doesn’t happen when these attributes are integers.
My guess is that during ingestion, the JSON value “” for Integers is processed as an empty/null value, while for String attributes this is processed as an Empty string and not as a Null value.
Import profile used
{
"type": "integrationprofile",
"data": {
"contexts": [
{
"context": {
"app": "RSConnect",
"channel": "AZURE_BLOB_CONTAINER",
"format": "JSON",
"order": "152",
"role": "admin",
"service": "ENTITY_IMPORT",
"source": "internal",
"subtype": "System",
"user": "system"
},
"jsonData": {
"statusEventEnabled": false,
"transform": {
"settings": {
"nullRecordTransformer": "true"
}
},
"integrationType": "System",
"isEnabled": "true",
"publish": {
"isBinaryStreamPersistent": "false",
"channel": [
{
"settings": {
"type": "RSJSON",
"version": "1.1"
},
"type": "rdpConnector"
}
],
"format": {
"settings": {
"additionalSettings": {
"dateTimeFormat": "yyyy-MM-dd'T'HH:mm:ss.SSSZ",
"isDuplicateCheckEnabled": "true",
"encoding": "utf8"
}
},
"type": "RSJSON",
"batchSize": 1,
"version": "1.1"
}
},
"isMergeableWithCustom": true,
"collect": {
"isBinaryStreamPersistent": "true",
"channel": [
{
"settings": {
"folderPath": "Entity/XXXX",
"containerName": "xxxxxxxxxxxxxx",
"useFlatBlobListing": false,
"fileType": "json"
},
"type": "azureBlobContainerConnector"
}
],
"format": {
"settings": {
"additionalSettings": {
"dateTimeFormat": "yyyy-MM-dd",
"encoding": "utf8",
"replaceValues": true
}
},
"type": "RSJSON",
"version": "1.1"
}
}
}
}
]
},
"name": "override_xxxxxxx_import_data_blob_task_base_JSON",
"id": "override_xxxxxxxxxxx_import_data_blob_task_base_JSON"
}
Let me know if you need more details, or clarification.
Kind regards,
Erik
-
Hi Erik,
I understand your point of string being passed as empty and due to duplicate check enabled , its considering as repeated value of empty.
You mentioned that PIM identifier attribute is part of match set with GTIN ,
I have few questions:
Is it in same match set sequence?
Is your GTIN being duplicated , so you added like combined Match set of PIM identifier and GTIN ?
IF GTIN is unique then did you try not passing the below block at all in import , instead of passing it as ""
"pimidentifierstring": {
"values": [
{
"value": "",
"locale": "en-GB",
"source": "internal"
}
]
},Can you please try this once and see if the issue persist ?
0 -
Hi Archana,
Thank you for your response.
GTIN & PIM Identifier are separate match sets, each with only one attribute in there.The JSON, is created by another supplier of our customer, and they preferred to have the JSON in that format, the feed can both contain new and existing products, existing products will have those details filled, causing Syndigo to update the matching record, but new product don't have the PIM Identifier since that's generated in Syndigo, and feed back to the other system, GTIN can sometimes be empty.
We understood from Syndigo support that they have no other solution, than not to include those identifiers in the JSON when empty. I was hopping to still find a fix, we even tried using decimals but that acted the same as Strings and had additional issues.
We've requested the change to the JSON from the other supplier, that should work around the issue.Erik
0 -
Hi Erik,
Got it, So only solution is not to pass the attribute block in JSON during create [ if its empty ].
Thanks for the update.
0
Please sign in to leave a comment.
Comments
3 comments