jueves, 12 de noviembre de 2009

Atención con los CustomerAddress utilizando DynamicEntity y FilteredViews

Lo ideal al desarrollar con aplicaciones para CRM, es utilizar las famosas "DynamicEntity".
De esta forma podemos realizar cualquier tipo de accion (crear, actualizar, etc.) con cualquier tipo de entidad.
Para formatear correctamente los valores, podemos acceder primero a los MetaDatos de los atributos de la entidad, para saber de que tipo es el registro, y asi crear dinamicamente los atributos de la entidad "Dinámica".
El problema surge con la entidad "CustomerAddress" en el atributo "objecttypecode". Este atributo es obligatorio y debe ser rellenado siempre para crear un registro de dirección. Al recoger el tipo del atributo, nos dice el CRM que es de tipo "Picklist", cuando en realidad es de tipo "EntityReference". Si intentamos crear una dirección pasando ese atributo como de tipo "Picklist", el CRM da un error y no nos lo permite.
Para solucionar esto hay que crear una propiedad de tipo "EntityNameReferenceProperty".
Para recoger el tipo del atributo hay que hacer:

RetrieveAttributeRequest atrreq = new RetrieveAttributeRequest();
atrreq.EntityLogicalName = "customeraddress";
atrreq.LogicalName = "objecttypecode";
RetrieveAttributeResponse atrresp = (RetrieveAttributeResponse)meta.Execute(atrreq);

Y luego verificar el valor de "atrresp.AttributeMetadata.AttributeType".

Nota adicional sobre la FilteredView: Si hacemos una consulta SQL en la vista "FilteredCustomerAddress", el atributo "parentid" que es la referencia a la Cuenta o Contacto relacionado con la dirección, no tiene el campo "parentidname" que deberia tener por ser un atributo de tipo "Customer".

Conclusión: mucho cuidado al trabajar con "CustomerAddress", que tiene cosillas que no son del todo "Dinámicas" como en el resto de entidades, y podemos encontrarnos cosas raras.

un saludo

No hay comentarios:

Publicar un comentario