Closed timster83 closed 7 years ago
Hey,
I've assigned @lpbarber to this, I believe he can help.
Thanks!
@lpbarber any update on this? Would love to get some resolution here.
Hello @timster83 ,
The mistake is in the SDK documentation.
The reason for the differences is that a consumer page can send several SDEs per attribute, while in authenticatedData it is always a single object.
As for your question, I would suggest you to use the same handler with a simple array check, something like:
var consumerDetails;
// information is fetched from either SDE for auth data
if(Array.isArray(consumerDetails.newValue)) {
consumerDetails.newValue.forEach(function(data) {
_consumerDetailsHandler(data);
});
} else {
_consumerDetailsHandler(consumerDetails.newValue);
}
We will fix our documentation on the next version - thanks for bringing it up!
Best regards, Meir.
Thanks @meirotstein.
With specific reference to the customerDetails and personalInfo SDEs, our understanding is that these only hold one value per attribute; i.e. when the page sends a new attribute, it overwrites the existing one.
We've certainly observed that updating any of the unauthenticated customerDetails or personalInfo attributes causes our eventlistener to act upon the data's new value, with the old value no longer being accessible / exposed via the SDK.
(Appreciate that the situation is different for lead generation / viewed products where the SDEs hold an array of items).
We're using the code below in our callback (this seems to work OK).
var updateCallback = function(data) {
switch(data.key) {
case "SDE.customerDetails":
Process_customerInfo(data.newValue[0]);
break;
case "authenticatedData.customerDetails":
Process_customerInfo(data.newValue);
break;
case "SDE.personalInfo":
Process_personalInfo(data.newValue[0]);
break;
case "authenticatedData.personalInfo":
Process_personalInfo(data.newValue);
break;
default:
}
}
@timster83
I reexamine our code and you are right - we always send a single object with the latest SDE values.
However we do save the data in an array due to some historic reasons - unfortunately this cannot be change due to backward compatibility.
Anyhow, according to your code - it seems that you handled it wisely :)
Best Regards, Meir.
Closing this issue for now, feel free to reopen if more work is needed around this!
The public model for engagement attributes exposed via the Agent Workspace Widget SDK follows below (as detailed in the documentation).
SDE: { customerDetails: [], personalInfo: [], marketingSource: [], leadGeneration: [], transaction: [], viewedProducts: [], shoppingCart: [], serviceActivity: [], error: [] }, authenticatedData: { customerDetails: [], personalInfo: [], }
However, when implemented, the structure of the SDEs in the authenticatedData. namespace is different than the structure of the SDEs in the SDE. namespace. This means that it is necessary to create different handlers for each namespace.
The structure we have observed is as follows.
SDE.customerDetails: data.newValue[0].[attribute-name] authenticatedData.customerDetails: data.newValue.[attribute-name]
SDE.personalInfo: data.newValue[0].[attribute-name] authenticatedData.personalInfo: data.newValue.[attribute-name]
Screenshot of SDE.customerDetails
Screenshot of authenticatedData.customerDetails
Screenshot of SDE.personalInfo
Screenshot of authenticatedData.personalInfo