Desplegar manualmente los paquetes de Retail para Microsoft Dynamics for Finance and Operations

Primer post sobre Microsoft Dynamics 365 for Finance and Operations Retail! Espero que lleguen más.

Como sabréis, uno de los contratiempos del refresco de datos desde producción en LCS es que hay algunos datos que no se copian. Esto es una medida de seguridad para evitar, entre otros, que no se manden correos o se ejecuten los lotes por accidente después de restaurar la DB.

Recordad que es una buena idea tener un script/query de SQL que cambie todos los endpoints, contraseñas, activar usuarios, etc. que se pueda ejecutar después del refresco de datos, igual que teníamos en AX2009/2012. Un F5 en SSMS y el entorno estará listo para usar y tendremos la DB lista para exportar a las máquinas de desarrollo.

Otra de las cosas que no se copian después del restore son los archivos de las cuentas de almacenamiento de Azure: ficheros XLSX del ER, archivos de la DocuValue y los instaladores self-service de Retail.

Paquetes de Retail

Los paquetes de Retail son los ejecutables que se usan para instalar el MPOS en el… bueno, en el terminal de venta (POS). Estos archivos están guardados en una cuenta de almacenamiento de Azure blob storage que es específico de cada entorno, así que cuando se refresca la DB no están los paquetes de autoservicio en el entorno de destino:

La solución oficial de Microsoft es aplicar un paquete binario que recreará los archivos EXE en la cuenta de almacenamiento de la máquina virtual donde se ejecute el paquete desplegable.Y como sabemos ya todos esto requiere de un tiempo, y aunque se puede ejecutar fuera de horario también lo podemos arreglar en menos de 10 minutos.

El workaround

Ahhh el «workaround»… una palabra tan bonita y que tiene tantos significados… Truquillo, ñapa, arreglo… Esta vez encima tiene una restricción: sólo va a funcionar en VMs de desarrollo y Tier 2+ normales, no se puede hacer en los entornos de tipo self-service porque no tenemos acceso la máquina del AOS.

Lo que tenemos que hacer es entrar a una de las máquinas del AOS por RDP e ir al disco de servicio (normalmente la K en desarrollo y G en los Tier 2+). Debería haber una carpeta llamada DeployablePackages si has aplicado alguno, sino hay que seguir con el método oficial. Si no existe la carpeta seguramente funcione también usando los archivos que hay en la unidad de instalación, pero no lo he probado.

Ordenamos los archivos por fecha de modificación (nuevos primero) y dentro del primero debería haber otra carpeta llamada RetailSelfService:

Y dentro de esa carpeta verás 3 carpetas más, Packages, Scripts y ServiceModel. Dentro de la carpeta Packages están los archivos EXE y en el Scripts están los scripts (un aplauso por favor), abrimos este último y vamos a la carpeta Upgrade, ahí encontraremos un script de PowerShell que se llama UpdateRetailSelfService. Tenemos que ejecutar este script en PowerShell como administrador. Va a tardar entre 3 y 5 minutos y cuando termine los paquetes estarán subidos a la cuenta de almacenamiento y ya aparecerán en el formulario de parámetros de Retail.

¡Eso a mi no me funciona!

Hay un caso es el que los instaladores no se cargan: si no tienes ninguna configuración hecha para Retail. ¿Por qué? El script de PowerShell comprueba lo siguiente:

  • Que existan datos de canal en la Channel DB
  • Que existan datos de canal en el AOS
  • Que haya transacciones en el AOS
  • Que haya datos de transacciones en la Channel DB
  • Que existan extensiones de la Channel DB

Si no se cumple ninguna de estas condiciones el script se salta la creación de los instaladores en el blob. ¡Pero podemos hacer algo! Sí, como configurar un canal por ejemplo. Pero ¿y si no tienes ganas?

Recuerdas el script UpdateRetailSelfService de antes? Sólo tienes que editarlo y comentar las siguientes líneas:

Esto hará que el script se salte la validación y se desplieguen los instaladores.

Es bastante guarro, ¿verdad? Sí. Hace honor a workaround.

¿Qué hay de los entornos self-service?

Estoy convencido de que esto también se puede conseguir modificando un Deployable Package (uno de los de las actualizaciones mensuales), dejando solo Retail en el archivo DefaultTopologyData.xml, e incluso editar el script si hace falta. Pero no lo he probado. ¿Algún voluntario?

Parsea XML y JSON en MSDyn365FO fácilmente

Hace un tiempo tuve que crear un interfasado entre MSDyn365FO yun sistema externo que devolvía los datos en XML. Decidí usar las clases XML de X++ (XmlDocument, XmlNodeList, XmlElement, etc…) para parsear el XML y acceder a los datos. Estas clases son horrorosas. Sacas el trabajo pero de una forma fea fea. Hay un método mejor para parsear XML o JSON en MSDyn365FO.

.NET al rescate

Hay una funcionalidad en Visual Studio que nos ayudará con esto, pero no está disponible para los proyectos de tipo Unified Oprations. Para usarlo sólo hay que abrir Visual Stuio y crear un proyecto de .NET. Ahora copias un ejemplo de XML que quieras parsear, vas al menú Edit, Paste Special, Paste XML As Classes:

Y con esto tendremos un contrato de datos con todos los elementos necesarios para acceder a todos los nodos del XML usando notación con puntos para accede a los datos! Por ejemplo, para este XML de ejemplo obtendremos este código:

namespace AASXMLHelper
{

    // NOTE: Generated code may require at least .NET Framework 4.5 or .NET Core/Standard 2.0.
    /// <remarks/>
    [System.SerializableAttribute()]
    [System.ComponentModel.DesignerCategoryAttribute("code")]
    [System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
    [System.Xml.Serialization.XmlRootAttribute(Namespace = "", IsNullable = false)]
    public partial class catalog
    {

        private catalogBook[] bookField;

        /// <remarks/>
        [System.Xml.Serialization.XmlElementAttribute("book")]
        public catalogBook[] book
        {
            get
            {
                return this.bookField;
            }
            set
            {
                this.bookField = value;
            }
        }
    }

    /// <remarks/>
    [System.SerializableAttribute()]
    [System.ComponentModel.DesignerCategoryAttribute("code")]
    [System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
    public partial class catalogBook
    {

        private string authorField;

        private string titleField;

        private string genreField;

        private decimal priceField;

        private System.DateTime publish_dateField;

        private string descriptionField;

        private string idField;

        /// <remarks/>
        public string author
        {
            get
            {
                return this.authorField;
            }
            set
            {
                this.authorField = value;
            }
        }

        /// <remarks/>
        public string title
        {
            get
            {
                return this.titleField;
            }
            set
            {
                this.titleField = value;
            }
        }

        /// <remarks/>
        public string genre
        {
            get
            {
                return this.genreField;
            }
            set
            {
                this.genreField = value;
            }
        }

        /// <remarks/>
        public decimal price
        {
            get
            {
                return this.priceField;
            }
            set
            {
                this.priceField = value;
            }
        }

        /// <remarks/>
        [System.Xml.Serialization.XmlElementAttribute(DataType = "date")]
        public System.DateTime publish_date
        {
            get
            {
                return this.publish_dateField;
            }
            set
            {
                this.publish_dateField = value;
            }
        }

        /// <remarks/>
        public string description
        {
            get
            {
                return this.descriptionField;
            }
            set
            {
                this.descriptionField = value;
            }
        }

        /// <remarks/>
        [System.Xml.Serialization.XmlAttributeAttribute()]
        public string id
        {
            get
            {
                return this.idField;
            }
            set
            {
                this.idField = value;
            }
        }
    }


}

Podemos crear esto en una Class Library de .NET y consumirla desde Finance and Operations. Este es el método más rápido para usar todas las clases y miembros de estas. Seguramente se pueda implementar como clases de Dynamics 365 FnO, pero habrís que crear tantas clases como tipos distintos de nodos haya en el XML. Y el propósito original de esto era parsear el XML más rápido. Yo me quedaría con la librería de .NET.

Todos estos pasos también son válidos para un archivo JSON, copias el JSON, paste special y tenemos todas las clases para acceder a los datos.

Usándolo en Dynamics

Una vez tenemos la librería o las clases creadas en Microsoft Dynamics 365 (no hagáis esto anda) añadimos la referencia al proyecto y (siguiendo el ejemplo) hacemos lo siguiente:

catalog			catalog		= new catalog();
XmlSerializer	        serializer	= new XmlSerializer(catalog.GetType());
TextReader		sr	        = new StringReader(xmlSample);
        
catalog = serializer.Deserialize(sr);

catalogBook[]   books   = catalog.book;
catalogBook     book    = books.GetValue(0);

Declaramos una variable del mismo tipo que el nodo raíz (el principal), catalog en el ejemplo. Creamos un nuevo XmlSerializer usando nuestro tipo y creamos un TextReader a partir del XML como cadena. Finalmente necesitamos deserializar el XML y asignar el resultado al catalog y…

Como se ve, podemos acceder a los datos usando notación de puntos y las clases que se crearon al usar la función del pegado especial.

Con la ayuda de herramientas que no son específicas de la programación en X++ podemos conseguir esto, y, definitivamente, es más rápido que tener que parsear el XML usando las clases Xml de Dynamics.

Configurar las nuevas tareas de Azure DevOps para generar el paquete y versiones de modelos

Durante la pasada noche (que por lo menos era noche para mí :P) se han publicado las nuevas tareas de Azure DevOps para desplegar los paquetes, actualizar versiones de modelos y añadir licencias a los DPs:

Se ha publicado tambien un anuncio en los blogs de Community con más detalles acerca de la configuración. Vamos a ver las nuevas tareas y cómo configurarlas.

Tarea Update Model Version

Esta es sencillita, simplemente hay que añadirla a tu definición de build debajo de la tarea actual, deshabilitas la original y listo. Si tienes algún filtro, excluyendo modelos por ej., necesitaras crear el filtro en el campo Descriptor Search Pattern usando la sintaxis de patrones de Azure DevOps.

Tarea Create Deployable Package

Esta tarea va a sustituir la Generate packages actual. Para configurarla correctamente necesitamos hacer un par de cambios a los valores que trae por defecto:

X++ Tools Path

Esto es el directorio físico de tu VM de build donde está la carpeta bin. La carpeta AosService normalmente está en la unidad K en las VMs desplegadas en la suscripción del cliente. Probablemente esto cambie cuando pasemos a un modelo sin VMs para hacer las builds.

Edito!: la ruta a la unidad se puede cambiar por $(ServiceDrive), quedando una ruta como $(ServiceDrive)\AOSService\PackagesLocalDirectory\bin.

Location of the X++ binaries to package

La tarea viene con este campo rellenado con $(Build.BinariesDirectory) por defecto, pero esto no nos ha funcionado para nuestras builds, quizás esa variable no esta en el archivo proj. Sólo hay que cambiarlo por $(Agent.BuildDirectory)\Bin y el DP se generará sin problemas.

Filename and path for the deployable package

La ruta en la imagen debería cambiarse por $(Build.ArtifactStagingDirectory)\Packages\AXDeployableRuntime_$(Build.BuildNumber).zip. Se puede dejar sin la parte de Packages pero entonces habra que cambiar el campo Path to Publish de la tarea Publish Artifact: Package de la definición.

Tarea Add Licenses to Deployable Package

Esta tarea añade las licencias a un Deployable Package que ya existe. Recuerda que la ruta del DP tiene que ser la misma que hayas configurado en la tarea Create Deployable Package.

¡Y ya esta todo listo! Un pasito más cerca de deshacernos de las VM de build.

Si necesitas ayuda para configurar Configurar Release en Azure DevOps puedes leer este post que escribí.

 

Entornos self-service: el futuro que ya está aquí

Ahora mismo Microsoft Dynamics 365 for Finance and Operations tiene una arquitectura de tipo monolítico, aunque está en la nube de Azure lo que tenemos en realidad es una (o varias en el caso de los entornos Tier 2+) máquina virtual que ejecuta todo: el AOS/IIS, Azure SQL Server, el servicio de lotes, MR, etc. Igual que teníamos en AX 2009/2012.

Esto va a cambiar en los próximos meses con los entornos self-service (o autogestionados). Vamos a pasar de una arquitectura monolítica a una de microservicios que ejecutarán todos los componentes con la ayuda de Azure Service Fabric. MSDyn365FO estará finalmente en un modelo SAAS real.

Antes de empezar quiero dejar claro que todos estos cambios solo afectan a los entornos Tier 2+ gestionados por Microsoft: entornos de tipo sandbox y producción. El entorno de build (hasta que desaparezca) y los entornos hospedados en la nube de la suscripción del partner o cliente seguirán siendo máquinas virtuales.

¿Qué cambia?

Despliegues más rápidos

Cuando despliegues un nuevo entorno se va a iniciar el despliegue en el momento, sin esperar a que lo haga Microsoft (es self-service). Además, gracias a la nueva arquitectura de microservicios, estará disponible en unos 30 minutos en comparación con las 6-8 horas que hay que esperar ahora. La primera vez parece…

Estimación de suscripción

Seguimos necesitando rellenar la estimación de la suscripción por un tema de licencias y para que MS estime la capacidad que debe asignar al entorno de producción. Los entornos self-service se pueden escalar más rápido (poner o quitar un AOS por ej.).

No hay acceso por RDP

El acceso al escritorio de la VM se ha quitado porque… bueno, supongo que es porque no hay una VM ya. Todas las operaciones que necesitaran que accedieramos al RDP se podrán hacer desde LCS.

No hay acceso a SQL Server

Exacto, que no haya acceso por RDP quiere decir que tampoco podemos acceder por RDP a la máquina de SQL. Seguimos teniendo acceso a la DB en Azure SQL, sólo tenemos que solicitarlo desde LCS y se activa en unos segundos:

Además hay que poner la IP desde la que se vaya a conectar a SQL en la withelist desde el botón Maintain – Enable access de LCS para poder conectar al Azure SQL Server. El acceso a la DB y la regla en el firewall estarán activos durante 8 horas.

Como siempre, no tenemos acceso a la DB de producción.

Un deployable package para gobernarlos a todos

Si has intentado desplegar un deployable package (DP) que no tenga todos los paquetes o modelos que tiene el entorno (básicamente creando el DP desde Visual Studio) habrás visto que aparece un aviso sobre la diferencia entre entorno y DP.

Con los entornos self-service tienes que incluir todos los modelos/paquetes Y!!! ISVs en un único DP.

Actualizar producción

Primero de todo, podemos lanzar la actualización de producción sin las 5 horas de preaviso que necesitamos ahora. Seguimos pudiendo programar el despliegue pero también lo podemos iniciar en el momento.

Después, la forma en la que se actualiza el entorno de producción ha cambiado un poco de lo que hacemos ahora. Con los nuevos entornos lo que haremos será actualizar un entorno de sandbox como hacemos ahora, y una vez esté hecho, seleccionaremos el entorno de sandbox para promocionarlo a producción. Esto supongo que es otro beneficio de los cambios de arquitectura.

En el futuro el tiempo de mantenimiento también se reducirá a cero para las actualizaciones de servicio siempre que estemos en la última actualización. Esto no será posible para DPs con código nuestro.

¿Cómo consigo estos entornos?

Por el momento esto sólo está disponible para algunos nuevos clientes. Los clientes actuales serán migrados en los próximos meses, Microsoft los contactará para programar una ventana de mantenimiento para aplicar los cambios.

Para más información podéis ver la sesión Microsoft Dynamics 365 for Finance and Operations: Strategic Lifecycle Services Investments del MBAS del pasado junio.

Nuestra experiencia

Llevamos en la preview privada desde hace casi un año con uno de los clientes de Axazure. El cliente ya está con producción en live con un entorno self-service y ha ido todo bien.

Pero los inicios fueron un poco duros. Muchas de las funcionalidades aun no estbaan disponibles en ese momento, como el refresco de DB o… el despliegue de DPs. Sí, teníamos que solicitar a MS cada vez que queríamos subir cambios a un entorno. ¡No podíamos ni poner los entornos en mantenimiento! En los primeros meses de 2019 se añadió un montón de funcionalidad a LCS, y en junio finalmente pudimos hacer los despliegues en producción nosotros mismos. La ayuda que hemos tendido por parte del equipo de producto de Microsoft ha sido clave y nos han desbloqueado algunos problemas que estaban deteniendo el progreso del proyecto.

Operaciones «set-based» lentas?

En Microsoft Dynamics 365 for Finance and Operations podemos ejecutar operaciones CRUD en el código de dos formas, operaciones set-based (que podríamos traducir como basadas en conjuntos más o menos) y registro a registro.

La recomendación de Microsoft es usar siempre las operaciones set-based, si es posible, como se puede ver en la sesión Implementation Best Practices for Dynamics 365: Performance best practices for a successful Dynamics 365 Finance and Operations implementation del pasado Business Applications Summit de junio.

¿Por qué?

Set-based Vs. Registro a registro

Cuando ejecutamos una query en MSDyn365FO usando la capa de acceso a datos lo que ocurre es que nuestra consulta termina convertida en un comando SQL. Podemos ver las diferencias usando el método getSQLStatement de la clase xRecord con un generateonly en la query (y un forceliterals para mostrar los valores de los parámetros) para obtener la consulta de SQL. Por ejemplo si ejecutamos el siguiente código:

Obtenemos esta consulta de SQL:

SELECT TOP 1 T1.PAYMTERMID,T1.LINEDISC,T1.TAXWITHHOLDGROUP_TH,T1.PARTYCOUNTRY,T1.ACCOUNTNUM,T1.ACCOUNTSTATEMENT,T1.AFFILIATED_RU,T1.AGENCYLOCATIONCODE,T1.BANKACCOUNT,T1.BANKCENTRALBANKPURPOSECODE,T1.BANKCENTRALBANKPURPOSETEXT,T1.BANKCUSTPAYMIDTABLE,T1.BIRTHCOUNTYCODE_IT,T1.BIRTHPLACE_IT,T1.BLOCKED,T1.CASHDISC,T1.CASHDISCBASEDAYS,T1.CCMNUM_BR,T1.CLEARINGPERIOD,T1.CNAE_BR,T1.CNPJCPFNUM_BR,T1.COMMERCIALREGISTER,T1.COMMERCIALREGISTERINSETNUMBER,T1.COMMERCIALREGISTERSECTION,T1.COMMISSIONGROUP,T1.COMPANYCHAINID,T1.COMPANYIDSIRET,T1.COMPANYNAFCODE,T1.COMPANYTYPE_MX,T1.CONSDAY_JP,T1.CONTACTPERSONID,T1.CREDITCARDADDRESSVERIFICATION,T1.CREDITCARDADDRESSVERIFICATIONLEVEL,T1.CREDITCARDADDRESSVERIFICATIONVOID,T1.CREDITCARDCVC,T1.CREDITMAX,T1.CREDITRATING,T1.CURP_MX,T1.CURRENCY,T1.CUSTCLASSIFICATIONID,T1.CUSTEXCLUDECOLLECTIONFEE,T1.CUSTEXCLUDEINTERESTCHARGES,T1.CUSTFINALUSER_BR,T1.CUSTGROUP,T1.CUSTITEMGROUPID,T1.CUSTTRADINGPARTNERCODE,T1.CUSTWHTCONTRIBUTIONTYPE_BR,T1.DEFAULTDIMENSION,T1.DEFAULTDIRECTDEBITMANDATE,T1.DEFAULTINVENTSTATUSID,T1.DESTINATIONCODEID,T1.DLVMODE,T1.DLVREASON,T1.DLVTERM,T1.EINVOICE,T1.EINVOICEATTACHMENT,T1.EINVOICEEANNUM,T1.ENDDISC,T1.ENTRYCERTIFICATEREQUIRED_W,T1.EXPORTSALES_PL,T1.EXPRESSBILLOFLADING,T1.FACTORINGACCOUNT,T1.FEDERALCOMMENTS,T1.FEDNONFEDINDICATOR,T1.FINECODE_BR,T1.FISCALCODE,T1.FISCALDOCTYPE_PL,T1.FORECASTDMPINCLUDE,T1.FOREIGNRESIDENT_RU,T1.FREIGHTZONE,T1.GENERATEINCOMINGFISCALDOCUMENT_BR,T1.GIROTYPE,T1.GIROTYPEACCOUNTSTATEMENT,T1.GIROTYPECOLLECTIONLETTER,T1.GIROTYPEFREETEXTINVOICE,T1.GIROTYPEINTERESTNOTE,T1.GIROTYPEPROJINVOICE,T1.ICMSCONTRIBUTOR_BR,T1.IDENTIFICATIONNUMBER,T1.IENUM_BR,T1.INCLTAX,T1.INSSCEI_BR,T1.INTBANK_LV,T1.INTERCOMPANYALLOWINDIRECTCREATION,T1.INTERCOMPANYAUTOCREATEORDERS,T1.INTERCOMPANYDIRECTDELIVERY,T1.INTERESTCODE_BR,T1.INVENTLOCATION,T1.INVENTPROFILEID_RU,T1.INVENTPROFILETYPE_RU,T1.INVENTSITEID,T1.INVOICEACCOUNT,T1.INVOICEADDRESS,T1.INVOICEPOSTINGTYPE_RU,T1.IRS1099CINDICATOR,T1.ISRESIDENT_LV,T1.ISSUEOWNENTRYCERTIFICATE_W,T1.ISSUERCOUNTRY_HU,T1.LINEOFBUSINESSID,T1.LVPAYMTRANSCODES,T1.MAINCONTACTWORKER,T1.MANDATORYCREDITLIMIT,T1.MANDATORYVATDATE_PL,T1.MARKUPGROUP,T1.MCRMERGEDPARENT,T1.MCRMERGEDROOT,T1.MULTILINEDISC,T1.NIT_BR,T1.NUMBERSEQUENCEGROUP,T1.ONETIMECUSTOMER,T1.ORDERENTRYDEADLINEGROUPID,T1.ORGID,T1.OURACCOUNTNUM,T1.PACKAGEDEPOSITEXCEMPT_PL,T1.PACKMATERIALFEELICENSENUM,T1.PARTY,T1.PARTYSTATE,T1.PASSPORTNO_HU,T1.PAYMDAYID,T1.PAYMENTREFERENCE_EE,T1.PAYMIDTYPE,T1.PAYMMODE,T1.PAYMSCHED,T1.PAYMSPEC,T1.PDSCUSTREBATEGROUPID,T1.PDSFREIGHTACCRUED,T1.PDSREBATETMAGROUP,T1.PRICEGROUP,T1.RESIDENCEFOREIGNCOUNTRYREGIONID_IT,T1.RFC_MX,T1.SALESCALENDARID,T1.SALESDISTRICTID,T1.SALESGROUP,T1.SALESPOOLID,T1.SEGMENTID,T1.SERVICECODEONDLVADDRESS_BR,T1.STATEINSCRIPTION_MX,T1.STATISTICSGROUP,T1.SUBSEGMENTID,T1.SUFRAMA_BR,T1.SUFRAMANUMBER_BR,T1.SUFRAMAPISCOFINS_BR,T1.SUPPITEMGROUPID,T1.TAXGROUP,T1.TAXLICENSENUM,T1.TAXPERIODPAYMENTCODE_PL,T1.TAXWITHHOLDCALCULATE_IN,T1.TAXWITHHOLDCALCULATE_TH,T1.UNITEDVATINVOICE_LT,T1.USECASHDISC,T1.USEPURCHREQUEST,T1.VATNUM,T1.VENDACCOUNT,T1.WEBSALESORDERDISPLAY,T1.AUTHORITYOFFICE_IT,T1.EINVOICEREGISTER_IT,T1.FOREIGNERID_BR,T1.PRESENCETYPE_BR,T1.TAXGSTRELIEFGROUPHEADING_MY,T1.FOREIGNTAXREGISTRATION_MX,T1.CUSTWRITEOFFREFRECID,T1.ISEXTERNALLYMAINTAINED,T1.SATPAYMMETHOD_MX,T1.SATPURPOSE_MX,T1.CFDIENABLED_MX,T1.FOREIGNTRADE_MX,T1.WORKFLOWSTATE,T1.USEORIGINALDOCUMENTASFACTURE_RU,T1.COLLECTIONLETTERCODE,T1.BLOCKFLOORLIMITUSEINCHANNEL,T1.AXZMODEL182LEGALNATURE,T1.AXZCRMGUID,T1.MODIFIEDDATETIME,T1.MODIFIEDBY,T1.CREATEDDATETIME,T1.RECVERSION,T1.PARTITION,T1.RECID,T1.MEMO 

FROM CUSTTABLE T1 

WHERE (((PARTITION=5637144576) AND (DATAAREAID=N'usmf')) AND (ACCOUNTNUM=N'0001'))

Podemos ver que se seleccionan todos los campos y que los filtros en el where incluyen la cuenta que hemos filtrado (además del DataAreaId y Partition).

Cuando se ejecuta un while select en MSDyn365FO, lo que ocurre en SQL Server es que se ejecuta una consulta por cada vuelta del while. Lo mismo ocurre si se ejecuta un update o delete dentro del bucle. Esto se conoce como operación registro a registro.

Imaginad que queréis actualizar la nota de todos los clientes que sean del grupo de clientes 10. Podríamos hacerlo con un while select de esta manera:

Esto ejecutaría tantas consultas en SQL como clientes del grupo 10 existan, una por cada vuelta del bucle. O podríamos usar operaciones set-based:

Esto ejecutará la actualización de todos los clientes del grupo 10 en una única consulta de SQL Server en vez de una por cliente:

UPDATE CUSTTABLE
SET MEMO = 'Special customer'
WHERE (((PARTITION=5637144576) 
    AND (DATAAREAID=N'usmf')) 
    AND (CUSTGROUP=N'10'))

Existen tres operaciones set-based en MSDyn365FO, update_recordset para actualizar, insert_recordset para crear registros y delete_from para borrarlos de forma masiva. Además de poder hacer inserciones masivas con las listas de tipo RecordSortedList y RecordInsertList.

Ejecutar estos métodos en vez de while selects debería ser por lo general más rápido porque se lanza una sola consulta SQL. Pero…

¿Por qué son lentas mis operaciones set-based?

Existen algunos escenarios documentados en los que las operaciones set-based se convierten en operaciones registro a registro como podemos ver en la siguiente tabla:

DELETE_FROMUPDATE_RECORDSETINSERT_RECORDSETARRAY_INSERTUse … to override
Non-SQL tablesYesYesYesYesNot applicable
Delete actionsYesNoNoNoskipDeleteActions
Database log enabledYesYesYesNoskipDatabaseLog
Overridden methodYesYesYesYesskipDataMethods
Alerts set up for tableYesYesYesNoskipEvents
ValidTimeStateFieldType property not equal to None on a tableYesYesYesYesNot applicable

En el ejemplo, si el método update de la CustTable está sobreescrito (que lo está) la operación del update_recordset se ejecutará como si fuera un while select, actualizando registro a registro.

En el caso del update_recordset esto se puede solucionar llamando al método skipDataMethods antes de ejecutar el update:

Esto hace que no se ejecute el método update (o insert si se hace un insert_recordset), más o menos como si se hiciera un doUpdate en el loop. El resto de los métodos también se pueden saltar con el método correspondiente que aparece en la última columna de la tabla.

Así que, para actualizaciones masivas siempre deberíamos usar operaciones set-based, y activar esto también en las data entities con la propiedad EnableSetBasedSqlOperations.

Y ahora viene otro pero.

¿Debería usar siempre operaciones set-based para actualizaciones masivas?

Bueno, depende de con qué datos estemos trabajando. Hay un post magnífico de Denis Trunin llamado «Blocking in D365FO(and why you shouldn’t always follow MS recommendations)» que explica un ejemplo perfecto de cuándo las operaciones set-based podrían ser perjudiciales.

Como siempre, desarrollar en un ERP es bastante delicado, y escenarios parecidos pueden tener soluciones totalmente diferentes. Simplemente hay que analizar y tomar la decisión.

Actualizar Visual Studio 2019 para #MSDyn365FO

¿Harto de desarrollar en Visual Studio 2015? ¿Te sientes abandonado en el pasado? No te preocupes, ¡es posible usar Visual Studio 2017/2019 para desarrollo de Microsoft Dynamics 365 for Finance & Operations!

¿Cuáles son sus ventajas?

¡Absolutamente ninguna! Visual Studio se quedará sin responder sea cual sea la versión que uses porque la extensión de las developer tools está un poco pasada de moda y es la que en realidad causa los cuelgues.

Sí se añade la posibilidad de usar Live Share, que para sesiones de pantalla compartida es mil veces mejor que Teams. Ey, y que estaremos usando la última versión de VS!

¿Cuesta mucho?

No, tiene cero misterio. Lo primero que hay que hacer es descargar Visual Studio 2019 Professional (o Enterprise pero para D365 no sirve de mucho más) e instalarlo:

Seleccionamos la opción de desarrollo de escritorio .NET y le damos al instalar. Cuando termine abrimos VS y nos conectamos con nuestra cuenta.

El siguiente paso es instalar la extensión de las developer tools de Dynamics. Vamos a la unidad K y en la carpeta DeployablePackages encontraremos unos ZIP que si abrimos veremos que tienen una carpeta DevToolsService/Scripts con la extensión de VS:

Otra alternativa es, por ejemplo, descargar el paquete de un Platform Update que también tiene las dev tools y puede que más actualizadas.

Instalamos la extensión y ya nos aparece la opción de VS2019:

Una vez instalado abrimos VS como administrador y…

Y también…

¡Que no cunda el pánico! La extensión está hecha para VS2015 y usarla en una versión más nueva da algunos avisos, pero solo eso, tenemos las herramientas listas y las podemos usar:

Como decía al principio la extensión de las dev tools es lo que a veces ralentiza o bloquea VS, y Visual Studio 2019 así lo notifica:

Pese a los avisos se puede trabajar con Visual Studio 2019 sin ningún problema. Yo llevo haciéndolo una semana y no he encontrado ningún problema que me haga volver a la 2015.

Preview de las nuevas dev tools

En octubre de 2019 se va a publicar la versión de preview de las herramientas de desarrollo tal y como se vio en el MBAS de Atlanta. Esperemos ver qué novedades trae tanto en versión de VS como mejora del rendimiento de la extensión.

Usando Azure Application Insights con MSDyn365FO

Primero de todo… AVISO: antes de usar esto en un entorno de producción pensadlo bien. Y luego volvedlo a pensar. Y si finalmente decides usarlo, hacedlo con cuidado y cariño.

Por qué este aviso? Bueno, a pesar de que los documentos aseguran que la afectación en el rendimiento del sistema en general es mínima hay que andar con cuidado. Es un ERP. Uno en el que no tenemos acceso al entorno de producción (a no ser que estéis On-Prem) para analizar si hay impacto. Además probablemente Microsoft ya está usandolo para recoger datos de los entornos y mostrarlos en LCS, y desconozco si puede haber interferencias. Un montón de no-lo-ses.

Lo usaría en producción? . Puede ser muy útil en algunos casos.

Y dicho esto, de qué voy a escribir que necesita un aviso? Como dice el título, sobre usar Azure Application Insights en Microsoft Dynamics 365 for Finance and Operations. Este post es consecuencia de uno de los «Has visto esto? Sí, deberíamos probarlo!» entre Juanan (aquí en Twitter, seguidle!) y yo. Y el esto esta vez era este post de Lane Swenka en AX Developer Connection. Así que nada original por aquí 🙂

Azure Application Insights

I spy
Made by Cazapelusas

¿Y qué es Application Insights? Como dice la documentación:

Application Insights is an extensible Application Performance Management (APM) service for web developers on multiple platforms. Use it to monitor your blah web application. It will blah blah detect blaaah anomalies. It blah powerful blahblah tools to bleh blah blih and blah blah blaaaah. It’s blaaaaaaaah.

Mmmm… ved este vídeo mejor:

Hay tanta miseria y tristeza en los primeros 30 segundos…

Monitoreo. Eso hace y para eso es. «Eh, pero LCS ya hace eso!«. Vale, monitoreo extra! A todo el mundo le gusta lo extra, como la pizza, excepto si es piña, claro.

Haciendo que funcione

El primer paso será crear un recurso para Application Insights en nuestra suscripción de Azure. Sobre el precio: los 5 primeros gigas por mes son gratuitos, y los datos se guardan durante 90 días. Más información aquí.

Después necesitamos el código. Me voy a ahorrar los detalles en esta parte porque está perfectamente explicado en el link que he puesto antes (este). Básicamente tienes que crear una DLL para manejar los eventos y mandar la información a AAI y usar esa DLL desde MSDyn365FO. En nuestra versión hemos añadido un método extra para trazas llamado trackTrace. Después solo hay que referenciar la DLL en 365 y ya lo podemos usar.

Qué podemos medir?

Ahora viene la parte interesante (espero). Visitas de páginas, capturar errores (o todos los infologs), ejecuciones de lotes, cambios de valor de campos, y cualquier cosa que podamos extender y desde ahí llamar a nuestra API.

Por ejemplo, podemos extender la clase FormDataUtil del motor de formularios. Esta clase tiene varios métodos que se llaman desde los formularios en acciones de los datasources, como validaciones de writes, deletes, campos, etc… Y también esto:

modifiedField in FormDataUtils

Este método se ejecuta cada vez que se modifica un campo en un formulario. Lo vamos a extender para registrar qué campo se ha modificado, el valor anterior y el nuevo. Así:

Extending modifiedField
Prometo que siempre uso etiquetas!

Y como la llamada a Application Insights también guarda el usuario que ha hecho el cambio de valor, tenemos un nuevo log de la base de datos! Incluso mejor, tenemos un nuevo registro de la base de datos que no afecta al rendimiento porque no se generan datos extra en MSDyn365FO. La única pega es que solo se llamará desde formularios, pero puede ser suficiente para monitorear el uso de formularios y los “yo no he tocado ningún parámetro!” 🙂

Esto es lo que vemos en el explorador de métricas de Azure Application Insights:

Azure Application Insights Custom Event
Qué quieres decir con que he tocado eso!?

Sí, fuiste tú usuario Admin! Uy si soy yo…

Custom events

Todas las métricas de los eventos se muestra  en Azure, y los datos se pueden mostrar en Power BI.

Repito, planead bien lo que queréis monitorear antes de usar esto y testeadlo. Luego testeadlo otra vez, sobretodo en entornos SAT con bases de datos Azure SQL. Tienen un rendimiento distinto a un SQL Server normal y hay que estar seguro.

A disfrutar de los datos!

Generando valores de secuencias numericas desde servicios REST y OData

Una de las opciones para realizar integraciones con MSDyn365FO es usar las data entities con servicios REST a través de OData. Para poder usar las entidades con servicios REST solo tenemos que comprobar que tengan la propiedad IsPublic a Yes:

Entidad Clientes V3

Si no la tienen, y es una entity estándar, tocará duplicarla porque no es posible editar la propiedad en una extensión.

Si realizamos una integración con un sistema externo a través de OData para insertar datos en el ERP, nos podemos encontrar con el problema que al generar el registro sea obligatorio el ID de ese registro, como ocurre con los clientes. Si vemos la propiedad Mandatory del campo CustomerAccount está en Auto, con lo que hereda el valor de la propiedad en la tabla CustTable donde esta a Yes.

En este caso si intentamos crear un cliente sin número de cuenta el servicio va a fallar como podemos ver en esta captura de pantalla de Postman:

Postman fail :(

El error es claro, la cuenta de cliente no puede estar vacía.

Esto no sucede así con la entidad de proveedores. «Pero si la cuenta de proveedor también es obligatoria en la VendTable!» dirá alguno. Sí, lo es, pero en la entidad no lo es:

Vendors V2

Para ver cómo lo soluciona el estándar vamos a ver el initValue de la entidad de proveedores:

Tiene truco!

El método skipNumberSequenceCheck es uno de los métodos de datos de la clase Common, y es de la familia de los skipDataMethods, skipDataSourceValidateWrite, skipAosValidation, etc… El método siempre nos devolverá un false a no ser que le digamos antes lo contrario, pasándole el parámetro true en las llamadas en el código.

El método enableNumberSequenceControlForField de la clase NumberSeqRecordFieldHandler lo que hace es inicializar el valor del campo que le pasamos por parámetro con el next de la secuencia numérica que le digamos. En este caso rellena la cuenta de proveedor con la secuencia que este configurada en los parámetros de proveedores para la cuenta de proveedor (lógico).

Reproduciendo el estándar, vamos a crear una clase de extensión para la data entity y extenderemos el método initValue:

Extensión de código de la entity Customers V3

Con esto podemos volver a probar a generar un nuevo cliente en Postman, borrando el parámetro de cuenta de cliente del cuerpo del mensaje, y…

Cliente creado por servicio REST y OData

Premio! Tenemos un nuevo cliente! Creado desde un sistema externo, usando la secuencia numérica del ERP.

Esto no tiene ningún misterio, sobretodo porque reproduce el comportamiento de las partes del estándar que ya lo hacen. Algo que deberíamos intentar hacer siempre, seguir el estándar. Siempre que podamos claro :), porque aunque se intente que los clientes se adapten al estándar lo máximo posible, todos sabemos que siempre, siempre, siempre habrá que hacer alguna customización (menos mal, que somos devs).

Dynamics 365 for Finance & Operations y Azure DevOps (parte II)

En la primera parte de este post vimos a importancia de Azure DevOps y como configurarlo para MSDyn365FO.

Quiero empezar esta segunda parte con una pequeña pataleta. Como decía en la primera parte, los que llevamos años trabajando con AX nos habíamos acostumbrado a no usar un control de versiones. MSDyn365FO nos ha llevado a un terreno sin explorar, con lo que no es raro que cada equipo haya decidido trabajar de una forma u otra según las experiencias que se hayan ido encontrando. Evidentemente, hay un componente del interés de los miembros de estos equipos para investigar un poco por su cuenta sobre la gestión de código, ramas y metodologías. Muchas veces a base de experimentación y prueba-error, y con las prisas de algunos proyectos esto sale mal, o muy mal. Y aquí he echado de menos un poco de guidance por parte de Microsoft (que igual la hay y me lo he perdido).

A pesar de esta quejita el camino y el aprendizaje ha sido, y creo que lo que viene también será, bastante divertido 😉

Estrategias de branching

Vaya por delante que no soy, ni mucho menos, un experto en gestión del código ni Azure DevOps. Todo lo que viene a continuación es fruto, como comentaba antes, de la experiencia (y las meteduras de pata) de casi 3 años trabajando con MSDyn365Ops. En este artículo de la documentación sobre estrategias de branching hay más información sobre branching y links a artículos del equipo de DevOps. Y en la Biblioteca de herramientas y guías de los DevOps Rangers hay incluso muchísimo más!

La verdad es que me encantaría una sesión de FastTrack sobre esto y, creo que no la hay. EDIT: parece que no lo vi y sí que existe una sesión de FastTrack sobre esto que se llama Developer ALM. Gracias a Dag Calafell (twitter) por la información!

Como vimos en la primera parte cuando desplegamos la máquina de Build se crea la carpeta de Main. Lo normal es que en un proyecto de implantación se desarrolle sobre Main hasta el momento del arranque, y que justo antes del go live se cree una branch (rama) de desarrollo. El árbol de código quedaría así:

Ramas despues de branch

En ese momento los mapeos de las máquinas de desarrollo deben cambiarse para que apunten a esta nueva rama de dev. Esto permitirá seguir desarrollando mejoras o corrigiendo errores y decidir el momento en el que se van a mover a producción haciendo un merge a Main.

Esta estrategia es bastante sencilla y que no provoca muchos quebraderos de cabeza. En mi anterior trabajo en cliente final decidimos usar 3 ramas por peculiaridades de la empresa. Main, Dev y Test con merges de Dev a Test y de Test a Main. Un dolor de cabeza al final, gestionar las 3 ramas, con upgrades de versiones, decenas de changesets pendientes y un partner ISV que no ayudaba mucho era bastante divertido.  ¿Pero, y lo que aprendí? Buf.

En cualquier caso un consejo: intentad evitar que se queden changesets pendientes de mergear durante mucho tiempo. La cantidad de conflictos que aparecen y hay que resolver a mano es directamente proporcional a lo viejo que sea el changeset.

Llegado a este punto no puedo hacer suficiente hincapié en lo de normal de más arriba. Como digo, esto lo escribo basado en mis experiencias. Está claro que no es lo mismo trabajar en un partner de implantación que en un ISV. Un ISV tiene la necesidad de mantener diferentes versiones de su producto y no va a usar una rama Main y otra Dev sinó que puede tener una (o varias) por versión a mantener para dar soporte a todos los clientes (aunque desde la 8.1 y el fin del overlayering ya no es necesario). Para más «ideas» el artículo que he enlazado al principio es perfecto para empezar.

Builds

En la primera parte y en otro post (Builds que no responden en Azure DevOps) expliqué un poco acerca de las builds. Ya vimos que la definición de build que se genera por defecto al desplegar el servidor es como la de la imagen inferior:

Pasos de la definición de build por defecto

Esta build tiene todos los pasos con los que se ha creado activos. Podemos desactivar (o borrar) los pasos que no necesitemos. Por ejemplo, los 3 de testeo si no tenemos tests creados, o la sincronización y despliegue de informes.

Podemos crear nuevas definiciones de build a partir de esta o de 0 (pero es más sencillo y rápido duplicar esta y modificarla) para que se apliquen a otras ramas u otros motivos.

Con la versión 8.1 de MSDyn365FO han desaparecido los hotfixes de código X++, todos son binarios. Esto lo que implica es que en la carpeta Metadata de nuestras ramas ya no van a aparecer los modelos del estándar, solo los nuestros. Hasta la versión 8.0 era muy útil tener una definición de build únicamente para nuestros modelos y otra con todos los modelos. Con esto lo que se consigue es tener un DP en mucho menos tiempo que generándolo para todos los modelos. Si se aplica algún hotfix hay que generar el DP de la rama con todos los modelos, pero si sólo hay código propio no hace falta generar un paquete con todos los modelos.

Y hasta aquí la información desactualizada. A estas alturas todos los proyectos deberían estar en 8.1 o listos para estarlo, que en abril llega One Version!

Otra opción que es bastante útil es que, por ejemplo, podemos crear una nueva definición que lo único que haga es compilar una rama:

Definicion build continua

Esta build no hace nada más, solo compila. Así a priori no parece muy útil pero si activamos la opción de integración continua:

DevOps continuous integration

Después de cada check-in de cada desarrollador se lanzará una build que compilará todo el código y fallará si hay algún error. ¿Claro que no debería fallar no? Porque todos compilamos los proyectos antes de hacer el check-in, ¿verdad?

tysonjaja

Pues por eso y porque las prisas son malas y a veces tenemos que vivir con ellas, esta build puede ser bastante útil. Sobretodo cuando lo tengamos configurado para la rama Main y nos «chive» los errores que pueden aparecer después de un merge con conflictos. Y cuando hay que pasar algo urgente a producción y tenemos poco margen nos interesa poder generar el paquete lo antes posible. Usando esta estrategia conseguimos que generar un DP con nuestros paquetes tardara 9 minutos en vez de 1h15m generando todo.

Igual alguien con más conocimiento de esto piensa, pero eso no lo puedes hacer con…

Gated check-ins

Con este tipo de check-in el código se compila ANTES de que el check-in se haga efectivo. Si falla la build el changeset no se hace efectivo hasta que se corrijan los errores y se vuelva a hacer el check-in.

A priori esta opción parece ideal para los check-in de merges de una rama de desarrollo a Main. Los problemas que me he encontrado con esta opción son varios:

  • Si haces múltiples merge y check-ins de un mismo desarrollo y el primero falla no se mergea, pero si el segundo compila correctamente sí.
  • Problemas con las notificaciones de errores y código pendiente al fallar el check-in
  • En merges con más de un check-in se encolan muchas builds (y por defecto solo tenemos un build agent disponible…)

Seguro que esto tiene solución, pero no he sabido encontrarla. Y de todas formas la opción de integración contínua que comentaba antes nos ha funcionado perfectamente para validar que la rama compila sin errores. Como digo todo esto ha sido fruto de la investigación del equipo y prueba-error.

Conclusiones

Supongo que la mayor conclusión es que con MSDyn365FO hay que usar Azure DevOps. Es obligatorio, no hay otra opción. Los que no lo estéis haciendo, si es que alguien no lo hace, hacedlo. Ya. Revisad vuestra forma de trabajo y olvidemos de una vez por todas AX, MSDyn365FO a nivel técnico es otro producto.

La verdad es que, a los desarrolladores, MSDyn365FO nos ha acercado un poco más a lo que es un proyecto de desarrollo de software clásico como puede ser uno de .NET o Java. Pero no del todo. Un proyecto de ERP tiene muchas peculiaridades, y creo que no partir de zero en el desarrollo del producto, tener una base que nos «obliga» un poco a seguir una línea, nos limita en algunos aspectos y en el uso de ciertas técnicas y metodologías.

Y hasta aquí estos dos posts sobre Azure DevOps. Espero que le sean de ayuda a alguien. Y si alguien con más experiencia, o mejores ideas, quiere recomendar algo, ¡los comentarios están abiertos!

Dynamics 365 for Finance & Operations y Azure DevOps (parte I)

Con la llegada de Dynamics 365 el uso de un sistema de control de versiones se ha convertido en obligatorio. En anteriores versiones disponíamos de Morph VCS en AX 2009 y la posibilidad de integrar TFS en AX 2009 y AX 2012 (del que hay un completo curso en El rincón Dynamics), pero no existía ninguna obligación de usar ninguno de los dos. En realidad, siempre según mi experiencia, creo que la mayoría de proyectos se llevaban a cabo sin ningún tipo de control de versiones aparte de, con suerte, comentarios en el código.

El AOT antes de la llegada del control de versiones
El AOT antes de la llegada del control de versiones, de cazapelusas.com

Azure DevOps en MsDyn365FO

En Microsoft Dynamics 365 for Finance and Operations el control de versiones que nos ofrece Azure DevOps no es un simple control de versiones, sino una LA herramienta que hará un poco de Anillo Único en nuestros proyectos (solo que, espero, no para atarnos en las tinieblas). Y es que el cambio no solo afecta al equipo técnico. Desde dirección de proyecto a funcionales pueden implicarse en el uso de Azure DevOps para la gestión del proyecto.

La sincronización del BPM y creación de todas las tareas, planificación del equipo, gestión del código, builds automatizadas y releases que veíamos en un post anterior, son algunas de las herramientas que nos ofrece. Todos estos cambios requieren de un aprendizaje y adaptación por parte del equipo al completo, pero van a ayudarnos mucho en el control del proyecto.

Como decía, puede parecer que el equipo técnico sea el más afectado por la introducción de Azure DevOps por la «obligatoriedad» de usarlo en Visual Studio (bendita obligación), pero también es el que más provecho le va a sacar… 😉

Primeros pasos

Lo primero que tenemos que hacer cuando empezamos un nuevo proyecto de implantación es conectar LCS y el proyecto de Azure DevOps que vayamos a usar. Está todo muy bien explicado en la documentación.

Una vez configurada la conexión tenemos que desplegar el entorno de Build que vimos en el anterior post. Esto se hace habitualmente en la máquina de desarrollo disponible en la suscripción de Microsoft en el proyecto de LCS. Cuando se despliega esta máquina se va a crear la estructura básica de carpetas en el proyecto de DevOps:

Carpetas en proyecto de Azure DevOps

(Ignorad la carpeta CSProjects que es de la actuación cómica del pasado 365 Saturday con mi compañero Juanan)

Con esto ya podemos mapear las máquinas de desarrollo y empezar a trabajar. La carpeta Main que veis en la imagen es una carpeta normal, pero la podremos convertir en una rama en caso de que lo necesitemos.

Carpeta convertida en rama

En la imagen de arriba podemos ver que el icono de Main cambia cuando se convierte en una rama. Las ramas (branches en inglés) nos ofrecen funcionalidades que no están disponibles en las carpetas. Lo podemos ver en el menú contextual:

Menú contextual carpeta
Menú contextual carpeta
Menú contextual rama
Menú contextual rama

Por ejemplo en las ramas podemos ver la jerarquía de las distintas ramas del proyecto (En este caso que sólo trabajamos con dos ramas no parece muy útil :P).

Jerarquía de las ramas

También son distintas las ventanas de propiedades de ambas. Las de una carpeta:

Y las propiedades de una rama, donde podemos ver las relaciones y las ramas que se han creado a partir de ella:

Propiedades de la rama

Todo esto son detallitos, pero quizás lo que mas nos interese de convertir Main en una rama es que nos permitirá ver dónde se ha mergeado qué, como veremos en un próximo post 😛

Un consejo

La carpeta de Projects es buena idea ponerla en la raíz del proyecto de DevOps (al mismo nivel que BuildProcessTemplates y Trunk). Si no se cambia y acabáis trabajando con una rama de dev y la de Main, los check-in de las soluciones y proyectos de Visual Studio se seguirán haciendo en Main (porque la carpeta de proyectos estará ahí). Os ahorrará microinfartos cuando veáis la lista de changesets en el correo de la build de Main 🙂


Y hasta aquí la primera parte del tema. En el próximo post voy a intentar explicar la estrategia de branching que podemos usar en los proyectos y definiciones de build que nos pueden ser útiles.