Cómo implementar una infraestructura de impresión extensible siguiendo el patrón utilizado por Microsoft en Business Central
Introducción
Cuando desarrollamos una nueva
funcionalidad en Business Central es habitual centrarnos en la lógica de
negocio, las páginas o los procesos de registro. Sin embargo, tarde o temprano
aparece una necesidad que parece trivial: imprimir un documento.
La solución rápida suele ser llamar
directamente a un informe mediante Report.RunModal(). Funciona, es sencilla y permite seguir avanzando.
Pero esa solución introduce un problema
que normalmente no detectamos hasta mucho más adelante: el proceso de negocio
queda acoplado al informe que hemos desarrollado.
En otras palabras, el código decide qué
informe debe ejecutarse.
Microsoft lleva años resolviendo este
problema mediante la infraestructura de Report Selections, permitiendo
que sea la configuración del sistema la que determine qué informe ejecutar para
cada proceso de negocio.
Es el mismo mecanismo utilizado para
documentos de venta, compra, almacén, servicio y muchas otras áreas de Business
Central.
En este artículo vamos a implementar una
nueva categoría de Report Selection siguiendo exactamente el patrón
utilizado por Microsoft, utilizando como ejemplo la nueva categoría de
impresión incorporada para Statistical Accounts dentro del proyecto BC
Scout Path.
El objetivo no es únicamente aprender a añadir una nueva categoría de impresión, sino entender la arquitectura que hay detrás para poder reutilizar este mismo patrón en cualquier desarrollo futuro.
Recuerda que tienes todo el código disponible en tu repositorio de confianza!
https://github.com/fernandoartalf/BC-Scout-Path
El Problema de los informes hardcodeados
Todos hemos escrito alguna vez algo
parecido a esto:
Report.RunModal(Report::"Mi
Informe", true, false, Rec);
Aparentemente no hay nada malo.
Sin embargo, esta aproximación presenta
varios inconvenientes importantes:
·
El informe queda fijado para siempre.
·
El cliente no puede sustituirlo por otro informe
personalizado.
·
No es posible ejecutar varios informes para un
mismo proceso.
·
Cualquier cambio requiere modificar el código.
·
Se rompe la filosofía de configuración de Business
Central.
La impresión pasa a formar parte de la
lógica de negocio cuando realmente debería ser únicamente una decisión de
configuración.
La filosofía de Microsoft
Si
observamos cualquier documento estándar veremos que Microsoft nunca ejecuta
directamente un informe concreto.
En su lugar,
toda la lógica pasa por una capa intermedia denominada Report Selections.
El proceso real
es mucho más parecido a esto:
El proceso de negocio únicamente conoce una categoría de impresión.
La
infraestructura de Report Selections es la encargada de resolver qué informe
debe ejecutarse.
Gracias a esta
separación conseguimos que el mismo proceso pueda utilizar informes
completamente diferentes dependiendo de la configuración del cliente.
Y lo mejor de todo es que el código nunca necesita modificarse.
Report Selection como patrón de diseño
Aunque Microsoft nunca lo presenta
explícitamente como un patrón de diseño, Report Selection implementa una
variante muy clara del patrón Strategy.
En lugar de que el código decida qué
informe ejecutar, delega esa responsabilidad en una estrategia configurable.
La lógica de negocio permanece completamente desacoplada de la implementación del documento.
Este pequeño cambio tiene un impacto
enorme en la mantenibilidad del proyecto.
Arquitectura de nuestra solución
La implementación sigue exactamente la
misma arquitectura utilizada por Microsoft.
Cada objeto tiene una única
responsabilidad.
·
La Enum identifica la nueva categoría.
·
La página
permite configurarla.
·
La tabla almacena la configuración.
·
El Management Codeunit resuelve el informe.
·
La lógica de negocio únicamente solicita la
impresión.
Esta separación hace que cada componente
pueda evolucionar de forma independiente.
Paso 1. Crear una nueva categoría de Report Selection
Todo comienza ampliando la enum Report
Selection Usage.
Esta enum representa todas las categorías
conocidas por Business Central y actúa como identificador dentro de la tabla Report
Selections.
Nuestra implementación añade una nueva
categoría destinada al estado de cuentas de los Statistical Accounts.
El aspecto importante aquí no es la enum
en sí.
Lo realmente importante es comprender que
Business Central nunca trabaja directamente con un Report ID.
Siempre trabaja con un Usage.
Ese Usage será el que posteriormente
permita configurar uno o varios informes.
Paso 2. Crear una página de configuración
Una vez creada la nueva categoría
necesitamos ofrecer una página para que el administrador pueda configurar qué
informes pertenecen a dicha categoría.
La página está basada directamente sobre
la tabla Report Selections, exactamente igual que ocurre con las páginas
estándar de Sales o Purchase.
Sin embargo, existen dos detalles muy
importantes.
Filtrar permanentemente la categoría
Durante la apertura de la página se utiliza un FilterGroup(2)
para fijar la categoría correspondiente.
Esto impide que el usuario elimine accidentalmente
el filtro y termine modificando configuraciones pertenecientes a otras
categorías.
Es un pequeño detalle que suele pasar
desapercibido, pero forma parte del patrón utilizado por Microsoft.
Inicializar automáticamente el Usage
Cuando el usuario crea un nuevo registro, el campo
Usage se rellena automáticamente.
De esta forma toda la configuración permanece
asociada a la nueva categoría sin intervención del usuario.
Paso 3. Crear el informe
Una categoría de Report Selection
únicamente representa una configuración.
Todavía necesitamos un informe que pueda
ser ejecutado.
En este caso se incorpora un nuevo informe
destinado a imprimir el estado de los Statistical Accounts,
completamente integrado dentro de la infraestructura de Report Selections.
La ventaja es que este informe no queda
ligado para siempre al proceso.
En cualquier momento podrá sustituirse por
otro informe desarrollado por un partner o por el propio cliente.
Paso 4. Centralizar la impresión
Probablemente ésta sea la parte más
importante de toda la implementación.
En lugar de ejecutar directamente el
informe desde las páginas, toda la lógica de impresión se concentra dentro de
un único Management Codeunit.
Este objeto se convierte en el único
responsable de:
·
localizar
la configuración;
·
resolver
el informe correspondiente;
·
ejecutar
el informe adecuado;
·
soportar
múltiples informes configurados.
De esta forma cualquier cambio futuro
queda aislado en un único punto.
Las páginas ya no conocen ningún Report
ID.
Únicamente conocen el Management Codeunit.
Paso 5. Resolver la configuración
Cuando el usuario solicita imprimir un
documento ocurre la siguiente secuencia.
La página no sabe qué informe terminará
ejecutándose.
Ni siquiera necesita conocerlo.
Toda esa responsabilidad pertenece
exclusivamente a la infraestructura de Report Selections.
Paso 6. Inicializar la configuración
Una aplicación no debería obligar al
usuario a configurar manualmente todos sus elementos después de instalarse.
Por ese motivo la implementación incorpora
la inicialización de un registro por defecto durante la instalación de la
extensión.
Sin embargo, existe una diferencia muy
importante entre inicializar y sobrescribir.
Antes de insertar la configuración se
comprueba si ya existe.
Si el cliente ya ha personalizado su
Report Selection, la instalación no modifica absolutamente nada.
Este pequeño detalle garantiza que futuras
actualizaciones no destruyan la configuración existente.
¿Por qué utilizar una Management Codeunit?
Una pregunta habitual es:
¿Por qué crear otro Codeunit si desde la
página puedo llamar directamente al informe?
La respuesta es sencilla.
- Porque el Codeunit no imprime.
- El Codeunit resuelve una estrategia.
- Hoy puede devolver un único informe.
- Mañana podrían ejecutarse varios informes.
- O quizá enviar un PDF por correo electrónico.
- O permitir distintos comportamientos dependiendo del contexto.
- La lógica de negocio permanece exactamente igual.
- Es la infraestructura la que evoluciona.
Ventajas obtenidas
BC Way
Cuando necesites incorporar una nueva
funcionalidad que genere documentos, intenta seguir siempre esta filosofía.
- ✔ Añade una nueva categoría de Report Selection.
- ✔ Crea una página específica de configuración.
- ✔ Centraliza toda la impresión en un Management Codeunit.
- ✔ Inicializa la configuración durante la instalación.
- ✔ Nunca ejecutes informes directamente desde las páginas.
De esta forma cualquier partner podrá sustituir
tus informes sin modificar una sola línea de código.
Y tu aplicación quedará alineada con los patrones
de diseño utilizados por Microsoft.
Conclusión
Muchas veces pensamos que extender Business
Central consiste en añadir tablas, páginas o nuevos procesos de negocio.
Sin embargo, las mejores extensiones son aquellas
que aprovechan la infraestructura que la plataforma ya ofrece.
Report Selections es
uno de esos componentes que suele pasar desapercibido, pero representa
perfectamente la filosofía de desarrollo de Business Central.
En lugar de decidir qué informe ejecutar desde
nuestro código, delegamos esa responsabilidad en una infraestructura
configurable, reutilizable y completamente extensible.
Proximamente dispondremos de una Skill sobre todo lo que hemos visto aquí en ALCSC.
Home | AL Copilot Skills Collection
El resultado es un código más limpio, más
mantenible y preparado para convivir con futuras personalizaciones sin
necesidad de modificaciones adicionales.
Eso es, precisamente, desarrollar a la manera
de Business Central.
Nos vemos en la próxima parada del BC Scout
Path 🧭
Remember:
Talk is cheap, show me the Skills!