SAP Application Tier on Azure
Understand the SAP three-tier architecture on Azure including ASCS/SCS message and enqueue services, application servers for dialog and batch processing, SAP Web Dispatcher for HTTP load balancing, and LaMa connector.
The SAP three-tier model
☁️ Mei sketches three boxes on the whiteboard. “Raj, we have been focused on the database layer. But HANA is just the foundation. Above it sits the application tier where all the business logic runs, and above that is the presentation tier where users connect. On Azure, each tier maps to different VMs and services.”
🏗️ Raj counts. “So at minimum we need database VMs, application VMs, and some way for users to connect?”
☁️ Mei nods. “Exactly. And within the application tier, there are specialized components with very different roles. Let me break them down.”
Think of it like a restaurant.
The kitchen (database tier) stores ingredients and prepares the food. The waitstaff (application tier) takes orders, coordinates between the kitchen and customers, and manages the queue. The dining room entrance (presentation tier) is where customers interact. The maitre d’ (ASCS) manages all the reservations and makes sure no two waiters serve the same table. Without the maitre d’, the restaurant descends into chaos — orders get lost, tables get double-booked.
📐 Architecture diagram: Open the SAP 3-Tier Architecture diagram in Excalidraw to see the full Web Dispatcher → App tier → HANA layout with VM families and Azure Load Balancer.
ASCS/SCS — the central nervous system
ASCS (ABAP SAP Central Services) is the most critical component in the application tier. It runs two essential services:
Message server — routes communication between SAP application servers. When a user logs in, the message server directs them to an available application server. It also distributes batch jobs and handles server group management.
Enqueue server — manages SAP lock management. When a user edits a purchase order, the enqueue server holds the lock to prevent another user from editing the same record simultaneously. Losing enqueue locks means losing in-flight transactions.
Why ASCS is a single point of failure:
- Only one ASCS instance runs at a time
- If the message server goes down, no new user sessions can be established
- If the enqueue server goes down, all locks are lost (which can corrupt in-flight transactions)
- This is why ASCS always needs HA clustering (covered in Domain 3)
ENSA1 vs ENSA2 — preview for Domain 3
The Enqueue Replication Server (ERS) maintains a copy of the lock table on a separate VM. ENSA1 (older) requires the lock table to be rebuilt on failover. ENSA2 (current, S/4HANA default) keeps an active replica — failover is seamless with no lock loss. The exam will test this in the HA domain.
Application servers — dialog and batch
SAP application servers handle the actual business processing. They come in two flavors:
Dialog instances — serve interactive user sessions (SAP GUI, Fiori). Each user session is allocated to a dialog work process. More users = more dialog instances needed.
Batch instances — run background jobs (reports, data loads, scheduled tasks). Batch-heavy systems may have dedicated batch servers to prevent background processing from impacting interactive performance.
On Azure, both run on E-series VMs. You can scale horizontally by adding more application server VMs as user count grows.
🏗️ Raj nods. “So if PrecisionSteel adds 500 users after going live, we just add more application server VMs?”
☁️ Mei confirms. “Exactly. The application tier scales out easily. You register new application servers with the message server, and it starts routing users to them. No downtime required.”
SAP Web Dispatcher
The SAP Web Dispatcher is a reverse proxy and HTTP load balancer built specifically for SAP. It distributes incoming HTTP/HTTPS requests across multiple SAP application servers.
Key features:
- Balances HTTP traffic for SAP Fiori, SAP GUI for HTML, and SAP Web applications
- URL-based routing — send different URLs to different backend servers
- SSL termination
- Runs on its own VM (typically a smaller E-series or D-series)
- Not a replacement for Azure Application Gateway or Azure Load Balancer — it operates at the SAP layer
| Component | Role | Azure VM | HA required |
|---|---|---|---|
| ASCS/SCS | Message server + enqueue server — coordinates all app servers | E-series (moderate sizing) | Yes — critical SPOF, needs clustering |
| Application servers (dialog) | Interactive user sessions and business logic | E-series (scale out with user count) | No — multiple instances provide natural redundancy |
| Application servers (batch) | Background job processing | E-series (scale based on batch volume) | No — jobs restart automatically on failure |
| Web Dispatcher | HTTP/HTTPS reverse proxy and load balancer | D-series or small E-series | Optional but recommended for production |
| ERS (Enqueue Replication) | Replicates lock table for ASCS failover | Small E-series or D-series | Yes — part of ASCS HA design |
SAP LaMa connector for Azure
SAP Landscape Management (LaMa) is SAP’s tool for system administration — starting, stopping, copying, and refreshing SAP systems. The Azure connector for LaMa allows LaMa to manage Azure VMs directly:
- Start and stop Azure VMs from LaMa console
- Create system copies by cloning VMs and managed disks
- Automate refresh operations for non-production systems
- Reduce manual Azure portal operations for SAP Basis teams
Exam tip: LaMa connector simplifies operations
The exam may present scenarios where SAP Basis administrators need to manage Azure VMs without learning the Azure portal. SAP LaMa connector is the answer — it lets them use familiar SAP tools to control Azure infrastructure. This is especially relevant for system copy and refresh workflows.
Sizing the application tier
Application tier sizing depends on SAPS requirement (from SAP sizing reports), user count and concurrency, batch job volume, and whether dialog and batch run on the same or separate VMs.
A common approach:
- Use SAP Quick Sizer to determine total application tier SAPS
- Divide across multiple E-series VMs (minimum 2 for redundancy)
- Separate batch-heavy processing onto dedicated VMs if needed
- Add Web Dispatcher for HTTP workloads
Knowledge check
During a production outage, PrecisionSteel discovers that the ASCS VM has crashed. What is the immediate business impact?
PrecisionSteel expects 2,000 concurrent SAP users after go-live and needs to distribute HTTP traffic across multiple Fiori application servers. What component should Mei deploy?
PrecisionSteel's SAP Basis team needs to perform system copies of SAP development environments on Azure without learning the Azure portal. What should Mei recommend?
Summary
You now understand how SAP’s application tier maps to Azure: ASCS/SCS as the critical coordinator (message server + enqueue server), dialog and batch application servers on E-series VMs that scale horizontally, Web Dispatcher for HTTP load balancing, and LaMa connector for Basis team operations. The application tier is where business logic lives — getting it right is essential for user experience and system stability.
Next, we will look at proximity placement groups and availability options to ensure these components are both close together (for performance) and resilient (for uptime).
🎬 Video coming soon