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

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.

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.

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.

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:

Libro: Desarrollo en Microsoft Dynamics AX 2012

Estoy muy ilusionado de poder anunciar el proyecto en el que he estado trabajando este último año, causa principal (probablemente no la única) de que haya publicado con menor intensidad en el blog. Se puede adquirir ya mismo el libro “Desarrollo en Microsoft Dynamics AX 2012“, publicado por Krasis Press en su “colección de las frutas” 🙂

PORTADA Desarrollo en Microsoft Dynamics AX 2012

Es el único libro del mercado escrito en castellano sobre desarrollo en Dynamics AX en general, y también lógicamente sobre desarrollo en AX 2012. Además, está actualizado con las novedades de la reciente versión AX 2012 R3.

Está escrito de manera didáctica y progresiva, de manera que sirve tanto como manual para aprender a desarrollar en Microsoft Dynamics AX, así como de manual de consulta o material de referencia para desarrolladores con experiencia, para buscar algún aspecto concreto utilizando el índice (muy detallado) y el glosario de términos. El índice, el glosario y los dos primeros capítulos se pueden descargar  GRATIS desde la página de compra, además del prólogo que debo agradecer a Salina Marí, de Microsoft.

Se puede adquirir en versión impresa (gastos de envío incluidos en el precio!!) y también en formato electrónico para leer en cualquier dispositivo, en cuyo caso se descarga inmediatamente tras la compra. Esta última quizás sea la mejor opción para los amigos de latinoamérica, que me consta son muchos y fieles 😀

Se puede comprar en los siguientes enlaces:

Si lo has comprado, estaré muy agradecido de recibir cualquier comentario al respecto por cualquiera de las vias habituales (twitter, linkedin, comentarios del blog, etc.) o bien en portales específicos como:

Si tienes dudas sobre el contenido descarga GRATIS los primeros capítulos en la página de compra.  Recuerda, es el único libro sobre desarrollo en AX 2012 en español. Espero sinceramente que puedas adquirirlo, que el contenido te permita mejorar y aprender, y que después me cuentes tu opinión para seguir mejorando.