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.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations con ChannelFactory

Si alguna vez necesitas consumir un servicio SOAP desde Dynamics 365 for Finance and Operations, lo primero que tienes que hacer es pedir a los responsables de ese servicio que creen una versión REST. Si eso no es posible, este post es para ti.

Voy a usar este web service que encontré por ahí en http://www.dneonline.com/calculator.asmx para el ejemplo, es una calculadora con las 4 operaciones básicas de suma, resta, división y multiplicación.

Consumir un servicio SOAP en .NET

Empecemos por lo más básico. ¿Cómo consumimos un servicio SOAP en Visual Studio? Muy fácil. Sólo hay que añadir una referencia de servicio en tu proyecto:

Apuntar al servicio web de tu elección:

Esto va a crear la referencia en Visual Studio:

Una vez hecho esto podemos crear una instancia del cliente del servicio y llamar a sus métodos:

3 + 6 = 9, parece que funciona.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations

Para consumir un servicio web en FnO crea un nuevo proyecto, haz click derecho en referencias y añade la referencia de servicio:

Emmm… no, no se puede, no hay referencias de servicio.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (espero…)

El problema es que en las máquinas de desarrollo de 365 no podemos añadir las referencias de servicio en Visual Studio.

¿Qué dice la documentación sobre esto? Bueno, igual que en AX2012 necesitamos crear una clase en .NET que consumira el servicio web y a través de la que accederemos a él desde 365. Muy bien!

Ya lo tenemos. Una referencia a nuestra librería y una runnable class que hará el trabajo:

A ejecutarlo:

¿Qué?

An exception of type ‘System.InvalidOperationException’ occurred in System.ServiceModel.dll but was not handled in user code

Additional information: Could not find default endpoint element that references contract ‘AASSOAPCalculatorService.CalculatorSoap’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

¿Contrato? ¿Qué contrato? No sé nada de un contrato. Nadie me ha dicho nada de un contrato! ¿Qué dice la Wikipedia del SOAP?

Soap is the term for a salt of a fatty acid or for a variety of cleansing and lubricating products produced from such a substance.

Creo que no es ese el SOAP que buscaba… (en inglés era más gracioso 🙁 )

SOAP provides the Messaging Protocol layer of a web services protocol stack for web services. It is an XML-based protocol consisting of three parts:

  • an envelope, which defines the message structure and how to process it

  • a set of encoding rules for expressing instances of application-defined datatypes

  • a convention for representing procedure calls and responses

El sobre es el contrato. Un contrato de datos es un acuerdo entre un servicio y un cliente que descibe qué datos se van a intercambiar. Ese contrato.

Consumir un servicio SOAP en Dynamics 365 for Finance and Operations (esta es la buena)

Si vemos el proyecto que hemos creado para consumir el servicio hay un archivo que se llama app.config:

En este archivo tenemos el endpoint que usa la DLL. Este valor es fijo, y en caso de que tengamos un endpoint de pruebas y uno de producción tendríamos que crear una librería para cada uno de ellos. También vemos el contrato que usa, AASSOAPCalculatorService.CalculatorSoap. Como #MSDyn365FO es un ERP basado en web podríamos solucionar esto añadiendo el nodo de  system.serviceModel en el web.config del servidor, no? (app.config para apps de escritorui, web.config para apps web). Sí, pero sólo podríamos hacerlo en desarrollo porque en producción no tenemos acceso al servidor, y en cuanto los entornos Tier2+ se migren a self-service será imposible ahí también.

¿Qué hacemos entonces? Fácil, ChannelFactory<T> al rescate.! ChannelFactory<T> nos permite crear una instancia de la factory para nuestro contrato del servicio y después crear un canal entre el cliente y el servicio. El cliente sería nuestra clase en D365and y el servicio el endpoint (obviamente).

Hacemos lo siguiente:

El objeto BasicHttpBinding puede ser un BasicHttpsBinding si el servicio web corre sobre HTTPS. El objeto EndpointAddress es la URL del servicio. Instanciamos un contrato del servicio de nuestra clase con el binding y el endpoint y creamos el canal. Ahora podemos llamar al servicio web y sus métodos y…

Funciona! Y lo que es mejor, si hay distintos endpoints con este método podemos parametrizarlos y solo necesitamos una DLL para todos los endpoints!

Pero de verdad, evitad los servicios SOAP, tiremos todos de REST.

¿Cómo ser un mejor desarrollador de X++?

He sido programador de X++ casi 10 años, eso es el 100% de mi vida profesional, sin contar becas. Durante estos 10 años he visto el producto evolucionar, y, en mi opinión, los últimos tres años con #MSDyn365FO han sido los mejores de lejos como he dicho otras veces.

El cambio de un IDE tipo bloc de notas como era MorphX a Visual Studio, poder usar Azure DevOps y las tasks de subida a LCS y despliegue me hacen sentir más como un desarrollador. Y esto es solo el principio del viaje, ahora estamos empezando con el testing automatizado, con RSAT y el ATL, ahora sí que sí vamos a hacer testeo!

Y cómo podemos mejorar como desarrolladores de X++?

Lleva tiempo

Como aprender cualquier cosa. No sabes nada el primer día, aprendes sobre la marcha a base de trabajar y hacer cosas, y con el tiempo te das cuenta de que el ERP es enorme y sólo conoces una parte pequeña. Pasará más tiempo y seguirás conociendo sólo una parte de Operations.

Ama tu trabajo

Esto puede ser jodido a veces… lo que hagas hazlo con pasión. Busca una empresa que te haga crecer, intenta divertirte en el trabajo. Será difícil, sobretodo en pleno arranque, pero incluso entonces habrá momento para las risas. El resto es más fácil si te lo tomas así.

Conocimiento funcional

Obviamente los desarrolladores necesitamos saber como funcionan los procesos desde el punto de vista funcional. En caso de duda pregunta a un compañero funcional, no pierdas el tiempo buscando por el código intentando entender la funcionalidad. Después de la explicación funcional ver el código estará más claro, seguro.

Siempre he pensado que programar en X++ es bastante fácil, lo difícil es conocer todos los procesos.

Aprende otros lenguajes

Sal de X++. Trabajar (o probar) otro lenguaje de programación puede ayudar a quitarnos algunos vicios de trabajar con AX.

Los programadores suelen conocer más de un lenguaje de programación, de otros trabajo o proyectos personales. C# es una buena opción porque podemos usar librerías de .NET en X++ o podemos crear las nuestras. Aprende la sintaxis (fácil), prueba los foreach (me encantaría tenerlo en X++), LINQ, etc.

Hace un tiempo pensaba que, en algún momento del futuro, susituirían X++ por .NET/C#, así que aprenderlo era una buena idea. Viendo las últimas novedades de X++ como el SysDA o ATL tengo algunas dudas a medio plazo. Además la capa de acceso a datos de X++ es maravillosa.

Explora Azure

Incluyendo DevOps. Por suerte no usarlo es imposible. Pero no lo uses solo como herramienta de control de código, es muuuuuucho más que eso.

Explora Azure, hay muchos recursos y la solucón a un problema puede estar ahí. Azure functions, Logic apps, Azure SQL, Service bus (combinado con Business events por ejemplo). AX ya no está solo, 365 viene con un montón de amigos en la nube.

Power Platform

Después del último MBAS, ha quedado clarísimo que Microsoft está invirtiendo mucho en la PowerPlatform. Flow, PowerApps, AI Builder… Todos estos productos se pueden integrar con MSDyn365FO.

Podemos sustituir un espacio móvil con una PowerApp que seguro que será más flexible, Flow para mandar correos que se lancen por un Business Event o una operación CRUD.

Aprende algo sobre CRM y CDS, seguro que en algun proyecto va a tocar integrarlo con FnO.

Comparte y enseña

Para mi enseñar es terriblemente difícil, soy un profesor horroroso, las cosas en mi cabeza están muy claras pero se pierden por el camino a la boca. Me cuesta a veces materializar esas ideas en palabras. Escribir me ayuda a ordenar las ideas, porque puedo escribir, borrar, escribir y volver a borrar una y otra vez 🙂

Comparte tu conocimiento, da formación interna con tus compañeros, hazte speaker. Nunca pensé en nada de esto hasta que empecé a trabajar en Axazure, y cuando me dijeron si quería dar una charla en el Dynamics 365 Saturday lo primero que pensé fue «¿Yo? ¿Qué puedo contar que le interese a alguien?». Al final lo único que necesitas es escoger o inventarte un tema del que sepas algo (o nada) y expandir los conocimientos, o tener ideas tontas y llevarlas a cabo!

Y nada más. Esto son sólo algunas ideas, hay muchas cosas que se pueden hacer para mejorar, pero creo que lo más importante es tener paciencia. Y el tiempo. Tiempo y paciencia.