LivePersonInc / developer-center

LivePerson’s Developer Center and Community
https://developers.liveperson.com/
31 stars 199 forks source link

Agent Workspace Widget SDK: Data Structure of Authenticated SDEs different from unauthenticated SDEs #7

Closed timster83 closed 7 years ago

timster83 commented 7 years ago

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 sde customerdetails

Screenshot of authenticatedData.customerDetails authenticateddata customerdetails

Screenshot of SDE.personalInfo sde personalinfo

Screenshot of authenticatedData.personalInfo authenticateddata personalinfo

EdenKupe commented 7 years ago

Hey,

I've assigned @lpbarber to this, I believe he can help.

Thanks!

EdenKupe commented 7 years ago

@lpbarber any update on this? Would love to get some resolution here.

meirotstein commented 7 years ago

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.

timster83 commented 7 years ago

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:
    }

} 
meirotstein commented 7 years ago

@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.

EdenKupe commented 7 years ago

Closing this issue for now, feel free to reopen if more work is needed around this!