PowerShell para la administración automática de Dynamics AX 2012 (PS-II)

En la primera entrega de esta serie sobre PowerShell y DevOps para Microsoft Dynamics AX 2012  hablábamos sobre los principios más básicos de PowerShell y su sintaxis. También vimos en post anteriores como PowerShell se puede usar de formas bastante creativas.

Keyboard

Esta vez vamos a ver los comandlets específicos para la administración de Microsoft Dynamics AX 2012, que podemos separar en varias familias:

Gestión de Modelos y la Model Store

Estos comandlets son muy importantes y van a ser la base de nuestra estrategia DevOps, combinada con los procesos builds automáticos que tendremos configurados en nuestro TFS, si es que los utilizamos.

La combinación de estos componentes va a permitirnos diseñar procesos que actualicen automáticamente nuestros entornos, orientando nuestros procesos hacia la integración o el despliegue continuo de nuestros entornos, especialmente entornos de desarrollo y/o pruebas. Hablaremos sobre esto en los siguientes posts de esta serie.

Estos son los que normalmente utilizamos para estas tareas, aunque vale la pena echar un vistazo a la referencia completa porque todos pueden ser útiles para tareas concretas o para scripts que automaticen tareas más completas:

Modelos

Comando Descripción
New-AXModel  Crea un nuevo modelo en la Model Store
Uninstall-AXModel  Elimina un modelo de la Model Store
Install-AXModel  Importa un modelo (desde un fichero) en la Model Store
Export-AXModel  Exporta un model de la Model Store a un fichero .axmodel
Move-AXModel  Mueve los objetos de un modelo a otro modelo, combinando todos los objetos en este último.

Continue Reading…

Desarrollo en Dynamics AX 7: La nueva arquitectura

Mientras esperamos que se publique la versión definitiva de “El Nuevo” AX o Dynamics AX 7, podemos empezar a comprender las bases del sistema utilizando la información publicada y la Preview pública. Antes de entrar a analizar los detalles de la nueva versión, que son muchos y nos va a llevar bastante tiempo, hay que comprender las bases que han motivado todos esos cambios y que nos van a permitir comprender mejor la nueva forma de desarrollar, que aunque utiliza herramientas parecidas a las versiones anteriores, veremos como son totalmente diferentes.

Model Store vs Local Repository

En versiones anteriores el código y los metadatos se almacenaban en ficheros de capa (AX 2009) y después en bases de datos, ya sea una base de datos dedicada (AX 2012 R2+) o en la propia base de datos de negocio (AX 2012 RTM). Este simple hecho condicionada las herramientas que podíamos utilizar para trabajar con este código y metadatos. Esto es, programar, crear nuevos objetos, hacer pruebas, compilar, etc…

En AX 7 el código se almacena en ficheros en el disco, como en la mayoría de lenguajes modernos, donde tenemos la versión de los ficheros que nosotros estamos modificando. No en ficheros XPO como en ficheros anteriores, sino en un formato nuevo del que hablaremos más adelante, y estos nuevos ficheros pueden abrirse desde Visual Studio utilizando Proyectos y Soluciones propias de este editor para organizar nuestros desarrollos.

Modelos vs Paquetes

Aparte de este cambio en el almacenaje y gestión de los metadatos, en la nueva versión X++ es un lenguaje completo y nativo de la plataforma .NET, y por tanto el compilador y la ejecución son la misma que en los lenguajes .NET. El resultado más evidente de este cambio es que el código compilado (que en la versión anterior se guardaba, también, en base de datos) genera ensamblados (librerías DLL) que se ejecutan en CLR, como el resto de la plataforma .NET.

packages models projects

Continue Reading…

Procesos BUILD automáticos con TFS y AX 2012 (2/2) (ALM-X)

En el artículo anterior de esta serie definimos el proceso principal para configurar una Build de Microsoft Dynamics AX 2012 en TFS, en resumen:

  • Instalar y configurar los componentes de TFS necesarios en el servidor de build (Agente, Controlador, etc.).
  • Crear un nuevo proyecto con las actividades personalizadas y la plantilla por defecto.
  • Subir todo esto al repositorio de código fuente en TFS o Team Services para que el Controlador pueda acceder a ellos.
  • Añadir estas referencias a Visual Studio para que éste reconozca las actividades nuevas.
  • Crear una nueva definición de Build utilizando la plantilla descargada.

Nos quedábamos ejecutando esta definición de Build recién creada con todas las opciones, actividades y plantilla por defecto, y tras todo lo cual recibíamos un error. Frustrante, ¿No? Puede que si, pero si lo pensamos es bastante lógico, veamos:

Una Build no es más que un workflow que ejecuta una serie de pasos en un determinado orden. Este workflow es la Plantilla (template) que nos hemos descargado, un fichero con extensión XAML que, si hemos seguido todos los pasos hasta aquí, podremos incluir en un proyecto o solución de Visual Studio y editarlo desde ahí, y que tiene este aspecto:

SimpleWorkflowTFS2013-Joris

Continue Reading…

Procesos BUILD automáticos con TFS y AX 2012 (1/2) (ALM-IX)

En los post anteriores de esta serie hemos visto cómo configurar un servidor TFS (local o en la nube) y cómo utilizarlo para gestionar nuestras tareas, controlar el código fuente y gestionar versiones mediante ramas, entre otras cosas. Para cerrar el círculo debemos procesar toda esa información, código y versiones en algo que podamos entregar a nuestros clientes/usuarios.

Aquí es donde entran en juego los procesos automáticos de construcción y compilado, llamados procesos Build. Ejecutar una Build en TFS es relativamente sencillo si trabajamos con lenguajes .NET, pero para hacerlo con AX tendremos que trabajar un poco antes para preparar el entorno e instalar los componentes necesarios en los servidores.

Tenemos un resumen bastante bueno de los componentes necesarios a nivel general en el siguiente enlace. Los componentes a instalar dependerá de si utilizamos un TFS local o en la nube.

Primero debemos familiarizarnos con algunos conceptos clave:

  • Build Service: Servicio que acepta peticiones de ejecución de Build.
    • Un servicio está asociado a una colección de proyectos en TFS.
    • Habitualmente sólo necesitamos un servicio por colección de proyectos.
  • Build Controller: Orquesta la Build y delega el trabajo en los Build Agents.
    • Un controlador está asociado a un Build service.
    • Puede que necesitemos varios controladores si tenemos varios entornos preparados para ejecutar Build. En ese caso asignaremos lo agentes a cada controlador para crear diferentes colas de proceso.
  • Build Agent: Servicio que realiza la Build.
    • Un agente se registra en un controlador
    • Debe instalarse en la misma máquina que el AOS que va a ejecutar el proceso
    • Se debe instalar un agente por cada AOS que tengamos procesando Build.

Es posible instalar y ejecutar varios servicios, controladores y agentes, pero para empezar es suficiente con instalar uno de cada. En nuestro caso es necesario que todos estos componentes estén instalados en nuestros servidores, ya que van a requerir utilizar instancias de AX. Pero el código fuente puede estar en una instancia de TFS en la nube sin ningún problema, cada componente puede estar en servidores diferentes, como se muestra en el siguiente esquema:

VSO Build Overview

Continue Reading…

Error: “The database XXX is not recognized as a model store” al copiar una base de datos AX 2012

Hay un error muy común desde la versión AX 2012 R2 que ocurre normalmente al mover o copiar bases de datos de un servidor o de un entorno a otro. Este error (The database XXX is not recognized as a model store) ocurre al iniciar el AOS tras mover las bases de datos y tiene el siguiente aspecto:

Error "The database XXX is not recognized as a model store"

Este error es bastante extraño, porque recordemos que la base de datos modelo (Model Store, base de datos separada que existe desde la versión R2) no puede configurarse en la utilidad de configurador del cliente ni del servidor:

Server Config

Sin embargo, a pesar de esto, esta base de datos sí se configura mediante varios parámetros del AOS que almacenan tanto el nombre de la base de datos como el servidor, y se almacenan en el registro de Windows (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\6.0\XX\NombreConfig).

Registro de windows

Por lo tanto para solucionar este error podemos modificar directamente estos valores en el registro de Windows (es la forma más sencilla), o podemos exportar la configuración del servidor desde la utilidad de configuración, modificar este parámetro en el fichero editándolo directamente con un editor de texto, e importando la configuración de vuelta mediante la utilidad de configuración. Quizás esta última opción es más trabajosa, pero es más fácil de exportar e importar rápidamente en otros servidores.

Microsoft Dynamics AX 2012, servicios web, .NET Interop, cliente-servidor y arquitectura de aplicación

¡Vaya título! ¿Qué tienen que ver todos estos conceptos y por qué debería tenerlos en cuenta? Es posible que no sea una situación que se nos presente todos los días, pero hay veces donde hay que tener todos esos conceptos en cuenta para hacer que un fragmento de X++ funcione correctamente. Este ha sido mi caso: Tengo que consumir un servicio web externo desde Microsoft Dynamics AX 2012. Parece fácil, ¿no?. El servicio web se va a consumir en un proceso por lotes (servidor), pero también debe poder llamarse manualmente desde formularios (cliente).

En Microsoft Dynamics AX 2009, para utilizar un servicio debíamos añadir una referencia de servicio al AOT. En la versión 2012 creamos un proyecto Visual Studio de tipo Librería de clases. En ese proyecto de Visual Studio agregamos una referencia de servicio y agregamos el proyecto al AOT. No voy a entrar en detalle sobre ésto porque esta bien explicado por ejemplo en este white paper.

Una de las cosas a tener en cuenta acerca de los conceptos del título de este post está en las propiedades del proyecto en Visual Studio:

Propiedades Proyecto Visual Studio

Lo relevante aquí es marcar Deploy to Client si queremos que la DLL se despliegue a los clientes y Deploy to Server si queremos que se despliegue al servidor. De esta manera, el sistema copiará la librería cuando sea necesario a la carpeta correspondiente, descargándola de la base de datos (de la Model Store) donde está almacenada. Dependiendo de cómo se ejecute el código X++ que utiliza esta librería podemos marcar uno u otro o los dos.

Continue Reading…