Debe ser imperativo intentar cumplir con las buenas prácticas de cada lenguaje, framework o metodología. No sólo porque ayudan a coordinar el trabajo en equipo aplicando mismas rutinas sino porque seguramente hayan sido diseñadas tras la experiencia de otras personas.
Dynamics 365 tiene las suyas propias. Es bueno siempre tenerlas en cuenta. Hoy reflexionaré sobre algunas que a veces no resultan tan evidentes a nivel de metadata.
Evitar el publicador por defecto
Nunca, nunca, nunca, pero que nunca, emplear el publicador por defecto. En otras palabras: ningún campo, relación, webresource, etc. de un entorno debe llevar el prefijo “new_”. Por varias razones:
- Demuestra desconocimiento de la plataforma. Ergo, poca profesionalidad.
- Dan a entender la forma de trabajar, posiblemente caótica.
- No ayuda a la trazabilidad de cambios. Todo forma parte del “core”.
Emplea un prefijo identificable y corto
El nombre publicador puede ser algo como “Construcciones Benito IT”. El prefijo ha de ser mínimo de 2 caracteres, máximo 4, puede contener números pero ha de empezar con una letra. ¡Ah! Y, por supuesto, no sea “mscrm”.
Ahora bien, ¿cómo definirlo? Lo recomendable es que sea lo más corto posibel (2-3 letras), claramente identificable, simplifcado tipo acrónimo y, a ser posible, amigable.
Evita los prefijos demasiado simples (“cons_”), cortos (“a_”) o raros (“wxwf_”). Algo más simpático como “cbit_” o “cben_” son más intuitivos.
Nunca cambiar el option value prefix
Dynamics 365 asigna un valor por defecto al publicador que posteriormente condicionará valores de picklists (v.g. 11.841). La recomendación es siempre utilizar el que se asigne. Nunca cambiarlo. Este valor sirve de prefijo a los option set y podría provocar conflicto si se cambia al instalarse en un entorno soluciones de distintos ISV.
No obstante, es posible que surga la necesidad por una integración o necesidad de negocio de asociar a valores de un picklist personalizado con nuestro publicador otros fijos (v.g. los típicos 0, 1, 2…). Ante esa situación, se ha de valorar el impacto de aplicar dicho cambio. Sobre todo a futuro.
Campos lookups acaban en id
Para reconocer a nivel de esquema de qué tipo de campo estamos hablando, procurad que los lookups acaben en id. Tal como en el estándar (customerid, p.e.). Aparte de para la identificación a ese nivel, en algunas circunstancias ayuda a que los desarrollos sean más dinámicos. Suele pasar cuando todos los lookups tienen la suerte de ser la combinación de “[prefijo] [logical name] [id]”. Por ejemplo, teniendo la entidad Casa (“cbit_casa”), la vinculamos al Contacto mediante el lookup Casa (“cbit_casaid”). Mucho más intuitivo y manejable.
Campos boolean comienzan por un verbo
Lo mismo para los booleanos, es preferible que empiecen con un verbo formulando una pregunta yes/no. Por ejemplo, crear un campo Tiene Casa (“cbit_hashouse”) o Es inquilino (“cbit_istenant”). Esto ayuda a ser claros a bajo nivel, pudiendo cambiar el display name si es necesario. En este caso, cambiando Es Inquilino a simplemente Inquilino.
Eliminar prefijos en las relaciones
Toda relación personalizada contiene el prefijo invariable del publicador con el que se construye. No sólo eso, si estamos relacionando entidades también personalizadas, automáticamente se añadirán. Ejemplo:
Entidad A: Casa (cbit_casa) Entidad B: Instalación (cbit_instalacion) Relación: Instalaciones (cbit_cbit_casa_cbit_instalacion_cbit_casaid)
¿No resulta difícil de leer? Por tanto, en favor de la legibilidad y simplificar la extensión (las relaciones tienen un límite de caracteres) se recomienda eliminar los prefijos innecesarios. Para este caso, podría simplificarse así:
Relación: Instalaciones (cbit_casa_instalacion_casaid)
Esta relación es mucho más legible pues de un sencillo vistazo se identifica todo: se personalizada (por el prefijo), marca el orden de las relaciones implicadas (Casa e Instalación) y se refiere a 1:N (pues casaid es el lookup alojado en la entidad Instalación).
Estructura webresources con carpetas
Los webresources es uno de los elementos más fáciles de desorganizar: algunos proyectos no los requieren, en otros son innumerables, existen distintos criterios para ordenarlos, etc. Lo principal es identificar que todos tienen un display name y name, siendo este último fijo y no modificable. Ahí está clave.
De tal forma, lo recomendable es organizar los mismos como en un sistema de archivos se tratara y especificando las carpetas por su tiempo. Además, especificar la extensión del tipo de archivo en el nombre así como las dimensiones si se tratan de tipo png o jpeg. Algo como sigue:
cbti_/scripts/contact.js cbit_/scripts/account.js cbit_/scripts/instalaciones.js cbit_/images/cbit_casa_16x16.png cbit_/images/cbit_casa_32x32.png cbit_/images/cbit_casa.svg cbit_/html/instalaciones.html cbit_/css/instalaciones.css
Esto permitirá que queden ordenados automáticamente en los listados de webresources, sean más fácilmente accesibles vía direcciones relativas e identifiquemos a nivel de esquema el contenido.
Tab, secciones y grids en formularios
Un formulario consta de elementos que pueden manipularse vía JavaScript como son tabs, sections y subgrids -aparte de los fields-. No obstante, su forma de nominar varía de una persona a otra.
La recomendación en este caso es seguir siempre el mismo patrón y algunas observaciones:
- El patrón sería “[tipo de elemento]_[nombre]”. Ejemplos: tab_informacion, tab_inmuebles, seccion_residencia, subgrid_instalaciones.
- Si el nombre son varias palabras, usar guiones bajos. Ejemplo: seccion_datos_personales.
- Si hay elementos con nombres duplicados, ampliar con el matiz. Es raro pero puede suceder, por ejemplo, con secciones prácticamente iguales pero construidas separadas y que se muestran en base a un valor. Ejemplos: seccion_datos_personales_antiguos, seccion_datos_personales_nuevos.
Prefijo ampliado en campos relacionados
En ocasiones, una entidad contiene varios campos asociados entre sí que no llegan a convertirse en otra entidad o son necesarios mostarlo juntos por necesidades de interfaz o por otras razones. Es el caso del estándar con los campos address1_ y sus relacionados: hacen mención de la dirección principal -pese a tener su registro dirección asociado-.
La práctica es mantener esa nomenclatura para campos personalizados que funcionalmente vayan a estar bastante relacionados y queremos identificarlos mejor. No siempre es evidente decidir este sistema cuando se presenta la oportunidad pero merece reflexionar si para cada caso planteado aplica o no.
Pongamos el siguiente ejemplo. En una entidad llamada coche tenemos que tener datos rápidos sobre la ITV que ha pasado el mismo. Bien podríamos aplicar lo siguiente:
Fecha Última ITV (cbit_itv_ultimafecha) Último Centro ITV (cbit_itv_ultimocentro) Resultado ITV (cbit_itv_resultado)
Picklist globales vs específicos
Cuando aparecieron los picklist globales fue una bendición: por fin distintas entidades podían compartir mismos valores comunes. Ahora bien, ¿todos los picklist han de ser globales? Siempre merece una revisión pues al final se abusa de ello. La forma de resolverlo es sencillo, preguntándose si la naturaleza de esa información es algo extrapolable a más entidades tanto existentes como futuras. Y no, el sexo del contacto (gendercode) no es global 🙂
Espero que estas recomendaciones hayan sido de interés y, sobre todo, prácticas. Por supuesto, si discrepas de alguna o quieres aportar con alguna visión nueva, no dudes en comentar. Seguiremos hablando de buenas prácticas.
Power Platform, Dynamics 365 & Beyond! 