Diferenciar la aplicación base y la aplicación del sistema
Los desarrolladores de AL pueden ampliar la funcionalidad de Business Central de varias maneras. Pueden ampliar tablas, enumeraciones, áreas de aplicación, páginas, informes, flujos de código y el modelo de seguridad. También pueden contribuir directamente a la aplicación base en los proyectos de código abierto para los módulos de aplicación del sistema.
La aplicación Business Central consta de varias capas.
Aplicación del sistema: un conjunto de módulos de código abierto que facilitan la creación, el mantenimiento y la actualización de aplicaciones locales y en línea. Estos módulos le permiten centrarse en la lógica empresarial y las necesidades de sus usuarios o clientes.
Aplicación básica: la lógica empresarial para la funcionalidad en Business Central.
Descripción general de la aplicación del sistema
La aplicación del sistema contiene módulos que interactúan con la plataforma Dynamics 365 Business Central y el ecosistema en línea a fin de dar soporte a la lógica de negocios en la aplicación básica. Si está desarrollando extensiones o complementos para Dynamics 365 Business Central, probablemente necesitará usar uno o más de los objetos en los módulos.
Para obtener una descripción general de los módulos de la aplicación del sistema, consulte Descripción general de los módulos en la aplicación del sistema.
Referencia para la aplicación básica y del sistema en Dynamics 365 Business Central
En la sección Aplicación del sistema, puede encontrar una descripción general de todos los objetos que componen la capa de aplicación del sistema en Business Central, incluidos los objetos obsoletos ordenados por tipo de objeto. En la sección Aplicación básica, puede encontrar una descripción general de todos los objetos que componen la capa de aplicación básica en Business Central. Esto también incluye una sección de objetos obsoletos, ordenados por tipo de objeto.
Para obtener más información, consulte Referencia para la aplicación básica y del sistema en Dynamics 365 Business Central.
Arquitectura del módulo
Aunque la arquitectura interna de los módulos puede diferir (lo que es muy probable), hay reglas que garantizan la uniformidad y fiabilidad en la arquitectura de los módulos de la aplicación. A fin de reducir el acoplamiento y aumentar la uniformidad, cada módulo es una entidad separada que tiene una apariencia de acceso público, mientras que la implementación interna no es pública, como se muestra en la siguiente imagen.
Los módulos son proyectos independientes y tienen sus propios archivos app.json.
Los módulos pueden pertenecer a un paquete específico o capa funcional. Un módulo pasa a formar parte de una capa cuando se agrega a la estructura de carpetas del paquete de la capa. Un módulo puede pertenecer a varios paquetes porque el módulo es un paquete en sí mismo y puede agruparse en paquetes de capas funcionales más grandes.
Las dependencias de otros módulos solo se pueden llevar a módulos de la misma capa funcional o a capas inferiores. Por ejemplo, un módulo de la aplicación central solo puede tener dependencias de módulos de la aplicación central o de la aplicación del sistema, pero nunca de extensiones.
Inicialmente, cada módulo debe apuntar al entorno más restrictivo, que es el entorno de nube. Si se requieren operaciones no seguras, estas deberían dar como resultado un módulo de aplicación del sistema donde las operaciones no seguras estén empaquetadas con API seguras. Para lograrlo, el Destino se establece en OnPrem. Los módulos en capas por encima de la aplicación del sistema deben tener el Destino establecido en Nube en el archivo app.json.
Solo se puede acceder a las codeunits, páginas y tablas de fachada requeridas en la API pública del módulo. Los detalles de implementación interna deben marcarse como tales estableciendo el modificador de acceso en Interno. Por ejemplo, se puede acceder a las entidades dentro del módulo, pero no se les puede llamar desde fuera del módulo.
Todo módulo debe tener una fachada que cumpla con las siguientes reglas:
El acceso debe ser Público. Debe configurarse explícitamente para enfatizar que se trata de una fachada o una codeunit similar a una API que expone la funcionalidad principal del módulo.
Todos los editores de integración y eventos de negocio deben estar en la fachada como funciones internas. Esto evita que sean invocados fuera del módulo.
Los editores de eventos deben marcarse como internos. Las excepciones deben documentarse.
Todos los métodos externos van en la fachada.
Las fachadas no pueden contener lógica ni funciones locales.
La fachada es la codeunit a la que hacen referencia otros módulos, así que debe tener un nombre corto y significativo. Las codeunits de implementación interna pueden tener el sufijo Impl, por ejemplo, porque no se hace referencia a ellas fuera del módulo.
Las codeunits de implementación contienen lógica de negocio. Las páginas y tablas pueden contener código, pero deben contenerlo solo cuando sea absolutamente necesario.
Se debe incluir la extensibilidad en la implementación interna de cada módulo. Si es necesario que un módulo no sea extensible, la propiedad Extensibilidad en tablas, páginas y enumeraciones debe establecerse en Falso para evitar que esos objetos se extiendan.
Estas son algunas opciones donde puede encontrar documentación sobre cómo desarrollar módulos:
Si desea contribuir con código a la aplicación del sistema de código abierto Business Central, debe determinar el tipo de contribución:
Pequeñas correcciones de errores, mejoras de productos o comodidades para el cliente
Nuevas capacidades o cambios más importantes en la plataforma de aplicaciones existente
Para obtener más información sobre cómo hacer contribuciones, vaya a Cómo hacer contribuciones en la aplicación del sistema de código abierto de Business Central.
Para obtener más información sobre la aplicación del sistema, la arquitectura de su módulo y cómo modificar o crear nuevos módulos, vaya a Arquitectura de módulos.