Ventajas y Desventajas de la programación AL. Por Fernando Álvarez
✅ Ventajas AL frente a CSIDE:
Microsoft ha decidido que, con Business Central, quiere que su nuevo entorno de trabajo sea más directo y simple. Para ello está transformando los entornos clásicos de NAV, como el de desarrollo y cliente, en unos entornos más modernos como la WEB y Visual Studio (su centro de desarrollo). Con esto pretende que desde un único entorno se puedan realizar todos los procesos y de una manera más globalizada.
CSIDE como tal desaparece y se torna en un lenguaje C/AL más cercano al conocido .NET – Volvemos a los orígenes de la programación-.
Desaparece la estructura clásica de objetos como Tablas, paginas, codeunit…, para unirlo todo en simples ficheros “.al” con nomenclaturas para diferenciarlos.
Como todo, esto lleva un proceso previo de remodelación. ¿Que nos ayuda en este proceso?, los eventos, que pretenden unificar nuestros desarrollos en un único objeto para facilitar su futuro proceso de adaptación a una nueva versión de NAV o mejor dicho, Business Central.
Es aquí donde AL obtiene su mayor fuerza. Pese a las futuras actualizaciones de Microsoft, el tener nuestras personalizaciones en una “extensión” o APP, podemos transmitirla a los futuros entornos del cliente sin ningún tipo de desarrollo previo de adaptación. Con decirle a nuestra APP que apunte a esta nueva versión bastaría. ¿Dónde lo hacemos? En los archivos “.json” que se encuentran dentro de nuestro proyecto.
Al no tener ya el entorno de CSIDE, no tendremos que crear campos, añadir el código desarrollado o crear esas diferentes acciones a nuestros formularios. Con AL, al no tocar los objetos estándar, puesto que los nuevos desarrollos son extensiones del estándar, no habrá problema de compatibilidad con las futuras versiones de Business Central.
AL se desarrollará únicamente en Visual Studio Code. Este entorno nos permite acercarnos más a una nomenclatura más común con el resto de los lenguajes de programación. Muy diferenciada hasta ahora con C/AL.
Las posibilidades que nos ofrece este entorno son muy grandes ya que nos permite desarrollar e implementar funcionalidades de la comunidad de NAV, para ayudar a nuestra programación, con aplicaciones que complementan y ayudan a que nos sea más fácil o nos permite ahorrar más tiempo.
Incluso sin acceder a esta comunidad online, el propio entorno tiene herramientas de personalización llamadas snippets que nos ahorran mucho tiempo. Como por ejemplo la traducción de nuestras nuevas tablas o formularios, en la que con una sentencia le diremos que nos complete estos caption con sus traducciones. O asignarle propiedades definidas anteriormente en estas llamadas.
A continuación, os meustro un ejemplo de símil del trigger de Documentación de C/SIDE desarrollado en AL, en el que con la sentencia ‘tDocumentation’, ya nos agregaría todo ese espacio en nuestro fichero .al. Una forma de ahorrarnos la tarea de tener que escribirlo todo cada vez que queramos añadir comentarios a nuestra extensión.
¿Desde donde creamos estos snippets? fácil…., desde nuestro proyecto, pulsamos F1 para abrir el explorador de VS, y con escribir la palabra snippets ya se nos abrirán diferentes opciones. La que nos interesa para empezar a crear uno es “Preferences: Configure User Snippets”, que nos permitirá crear un snippet para nuestro proyecto actual o para todo el entorno. Las posibilidades son infinitas, se puede crear un atajo de cualquier código de NAV.
Esto es un gran avance para desarrollar más rápido en un futuro.
A pesar de todo lo comentado, hay ciertas cuestiones que generan «desventajas» . Las comento a continuación…
❌ Desventajas de AL:
AL cambia el concepto de implementación y desarrollo como lo conocíamos hasta ahora en NAV. Nos encontramos con un entrono nuevo de trabajo muy potente, pero aún, falta mucho por pulir en esta nueva forma de trabajar.
El concepto de un único estándar para todos, sin modificaciones, a excepción de las extensiones, tiene algunos problemas como son los eventos. Hay ausencia de muchos de ellos en nuestro código y no siempre la funcionalidad es la correcto. Aunque bien, cabe destacar, que hay un portal, en el que puedes reclamar la creación de un evento en una parte concreta del código, y Microsoft lo implementará en futuras actualizaciones como son los CU.
Otro problema con el que nos encontramos es la revisión de nuestras Apps en los clientes OnCloud una vez que Microsoft lanza una actualización. Microsoft nos manda un aviso para que revisemos nuestra extensión en un periodo de 90 días. En ese periodo de tiempo, debemos adaptarla para que no sea eliminada por parte de Microsoft y nuestro cliente no pierda esa funcionalidad.
Este problema enlaza con otro futuro. En C/SIDE al tener el entorno de desarrollo, teníamos acceso a todos los desarrollos implementados, ya sea por nosotros mismos, por otros partners o el propio cliente. Pero esto con AL y la desaparición de este entorno cambia.
Al ser extensiones (Apps) instaladas sobre la base de datos directamente, no tendríamos acceso a aquellas desarrolladas externamente. Por lo que a la hora de que existan errores o problemas de compatibilidad, puede que no podamos revisarlas o evitar la eliminación de estas visto anteriormente.
AL nos ahorrará tiempo de cara a futuro, agilizando el desarrollo de código. Una vez que tienes todo configurado empezar a programar es igual que antes. Pero esta configuración previa es la que nos ha dado problemas en diferentes equipos para dejar todo listo y no tener problemas de publicar a la base de datos destino.
Ya sea por las diferentes versiones de VS, de NAV o de las propias extensiones dentro del entorno, así como sus parámetros, no siempre es una tarea fácil empezar a programar con AL. Incluso nos puede llevar mas tiempo que la propia programación.
Migraciones del entorno de programación AL
En este punto hay ventajas y desventajas. Con las versiones anteriores teníamos la suficiente información a la hora de actualizar las versiones de datos de nuestros cliente. Con AL la información es escasa.
La idea que tiene Microsoft es que las migraciones a futuras versiones de Business Central sea ágil y rápida, ¿Cómo? con un estándar sin tocar y unas Apps propias que se instalarán como si fueran un programa en nuestro ordenador o una App en el nuestro teléfono móvil.
Esto suena muy bien aunque cuando tenemos el caso de un cliente en una versión antigua como puede ser la 2009, el trabajo que nos supone transformar todo el entorno antiguo a esta nueva forma es bastante extenso. Un tramite que habrá que sobrepasar sí o sí, pero que nos puede dar mas de un dolor de cabeza.
Me parece importante destacar una herramienta que me parece muy útil y de mucha ayuda en nuestros nuevos desarrollos, ya que nos permite controlar los cambios hechos en nuestros ficheros para llevar un seguimiento o para revertir estos mismos. Con implementaciones grandes nos puede ahorrar muchos «descalabros» por no saber que se ha tocado y que no.
Esta herramienta se llama Git Lens. La podemos encontrar en el market de VS.
Requerirá también la instalación del programa Git Bash en nuestro equipo. Una vez lo tengamos, cada desarrollo y cambio que realicemos se irá registrando a través de esta aplicación, dándonos el control de revisar o revertir estos mismos, los cambios se nos avisaran a la izquierda de VS:
Con los llamados commits podemos grabar cada cambio y acceder a ellos posteriormente. El aspecto de estos es parecido al ya conocido Beyond Compare.WEB
Por último, me gustaría destacar la importancia y el protagonismo que adquiere el entorno web, ya que será el único cliente en un futuro con el que el usuario podrá operar. Microsoft esta avanzando mucho en este entorno, añadiendo nuevas personalizaciones en nuestros formularios, acceso a la información de los registros, añadir accesos directos a los departamentos en la pantalla de inicio y una exploración más rápida por las diferentes pantallas.
Como estos, otros cambios se irán añadiendo poco a poco.