Esempi di mappature dei tipi di oggetti - Amazon Connect

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Esempi di mappature dei tipi di oggetti

Una mappatura dei tipi di oggetto che genera un profilo

L'esempio seguente mostra i dati che popolano il profilo standard.

Di seguito è riportato l'oggetto in arrivo:

{ "account": 1234, "email": "john@examplecorp.com", "address": { "address1": "Street", "zip": "Zip", "city": "City" }, "firstName": "John", "lastName": "Doe" }

Il codice seguente mostra la mappatura degli oggetti in entrata in un oggetto del profilo standard e l'indicizzazione PersonalEmailAddress, fullName e accountId, che è una chiave univoca.

{ "Fields": { "accountId": { "Source": "_source.account", "Target": "_profile.AccountNumber", "ContentType": "NUMBER" }, "shippingAddress.address1": { "Source": "_source.address.address1", "Target": "_profile.ShippingAddress.Address1" }, "shippingAddress.postalCode": { "Source": "_source.address.zip", "Target": "_profile.ShippingAddress.PostalCode" }, "shippingAddress.city": { "Source": "_source.address.city", "Target": "_profile.ShippingAddress.City" }, "personalEmailAddress": { "Source": "_source.email", "Target": "_profile.PersonalEmailAddress", "ContentType": "EMAIL_ADDRESS" }, "fullName": { "Source": "{{_source.firstName}} {{_source.lastName}}" }, "firstName": { "Source": "_source.firstName", "Target": "_profile.FirstName" }, "lastName": { "Source": "_source.lastName", "Target": "_profile.LastName" } }, "Keys": { "_email": [ { "FieldNames": ["personalEmailAddress"] } ], "_fullName": [ { "FieldNames": ["fullName"] } ], "_account": [ { "StandardIdentifiers": ["PROFILE","UNIQUE"], "FieldNames": ["accountId"] } ] } }

Nota che email e fullname sono indicizzati, ma non vengono utilizzati per cercare il profilo. L'account è la chiave univoca. È necessario specificare l'oggetto. Ogni volta che viene inserito un oggetto con lo stesso ID account, sovrascrive l'oggetto precedente con lo stesso ID account.

Nell'oggetto del profilo standard vengono popolati diversi campi (vedi i campi che sono stati definiti Target).

Una mappatura dei tipi di oggetto che non popola il profilo standard

Questo esempio mostra un caso d'uso più complicato. Acquisisce i dati relativi a un profilo ma non popola necessariamente l'oggetto del profilo standard.

Di seguito è riportato l'oggetto in arrivo:

{ "email": "john@examplecorp.com", "timestamp": "2010-01-01T12:34:56Z", "subject": "Whatever this is about", "body": "Body of ticket" }

Di seguito è riportato un modo per mappare questi dati:

{ "Fields": { "email": { "Source": "_source.email", "ContentType": "EMAIL_ADDRESS" }, "timestamp": { "Source": "_source.timestamp" } }, "Keys": { "_email": [ { "StandardIdentifiers": ["PROFILE","LOOKUP_ONLY"], "FieldNames": ["email"] } ], "ticketEmail": [ { "StandardIdentifiers": ["PROFILE","SECONDARY","NEW_ONLY"], "FieldNames": ["email"] } ], "uniqueTicket": [ { "StandardIdentifiers": ["UNIQUE"], "FieldNames": ["email","timestamp"] } ] } }

Questo esempio importa i dati e, alla prima ricerca, importa l'indirizzo e-mail.

  • Se l'indirizzo e-mail corrisponde a un profilo singolo, viene utilizzato per allegare i dati a quel profilo specifico. L'identificatore univoco del ticket è composto dall'e-mail e dal timestamp poiché non esiste nessun altro identificatore univoco.

  • Se non esiste alcun profilo con l'e-mail specificata, viene creato un nuovo profilo con il campo singolo EmailAddress compilato. L'oggetto importato è allegato a questo nuovo profilo dedotto. Le due chiavi ricercabili che possono trovare il profilo sono _email e uniqueTicket.

  • Se esiste più di un profilo con l'indirizzo e-mail specificato, viene creato un nuovo profilo con il campo singolo EmailAddress compilato e l'oggetto viene allegato a questo nuovo profilo. Questo profilo viene creato con la chiave definita ticketEmail, oltre a _email e uniqueTicket. Tutti i ticket successivi provenienti da quell'e-mail vengono assegnati a questo nuovo profilo dedotto. Il motivo è che la chiave _email si riferisce a tre profili e quindi viene scartata, tuttavia la chiave ticketEmail si riferisce solo a un singolo profilo (quello nuovo dedotto) ed è ancora valida.

  • Nei casi in cui viene creato un nuovo profilo dedotto, il campo EmailAddress viene popolato dal primo oggetto che lo ha creato.