Soluciones en Common Data Services de 0 a 100

Soluciones en Common Data Services de 0 a 100

Lo del tema de las soluciones de CDS ha sido y será siempre un dolor de muelas para quienes nos dedicamos a esto y lo es porque tendemos a ser poco lógicos o disciplinados cuando desarrollamos en nuestras soluciones. En este artículo no voy a describir las ventajas de tener un buen ALM en tu organización (tal vez más adelante). Será un artículo básico de manejo de soluciones para poder migrar nuestros desarrollos/personalizaciones de un entorno a otro del CDS. Para los más avanzados os dejo este enlace para que podáis leer un poco más de ALM.

Y bien, ¿qué son las soluciones? Pues ni más ni menos que los conjuntos de componentes que forman parte o que creamos dentro de un entorno de CDS. Este conjunto de componentes finalmente lo exportaremos en un .zip y podemos importarlo en un entorno de destino.. visto así suena fácil, pero como veremos en los siguientes apartados, tenemos el problema de las dependencias en las soluciones.

Créate un editor

Cuando creamos una solución en CDS vemos que ya existen algunos editores dentro del entorno (seguramente los de Microsoft). Yo te recomiendo que te crees un editor personalizado. En el editor personalizado podemos definir un prefijo. Si os habéis fijado, cada campo que creamos en el CDS tiene un nombre interno, y este nombre interno siempre tiene un prefijo (excepto entidades del common data model). El prefijo que definamos aquí aparecerá en el nombre interno de componentes creados en soluciones con este editor, de esta manera podemos identificar si el componente lo hemos creado nosotros.

Dependencias en soluciones

El problema la mayoría de las veces no son las soluciones, sino que suelen ser los entornos y la dependencia con estos. Os pongo un ejemplo: Si tenemos un campo en un formulario existente en un entorno de desarrollo e intentamos desplegar el formulario en otro entorno, nos dará error porque en el entorno de destino no existe el campo. Para solucionar este error debemos incluir el campo dentro de nuestra solución y se solucionaría. Básicamente tenemos que asegurarnos que componentes dependientes existan en el entorno de destino. Podemos ver las dependencias de cada elemento seleccionando el elemento nos aparecerá el botón de mostrar dependencias.

De todos modos no os preocupéis porque si os faltan componentes ya se encargará el entorno de informaros. Suele ser de una manera bastante lógica pero algunas veces…

¿Qué es eso de administrado y no administrado y por qué no puedo editar algunos componentes?

Bueno, abrimos el punto fuerte de esta entrada: las soluciones administradas. Si habéis indagado un poco en el CDS habéis observado que ciertas soluciones aparecen con un candado como muestro aquí:

Estas soluciones marcadas con el candado cerrado significa que la solución instalada es administrada y por lo tanto implicará lo siguiente:

  • La solución NO puede ser exportada
  • Los componentes de la solución NO pueden modificarse
  • Cuando desinstale la solución los componentes que contiene se borrarán del sistema (al no ser que tenga dependencias, claro. En ese caso no podrás desinstalar!)

Si prestáis atención a la anterior imagen, en el primer elemento el candado está abierto. Eso significa que esa solución es no administrada y significará que los componentes que modifique ahí se modificarán también en la solución predeterminada, que será la solución que contiene todos los componentes existentes en el entorno. Para nada recomiendo que desarrolléis en la solución predeterminada ya que, seguramente no os deje exportarla ni migrar esas personalizaciones a otro entorno.

Cuando exportamos la solución, tenemos la opción de exportarla tanto administrada como no administrada. Depende mucho de cómo decidas trabajar ya que, si decides trabajar con soluciones administradas deberás tener mucho «respeto» a los entornos administrados ya que, modificar los componentes en este entorno puede traer graves consecuencias. Esto es debido a las capas de las soluciones que tenemos en el CDS.

Si analizamos esta imagen vemos que abajo del todo tenemos la solución predeterminada, después la capa administrada de nuestro entorno, por encima las personalizaciones o soluciones no administradas y finalmente el comportamiento del usuario. ¿Qué ocurre? Si nosotros desplegamos en un entorno una solución administrada y posteriormente modificamos manualmente un componente (o de manera no administrada) el comportamiento de la aplicación será el del componente no administrado y, creedme, que esto da bastantes problemas. Lo bueno de este método de trabajo es que si hacemos un despliegue y falla, esto nos permitirá hacer un rollback de nuestros cambios porque los componentes se eliminarán.

Por supuesto al final decidid vuestro método de trabajo pero la recomendación de Microsoft es utilizar soluciones administradas. Si os acogéis a ese método de trabajo poco a poco os iréis adaptando y puliendo esos errores. Espero que dentro de poco me anime a un artículo de ALM, donde espero enseñaros a solucionar problemas comunes con soluciones administradas.

Leave a Reply:

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *