The signs below are not catastrophic failures. They are the architectural patterns that add operational cost slowly, show up as hours of investigation time per incident, and make every system change more complicated than it should be. Each one is recognizable. Most SAP landscapes have at least three of them.

Sign 1.  SM59 contains RFC destinations that fail the connection test and nobody knows if they are still needed

Open SM59 in your production system. Run the connection test on every type 3 RFC destination. Count how many fail. Then ask the team which of the failing ones can be safely deleted.

In most landscapes that have been running for more than four years, the honest answer is: we are not certain. Connections were added during projects, during emergency integrations, during migration activities, and during consultancy engagements that ended years ago. The system they pointed to may have been decommissioned. Or it may still exist and is actively receiving calls from a program that the connection test does not exercise.

The operational consequence is not the dead connections themselves. It is the hidden dependency web they represent. When a connected system is decommissioned, the people making the decommission decision do not know that three RFC destinations in production point to it. They find out when an interface fails in production and the investigation leads back to a destination that was pointing at a server that no longer exists.

An SM59 audit that documents every destination, its owner, its last successful call date, and the business process it supports costs half a day. It removes the ambiguity permanently and reveals which connections can be cleaned up versus which are genuine operational dependencies that need to be monitored.

Sign 2.  The batch schedule exists in SM36 and also in a spreadsheet and also in the service management tool, and none of them agree

This is the most common form of operational debt in SAP batch management. The official schedule is in SM36. A project created a parallel tracking spreadsheet three years ago that has not been updated since the last consultant rotation. The ITSM has recurring tasks for the most critical jobs that were added for SLA tracking and reflect the schedule as it was when they were created, not as it is today.

When a job needs to change, one or two of these three places gets updated. The others drift. A job that moved from 03:00 to 02:00 still has an ITSM recurring task checking for completion at 04:30, because nobody updated it, and it passes every morning based on a completion time that is no longer the right reference.

The operational cost shows up when something goes wrong. The investigation uses the spreadsheet or the ITSM task as the reference, not SM36, because it is faster to check. The reference is wrong. The investigation goes in the wrong direction. An additional 45 minutes of analysis time per incident is invisible in any single post-incident review and completely visible when you add up the hours across a quarter.

Sign 3.  The “hotfix” transport route is used more often than the standard development-to-production route

Every SAP transport landscape has or has had a hotfix route: a path that allows transports to move from a correction system directly into production, bypassing the quality gate. The hotfix route exists for legitimate emergencies: an OSS note that must be applied immediately, a legal change with a fixed effective date that cannot wait for the next release cycle.

The sign of operational debt is when the hotfix route is the default path for a significant fraction of transports. When the team has stopped using the development-to-QA-to-production route for most changes because QA is three versions behind, or because the QA testing cycle takes longer than the business is willing to wait, or because the transport approval process for the standard route has become a bottleneck. At that point, the quality gate is not a gate. It is an optional step for changes that are not urgent, which in practice means almost no changes.

The consequence is not visible in the transport system, which shows all transports as approved and imported. It is visible in production incidents where a change was not tested in an environment that matched production, and the failure that would have been caught in QA is instead caught by a user.

Sign 4.  Quality and production systems run different HANA versions or have data volumes that differ by more than an order of magnitude

QA exists to catch problems before they reach production. Its value depends entirely on how accurately it represents production conditions. A QA system running an older HANA version, or a QA system that carries 15% of production data volume, provides a different type of assurance than one that matches production closely.

The specific failure mode this creates is the problem that is not reproducible in QA. A performance issue that only occurs at production data volumes cannot be tested in a 15% copy. A behavior change introduced by the HANA version difference between QA and production only appears after the production system is updated. Each of these failures required a production incident to discover, at which point the organizational response is “this should have been caught in QA” and the technical response is “it could not have been caught in QA given how QA is configured.”

Keeping non-production environments reasonably current with production is an operational discipline that requires budget and planning. The budget for regular system copies and version alignment is consistently cut in favor of more visible project spending. The debt accumulates every time a production incident could have been caught in a properly maintained QA environment and was not.

Sign 5.  Authorization roles are copies of copies, and nobody can explain why specific transactions are included

Ask the authorization administrator to explain why a specific transaction code is included in a critical role. If the answer is “it was in the role when we copied it” or “I think a consultant added it for a specific requirement,” the landscape has authorization debt.

The mechanism is straightforward. A role is created by copying an SAP standard role. It is modified for the specific requirement. Later, someone needs a similar role and copies the modified one rather than starting from the standard. The copy inherits everything from the first modification, including authorizations that were specific to the first use case and irrelevant for the second. The second role is then copied for a third case. By the fourth generation, the role contains authorizations from three different use cases, each of which has evolved since the role was copied, and none of which anyone can fully trace.

This is not a security failure in the sense of unauthorized access. It is a governance failure that makes access reviews misleading and audit findings inevitable. The role contains more than it should contain, for reasons nobody can document, in a system that handles financial transactions.

Sign 6.  Custom ABAP enhancements are undocumented and the person who built them is no longer at the company

The enhancement exists. It modifies standard SAP behavior. It has been running in production for four years. When a new ABAP enhancement package is installed and a standard SAP function changes, the enhancement breaks. The team opens the code to fix it and discovers that it contains no comments, uses non-standard techniques, and accesses database tables directly in ways that the standard SAP APIs would have handled differently.

The time to fix it is three times what a well-documented enhancement would require, because the investigation is reconstructing the original intent before the fix can be designed. The risk of the fix is higher because the original design constraints are unknown.

This pattern compounds every time the landscape is upgraded, every time a standard program the enhancement relies on changes, and every time a new consultant touches the codebase and discovers an undocumented behavior that was producing results the business depended on without knowing it was custom.

The operational debt is not the existence of custom ABAP. It is the existence of custom ABAP without documentation. One is an architectural choice. The other is a maintenance liability with a cost that compounds with every system change.

Sign 7.  The “known issues” list has grown every quarter for two years and has not been reduced

Every SAP operations team has a known issues list. It contains items like: the SM37 failed job history from a cancelled migration project in 2021 that should be cleaned up. The RFC destination pointing to the decommissioned CRM system that still shows in SM59. The development client that was accidentally unlocked six months ago and has not been relocked. The background job that was cancelled manually during an incident and never rescheduled.

The list grows because resolving these items requires effort that is always lower priority than the current active work. Each item is small enough to defer. Collectively, they represent the explicit debt register of the landscape: a documented list of known-wrong conditions that the team has accepted as permanent background noise.

The operational cost is not the items themselves. It is what they do to incident investigations. When a failure occurs in a landscape with 40 known issues, the first question in the investigation is whether the failure is related to one of the known issues. That disambiguation step, checking whether the new incident is connected to an existing known problem, adds time to every investigation in a landscape where the known issues list is long enough to be a real reference list rather than a short exception list.

Operational debt in SAP landscapes is not an accident and it is not the result of bad intentions. It is the cumulative effect of reasonable decisions made under real constraints, accumulated without a mechanism to review and address them before they compound.

The review that identifies these signs does not require a lengthy architecture engagement. It requires someone to look at the landscape with the question of which patterns are creating operational cost rather than which ones are architecturally elegant. Most of the signs above are visible in a half-day of looking at the right transactions: SM59, SM36, SE01, PFCG, and the team’s own known issues list.

What the review requires is the willingness to treat the findings as actionable rather than as the accepted background condition of a system that has been running for years. The debt does not stop compounding on its own.

Redpeaks monitoring surfaces several of these operational debt indicators continuously: RFC connection health, batch schedule integrity, authorization change events, and configuration drift from documented baselines. See the landscape health monitoring features.

L’article SAP landscape architecture review: 7 signs your design is creating operational debt est apparu en premier sur Real-time SAP monitoring software | Redpeaks .

A hub that processes messages correctly is invisible to the SAP system that sent them. A hub that fails is also invisible, from the SAP side. Whether the message was delivered, transformed correctly, and processed by the receiving system is something the SAP sender does not know unless the hub is monitored separately and that monitoring is designed to surface failures back to the team that owns the SAP side.

This article covers the specific ways that middleware architecture changes what can be seen, where monitoring responsibility shifts, and what design decisions at architecture time make operations across the integration boundary more manageable.

What a hub architecture actually changes about visibility

The point-to-point baseline

In a direct RFC or IDoc connection between two SAP systems, the monitoring picture on the sending side is relatively complete. SM58 shows whether a transactional RFC call was dispatched and acknowledged. BD87 shows the IDoc status at each step. If the call fails, the failure is visible in the sending system’s transaction monitors. If it succeeds, the acknowledgment confirms that the receiving system accepted the message.

This visibility is not perfect. A message acknowledged as received by the receiving system’s RFC layer may still fail at the application processing level, producing a status 51 IDoc error on the receiver that is not visible on the sender without explicit monitoring of the receiver. But the failure surface is defined and bounded. The monitoring tools available on the SAP side cover most of it.

What changes when middleware enters the picture

When a message passes through a hub, the SAP sender’s view narrows to a single data point: did the message reach the middleware successfully? If the answer is yes, the SAP system moves on. Everything that happens after that, the middleware’s processing, the transformation, the delivery to the target system, the target system’s application-level processing, is outside the SAP sender’s direct observation.

The monitoring gap this creates is proportional to how asynchronous the hub architecture is. In a fully asynchronous design, the SAP system posts a message to the middleware’s inbound queue and returns immediately. From the SAP transaction monitor’s perspective, the send was successful. Whether the downstream system received and processed the message is a question that the middleware’s monitoring must answer, not the SAP system’s.

In a synchronous hub design, the SAP system waits for a response from the middleware, which waits for a response from the target. The SAP system knows the outcome because the call either returns successfully or returns an error. Synchronous designs preserve end-to-end visibility at the cost of performance: the SAP work process holds a connection for the entire duration of the downstream call chain.

Asynchronous hubs and the dead letter queue problem

Asynchronous integration is the dominant pattern in modern SAP middleware architectures because it decouples sender and receiver performance. The SAP system is not blocked waiting for the downstream system to respond. Message processing spikes on the receiver do not slow down the SAP sender. These are genuine benefits.

The monitoring cost is that delivery confirmation moves entirely out of the SAP sender’s view. The sender knows it handed off the message. Confirmation that the message was processed by the receiver exists only in the middleware’s logs and, if the hub is well designed, in the target system’s application data.

The specific failure mode that asynchronous architectures introduce is the dead letter queue, or DLQ. When a message fails processing in the middleware after the maximum retry count is exhausted, it is moved to the DLQ. This is the correct behavior: it preserves the message for investigation rather than discarding it. The operational problem is that messages accumulate in the DLQ silently unless someone has configured an alert on DLQ depth.

A DLQ that has been accumulating messages for three days represents three days of failed message delivery that no alert flagged, because the SAP sender considered delivery successful (the message reached the hub), and the hub considered its job done (the message was moved to the DLQ per the error handling policy). The business discovers the failure when a downstream process produces incorrect or missing data.

The dual monitoring requirement and where responsibility gaps form

Any integration that passes through middleware requires monitoring at two points: the sending system and the hub. The sending system confirms that the message was handed off. The hub confirms that the message was processed and delivered. Neither confirmation alone is sufficient.

In most organizations, these two points are owned by different teams. The SAP Basis or operations team monitors the SAP side. A middleware team, a BTP operations team, or an infrastructure team monitors the hub. When a message fails somewhere in the middle, the investigation requires both teams to look at their respective monitoring, compare timestamps and message identifiers, and reconstruct the failure sequence across the boundary.

The gap forms when the two monitoring environments do not share a common identifier for each message. Without a correlation ID that persists from the SAP sender through the middleware to the target system, matching a SAP-side event to a hub-side event requires timestamp alignment and manual reconciliation. This is slow and error-prone under incident pressure.

The architectural decision that eliminates this gap is requiring a correlation ID in every message from the point of origin. The SAP sender generates or includes a unique message identifier in the payload. The middleware preserves that identifier in its processing logs. The target system includes it in application-level acknowledgments. When a failure occurs, any team can search all monitoring systems using the same identifier and immediately locate the relevant events at each processing step.

Transformation failures: technically delivered, business outcome failed

Message transformation in middleware, converting an IDoc format to a REST payload, mapping field names between systems, restructuring hierarchical data, introduces a failure mode that neither the SAP sender nor the target receiver automatically detects. The transformation runs in the middleware. If the transformation produces an output that is syntactically valid but semantically incorrect, the message is delivered successfully and the target system processes it without error. The business outcome is wrong.

An order IDoc where a field mapping error causes the quantity to be copied into the price field will create a purchase order with a correct structure and incorrect values. Both the middleware and the target system report success. The error surfaces when someone reviews the purchase order and notices that the price is exactly equal to the ordered quantity, which is an implausible coincidence.

Monitoring that catches this category of failure requires payload validation at the middleware level, checking that transformed outputs contain expected field values within expected ranges, not just that the transformation completed without a runtime error. This is a monitoring requirement that belongs in the integration hub design specification, not discovered after the first production incident.

SAP Integration Suite: the monitoring interface most teams underuse

SAP Integration Suite on BTP provides an Operations view that shows message processing status, flow execution results, and error logs. It is the correct tool for monitoring BTP-hosted integration flows. It is also a tool that most SAP Basis teams have read-only access to at best and have never used in an operational context.

The more useful capability for integration monitoring is the Integration Suite OData API. It exposes message processing status, flow execution statistics, and error counts in a machine-readable format that monitoring platforms can poll and alert on. A monitoring platform configured to query the Integration Suite API every minute and alert when error rates on specific flows exceed a threshold provides the real-time hub-side visibility that the Operations view requires manual checking to achieve.

The setup requires an API client credential in the BTP subaccount with message monitoring scope, an endpoint for the Integration Suite management API, and a monitoring platform capable of querying REST APIs. Most SAP monitoring tools do not include this integration out of the box, which is why the Operations view remains a manually-checked tool rather than an alerting source. Building the API integration changes that.

Architecture decisions that make monitoring achievable

The monitoring consequences of an integration hub architecture are largely determined by decisions made during the architecture phase, not the operations phase. Three decisions have the highest impact on monitoring coverage.

First, standardize on a single integration platform for the majority of SAP message flows rather than allowing each project team to introduce their own middleware. A landscape where integrations run on five different platforms requires five different monitoring approaches, five different alert configurations, and five different escalation paths. Consolidation does not need to be immediate or absolute, but it should be the stated direction and new integrations should require explicit justification to deviate from the standard platform.

Second, define the monitoring ownership boundary explicitly in the integration architecture document. Who monitors the SAP sender side? Who monitors the hub? Who monitors the target receiver side? Who is the escalation contact when a message fails in transit? These questions have operational answers that need to be established before the first production incident, not during it.

Third, require DLQ alerting and correlation ID implementation as non-negotiable deliverables for every new integration, not optional nice-to-haves. These are not complex to implement. They are consistently omitted because they are not part of the functional requirements that drive project delivery timelines. Making them part of the integration acceptance criteria, the same way functional business requirements are acceptance criteria, ensures they are implemented before go-live rather than retrofitted after the first silent failure.

A middleware architecture designed with these three requirements met will not eliminate integration failures. It will ensure that when a failure occurs, the monitoring layer has the data needed to detect it quickly and the organizational structure in place to act on it. That is the only realistic goal for integration monitoring in a complex SAP landscape.

Redpeaks monitors SAP-side interface metrics including IDoc status, RFC queue depth, and qRFC health, and supports integration with BTP Operations API data for end-to-end integration visibility across the middleware boundary. See the integration monitoring coverage.

L’article SAP integration hub design: how middleware architecture affects monitoring coverage est apparu en premier sur Real-time SAP monitoring software | Redpeaks .

That scenario is not hypothetical. It plays out in environments that chose agent-based monitoring without fully accounting for the maintenance it creates. At one system, the cost seems manageable. At ten systems with different patch cycles, different SAP versions, and different agent configurations, the maintenance work becomes a parallel operational track that nobody explicitly budgeted for.

Agentless monitoring solves this by removing the agent from the SAP system entirely. The monitored system has no monitoring software installed on it. No transport requests. No ABAP programs deployed. No processes running on the application server. The connection is made entirely from outside, using standard SAP interfaces that already exist. This article covers exactly how that works technically, what it means operationally, and where the approach has limits worth being honest about.

What agentless actually means in an SAP context ? 

The agent as a maintenance dependency

An agent in the traditional monitoring sense is a software process running on or within the monitored system. For SAP, this takes several forms. An OS-level agent running on the Linux or Windows host reads process metrics, file system data, and network statistics. An ABAP agent deployed via transport runs programs, reads tables, and executes function modules directly inside the SAP ABAP stack. A Java monitoring agent hooks into the JVM to read thread states, heap memory, and class loading. Each of these is software that needs to exist, run reliably, and remain compatible with the SAP environment as it evolves.

The maintenance dependency each agent creates is specific to its type. An OS-level agent needs to be updated when the operating system changes, tested when the hardware changes, and restarted when it crashes. An ABAP agent deployed via transport needs to pass through the SAP transport landscape: installed in development, tested in QA, promoted to production, and re-tested after every SAP upgrade that might have changed the behavior of the functions it calls. A Java agent needs version compatibility with the SAP Java VM, which changes with enhancement packages and feature packs.

When an organization runs a single SAP system, these maintenance tasks are manageable. When an MSP manages 40 SAP systems for different clients, each with its own patch cycle, each requiring independent agent validation, the maintenance volume becomes the operational cost that was not in the original pricing model.

What the connection looks like without an agent ? 

Agentless monitoring connects to the SAP system from the outside using interfaces the system already provides. The connection path depends on which layer of the SAP stack is being monitored.

For the ABAP application layer, the connection is an RFC of type 3: an external RFC connection pointing to the SAP system’s message server or gateway. The monitoring collector sends RFC calls to the SAP system, which executes standard function modules or reads from standard tables and returns the result. No custom code runs on the SAP side. No transport is needed. The SAP system receives and processes RFC calls using the existing RFC infrastructure it uses for all other external connections.

For the SAP HANA database layer, the connection is a JDBC or ODBC connection to the HANA database, authenticated with a dedicated database-level monitoring user. The collector sends SQL queries against the system views in the SYS and _SYS_STATISTICS schemas: M_MEMORY_OVERVIEW, M_SERVICE_REPLICATION, M_DISK_USAGE, M_EXPENSIVE_STATEMENTS, and others. The HANA database executes these queries and returns the results. No HANA-side software is needed beyond the database user and its authorizations.

The monitoring collector, the software that initiates these connections and stores the returned data, runs on infrastructure separate from the SAP systems. It is external to everything being monitored. From the SAP system’s perspective, the monitoring collector looks like any other RFC client or database application: a connection that authenticates, queries, and disconnects.

How agentless data collection works technically ? 

RFC-based collection: reading the ABAP layer

The RFC protocol is SAP’s standard mechanism for inter-system communication. An external application that wants to call a function module in a remote SAP system establishes an RFC connection, sends a call request with the function module name and parameters, and receives the return parameters. This is exactly what SAP systems use to communicate with each other in distributed landscapes. The monitoring collector uses the same mechanism.

The function modules and table reads available via RFC cover the full set of ABAP-layer monitoring data: SM50 equivalent data is available through standard function modules that return work process state and statistics. SM37 job data is accessible via RFC-enabled batch job interfaces. IDoc and qRFC queue states are readable through standard ALE and RFC API function modules. System log data from SM21 is accessible through the system log read interfaces. None of this requires custom code. It uses the same RFC-accessible interfaces that CCMS, Solution Manager, and various SAP standard tools have used for years.

The collection interval is determined by the monitoring collector’s schedule. A collector configured for 60-second polling sends an RFC call every 60 seconds, receives the current system state data, and stores it. A collector configured for 30-second polling doubles the collection frequency. The SAP system processes these calls like any other RFC request, drawing from its available background or dialog work processes depending on how the RFC connection is configured. The overhead is proportional to the collection frequency and the data volume per call, and is generally small relative to production transaction load.

HANA SQL collection: reading the database layer

HANA system views, prefixed M_ in the SYS schema, are the primary source of HANA monitoring data. They expose real-time information about memory allocation, service states, active queries, replication status, disk usage, and dozens of other metrics. These views are standard HANA objects, documented by SAP, and queryable by any application with appropriate database privileges.

The monitoring collector connects to HANA via JDBC using a database user with MONITORING system privilege and CATALOG READ privilege. With those two privileges, it can query every M_* view in the SYS schema. No additional setup is required on the HANA side. No scripts are deployed. No stored procedures are installed. The monitoring user exists as a database user, its privileges are documented and auditable, and it can be reviewed or revoked at any time through standard HANA user management.

The separation between the ABAP RFC connection and the HANA SQL connection reflects the architecture of the SAP system itself. ABAP metrics and HANA metrics come from different layers with different access mechanisms. The monitoring collector maintains both connections independently. A change in the HANA configuration does not affect the RFC connection. A change in the ABAP authorization profile does not affect the HANA database user.

The collector: where the non-agent lives

Saying a monitoring approach is agentless does not mean there is no software involved. There is software: the monitoring collector. The distinction is where it runs. The collector runs on infrastructure that the SAP team controls but that is separate from the monitored SAP systems. It might be a dedicated server, a virtual machine, a container in a management network, or a cloud-hosted service. The key property is that it is not on the SAP application server, not installed in the HANA database, and not deployed through the SAP transport system.

This placement means the collector has its own lifecycle, independent of the SAP systems it monitors. When a SAP kernel is patched, the collector does not need to be updated. When SAP changes a standard function module interface, the collector’s next scheduled version update handles the adjustment without requiring any change on the monitored system. The monitored system has no knowledge of which monitoring tool version the collector is running. It only knows that an RFC client authenticated, sent a call, and received a response.

The collector’s availability matters for monitoring continuity. A collector that goes down stops collecting data, which means monitoring gaps. Collector high availability, whether through redundant instances or automatic failover, is a design concern for the monitoring infrastructure, not for the SAP systems. The SAP team does not manage the collector’s availability. The monitoring team or the MSP does.

The operational cost of agents that becomes visible at scale

One system, one agent: the cost seems manageable

A single agent installation on a single SAP system is a few hours of work. Create the transport, test in DEV, promote to QA, test, promote to production. Maybe a restart. Document the change. The overhead is real but contained. The compatibility test after the next SAP upgrade is another half-day. Over a year, the agent maintenance for one system might be 5 to 10 person-hours.

At that scale, the argument against agents is not compelling. The agent works, the data flows, the maintenance is occasional. Teams accept the overhead because it is invisible against the total operational workload.

Twenty systems, twenty agents: where the math changes

At 20 SAP systems, the agent maintenance scales linearly. Twenty transport sets to manage. Twenty compatibility tests per SAP upgrade cycle. Twenty restart windows to coordinate. Twenty change management records to create and close. If the organization runs quarterly SAP upgrades, that is 80 compatibility tests per year. If the agent vendor releases updates twice per year, that is 40 update deployments across 20 systems.

The math compounds when the 20 systems have different SAP versions, different operating systems, or different patch schedules. An agent that has been validated for S/4HANA 2023 FPS02 may behave differently on S/4HANA 2022 FPS04. The monitoring team needs to maintain a compatibility matrix and test each agent version against each SAP version before deploying. In a heterogeneous landscape, that matrix has real dimensions.

The invisible cost in this calculation is the project overhead. Every SAP upgrade project that includes agent compatibility testing is a larger project than it would be without agents. The testing effort is not always attributed to the monitoring tool in the project budget. It shows up as “upgrade project overrun” without a clear cause.

The upgrade problem: why agent maintenance compounds with SAP patch cycles

SAP releases kernel patches, enhancement packages, feature packs, and major releases on a schedule that has accelerated since the introduction of S/4HANA. Each release is a potential compatibility event for any software running on or within the SAP system. The monitoring vendor needs to test their agent against the new release, release an updated version, and customers need to deploy it before updating their SAP systems.

In practice, the sequence is rarely that clean. The SAP update releases ahead of the agent update. The customer has a maintenance window for the SAP patch but no compatible agent version. The options are to delay the SAP patch (unacceptable for security patches), to proceed with the patch and accept a monitoring gap until the agent update ships (which defeats the purpose of monitoring), or to remove the agent before patching and reinstall after (which is three change management records instead of one).

With agentless monitoring, this problem does not exist. The SAP kernel patch changes nothing about the RFC interface or the HANA system views. The monitoring collector continues collecting without modification. The upgrade project scope is smaller because monitoring compatibility is not a test item. The SAP team patches on schedule without coordinating with the monitoring vendor.

Authorization design: the agentless security model

What the monitoring user actually needs

An RFC-based monitoring connection authenticates as an SAP user. That user needs authorizations to execute the RFC calls and read the data the monitoring tool requires. The principle of least privilege applies here exactly as it does anywhere: the monitoring user should have exactly the access needed for monitoring and nothing beyond that.

The core authorization objects for ABAP-layer monitoring are S_RFC, which controls which RFC function groups and function modules can be called from external connections, S_TCODE, which controls access to transaction codes whose data the monitoring tool reads, and in some cases S_ADMI_FCD for specific system administration read functions. The exact values depend on which metrics the monitoring tool collects, and a well-documented monitoring tool provides a list of required authorization objects with their specific values.

Creating the monitoring user with a custom role built from these specific authorizations produces an account whose access is explicitly defined, documented, and auditable. A security team can review the role and confirm that the monitoring user cannot modify any SAP data, cannot execute any business transactions, and cannot access any application data beyond what is needed for system health metrics. That audit trail does not exist for an agent that has been granted broad OS-level process access or has been installed with a high-privilege account for convenience.

Why minimal authorization is more auditable than agent installation ?

An agent running on the OS level with root or Administrator privileges to access process information has a broad authorization footprint that is difficult to scope in an access review. The access control model for OS-level processes is binary: the process can read anything accessible by its user account, and scoping that to only monitoring-relevant data requires OS-level policy enforcement that is separate from the monitoring tool itself.

An RFC monitoring connection with a specifically configured authorization role has an explicit scope defined in SAP’s own access control system. The authorization review for the monitoring user is done in SU01 and the role editor, using the same tools the security team uses for all other user access reviews. The monitoring user’s access is no different in kind from any other functional SAP user. It is just narrower in scope.

The practical value of this auditability is most visible during security audits and penetration testing exercises. The question “what access does the monitoring system have” has a clear, precise answer that comes directly from the SAP authorization documentation, not from an external agent’s configuration files. That precision is valued by auditors and by the security teams responsible for the production systems.

What agentless monitoring cannot do, and what fills the gap ? 

OS-level metrics and the hybrid approach

Agentless SAP monitoring via RFC and HANA SQL provides coverage of the SAP ABAP application layer and the HANA database layer. It does not provide coverage of the operating system layer: file system utilization on non-HANA volumes, network interface traffic, hardware-level temperature and fan status, kernel-level memory pressure indicators that are not surfaced through SAP APIs.

This is the honest limitation of the architecture. RFC and SQL interfaces expose what SAP exposes. Some OS-level data is available through SAP APIs, because SAP reads OS metrics internally and exposes them through CCMS or through HANA system views. But the coverage is not complete.

The practical resolution for most environments is a hybrid approach. OS-level metrics are collected by standard infrastructure monitoring tools, whether that is a lightweight OS agent from the infrastructure monitoring platform, SNMP polling, or cloud provider native monitoring in hyperscaler deployments. SAP application and database metrics are collected agentlessly through the monitoring platform. The two data sources are presented in integrated dashboards where OS events and SAP events can be correlated without requiring either tool to cross into the other’s domain.

This hybrid is generally preferable to trying to extend the SAP-specific monitoring tool into OS coverage. OS monitoring is a solved problem with mature tooling. SAP application monitoring is a specialist problem with specific tooling requirements. Combining them in a purpose-built SAP monitoring tool that also installs OS agents reintroduces the maintenance dependency that agentless monitoring is designed to avoid.

When an agent is still the right answer

There are scenarios where an agent is the appropriate choice even in an environment that otherwise uses agentless monitoring. Custom metric collection that requires access to data not exposed through SAP’s standard APIs may need a custom ABAP report or a lightweight agent to collect and forward it. Some hardware monitoring scenarios require access to data that only the OS or BMC provides. Specific regulatory requirements may mandate a monitoring architecture that places monitoring code on the monitored system for chain-of-custody reasons.

Agentless is not a universal rule. It is the right default architecture for SAP monitoring because the standard SAP interfaces cover the metrics that matter most, the maintenance overhead is the dominant operational cost at scale, and the authorization model is cleaner. Where a specific requirement cannot be met through standard interfaces, an agent is a justified exception rather than a philosophical defeat.

The important operational discipline is treating agents as exceptions that are documented and reviewed, rather than as defaults that accumulate silently. An SAP landscape where every system has six different agents installed by six different teams over five years, none of them fully documented and some of them incompatible with current SAP versions, is the condition that agentless architecture prevents.

Deployment speed and onboarding at scale

The per-system connection timeline

Connecting a single SAP system to an agentless monitoring platform takes a predictable amount of time. Create the RFC monitoring user in SU01 with the required authorization role: 20 minutes. Create the RFC destination in SM59 pointing to the monitoring collector: 10 minutes. Verify the RFC connection test passes and the authorization test passes: 5 minutes. Configure the HANA monitoring database user with the required system privileges: 15 minutes. Verify HANA connectivity from the collector: 5 minutes. Start data collection and confirm metrics are appearing in the monitoring dashboard: 10 minutes.

Total elapsed time to add a new SAP system to monitoring: roughly 1 hour, plus any internal approval time for creating the monitoring user. No transport request. No SAP restart. No change management ticket for software installation. No compatibility testing against the specific SAP version. No involvement from the SAP vendor or the monitoring vendor beyond the initial platform setup.

In an agent-based scenario, the equivalent timeline includes creating and testing a transport in development, scheduling a promotion to QA, testing in QA, scheduling a promotion to production, executing the production deployment in a change window, and verifying the agent is running. Depending on the organization’s change management cadence, that sequence takes one to three weeks. For an MSP onboarding a new client system, the difference between one hour and three weeks has direct commercial implications.

How MSPs and large IT teams use this differently ? 

For an MSP managing SAP environments for multiple clients, the agentless architecture changes the economics of each new system onboarded. The onboarding cost is consistently low. The ongoing maintenance cost does not grow with the number of systems. A team that manages 50 SAP systems with agentless monitoring has the same per-system ongoing maintenance burden as one managing 5. The team managing 50 systems with agents has ten times the maintenance volume.

This difference is not just about efficiency. It affects what services the MSP can offer credibly. An MSP with low-overhead monitoring can offer monitoring coverage as part of a standard managed services package without inflating the per-system price to cover maintenance costs. An MSP with high-overhead monitoring either absorbs the maintenance cost as a margin reduction or passes it to clients as a monitoring surcharge that makes the pricing less competitive.

For large enterprise IT teams managing SAP landscapes internally, the advantage is different. The constraint is usually not per-system cost but engineering time. An architecture that does not require engineering involvement in every SAP upgrade cycle, and does not require coordination between the SAP upgrade team and the monitoring team for compatibility testing, returns engineering time to higher-value work. The SAP team owns the upgrades. The monitoring team owns the monitoring platform. Neither team needs the other’s involvement for routine maintenance.

The architecture that shrinks as you scale it

Most infrastructure grows more complex as the number of managed systems increases. More systems mean more agents, more configurations, more compatibility matrix entries, more maintenance tracks running in parallel. The operational overhead is proportional to the scale, and at a certain point it becomes the primary operational constraint rather than a background cost.

Agentless monitoring inverts this relationship. Adding a new SAP system to the monitoring landscape is the same operation regardless of whether it is the fifth system or the fiftieth. It is one RFC user, one authorization role, one database user, one collector configuration entry. The complexity of the monitoring infrastructure does not grow with the number of systems it covers. It grows with the complexity of the collector itself, which is a single point of investment shared across the entire monitored landscape.

That property, stable operational overhead as the landscape scales, is what makes agentless monitoring the appropriate default architecture for any organization managing more than a handful of SAP systems. Not because agents are always wrong, but because the maintenance cost of agents is a variable that compounds and eventually dominates, while the absence of agents removes that variable from the equation entirely.

Redpeaks connects to SAP systems via RFC and HANA SQL without agents, transports, or SAP-side software. A new system is typically live in monitoring within an hour of the RFC user being created. See the connection architecture in detail.

L’article SAP agentless monitoring architecture: how it works and why it matters at scale est apparu en premier sur Real-time SAP monitoring software | Redpeaks .

This article covers the architectural patterns that actually hold up when production systems fail, not the ones that look good in vendor presentations. It assumes you know what SAP HANA System Replication is. The goal is to cover the specific decisions and misconfigurations that determine whether your HA setup survives contact with a real outage.

What SAP high availability actually needs to protect against ?

The difference between HA and DR, and why conflating them creates gaps ?

High availability and disaster recovery are different problems with different solutions, and the SAP teams that handle both well treat them as separate design concerns from the start. HA is about keeping service running when a single component fails: a database node, an application server, a network link. The recovery target is minutes. The geographic scope is typically within a single data center or between two sites with low-latency connectivity.

Disaster recovery is about restoring service after a site-level event: a data center power failure, a major hardware incident, a regional network outage. The recovery target is hours. The geographic scope requires physical distance, which typically means asynchronous replication because synchronous replication across long distances introduces write latency that production HANA systems cannot absorb.

The gap that costs organizations the most is designing one system to do both jobs. A HANA System Replication setup in synchronous mode between two racks in the same data center provides HA but not DR. A setup in asynchronous mode between two data centers 500km apart provides DR but accepts potential data loss. A multi-tier replication setup with a synchronous secondary nearby and an asynchronous tertiary at distance provides both, but it is a more complex configuration to operate and test. Knowing which scenario you are designing for before you configure replication prevents the expensive discovery that your DR plan assumed capabilities your HA configuration does not provide.

Failure modes that standard HA configurations miss

A database node failover is the failure mode every SAP HA configuration is designed to handle. It is also among the rarest failure modes in a well-maintained environment. The failures that actually cause downtime in production are typically more mundane and more varied: network interface saturation between the application and database tiers, storage I/O degradation affecting HANA log write performance, a background job monopolizing work processes across all application server instances, or a configuration change that was not tested in non-production first.

Standard HA architecture does not protect against any of these. A two-node HANA cluster with Pacemaker handles database node failure. It does not help when the application server layer is the problem. It does not help when all application servers are reachable but the HANA primary is so busy with a rogue analytical query that dialog transactions are timing out.

This matters for architecture decisions because teams that design purely for node failure end up with a robust response to one failure mode and no coverage for the others. A complete HA approach considers the application tier, the integration layer, and the monitoring infrastructure alongside the database cluster.

The SAP HANA layer : system replication done right

Synchronous vs Asynchronous replication : the Choice that fixes your RPO

SAP HANA System Replication operates in three modes. The choice between them is not a preference. It is a decision that directly determines your Recovery Point Objective and has a measurable impact on primary system write performance.

SYNC mode is the correct choice for primary HA within a data center or between sites connected by a network with round-trip latency under 1ms. The performance impact is real but bounded, and it is the only mode that guarantees zero data loss on failover. Running SYNC over a high-latency WAN link introduces write latency that accumulates across every committed transaction. In a busy production system, this becomes visible to users.

SYNCMEM is a reasonable compromise when SYNC performance impact is measurable and the theoretical risk of data still in memory on the secondary (not yet written to disk) is acceptable. For most production environments, this risk is very small, and SYNCMEM performs noticeably better than SYNC under high write load.

ASYNC for primary HA is an architectural mistake that is surprisingly common. It is easy to see why it happens: the configuration looks identical, the secondary is online, and in a test environment with low write volume the replication lag is negligible. Under production load, ASYNC lag can grow to seconds or minutes during write-intensive periods. A failover during a lag window means committed transactions on the primary that never reached the secondary are permanently lost.

HANA system replication with Pacemaker : configuration details that matter

Pacemaker is the standard cluster resource manager for SAP HANA HA on Linux. It handles node failure detection, failover sequencing, and fencing (STONITH: Shoot The Other Node In The Head). Each of those three functions has configuration details that determine whether a failover completes cleanly or hangs.

Node failure detection speed is controlled by the Pacemaker timeout and ping interval configuration. The defaults are conservative, which means a failed node may not be detected for 30-60 seconds under default settings. For environments with aggressive RTO targets, tuning these values downward is necessary, but it requires careful testing. Overly aggressive detection thresholds cause false positives: Pacemaker declares a node failed during a brief network hiccup and initiates a failover that was not needed.

STONITH configuration is the piece most frequently treated as a checkbox during setup. The purpose of fencing is to guarantee that a node Pacemaker believes is failed cannot continue writing to shared resources before the secondary takes over, which could otherwise cause split-brain data corruption. In a virtual machine environment, STONITH is typically implemented via the hypervisor’s power management API. In a bare-metal environment, it requires a dedicated out-of-band management network and hardware. Environments that disable STONITH because it is difficult to configure are accepting split-brain risk in exchange for simpler setup. This is not a trade-off that should be made for production HA.

Multi-Tier Replication : when you need both HA and DR ?

HANA System Replication supports chaining: a primary replicates synchronously to a local secondary (HA), and that secondary replicates asynchronously to a remote tertiary (DR). This configuration provides near-zero RPO for local failures and a DR target that accepts some data loss but preserves geographic separation.

The operational complexity of multi-tier replication is higher than single-tier. After a primary failure and HA failover, the old secondary is now the new primary, and the tertiary needs to be repointed to replicate from it. This repointing is not automatic by default. It requires either manual intervention or a custom automation script as part of the failover runbook. Teams that deploy multi-tier replication without documenting and testing the DR repointing procedure have a configuration that works for the first failure mode but leaves them manually patching together a DR chain while dealing with an active incident.

Application server high availability : the layer that gets less attention

The enqueue replication server : the most commonly misconfigured SAP HA component

The SAP Enqueue Server manages lock management for the ABAP application. It is a single process. In a standard installation without HA configuration, the Enqueue Server runs on one application server instance, and if that instance fails, all locks are lost. Users receive a session error, ongoing transactions cannot be committed, and the system effectively needs a restart to clear the lock table.

The Enqueue Replication Server (ERS) solves this by maintaining a replicated copy of the lock table on a second instance. When the primary Enqueue Server fails, the ERS promotes itself, and the lock table is preserved. The failover is transparent to users in most cases.

The configuration gap that appears repeatedly in production environments is ERS setup that is technically present but not correctly integrated with Pacemaker. The ERS instance exists and replicates the lock table, but Pacemaker does not know about it, so a node failure that takes down the primary Enqueue Server does not trigger an automatic ERS promotion. The lock table is replicated but not activated. The result is the same downtime as if ERS had not been configured at all.

Verifying correct ERS-Pacemaker integration should be part of every HA configuration review. The test is straightforward: simulate a failure of the node running the primary Enqueue Server and confirm that the ERS promotes cleanly and users with active sessions can continue their transactions. If that test has not been run, the ERS configuration is unverified.

Distributing application server instances without creating new failure modes

Running multiple SAP dialog instances across several application servers is the standard approach to application-layer availability. If one AS instance fails, users reconnect through the message server to another available instance. This works reliably for stateless operations.

The failure mode that multiple AS instances do not protect against is work process pool saturation across all instances simultaneously. If a runaway batch job or a poorly optimized report monopolizes background or dialog work processes on every available application server, the system is effectively unavailable even though no instance has failed. HA architecture at the infrastructure level does not address this.

Work process distribution also requires that the message server, which handles load balancing between application server instances, is itself protected. In most production deployments the message server runs as a component of the primary application server instance. A failure of that instance takes down both the dialog processes and the routing layer. Running the message server on a dedicated instance with its own failover configuration adds complexity but removes a meaningful single point of failure in high-demand environments.

High availability in cloud and hybrid environments

What changes when SAP runs on a hyperscaler ? 

The underlying HA concepts for SAP on AWS, Azure, or GCP are the same as on-premise. HANA System Replication, Pacemaker, ERS, multiple AS instances. What changes is the infrastructure layer those components run on, and that layer introduces both new capabilities and new constraints.

Availability Zones on hyperscalers provide physical separation within a region, and placing the primary and secondary HANA nodes in separate AZs protects against a zone-level failure. The practical constraint is network latency. AZ-to-AZ latency within a single region typically sits between 1ms and 2ms, which is within the range where HANA SYNC replication is viable but closer to the threshold where write-heavy workloads start showing measurable impact. Testing replication performance under production-representative write load before committing to a cross-AZ SYNC configuration is a necessary step, not an optional one.

Hyperscalers also handle STONITH differently from on-premise environments. The hardware-based IPMI/BMC fencing that is standard on bare metal is not available in a virtual machine context. Cloud-native STONITH agents use the hyperscaler’s instance management APIs to power off a target node. These agents are well-tested and reliable, but they require the appropriate IAM permissions to be configured, and those permissions need to be verified before a real failover scenario, not during one.

RISE with SAP and the monitoring boundary

RISE with SAP moves infrastructure management and base platform operations to SAP and the underlying hyperscaler. For HA architecture specifically, this means SAP manages the HANA cluster configuration, the Pacemaker setup, and the infrastructure-level failover for the S/4HANA core. The customer does not configure or maintain those components directly.

What the customer retains in a RISE environment is responsibility for application-level availability: the extensions built on SAP BTP, the integrations with non-SAP systems, the background job scheduling that determines whether critical processes run within their windows, and critically, the monitoring layer that provides visibility into whether the system is actually healthy from a business perspective.

SAP’s RISE SLA covers infrastructure availability. It does not cover the health of custom ABAP code, the success rate of interface processing, or whether scheduled jobs completed within their business deadlines. An organization running on RISE that has no independent monitoring layer is dependent entirely on SAP’s support portal to discover when something is wrong at the application layer. That is a meaningful operational gap, regardless of what the infrastructure SLA says.

Testing your HA configuration : the step most teams skip

An untested failover is an unknown failover

HA configurations degrade over time without anyone noticing. A cluster resource that was correctly registered with Pacemaker at go-live gets orphaned when an OS patch changes a service name. A Pacemaker timeout that was calibrated for the original hardware profile no longer fits after a VM resize. An ERS instance that was verified after initial setup was never re-verified after a major SAP upgrade.

The only way to know whether a failover will work is to run one. Not a simulated failover in a sandbox environment with a fraction of the data. An actual failover of the production cluster, in a maintenance window, with the operations team watching the monitoring dashboards and timing each phase of the recovery sequence.

Most organizations do not do this annually. Many have never done it at all. The argument against testing is risk: a failover test could itself cause an unplanned outage if something goes wrong. This argument is real. But the counterargument is that discovering a broken failover configuration during an actual production incident, without a maintenance window, under pressure, with users affected, is a much worse outcome than discovering it during a controlled test when you have time to fix it.

What a realistic HA test covers?

A useful HA test is not just verifying that the secondary HANA node picks up after a primary shutdown. It tests the full recovery sequence and measures each phase.

• Time from primary failure to Pacemaker detection : should be under 30 seconds with standard configuration.
• Time from detection to STONITH completion : confirms the fencing mechanism is working.
• Time from fencing to secondary promotion : the HANA takeover phase, typically 30-90 seconds depending on delta log volume.
• Time from secondary promotion to first successful user login : includes application server reconnection and message server registration.
• ERS behavior : confirm that users with active sessions at the time of failure can continue their transactions without a session error after reconnection.
• Alert delivery : confirm that the monitoring system detected the failure and routed the correct alert to the correct team within the expected timeframe.

That last point is worth emphasis. An HA test that does not include monitoring verification is incomplete. The cluster might recover in 90 seconds, but if the operations team found out about the failure by reading an email 20 minutes later, the effective MTTR for that incident includes the detection gap. Monitoring is not separate from HA architecture. It is the layer that determines whether the architecture performs as designed when something actually goes wrong.

Monitoring as a functional component of SAP high availability

HA architecture documents typically end at the infrastructure layer. Cluster configuration, replication mode, fencing setup. The monitoring layer is usually addressed separately, in a different section of the architecture documentation, by a different team.

This separation creates a practical problem. During a real failover, the monitoring system is the primary source of truth for what is happening and how fast. If it shows a HANA takeover in progress, the operations team knows not to restart services manually. If it shows the ERS promotion failing, they know where to focus. If it shows the alert was triggered 40 seconds after failure detection, they know the escalation chain is working. Without that real-time view, the response is slower and the risk of a manual intervention making things worse is higher.

The monitoring layer also catches the failure modes that HA architecture does not handle: the degraded performance that precedes a node failure, the work process saturation that makes the system effectively unavailable without any infrastructure event, the background job that is running at 200% of its normal duration and is about to miss a deadline that will require manual remediation. None of those trigger a Pacemaker event. All of them affect business continuity.

A well-designed SAP HA architecture specifies what the monitoring layer needs to observe, at what frequency, with what alert routing. It does not leave monitoring as an afterthought that gets configured by whoever is available after go-live. The two designs are not separate: one protects the infrastructure, the other provides the visibility that makes the infrastructure protection actionable.

The patterns that actually hold

SAP high availability is not a configuration you set once and forget. It is a system of interdependent components, each of which can drift from its intended state over time, and each of which needs to be periodically verified to confirm it still does what the architecture document says it does.

The patterns that hold under real production pressure have a few things in common. They separate HA from DR by design, not by assumption. They protect the Enqueue layer with the same rigor as the HANA layer, because a lock table loss is as disruptive as a database node failure. They test failover on a schedule rather than waiting for an incident to discover gaps. And they treat monitoring not as an add-on but as a structural requirement: the layer that converts a theoretical HA capability into a practical one.

The configurations that fail under pressure are the ones where each individual component was correctly installed but the interactions between components were never validated as a system. The HANA cluster is ready. The ERS is configured. The monitoring is running. But the ERS was never registered with Pacemaker, the monitoring threshold for HANA takeover was set too low and fires false positives, and the failover test was scheduled twice and cancelled both times because production was too busy.

That is not an HA configuration. It is a set of HA components that have not been assembled into a working system. The difference becomes apparent at 03:00 on a Monday when the primary node goes down.

Redpeaks monitors SAP HANA System Replication status, Pacemaker cluster health, application server availability, and ERS state in real time, with alerting that covers the transition phases of a failover, not just the steady-state metrics.

See the monitoring coverage details.

L’article SAP high availability architecture : patterns that hold under real production pressure est apparu en premier sur Real-time SAP monitoring software | Redpeaks .

L’article Designing Resilient SAP Landscapes for Hybrid Cloud and S/4HANA Deployments est apparu en premier sur Real-time SAP monitoring software | Redpeaks .