Arquitectura en tres capas
La arquitectura SAP se organiza en tres capas lógicas bien diferenciadas que separan las responsabilidades de presentación, procesamiento de lógica de negocio y gestión de datos. Esta separación no es solo conceptual sino que se implementa físicamente en servidores diferentes, permitiendo escalar cada componente de forma independiente.
Esta arquitectura multinivel ha sido un pilar fundamental del diseño SAP desde sus orígenes y se mantiene tanto en SAP ECC como en SAP S/4HANA, aunque con evoluciones técnicas en cada versión.
Capa de presentación
La capa de presentación es el punto de contacto entre los usuarios y el sistema SAP. Su única responsabilidad es mostrar información al usuario y capturar sus entradas, sin contener ninguna lógica de negocio.
SAP GUI (Graphical User Interface) ha sido tradicionalmente el cliente principal para acceder a SAP. Es una aplicación de Windows que se instala en las estaciones de trabajo de los usuarios y se comunica con los servidores de aplicación mediante el protocolo DIAG (Dynamic Information and Action Gateway).
SAP GUI for HTML permite acceder al sistema mediante un navegador web estándar, ejecutando las pantallas SAP tradicionales en el navegador sin necesidad de instalar software en el cliente. Esta modalidad es útil para usuarios ocasionales o accesos desde dispositivos no Windows.
Las aplicaciones SAP Fiori representan la evolución moderna de la capa de presentación. Son aplicaciones web responsivas basadas en tecnologías estándar (HTML5, JavaScript) que se ejecutan en navegadores modernos y proporcionan una experiencia de usuario más intuitiva y atractiva.
SAP Business Client es otro cliente que combina acceso a transacciones tradicionales SAP GUI con capacidades de acceso a aplicaciones web y servicios de colaboración.
Comunicación de la capa de presentación
Los clientes de presentación se comunican con la capa de aplicación mediante diferentes protocolos. SAP GUI utiliza el protocolo propietario DIAG que es muy eficiente en términos de ancho de banda porque solo transmite cambios en la interfaz, no pantallas completas.
Las aplicaciones Fiori se comunican mediante protocolos estándar HTTP/HTTPS, invocando servicios OData que son proporcionados por el SAP Gateway en la capa de aplicación.
Esta separación permite que usuarios con conexiones de red lentas puedan trabajar eficientemente. Solo se transmiten comandos del usuario y datos de negocio comprimidos, no representaciones gráficas completas de las pantallas.
Capa de aplicación
La capa de aplicación es el corazón del sistema SAP donde reside toda la lógica de negocio. Los servidores de aplicación ejecutan el código ABAP que implementa los procesos empresariales, procesan transacciones, coordinan el acceso a datos y gestionan la seguridad.
Esta capa se compone de uno o múltiples servidores de aplicación. En un sistema pequeño puede existir solo un servidor que contiene todos los servicios (instancia central). En sistemas empresariales típicos hay múltiples servidores de aplicación distribuidos para balancear la carga y proporcionar redundancia.
Los work processes dentro de cada servidor de aplicación son los componentes que ejecutan realmente el código. Existen work processes especializados para diferentes tipos de tareas: diálogo (interacción de usuarios), background (trabajos programados), actualización (updates asíncronos) y spool (impresión).
Componentes de la capa de aplicación
El dispatcher es el punto de entrada de cada instancia de aplicación. Recibe las peticiones de los usuarios y las distribuye entre los work processes disponibles. Si todos los work processes están ocupados, el dispatcher encola las peticiones hasta que un process se libere.
El Internet Communication Manager (ICM) es un componente que gestiona las comunicaciones HTTP/HTTPS. Permite servir aplicaciones web directamente desde SAP sin necesidad de servidores web externos. Es fundamental para aplicaciones Fiori y servicios web.
El gateway gestiona las comunicaciones RFC (Remote Function Call) con otros sistemas SAP o aplicaciones externas. Cada instancia tiene su propio gateway que mantiene conexiones activas y enruta las llamadas al destino correcto.
El message server coordina la comunicación entre las diferentes instancias de aplicación de un mismo sistema. Mantiene información sobre qué instancias están activas y cuántos work processes libres tiene cada una, permitiendo balancear la carga automáticamente.
El enqueue server gestiona los bloqueos (locks) de registros de la base de datos para garantizar la consistencia cuando múltiples usuarios trabajan simultáneamente sobre los mismos datos.
Memoria en la capa de aplicación
La capa de aplicación utiliza diferentes áreas de memoria para diferentes propósitos. La memoria compartida (shared memory) contiene datos a los que todos los work processes necesitan acceder: buffers de tablas de la base de datos, programas ABAP compilados, configuración del sistema.
El uso efectivo de buffers es crítico para el rendimiento. Cuando un programa necesita leer un registro de la base de datos, primero busca en el buffer. Solo si no está allí se ejecuta una consulta costosa a la base de datos. La configuración correcta de buffers es una tarea importante del administrador BASIS.
Cada work process tiene memoria privada para procesar las peticiones actuales. Cuando termina una petición, esta memoria se libera para la siguiente transacción. La memoria extendida (extended memory) es un pool compartido del que los work processes solicitan memoria adicional cuando procesan transacciones grandes.
Capa de base de datos
La capa de base de datos almacena de forma persistente todos los datos del sistema SAP: datos maestros, documentos transaccionales, configuración del sistema, código ABAP, usuarios y autorizaciones.
SAP utiliza bases de datos relacionales estándar, aunque con un esquema de datos específico diseñado por SAP. En ECC se soportan múltiples bases de datos (Oracle, SQL Server, DB2, Sybase), mientras que S/4HANA requiere obligatoriamente SAP HANA.
La base de datos ejecuta en uno o más servidores dedicados separados de los servidores de aplicación. Esta separación permite optimizar cada capa independientemente: los servidores de aplicación necesitan mucha CPU, mientras que los servidores de base de datos necesitan mucha memoria y almacenamiento de alto rendimiento.
Comunicación con la base de datos
Los servidores de aplicación se comunican con la base de datos mediante la DBI (Database Interface), una capa de abstracción que permite que el mismo código ABAP funcione con diferentes sistemas de base de datos.
Cuando un programa ABAP ejecuta una sentencia SELECT, el runtime ABAP la convierte a SQL nativo de la base de datos específica mediante la DBI. Esta abstracción es transparente para los desarrolladores y permite portabilidad entre plataformas de base de datos.
Las conexiones de base de datos se gestionan mediante un pool de conexiones. Cada work process establece una conexión persistente con la base de datos que reutiliza para múltiples transacciones, evitando el overhead de conectar y desconectar continuamente.
Ventajas de la arquitectura en capas
La separación en capas proporciona múltiples beneficios técnicos y operativos. La escalabilidad se logra añadiendo más servidores en la capa que lo necesite. Si hay problemas de CPU por exceso de usuarios, se añaden servidores de aplicación. Si el cuello de botella está en la base de datos, se refuerza esa capa específicamente.
El mantenimiento es más sencillo porque se pueden actualizar componentes de una capa sin afectar las otras. Por ejemplo, aplicar parches a la base de datos no requiere cambios en los servidores de aplicación o clientes.
La seguridad mejora al concentrar los datos en servidores de base de datos protegidos en el centro de datos, sin que residan datos en las estaciones de trabajo de los usuarios. Los firewalls pueden configurarse para permitir solo comunicaciones específicas entre capas.
El rendimiento de red se optimiza porque el tráfico más intensivo (comunicación entre aplicación y base de datos) ocurre dentro del centro de datos con redes de alta velocidad, mientras que el tráfico a clientes (que puede ser por redes más lentas) es mínimo.
Distribución física de las capas
En sistemas pequeños de desarrollo o demo, las tres capas pueden ejecutarse en un mismo servidor físico: el cliente SAP GUI en una máquina Windows, y el servidor de aplicación y base de datos compartiendo el mismo servidor Linux o Windows.
En sistemas productivos típicos, la distribución es: múltiples estaciones de trabajo ejecutando clientes, varios servidores ejecutando instancias de aplicación, y uno o más servidores ejecutando la base de datos en configuración de alta disponibilidad.
En despliegues cloud, esta separación se mantiene pero utilizando máquinas virtuales o contenedores en lugar de servidores físicos. La arquitectura lógica en capas permanece independientemente de la infraestructura física subyacente.
Evolución de las capas en S/4HANA
Con S/4HANA y SAP HANA, la separación entre capas evoluciona pero no desaparece. HANA introduce capacidades de procesamiento de lógica de negocio directamente en la base de datos mediante procedimientos almacenados y vistas CDS que se ejecutan como código nativo de la base de datos.
Esto permite "empujar" cierto procesamiento a la capa de base de datos donde los datos residen, reduciendo la transferencia de datos entre capas. Sin embargo, la mayor parte de la lógica de negocio permanece en la capa de aplicación ABAP.
La capa de presentación también evoluciona con Fiori, que introduce arquitecturas más complejas con Frontend Servers y Gateway actuando como capas intermedias entre el navegador del usuario y el backend S/4HANA.
Preguntas Frecuentes (FAQ)
¿Cuáles son las tres capas de SAP?
Las tres capas son: Presentación (donde interactúa el usuario), Aplicación (donde se procesa la lógica ABAP) y Base de Datos (donde se almacenan los datos persistentemente).
¿Qué es el Message Server en la capa de aplicación?
El Message Server coordina la comunicación entre las diferentes instancias de aplicación de un sistema SAP y balancea la carga de los usuarios cuando inician sesión.
¿Por qué se separan las capas de aplicación y base de datos?
La separación permite escalabilidad independiente. Los servidores de aplicación necesitan mucha CPU para procesar lógica, mientras que la base de datos necesita mucha memoria y rendimiento de disco.
Temas relacionados
Para profundizar en las capas del sistema SAP, consulta:
Conceptos básicos de arquitectura SAP para entender los work processes, dispatcher y otros componentes.
SAP BASIS para las tareas de administración de servidores de aplicación.
SAP HANA para conocer la capa de base de datos moderna de SAP.
Escalabilidad y dimensionamiento para calcular cuántos servidores necesita cada capa.
Alta disponibilidad para diseñar redundancia en cada capa del sistema.