Trabajando con la máquina virtual de desarrollo local en Dynamics 365 for Operations

No voy a escribir una entrada sobre cómo configurar una MV local de Dynamics 365 for Operations para desarrollo, porque ya se han publicado muchísimas desde el lanzamiento del producto hace unos meses. También está publicado en la documentación oficial de forma bastante clara, así que sería repetir lo que ya se ha explicado mil veces.

Lo más importante es configurar bien la conexión con el proyecto de Visual Studio Team Services y con la rama que estemos utilizando, mapeando de forma acorde las carpetas locales. Por ejemplo:

  • La carpeta Metadata debe apuntar a donde están almacenados los paquetes de Dynamics 365 en el disco. Dependiendo de la versión de la máquina virtual pueden estar en C:\AOSService\PackagesLocalDirectory o en C:\Packages (en las versiones antiguas).
  • La carpeta Projects normalmente se configura en la carpeta por defecto donde Visual Studio almacena los proyectos (en Mis Documentos), pero esto dependerá de la estructura que siga cada equipo para almacenar los proyectos que, recordemos, no forman parte de los metadatos de AX en esta versión, como sí hacían los proyectos del AOT de versiones anteriores.

También hay una serie de propiedades que se pueden modificar para que la máquina se comporte de una forma más natural para un desarrollador de AX e incluso para mejorar un poco el rendimiento.

Siguiendo con nuestra cadena respecto a la introducción al desarrollo para Dynamics 365 for Operations, voy a comentar algunos escenarios que suceden mucho y parecen ser problemáticos para programadores que empiezan a utilizar las nuevas herramientas. Pequeños detalles que conviene no olvidar. Es posible que actualice este post en el futuro para tenerlos todos localizados:

Continue Reading…

Internet of Fun – Demostrando el concepto IoT

big-bang-t3e23-jaestevan

En un artículo anterior, hacía una introducción del concepto de Internet of Things (IoT, Internet de las Cosas) y por qué iba a ser relevante en el futuro en multitud de procesos empresariales, procesos que inevitablemente van a llegar al mundo del ERP en mayor o menor medida.

Uno de los factores que, en mi opinión, van a hacer que estas prácticas se disparen en un futuro cercano es su accesibilidad. La facilidad de desarrollarlos y el bajo coste con el que se puede empezar a hacer cosas útiles y de eso estamos hablando, ¿Verdad?… de cosas 🙂

En la demostración que empieza con este post vamos a crear un ejemplo funcional sencillo para comprobar las posibilidades de las que disponemos en cada caso, y comprobar lo sencillo que puede ser investigar y crear prototipos que luego podremos convertir en sistemas reales. Utilizaremos materiales de bajo coste para hacer pruebas, que luego podremos convertir en sistemas reales con material industrial equivalente.

Este artículo contará por lo menos con tres partes (puede que más, si el tema interesa) teniendo en cuenta los que para mi son los tres boques de estas técnicas: Sistemas que van a generar la información (las “cosas” del IoT), los consumidores que harán uso de esta información, y los canales que nos permitirán capturar, almacenar y procesar la información generada.

grafico-iot-jaestevan

Continue Reading…

Control de versiones en Microsoft Dynamics AX 2012 mediante ramas de Team Foundation Server (ALM-VII)

En capítulos anteriores hablamos sobre cómo instalar y configurar Team Foundation Server, así como las posibilidades que ofrece para gestionar tareas y administrar el código fuente desde nuestra instancia de Microsoft Dynamics AX 2012. Comentamos las funciones básicas ,aunque imprescindibles, para proteger y desproteger el código en el servidor y las ventajas que ello suponía en cuanto a almacenar todo el histórico de cambios de los objetos, como por ejemplo: revisar el historial de cambios de un objeto, volver a una versión anterior, descartar cambios sin confirmar, etc.

Sin embargo hay ciertos problemas que una gestión básica del código fuente no es capaz de solucionar. Por ejemplo, en una instalación normal de nuestro ERP, a la vez que damos el soporte diario y realizamos pequeñas modificaciones para solucionar problemas, estamos llevando a cabo desarrollos de mayor o menor impacto. Estos desarrollos paralelos necesitan ser integrados en el código de producción de alguna forma, pero si usamos el mismo servidor para desarrollar y para hacer el mantenimiento, tendremos que llegar a un punto en el que todos los desarrollos estén totalmente terminados para pasar a producción de forma limpia y segura.

De la misma forma, si nuestra empresa desarrolla un producto final, es necesario avanzar el desarrollo de las siguientes versiones mientras damos soporte a las versiones publicadas en el pasado, incluso para diferentes versiones de AX. ¿Cómo estar seguro que un hotfix urgente desarrollado para un cliente llega a todas las versiones de nuestro producto que la necesitan, de forma limpia y estable?

Visual Studio loves Dynamics AX 2012

Por supuesto hace falta un buen método de trabajo para que todo esto pueda realizarse de forma ordenada y sin errores, pero también hace falta la ayuda de alguna herramienta y para eso tenemos las ramas (Branches) disponibles en casi todos los sistemas de control de versiones del mercado, y por supuesto en nuestro Team Foundation Server.

Estrategias de branching

Existen infinidad de estrategias para definir las ramas que necesitamos en nuestros equipos, y ello va a depender de la cantidad de equipos que tengamos, la cantidad de productos, de versiones, etc. NO HAY una estrategia de ramas estándar o válida para todos y es algo que se debe pensar con cuidado ya que la estrategia elegida nos va a suponer ventajas e inconvenientes. Lo más recomendable es empezar por la lectura de la guía Version Control Guide escrita por el grupo Visual Studio ALM Rangers donde explican la mayoría de opciones con sus pros y sus contras.

Continue Reading…

Control del código fuente con TFS en Microsoft Dynamics AX 2012 (ALM-VI)

En anteriores capítulos de esta serie ya hablamos de cómo instalar y/o configurar nuestra instancia de Microsoft Team Foundation Server, y también sobre cómo usarlo para gestionar nuestras tareas y requerimientos. Este artículo es la última parte acerca de la funcionalidad básica de la integración entre Microsoft Dynamics AX 2012 y TFS, para poder empezar en los siguientes post con temas más avanzados.

En este artículo veremos como trabajar con TFS para la gestión de versiones del código fuente (VCS), que es el primer paso para poder utilizar las funcionalidades más avanzadas del sistema en cuanto a sus capacidades de ALM. Básicamente, el control de versiones pretende que cualquier cambio realizado sobre los objetos del sistema quede registrado, así como la fecha, el autor de dichos cambios, qué otros objetos se modificaron a la vez y por qué (mediante los comentarios en durante el check-in).

Esto nos permite revertir los cambios, volver a una versión anterior, comparar el estado actual de un objeto con una versión anterior, revisar los cambios realizados un determinado día por un desarrollador (para realizar revisiones de código), asociar los cambios a una determinada tarea para ver todos los cambios que ha requerido finalizarla, y un largo etcétera.

Las tres operaciones más evidentes que requiere cualquier control de versiones son: añadir nuevos objetos, check-in y check-out (traducidas en AX como Proteger y Desproteger respectivamente) y Sincronizar.

Agregar nuevos objetos

En Microsoft Dynamics AX no se añade todo el código al gestor de código fuente, al contrario que en otros VCS. No tendría sentido añadir todos los objetos que forman parte de la aplicación estándar ya que esto supondría un desperdicio notable de recursos. Por eso, sólo se añaden los objetos nuevos o aquellos objetos estándar que se han modificado, suponiendo que si un objeto no está controlado por el control de versiones es que es un objeto estándar que nunca ha sido modificado. En resumen, se añaden todos los objetos que no forman parte de las capas o modelos del sistema.

Para añadir un objeto al gestor de código fuente, TFS en este caso, se hace botón derecho sobre el mismo y Añadir al control de versión. Es importante recordar esta operación ya que no se realiza automáticamente. Si un objeto no se agrega al control de código, provocará errores e incoherencias cuando otros desarrolladores sincronicen nuestros cambios y no obtengan todos los objetos, por lo que es muy importante hacer de esta tarea un hábito y añadir los objetos a TFS cuanto antes, a ser posible justo después de crearlos, para no olvidarlo.

AX2012 vs TFS - Añadir a control de versión

Como se puede ver en la imagen anterior, los proyectos de MorphX también se consideran objetos y, por tanto, hay que agregarlos manualmente. No es recomendable añadir proyectos privados al control de versiones. En cualquier caso, dejarían de ser privados en TFS, donde se almacenarían como un objeto más.

Continue Reading…

HOWTO: Depurar desde Visual Studio código X++ que se ejecuta en el servidor AX 2012

Gran parte del código X++ que desarrollamos en clases se ejecuta en la capa del servidor (Data Providers en informes, procesos Batch, SysOperation, …), lo que resulta un poco incómodo a la hora de depurar. Si ponemos un breakpoint desde el editor de X++ en MorphX en código que se ejecuta en el servidor, veremos como el depurador integrado nunca se detiene en este punto.

Preparar el entorno de desarrollo para poder depurar código del servidor desde Visual Studio (incluso el código X++, que en el servidor siempre se ejecuta como código CIL) nos obliga a tener en cuenta unos cuantos pre-requisitos, así que los voy a enumerar aquí para tenerlos a mano cuando nos hagan falta:

Pre-requisitos y consideraciones previas:

  • Asegurarse de que el código CIL se ha ejecutado completamente y sin errores. De otra forma, el ensamblado que queremos depurar puede no estar disponible en su última versión, sino en la última que se compiló sin errores.
  • Para depurar código remoto, ejecutar Visual Studio siempre como Administrador (con permisos elevados, haciendo click-derecho > Ejecutar como administrador). Si no, más adelante tendremos problemas de permisos.
  • La depuración remota desde Visual Studio debe hacerse en el mismo servidor donde está instalado el AOS, lo que nos obliga indirectamente a utilizar un entorno de desarrollo, ya que esta no es la configuración ideal para un AOS en producción.
  • En la configuración del AOS debe estar activada la opción Enable breakpoints to debug X++ code runing on this server (esto tampoco es nada recomendable en un AOS en producción).
  • Asociar un proceso al AOS para depurar pone el servidor en un estado extremadamente inestable, con un riesgo muy importante de que el servicio se reinicie inesperadamente. Por tanto es muy recomendable utilizar un servidor de desarrollo aislado para no molestar al resto de desarrolladores. Si utilizamos un sólo AOS para todos los desarrolladores, puede ser interesante tener otro AOS para la depuración remota.

Iniciar la depuración remota:

  • Iniciar Visual Studio en el servidor y con permisos elevados.
  • Si no se está mostrando ya, mostrar el Application Explorer (desde el menú Ver), lo que nos muestra el AOS en VS.

Continue Reading…

Leer elementos de Team Foundation Server desde Microsoft Dynamics AX 2012 (ALM-V)

Vuelvo brevemente sobre una de mis series de post mas largas hasta la fecha, lo referente a la integración de AX 2012 con Team Foundation Server, no sólo para la gestión del código fuente, sino también como herramienta de gestión del trabajo del equipo. En capítulos anteriores ya vimos cómo se instala y configura TFS (esto cambia entre versiones, también vimos que no necesitamos instalar nada si utilizamos la versión en la nube) y cómo podíamos crear elementos de trabajo en TFS (WorkItems) para gestionar el trabajo desde esta herramienta.

Al hacer un check-in de código desde Microsoft Dynamics AX 2012 se nos plantea la posibilidad de asociar ese check-in a algunos elementos de trabajo de TFS. Esto es casi obligatorio para poder llevar un buen control de para qué se realiza cada cambio, pero la herramienta que nos ofrece AX es bastante limitada. Sin embargo, gracias al API de TFS, podemos ampliarla e incluso desarrollar nuestras propias herramientas e informes en AX 2012 obteniendo datos del servidor de TFS (sí, también desde Visual Studio Online).

Una funcionalidad muy interesante para ahorrarnos tiempo de desarrollo es poder ejecutar desde AX 2012 consultas que están guardadas y utilizamos en TFS. Esto nos permite tener las mismas vistas de datos en los dos entornos, lo que facilita el trabajo. Profundizaré sobre esto en los siguientes post sobre este tema, pero ahí va un código de ejemplo para realizar esta tarea.

NOTA: Para que estos ejemplos funcionen, es necesario tener instalado el SDK de Visual Studio de la versión de TFS que estemos utilizando. En mi caso es el SDK de la versión 2013 porque estoy utilizando Visual Studio Online, pero esto puede variar en cada instalación. Se puede descargar del siguiente enlace:

Después de instalar el SDK, hay que añadir las referencias necesarias al AOT para que AX 2012 pueda utilizarlas:

Add references to AOT

Ahora si, el código:

Continue Reading…