Si alguna vez viste un diagrama de arquitectura de SAP, probablemente parecía el plano de una central nuclear: decenas de cajas con siglas (ASCS, ERS, HANA, PAS, Web Dispatcher…) conectadas por flechas en todas direcciones. Intimidante. Pero aquí está el secreto: debajo de todas esas siglas hay solo un puñado de ideas simples. Y una vez que las ves, el plano entero cobra sentido.
En este artículo vas a entender, sin ser consultor SAP:
- Qué hace cada componente.
- Cómo se comunican entre sí.
- Y por qué casi todo está duplicado (spoiler: porque una empresa no puede permitirse que SAP se caiga).
Vamos a usar una analogía que sostiene todo el artículo: SAP es como un banco físico gigante. Con su bóveda, sus ventanillas, su recepcionista y sus guardias. Cada pieza técnica la iremos conectando con esa imagen.
Primero, la idea de una frase
SAP es el sistema nervioso central de una empresa grande. Cuando alguien emite una factura, mueve inventario, paga a un proveedor o cierra la contabilidad del mes, todo eso ocurre «dentro de SAP».
Como el negocio entero depende de ese sistema, la arquitectura obsesivamente busca una sola cosa: que nunca se caiga. Ese objetivo explica el 90% de la complejidad que ves. Ténlo presente.
El esqueleto: las 3 capas
Todo sistema SAP se organiza en tres capas. Este es el concepto base; el resto son detalles que cuelgan de aquí.
Cómo leer este diagrama: el usuario (arriba) nunca habla directo con la base de datos (abajo); siempre pasa por la capa de aplicación del medio. Es una regla de oro: en el banco, el cliente nunca entra a la bóveda — le pide todo al cajero, y el cajero es quien accede.
| Capa | Qué es | En el banco… |
|---|---|---|
| Presentación | Lo que ve el usuario | El cliente frente a la ventanilla |
| Aplicación | Donde corre la lógica de negocio | Las ventanillas que hacen el trámite |
| Base de datos | Donde viven los datos de verdad | La bóveda |
Un par de términos que verás todo el rato
- SAP GUI vs Fiori — las dos «caras» de SAP. SAP GUI es la interfaz clásica de escritorio (pantallas densas, códigos como «VA01»): el formulario en papel de toda la vida. Fiori es la interfaz moderna que se abre en el navegador o el móvil: la app del banco en tu celular. Misma lógica por debajo, distinta cara.
- Sistema vs Landscape — un sistema es un SAP completo (las 3 capas juntas y funcionando): una sucursal entera del banco. Un landscape («paisaje») es el conjunto de todos los sistemas de la empresa: típicamente Desarrollo (DEV), Calidad (QAS) y Producción (PRD), con los cambios viajando DEV → QAS → PRD. Es la cadena entera de sucursales.
- ABAP — el lenguaje de programación propio de SAP (como Java o Python, pero de SAP). Toda la lógica de negocio está escrita en él.
Los componentes, uno por uno
🗄️ SAP HANA — la bóveda mágica
Es la base de datos principal, y su superpoder es que es in-memory: guarda los datos en la RAM (memoria) en vez del disco. Por eso responde en segundos lo que otras bases tardan minutos.
Es la fuente de la verdad: el dato de negocio vive aquí. Y justo por eso no puede perderse jamás. Se protege con HANA System Replication (HSR): un HANA primario activo y un secundario que recibe una copia en vivo. Si el primario cae, el secundario toma el mando.
Cómo leer este diagrama: la flecha sólida es el tráfico normal (la app habla con el primario). Las flechas punteadas son el mecanismo de seguridad: el primario copia todo al secundario continuamente, y si muere, el secundario ocupa su lugar. Es tener una segunda bóveda idéntica lista para abrir.
🗄️ SAP Sybase ASE — la segunda bóveda
Otra base de datos (SAP Adaptive Server Enterprise, antes «Sybase»), pero tradicional (no in-memory). Aparece cuando ciertos entornos o aplicaciones corren sobre ASE en vez de HANA — común en empresas donde no todo migró a HANA. Piensa en una segunda bóveda más pequeña para un negocio específico. También se protege con redundancia (IP virtual + clúster, que explicamos más abajo).
⚙️ Servidores de Aplicación (PAS / AAS) — las ventanillas
Aquí corre la lógica de negocio (ABAP). El PAS (Primary Application Server) es la ventanilla principal; los AAS (Additional Application Servers) son ventanillas extra que abres cuando hay fila.
Su gran virtud: son desechables y escalables. Puedes agregar o quitar AAS sin drama, como abrir más cajas en hora punta. Por eso, curiosamente, no son la pieza crítica de la alta disponibilidad. La pieza crítica es la siguiente.
🔒 ASCS / ERS — el corazón de la alta disponibilidad
Esta es la pareja más importante de entender, y la que más confunde. Despacio.
El ASCS (ABAP SAP Central Services) contiene dos servicios que solo pueden existir una vez en todo el sistema:
- Message Server: el operador de central telefónica que coordina y balancea entre las ventanillas.
- Enqueue Server: el portero de los candados (locks). Cuando alguien edita una factura, pone un candado para que nadie más la toque a la vez. Sin esto, dos personas editarían el mismo dato y lo corromperían.
El problema es evidente: si esos candados viven en un solo lugar y ese lugar se cae, se pierde el registro de qué estaba bloqueado → caos. El ASCS es, por naturaleza, un punto único de fallo (SPOF).
La solución es el ERS (Enqueue Replication Server): mantiene una copia en vivo de la tabla de candados. Si el ASCS cae, con la copia del ERS se reconstruyen los bloqueos sin perder nada.
Cómo leer este diagrama: las ventanillas piden candados al ASCS (flecha sólida). El ASCS le pasa continuamente una copia al ERS (punteada). Analogía: el ASCS es el gerente con el libro de «quién está usando qué caja fuerte»; el ERS es el asistente que copia ese libro renglón por renglón. Si el gerente se desmaya, otro toma el libro actualizado y nadie pierde su lugar. La versión moderna, ENSA2, permite que el ASCS reviva en cualquier nodo del clúster, no solo donde está el ERS.
💡 Dato
🚪 Web Dispatcher — el recepcionista
Es el punto de entrada web: recibe las peticiones del navegador (Fiori) y las reparte entre las ventanillas disponibles, preguntándole al Message Server quién está menos ocupado. También termina el HTTPS (el cifrado).
Como es la puerta, suele duplicarse (dos Web Dispatchers tras un balanceador) para que nunca esté cerrada.
🛡️ SAProuter — el guardia de la entrada
Controla qué conexiones entran y salen de la red SAP hacia el exterior. No hace trabajo de negocio; solo vigila el acceso, típicamente en la DMZ («zona desmilitarizada»: una red intermedia entre internet y la red interna, una tierra de nadie vigilada donde se colocan los componentes que hablan con el exterior sin exponer el interior). Es la vía por la que SAP se conecta para dar soporte.
🌉 SAP Cloud Connector — el túnel a la nube
Un puente seguro entre tu SAP on-premise (en tus propias instalaciones/datacenter, en contraste con la nube) y la plataforma cloud de SAP, SAP BTP. Su truco de seguridad: el túnel es saliente — lo inicia tu red hacia la nube, nunca al revés. Así aprovechas servicios en la nube sin abrir puertos de entrada a tu red interna. Un túnel privado y vigilado entre la sucursal y su oficina en la nube.
✉️ Process Orchestration (PI/PO) — el traductor
El middleware de integración (middleware = software que se sienta «en el medio» para conectar dos sistemas que no hablan el mismo idioma, como un intérprete). Conecta SAP con bancos, proveedores y otras apps, traduciendo formatos de mensaje. Es el departamento de correspondencia y traducción del banco. Y como también es un sistema SAP, tiene su propio par ASCS/ERS para su HA.
📊 SAP Solution Manager — el gerente regional
No procesa negocio: gestiona a los demás. Monitorea la salud de todo el landscape, administra incidentes y controla los transportes (el movimiento de cambios DEV → QAS → PRD). Es la oficina del gerente regional que vigila todas las sucursales.
Las tres ideas que hacen clic
Si entiendes estos tres conceptos, entiendes por qué la arquitectura se ve como se ve.
1. La IP Virtual (VIP): pedir un rol, no una persona
En vez de que una app apunte a «servidor-A» (una máquina física que puede morir), apunta a una IP virtual: una dirección que no está atada a ningún servidor concreto. Si el servidor A cae, esa IP «salta» automáticamente al servidor B, y la app ni se entera.
Analogía: en lugar de pedir «que me atienda Juan», pides «que me atienda el cajero de turno». Si Juan se enferma, María toma el turno y para ti nada cambia. Por eso en SAP verás tantos nombres con «vip».
2. El clúster y el failover: servidores que se cuidan entre sí
Un clúster son dos o más servidores que actúan como uno y se vigilan mutuamente. Si uno cae, otro asume su trabajo automáticamente: eso es un failover. (En SAP sobre Linux, el software de clúster típico es Pacemaker; en Windows, WSFC.) Dos gerentes que se turnan y se vigilan.
3. El SPOF: el enemigo a eliminar
Un SPOF (Single Point of Failure, punto único de fallo) es cualquier pieza que, si falla, tumba todo. Toda la redundancia de SAP existe para matar SPOFs: por eso HANA se replica, el ASCS tiene su ERS, el Web Dispatcher se duplica y las IPs son virtuales.
✅ Regla mental
Cómo se comunica todo: el viaje de una factura
Juntemos las piezas siguiendo a un usuario que crea una factura, de principio a fin.
Cómo leer este diagrama, paso a paso:
- El usuario entra; si viene de afuera, pasa primero por el SAProuter (el guardia).
- El Web Dispatcher lo dirige a la ventanilla menos ocupada.
- El servidor de aplicación ejecuta la lógica. Antes de tocar el dato, le pide un candado al ASCS para que nadie más edite esa factura a la vez.
- Con el candado puesto, escribe en HANA (la bóveda).
- En paralelo y todo el tiempo, el ERS copia los candados y el HANA secundario copia los datos — la red de seguridad.
- La respuesta vuelve por el mismo camino hasta el usuario.
Ese ida y vuelta, con su candado y sus copias de respaldo, es SAP funcionando bien.
La foto completa
Y así se ve un landscape SAP realista con alta disponibilidad, con todas las piezas en su sitio:
Cómo leer este diagrama: léelo por zonas (los recuadros). Arriba, el mundo exterior. Debajo, la DMZ filtra todo lo que entra. El tráfico llega a la capa de aplicación (las ventanillas), que se apoya en los Central Services (los candados, con su réplica) y en la capa de datos (las bóvedas, con su réplica). El Solution Manager, a un lado, lo vigila todo. Fíjate en un patrón: cada zona crítica tiene su pieza «en espera» (x2, réplica, secundario). Eso es la alta disponibilidad hecha diagrama.
Glosario rápido
| Término | Qué significa |
|---|---|
ABAP | Lenguaje de programación propio de SAP |
Fiori | Interfaz web/móvil moderna de SAP (vs SAP GUI, la de escritorio) |
Sistema | Un SAP completo (3 capas) funcionando como unidad |
Landscape | El conjunto de sistemas SAP de la empresa (DEV/QAS/PRD) |
in-memory | Datos en RAM en vez de disco (ultra rápido) |
HSR | HANA System Replication: copia en vivo de la BD |
ASCS | Central Services: Message Server + Enqueue (candados) |
ERS | Réplica de la tabla de candados del ASCS |
ENSA2 | Versión moderna del Enqueue que permite failover flexible |
VIP | IP virtual que «flota» entre servidores |
Clúster / failover | Servidores que se cuidan y se relevan al caer |
SPOF | Punto único de fallo: lo que la HA busca eliminar |
DMZ | Red intermedia vigilada entre internet y la red interna |
on-premise | En tus propias instalaciones (vs nube) |
middleware | Software que conecta e «traduce» entre sistemas |
BTP | SAP Business Technology Platform (la nube de SAP) |
Conclusión
La arquitectura de SAP parece complicada porque hace dos cosas a la vez: procesar el negocio y no caerse nunca. Si separas esas dos intenciones, todo se ordena:
- Las 3 capas (presentación, aplicación, datos) hacen el trabajo.
- Cada componente especializado (Web Dispatcher, SAProuter, PI/PO, Cloud Connector, Solution Manager) resuelve una necesidad concreta: entrar, integrar, vigilar.
- Y toda la redundancia (HANA replicado, ASCS+ERS, IPs virtuales, clústeres) existe por una sola razón: eliminar puntos únicos de fallo.
La próxima vez que veas ese plano intimidante, no cuentes las cajas. Busca el patrón: ¿qué hace el trabajo y qué está ahí para que el trabajo nunca se detenga? Con eso, ya entiendes SAP.
💡 Nota de transparencia