Continuamos con el artículo que escribimos hace unos días compartiendo con nuestros seguidores y compañeros la experiencia vivida en nuestro primer despliegue en España con la nueva versión Microsoft Dynamics 365 Finance and Operations Enterprise Edition, en adelante D3FO. (Ver la primera parte del artículo).

Aplicaciones NATIVAS (Workflows y Manager Reporter)

Si algo no ha cambiado de una versión a otra es el editor de workflows y el Manager Reporter, siguen siendo las versiones tradicionales, esto quiere decir que el sistema debe instalarnos algún addon en nuestros ordenadores para poder ejecutar estas aplicaciones. Y lo hace cada vez que lo abrimos. Os contamos esto porque si lo intentáis con cualquier navegador que no sea EDGE os llevaréis alguna sorpresa desagradable.

Modern APP

En D3FO tenemos 2 aplicaciones para Windows 10, el POS y el WHS, para instalar ambas aplicaciones hay que configurar las aplicaciones en Azure, conseguir las claves de cliente y de seguridad, etc. Si no tenéis a alguien con conocimiento de Azure se puede volver tedioso.

Implantación SII

La configuración del Suministro Inmediato de Información ha sido bastante complicada, sobre todo por la falta de un step by step claro y conciso con todas las partes que hay que configurar y parametrizar, no solo en la parte funcional sino también en la parte de instalación y configuración. Finalmente tuvimos que contar con el equipo de Microsoft que ha desarrollado el producto junto con el equipo de soporte en España, puesto que para ciertos formularios de configuración no encontrábamos un documento fiable que nos sirviese de guía. Una vez que conseguimos configurar correctamente todo (certificado de seguridad en Azure y datos de configuración), comenzamos con los errores “técnicos”. Principalmente fueron 2 los problemas que tuvimos: errores con los ficheros de configuración de los informes electrónicos, y errores que, después de varias sesiones con el equipo de producto, se ha llegado a la conclusión de que se trata de un error propio de la plataforma PU10, y que debería solucionarse actualizando a la PU11.

En cuanto a los errores con los ficheros de configuración de los GER, lo que nos ocurrió es que, por un lado, no teníamos la posibilidad de importar los xml desde el repositorio de LCS debido a un error que está ahora mismo a la espera de fix, por lo que la única opción era importar los ficheros de forma manual. Y aquí es donde nos encontramos con la segunda parte del error, y es que, al intentar importar dichos ficheros, había ciertos prerrequisitos de versión sin mucho sentido a nuestro juicio, que nos impedían validar estos ficheros, y por lo tanto importarlos. Indicaba que para la versión que teníamos actualmente (última disponible) nos faltaban “prerrequisitos”. Después de bastante investigación, vimos que se trataba de un bug que podríamos solventar, y decidimos modificar ese prerrequisito directamente en los xml indicándole el número de versión que tenía nuestra aplicación, lo que nos permitió proceder con la importación y terminar con la configuración del SII de forma satisfactoria. Actualmente ya somos capaces de enviar ficheros a Hacienda sin ningún tipo de problema.

Integración PowerBI

Power BI se despliega de forma nativa y sencilla en los entornos de producción, pero tanto la configuración de la integración como su despliegue en entornos de test resulta bastante compleja hasta que se realiza por primera vez. Existe mucha documentación al respecto, pero de forma resumida comentaros que en los entornos de test se debe instalar accediendo por terminal server el Power BI desktop, descargar de LCS los modelos y publicarlos directamente contra la cuenta de Power BI, si además queremos que los datos se actualicen tendremos que configurar un gateway en esas máquinas. No es tan complicado como parece, pero tiene sus truquillos. Esta forma de trabajo también es indispensable para desarrollar nuestros propios cuadros de mando.

FLOW, POWERAPP y Common Data Model

A priori está parte debería ser sencilla ya que la integración con Flow es nativa (y usaremos Flow para integrarnos con CRM, CDM, etc.), pero existe una limitación, D3FO no tiene desencadenadores y por lo tanto no existe una opción tan simple como “cuando se cree un cliente haz…”. La solución es usar un temporizador que revise cambios en las entidades cada X tiempo y eso requiere más conocimiento técnico. ¿Por qué necesitaría usarlo? Pensar que D3FO no tiene gestión de alertas… Por suerte la solución llamada Prospect to Cash entre CRM y D3FO usando CDM ya es bastante potente (de momento solo hemos podido probarla en test porque no está liberada pero lo que hemos visto nos ha gustado bastante).

Conjunto de dimensiones por defecto

No se debe editar nunca el conjunto de dimensiones que vienen por defecto con el valor incluido de las cuentas principales. En nuestro caso, utilizamos el conjunto de dimensiones original para incluir el resto de dimensiones analíticas y esto nos generó un problema grave a la hora de salir a Producción que comentaremos más abajo.

Jerarquía de empresas

Si tienes pensado parametrizar una Jerarquía para las empresas, nosotros os recomendamos esperar a configurarla en el entorno Productivo puesto que también nos generó conflictos que en el siguiente punto comentaremos.

Subida a Producción

Como seguro que sabéis, el Partner ya no tiene acceso al entorno Productivo y cualquier tipo de interacción con el mismo se realizará vía LCS subiendo un ticket, o petición, al que, como reloj suizo en el horizonte de 5 horas, Microsoft responderá sobre la actuación o duda reflejada. Cuando decidimos solicitar que el entorno de UAT se restaurase vía backup a PRO, lo lanzamos por la noche para que al día siguiente nos encontrásemos con el entorno listo para operar desde primera hora de la mañana. La realidad no fue esa, ya que en la madrugada recibimos un mensaje con la resolución que reflejaba un conflicto en BBDD y que no era posible restaurar el entorno PRO con nuestros datos. Os podéis imaginar el estado de estrés al no saber la razón real, y mediante otro ticket nos derivaron a otro equipo que nos indicó dónde la BBDD se encontraba corrupta. Pues bien, si revisáis los 2 puntos anteriores, tenedlos presentes porque a nosotros nos generó esta incidencia a la hora de tener listo el entorno de PRO.

También en este tránsito, la pregunta del cliente “¿Dónde está mi entorno?” puede generar cierto clima de inseguridad ya que es un tercero de quien dependes. Aunque a favor de esta nueva forma de trabajo, tenemos que decir que fueron ágiles en las respuestas ante la criticidad del momento en el que nos encontrábamos, y que además este tiempo de subida tiene un beneficio colateral, nos obliga a todos a ser mucho más estrictos en las pruebas que realizamos (sobre todo las que el cliente debe realizar). Imaginar que pasaría si subimos un desarrollo a UAT, el cliente lo prueba sin demasiado detalle y pedimos el paso a PROD, 5 horas más tarde está en PROD y detectamos un error grave, por mucha prisa que nos demos en resolverlo, tenemos una espera de como mínimo 5 horas más hasta que MSFT vuelva a subirlo.

Informe de Reporting Services sin publicar

En este punto, comentar las dificultades que nos han surgido a la hora de desplegar los desarrollos en los entornos tanto de UAT como de Producción. A priori, es todo tan sencillo como exportar el Software Deployable Package desde Visual Studio, subirlo al Asset Library de LCS y aplicarlo en el entorno en cuestión. Del resto, se encarga Microsoft (instalar, compilar, sincronizar, desplegar reports, etc.). Aun así, no todo es tan automático y seguro ya que nos surgió un problema con el despliegue de uno de los informes. Todo iba bien hasta que el cliente intenta sacar una factura de ventas con el informe personalizado que habíamos subido a Producción y nos encontramos con el error de que el report en cuestión no existía. ¿Cómo podía suceder si en UAT estaba publicado? Como sabéis el entorno de Producción en la solución 100% cloud es una caja negra tanto para nosotros como para el cliente, lo único que puedes hacer para solventar estos momentos de crisis, es abrir un ticket de soporte y esperar. Tras 4 ó 5 días en los que la única respuesta que recibimos fue que comprobásemos si el paquete realmente contenía dicho informe (estábamos seguros de ello y en UAT se desplegó) decidimos “tirar por la vía de en medio”, y generar un nuevo paquete (por segunda vez) con el modelo en el que se encontraba el informe, desplegarlo de nuevo en UAT, y solicitar una vez más a Microsoft que lo desplegase en Producción. Una vez finalizado ya pudimos comprobar que esta vez sí, el report había sido implementado correctamente.

Creo que el mensaje es ser creativo, y si el soporte del entorno productivo se bloquea, tratad de generar otra vez el paquete por si hubiera sucedido algún tipo de incidencia, ya que, aunque muchos piensen que el «cloud» es un ente mágico y perfecto, la realidad es que sigue siendo operado y administrado por decisiones humanas.

Cada punto en los 2 artículos ha sido descrito por aquella persona del equipo de AXAZURE que ha sido responsable según su área de expertise y por supuesto recordamos que las opiniones aquí expresadas son solo nuestras en base a la experiencia vivida.

Estamos completamente abiertos a comentar, valorar y entender la casuística de futuros proyectos ERP, en AXAZURE nos gustan los retos y para nosotros arrancar la nueva versión, lo es.