Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Ejemplos de asignaciones de tipos de objetos en los perfiles de clientes de Amazon Connect
Una asignación de tipo de objeto que genera un perfil
En el siguiente ejemplo se muestran los datos que rellena el perfil estándar.
A continuación, se muestra el objeto entrante:
{ "account": 1234, "email": "john@examplecorp.com", "address": { "address1": "Street", "zip": "Zip", "city": "City" }, "firstName": "John", "lastName": "Doe" }
En el siguiente código se muestra que el objeto entrante se asigna a un objeto de perfil estándar e indexa PersonalEmailAddress
, fullName
y accountId
, que es una clave única.
{ "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"] } ] } }
Tenga en cuenta que se indexan email
y fullname
, pero no se utilizan para buscar el perfil. La cuenta es la clave única. Es necesario especificar el objeto. Cada vez que se realiza la ingesta de un objeto con el mismo ID de cuenta, se sobrescribe el objeto anterior con el mismo ID de cuenta.
En el objeto de perfil estándar se rellenan varios campos (consulte los campos que tienen Target
definido).
Una asignación de tipo de objeto que no rellena el perfil estándar
En este ejemplo se muestra un caso de uso más complicado. Realiza la ingesta de datos relacionados con un perfil, pero no rellena necesariamente el objeto de perfil estándar.
A continuación, se muestra el objeto entrante:
{ "email": "john@examplecorp.com", "timestamp": "2010-01-01T12:34:56Z", "subject": "Whatever this is about", "body": "Body of ticket" }
A continuación, se presenta una forma de asignar estos datos:
{ "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"] } ] } }
En este ejemplo se realiza la ingesta de los datos y, en la primera búsqueda, se efectúa la ingesta de la dirección de correo electrónico.
-
Si la dirección de correo electrónico coincide con un único perfil, se utiliza para asociar los datos a ese perfil específico. El identificador único del ticket se compone del correo electrónico y la marca temporal, ya que no existe otro identificador único.
-
Si no existe ningún perfil con el correo electrónico especificado, se creará uno nuevo con el único campo de
EmailAddress
rellenado. El objeto de ingesta se asocia a este nuevo perfil inferido. Las dos claves de búsqueda que pueden encontrar el perfil son_email
yuniqueTicket
. -
Si existen varios perfiles con la dirección de correo electrónico especificada, se crea un nuevo perfil con el único campo de
EmailAddress
rellenado y el objeto se asocia a este nuevo perfil. Este perfil se crea con la claveticketEmail
definida, además de_email
yuniqueTicket
. Cualquier ticket posterior de ese correo electrónico se asigna a este nuevo perfil inferido. La razón es que la clave_email
se refiere a tres perfiles y, por tanto, se descarta; no obstante, la claveticketEmail
solo se refiere a un único perfil (el nuevo inferido) y sigue siendo válida. -
En los casos en los que se crea un nuevo perfil inferido, el campo
EmailAddress
se rellena a partir del primer objeto que lo creó.