2024 Wave 1: Business Foundation Layer, modules, facade pattern…➡️➡️➡️

2024 Wave 1: Capa de base empresarial (Business Foundation), módulos, patrón fachada…➡️➡️➡️

En esta nueva versión 24, Wave 1 del 2024 contamos con una nueva extensión denominada «Business Foundation» que contiene objetos referidos a diversos módulos que son la base de negocio y que nos servirán de base para el desarrollo de aplicaciones empresariales.

Origen y algo de historia

En sus versiones iniciales en NAV (1) contábamos con una aplicación monolítica, en la cual desarrollábamos las personalizaciones en el medio de la aplicación base. Entre las personalizaciones hablamos también de los verticales y de las localizaciones.

Posteriormente hubo un cambio importante con la inclusión del concepto de la extensibilidad (2) en el cual agregamos capas de aplicaciones personalizadas que no se mezclan directamente con la aplicación base. Ahora tenemos las extensiones tipo PTE y del Appsource.

Pero, durante este tiempo hemos experimentado algunas complicaciones en este escenario de extensibilidad, como pueden ser:

  • Inexistencia de puntos de conexión adecuados en la aplicación base para atender algunos requerimientos. Hablamos de eventos principalmente, y no podemos negar que Microsoft en cada cambio menor y mayor ha ido escuchando e incrementando la cantidad de estos eventos en diferentes objetos. O también procedimientos públicos que permitan su uso.
  • No todas las funcionalidades han sido diseñadas para extenderse.
  • Diferentes realidades o escenarios (localizaciones) exigen diferentes comportamientos de las extensiones, y algunas veces no se ha tomado en cuenta.
  • Documentación incompleta, desactualizada o inexistente en ciertos puntos de conexión, que exigen en muchos casos una lectura de código para entender como funciona el sistema.
  • Saber todo lo anterior tampoco te aseguraba que un cambio menor o mayor rompa tu extensión.

El cambio efectuado para mitigar estas complicaciones mencionadas es trocear las funcionalidades en pequeños módulos funcionalmente coherentes, más fáciles de probar y mantener.

Módulos

La arquitectura de los módulos trae diversos beneficios, entre los cuales podemos mencionar:

  • Separan funcionalidades coherentes y sus problemas.
  • Tienen APIs estables y bien documentadas expuestas a través de fachadas (patrón).
  • Encapsulan la complejidad y ocultan detalles de implementación.
  • Tienen una superficie de ataque más pequeña, lo que facilita su seguridad.
  • Son más rápidos de compilar.
  • Son más fáciles de monitorear y probar su rendimiento.

Patrón Fachada

Imagen del post: Facade Pattern in Business Central – AL Language (dynamics.com)

El patrón de diseño de fachada funciona como una interfaz frontal que simplifica la interacción con componentes más complejos detrás de una API. Puedes aprender sobre este patrón:

Interfaces

Este tipo de diseño mencionado, con los módulos y el patrón de fachada está abierto a extensiones, pero cerrado a modificaciones. Además, brinda interfaces que no necesariamente tienes que implementarlas.

Puedes aprender sobre interfaces:

Business Foundation

El proceso de separar en módulos las funcionalidades y separarlas desde la aplicación base a otra capa (componentización), requiere el traspaso de información (tablas). Esto significaría marcar como obsoletas muchas tablas y/o campos, siendo un trabajo muy costoso su implementación para todos los involucrados.

Pero ahora, tenemos algunas propiedades que nos ayudan a mover tablas entre aplicaciones y capas sin romper nada.

Lo que permite, contar con una aplicación intermedia entre la base y la de sistema, denominada «Business Foundation» que contendrá los módulos.

Esta aplicación no contendrá localizaciones, las localizaciones se seguirán trabajando a través de las extensiones. Lo que contendrá son módulos en las que se basa un negocio, como las siguientes: gestión de direcciones, de monedas, de series, de dimensiones y otros.

Nuevo Módulo de Nro. de Series

Se ha iniciado el proceso de componentización con el módulo de Nro. de series.

Los objetos nuevos son los siguientes:

Donde vemos, por ejemplo que la tabla 308 «No. Series» de la aplicación base, se ha marcado como obsoleta y se indica que se mueve hacia la extensión de «Business Foundation».

Y en la extensión de «Business Foundation», tenemos la tabla 308 «No. Series», que indica el ID de la extensión de la aplicación base, que es el origen de la tabla.

Un punto a destacar, es que se ha creado una interface la cual podemos extender si deseamos modificar el comportamiento estándar de la gestión de los números de serie.

Dos codeunits han implementado la interface, una denominada «Secuencia» y otra «Normal»

En Business Central, tenemos algunos cambios con la funcionalidad de números de serie, como la aparición de unos botones en la parte superior promovidos, y un factbox con la información de las líneas y las relaciones de la serie.

También vemos el campo, que indica el tipo de implementación (interface) aplicado a cada número de serie.

Refactorización del código para usar el nuevo Módulo de Nro. de Series

Estos cambios mencionados, afectarán los desarrollos donde hemos trabajado con la funcionalidad de números de serie.

Consideración en la migración de versiones anteriores

Por lo tanto, veremos próximamente la aparición de nuevos módulos, y probablemente optimizados con la ayuda de Copilot. Se vienen tiempos nuevos.

Espero que esta información te ayude.


2024 Wave 1: Business Foundation Layer, modules, facade pattern…➡️➡️➡️

In this new version 24, 2024 Wave 1 we have a new extension called «Business Foundation» that contains objects referring to various modules that are the business base and that will serve as a basis for the development of business applications.

Origin and some history

In its initial versions in NAV (1) we had a monolithic application, in which we developed the customizations in the middle of the base application. Among the customizations we also talk about verticals and localizations.

Later there was an important change with the inclusion of the concept of extensibility (2) in which we add layers of custom applications that do not mix directly with the base application. Now we have the PTE and Appsource type extensions.

But, during this time we have experienced some complications in this extensibility scenario, such as:

  • Lack of adequate connection points in the base application to meet some requirements. We are talking about events mainly, and we cannot deny that Microsoft in each minor and major change has been listening and increasing the number of these events in different objects. Or also public procedures that allow its use.
  • Not all features have been designed to be extended.
  • Different realities or scenarios (localizations) require different behaviors of the extensions, and sometimes this has not been taken into account.
  • Incomplete, outdated or non-existent documentation at certain connection points, which in many cases requires reading the code to understand how the system works.
  • Knowing all of the above also did not ensure that a minor or major change would break your extension.

The change made to mitigate these aforementioned complications is to break the functionalities into small functionally coherent modules, easier to test and maintain.

Modules

The architecture of the modules brings various benefits, among which we can mention:

  • They separate coherent functionalities and their problems.
  • They have stable and well-documented APIs exposed through facades (pattern).
  • They encapsulate complexity and hide implementation details.
  • They have a smaller attack surface, making them easier to secure.
  • They are faster to compile.
  • They are easier to monitor and test their performance.

Facade Pattern

Post image: Facade Pattern in Business Central – AL Language (dynamics.com)

The facade design pattern functions as a front-end interface that simplifies interaction with more complex components behind an API. You can learn about this pattern:

Interfaces

This type of design mentioned, with the modules and the façade pattern, is open to extensions, but closed to modifications. Additionally, it provides interfaces that you don’t necessarily have to implement.

You can learn about interfaces:

Business Foundation

The process of separating the functionalities into modules and separating them from the base application to another layer (componentization) requires the transfer of information (tables). This would mean marking many tables and/or fields as obsolete, making its implementation a very expensive job for everyone involved.

But now, we have some properties that help us move tables between applications and layers without breaking anything.

This allows you to have an intermediate application between the base and the system application, called «Business Foundation» that will contain the modules.

This application will not contain localizations, the localizations will continue to be worked through extensions. What it will contain are modules on which a business is based, such as the following: management of addresses, currencies, series, dimensions and others.

New «No. Series» module

The componentization process has begun with the No. Series module.

The new objects are the following:

Where we see, for example, that table 308 «No. Series» of the base application has been marked as obsolete and it is indicated that it is moving towards the «Business Foundation» extension.

And in the «Business Foundation» extension, we have table 308 «No. Series», which indicates the extension ID of the base application, which is the source of the table.

A point to highlight is that an interface has been created which we can extend if we wish to modify the standard behavior of serial number management.

Two codeunits have implemented the interface, one called «Sequence» and the other «Normal»

In Business Central, we have some changes with the serial number functionality, such as the appearance of some promoted buttons at the top, and a factbox with information on the lines and relationships of the series.

We also see the field, which indicates the type of implementation (interface) applied to each serial number.

Code refactoring to use the new «No. Series» module

These mentioned changes will affect the developments where we have worked with the serial number functionality.

Consideration when migrating from previous versions

Therefore, we will soon see the appearance of new modules, and probably optimized with the help of Copilot. New times are coming.

I hope this information helps you.


Más información / More information:

Deja un comentario