A financial controller opens the daily revenue dashboard at 07:30 every morning. The report is always there, always populated, always showing last night’s data. Until one Wednesday, it is there but empty. No error message. The scheduled instance shows status Success in the Central Management Console. The report ran, it just delivered no data. The data source connection timed out during execution, the query returned zero rows, and BusinessObjects treated that as a successful completion.
That specific scenario is not unusual. It is the defining characteristic of BusinessObjects monitoring done poorly: the system reports success at the technical layer while delivering failure at the business layer. The schedule ran. The report is there. The dashboard is empty.
BusinessObjects sits in a position in the SAP landscape that makes it easy to undermonitor. It is not a transactional system. Failures do not immediately block business processes the way an SAP ERP outage does. Problems accumulate: reports that silently stop running, users who stop getting publications they were supposed to receive, rendering times that have doubled over six months. By the time the issue reaches someone who can fix it, it has been a problem for weeks.
This article covers the monitoring that actually catches these failures: what to watch in the scheduling layer, how to read service health beyond what the CMC shows, what user experience metrics are worth collecting, and where the most useful monitoring data in a BOBJ environment is sitting unread.
Why is BusinessObjects monitoring different from SAP application server monitoring ?
The CMC is a management console, not a monitoring tool
Most BOBJ administrators use the Central Management Console as their primary operational view. It shows service states, recent scheduled job instances, user sessions, and system configuration. It is the right tool for managing the environment. It is not designed for continuous monitoring.
The CMC shows current state, not historical state. A service that crashed and restarted at 03:00 shows as Running at 09:00 with no visible record of the restart unless the administrator knows to look at the audit database or server logs. A scheduled report that produced an empty result set shows in the job instance history with a green Success indicator. A report that has been silently failing every other run for two weeks shows a mix of Success and Failed entries in the instance history, and the overall success rate is only visible to someone who calculates it manually.
External monitoring that continuously polls BOBJ service health, job instance outcomes, and system resource consumption does what the CMC cannot: it records the sequence of states over time, correlates events across services, and produces alerts when conditions deviate from normal rather than requiring someone to check manually.
Service state and service health are not the same thing
BusinessObjects is composed of multiple server services: the Central Management Server (CMS), the File Repository Servers (input and output FRS), the Adaptive Processing Server (APS), the Web Intelligence Processing Server, the Crystal Reports Processing Server, the Adaptive Job Server, the Connection Server, and several others depending on the version and modules deployed. Each service has a state visible in the CMC: Running, Stopped, Failed.
Running means the service process is active and responding to the CMS. It does not mean the service is processing requests correctly. An Adaptive Job Server in Running state with its processing thread pool exhausted will not pick up new scheduled jobs. New jobs queue behind existing ones with no error indication on the server service itself. A Web Intelligence Processing Server in Running state with memory pressure will process report requests slowly without showing any abnormal state in the CMC.
Service health, as distinct from service state, requires metrics beyond process availability: request queue depth per service, active session count, memory consumption per service process, and error rates on incoming requests. These metrics are available through the BOBJ REST API and through the audit database. They are not visible in the CMC service state display. A monitoring approach that only checks service state will report a healthy system during conditions that users experience as slow or unresponsive.
Scheduling layer monitoring : beyond pass/fail status
What “success” actually means in a scheduled job instance
A scheduled BusinessObjects report reaches Success status when the report program executes without throwing an exception and the output file is written to the File Repository Server. Neither of those conditions requires that the report contains any data. A report whose query returns zero rows because the data source returned an empty result set completes with Success. A report whose data source connection timed out after three retries but then succeeded on a fourth attempt, producing partial data, also completes with Success if the final execution did not throw an exception.
For reports used as operational dashboards or executive summaries, the distinction between technical success and meaningful delivery is the difference between monitoring that works and monitoring that reports what users already know to be false. A zero-row output in a report that normally contains hundreds of rows is a delivery failure. Catching it requires monitoring at the output level, not just the execution level.
The monitoring check is straightforward for reports where the expected output size is known: compare the row count or file size of the current instance output against the historical average for the same report at the same schedule time. A report that normally produces a 2MB output and is currently producing 4KB is not a successful delivery, regardless of what the CMC instance status says. This comparison requires access to the FRS output file metadata and to the audit database’s historical execution records, but it is implementable without custom development.
Zero-row reports : the silent delivery failure nobody catches
Zero-row outputs are more common than most BOBJ administrators realize, because they are invisible to the standard monitoring layer. They tend to occur in specific patterns. Connection timeouts to data sources that retry successfully but too late to retrieve meaningful data. Date filter parameters in report queries that were correct when the schedule was first created and have drifted as the report ages. Universe or query panel filters that reference a prompt with a default value that no longer matches any data.
The practical monitoring approach is to maintain expected output size ranges for Tier 1 reports, defined as reports that business stakeholders actively rely on. For a weekly sales report, an expected output range of 500 to 2,000 rows based on historical execution captures both the zero-row failure and the unusually small result set that may indicate a partial data retrieval. Any execution outside that range flags for review.
This does not require monitoring every report in the environment. It requires identifying the 20 to 30 reports that, if they delivered empty or incorrect data, would generate an immediate business escalation, and applying the output size check specifically to those. The 80% of reports in the environment that are low-stakes operational queries do not need this level of monitoring attention.
Recurring schedules that silently stop recurring
BusinessObjects recurring schedules have a dependency on the CMS that is easy to break. A scheduled report configured to run daily at 06:00 relies on the Adaptive Job Server picking up the pending instance at the scheduled time. If the Adaptive Job Server was stopped or restarted at 05:55 and was not fully running at 06:00, the instance may not have been created. The next scheduled time is tomorrow at 06:00. The schedule did not fail. Nothing in the CMC indicates a problem. The report simply did not run.
A service restart that happens to overlap with a scheduled execution window creates a gap that is invisible unless the scheduled run is being monitored by expected execution time. Monitoring that tracks whether a specific schedule produced a new instance within a defined window after its expected execution time catches this gap. A schedule configured for 06:00 that has produced no new instance by 06:15 is an alert condition, regardless of what the service states show.
The more insidious version is a schedule that has been paused by an administrator during a maintenance window and never re-enabled. The schedule exists in the CMC in paused state. The report was last run three weeks ago. No one has noticed because the distribution list for that report has not complained, either because they are not monitoring their own received publications or because the report’s absence has not yet affected any visible business process.
| Watch out: Publication-based distribution in BusinessObjects adds a layer of failure modes that schedule monitoring alone does not catch. A publication can execute successfully, generate the report instances, and fail silently at the distribution step if the SMTP server is unavailable or if the destination email addresses are invalid. Monitoring the publication job instance status separately from the report generation status is necessary to confirm that delivery, not just generation, completed. |
Server service monitoring: the components that determine report availability
CMS availability and the cascade it controls
The Central Management Server is the authentication and metadata hub for the entire BusinessObjects environment. Every user login, every report access, every scheduled job instance creation goes through the CMS. A CMS that is unavailable or degraded does not produce partial failures: it produces a complete inability to access the system for any purpose.
CMS availability monitoring is the most critical single check in the BOBJ landscape. But availability monitoring alone misses the degraded state that precedes a CMS failure. A CMS under memory pressure processes authentication requests slowly. User login times increase from under a second to several seconds. Report opens take longer than usual because CMS metadata queries are slow. The system is technically available. Users are experiencing something that feels like unavailability.
The CMS metrics worth monitoring continuously are memory consumption relative to the configured Java heap (a CMS running at 85% of its heap will trigger garbage collection cycles that pause authentication processing), active database connection count to the CMS repository database (connection pool exhaustion prevents new sessions), and authentication request response times if accessible through the REST API. Response time degradation at the CMS is the leading indicator that availability problems are approaching.
Adaptive processing and job servers : capacity and queue depth
The Adaptive Processing Server handles document processing, search indexing, and several report types depending on the version deployed. The Adaptive Job Server manages scheduled job execution: it picks up pending scheduled instances, assigns them to appropriate processing servers, and tracks their execution.
Queue depth on the Adaptive Job Server is the metric that reveals scheduling capacity problems before they affect delivery times. Under normal conditions, pending job instances are picked up and started within seconds of their scheduled time. When the processing capacity across all connected processing servers is fully occupied, new pending instances wait in the queue. Users whose reports were scheduled for 06:00 receive their reports at 07:15 because the queue cleared only at 07:14.
Neither the delayed delivery nor the queue depth is visible in the standard CMC interface unless the administrator opens the job queue view and manually counts pending instances. External monitoring that polls the job server queue depth at regular intervals and alerts when pending instances are accumulating, provides the visibility that manual checks cannot sustain across a production environment.
Connection Server and the data source layer
The BusinessObjects Connection Server manages database connections from reports to underlying data sources. It maintains connection pools for each configured connection, handles retries, and provides the connection abstraction layer that allows reports to run regardless of which physical database server is active.
Connection Server failures produce a specific pattern: reports begin failing with database connection errors simultaneously across multiple reports that share the same data source connection. The failure is concentrated in one data source, not spread randomly across the report landscape. That concentration pattern points to the Connection Server or the data source itself rather than to a report-specific problem.
The metrics to monitor on the Connection Server are connection error rates by connection name, active connection count versus the pool maximum (approaching the pool maximum means new report executions will queue waiting for a free connection), and average query execution time per connection. A connection whose average query time has doubled over the past week is not failing, but it is showing the data source health degradation that precedes failures.
User experience metrics: rendering time, sessions, and cache
Report rendering time as a quality-of-service signal
There is a meaningful difference between a report that runs in 12 seconds and one that runs in 45 seconds, even if both are considered acceptable by any individual user. The 45-second report is occupying a processing slot on the Web Intelligence Processing Server for nearly four times as long, which reduces the capacity available for other concurrent users. If 10 users request the same slow report simultaneously, the processing server is occupied for the duration that 40 similar reports at the 12-second baseline would have occupied.
Rendering time per report, tracked over time, is the metric that catches performance regression before it creates visible capacity problems. A Web Intelligence report that rendered in 8 seconds last quarter and now consistently takes 25 seconds has had a performance regression somewhere: a universe change that introduced a less efficient query, a data volume growth that exceeded a threshold in the query plan, or a database index that was dropped or rebuilt incorrectly. Catching the regression early, before it creates downstream capacity problems, requires the historical rendering time data.
The audit database records execution time for every report instance. Mining that data for per-report trends, rather than looking at average rendering times across the environment, reveals the specific reports where performance has degraded. Average rendering times across hundreds of reports are dominated by a few very fast reports and a few very slow ones, and they do not change significantly even when individual reports have degraded substantially.
License utilization : the metric that produces silent lockouts
BusinessObjects licensing in most enterprise deployments uses either named user licenses (each user has a dedicated license) or concurrent access licenses (a pool of licenses shared by all users, with the limit being the number of simultaneous sessions). Both models have a ceiling, and when that ceiling is reached, the behavior is silent.
For concurrent access licenses, when the session count reaches the licensed maximum, new users attempting to log in receive a message indicating that no sessions are available. They cannot log in. There is no alert to the BOBJ administrator, no email, no monitoring event. The administrator discovers the problem when a user escalates. By that point, an unknown number of users have already been unable to log in for an unknown duration.
Monitoring concurrent session count against the license limit, with an alert at 80% of the maximum, provides the window to either request emergency license expansion or to investigate whether there are stale sessions consuming licenses without active users. Stale sessions, from users who closed their browser without logging out properly, are common in BOBJ environments and accumulate over time unless session timeout configuration is set correctly.
For named user licensing, the risk is different: adding new users without checking remaining license capacity. An organization that purchases 500 named user licenses and has provisioned 498 has very little room to add contractors, temporary workers, or new team members without a license procurement cycle. Monitoring the provisioned user count against the license limit flags this before the limit is reached.
Cache performance and why stale data is a monitoring problem
Web Intelligence and other BusinessObjects report types support a report caching mechanism: a freshly run report’s data is stored in the cache, and subsequent requests for the same report are served from the cache rather than re-executing the database query. This is beneficial for performance when many users access the same report but the underlying data changes infrequently.
Cache invalidation is where monitoring adds value. A report cache that was valid at 08:00 may contain stale data by 14:00 if the underlying data has been updated but the cache has not been refreshed. Users viewing the cached report see data that does not reflect current reality. They may make decisions based on it. The technical system is functioning normally. The business information being served is wrong.
Monitoring cache age per report, relative to the refresh frequency of the underlying data, identifies reports where the cache may be delivering stale information. A report on daily sales figures with a cache that was last refreshed 36 hours ago is not serving the data users expect when they open it during business hours. The appropriate monitoring response is either a cache invalidation trigger or an alert to the report owner that the refresh schedule needs adjustment.
The audit database: the monitoring source most BOBJ environments ignore
What the audit database actually contains ?
SAP BusinessObjects maintains an audit database that records every significant event in the system: every user login and logout, every report view, every scheduled job execution start and end, every publication dispatch, every failed authentication attempt, every document creation and deletion. In most production environments, this database has been running for years and contains a complete operational history of the BusinessObjects landscape.
The audit database is used for compliance reporting in organizations where it is used at all. It is used for monitoring almost nowhere, which is a missed opportunity because it is the richest source of operational data in the BOBJ environment. Most external monitoring tools for BOBJ poll the CMS REST API for real-time state information. The audit database adds the historical dimension that the REST API cannot provide: not what is happening now, but what has been happening and how that compares to what normally happens.
The tables in the audit database that are most relevant for monitoring purposes are the event log (all events by type, timestamp, user, and status), the job execution log (schedule instances with timing, success/failure, and output metadata), and the session log (login and logout events with session duration). These three tables together provide everything needed for trend-based monitoring of scheduling success rates, user activity patterns, and report performance over time.
Using audit data for proactive monitoring
The audit database enables a class of monitoring that real-time polling cannot support: anomaly detection based on historical patterns. If a specific report has been running every weekday at 06:00 for the past 18 months and has not run today, that absence is detectable by querying the audit database for the expected execution. If a specific user account has been inactive for 90 days and suddenly shows 200 login events in a 10-minute window, that anomaly is detectable from session log data.
More practically, the audit database allows calculation of scheduling success rates over rolling periods. A report with a 98% success rate over the past 30 days is behaving normally. The same report at 72% over the past 7 days is degrading and warrants investigation before the failure rate becomes high enough to affect business processes that depend on it.
The implementation path for audit-database-based monitoring is a scheduled query job that extracts aggregated metrics from the audit tables and feeds them into a monitoring platform. This is not a complex technical implementation. It does require that the audit database connection credentials are available to the monitoring platform and that the monitoring team understands which audit event types correspond to which operational conditions. That understanding is the main barrier. The data is already there.
| Note: The audit database grows continuously with every system event and requires a retention and archival strategy to remain performant as a query target. In high-activity environments, the event log table can grow to hundreds of millions of rows over a few years. Querying it without appropriate indexing and date-range filtering produces slow queries that compete with normal system activity. Most BOBJ administrators know the audit database exists but have not maintained it for efficient querying. Before using it as a monitoring source, verify the indexing strategy and establish a data retention window that balances historical depth against query performance. |
What BOBJ monitoring needs to protect against ?
BusinessObjects occupies a specific position in the SAP landscape: it is the layer where business data becomes business information. The transactional data that ERP systems generate is only useful at the point where a person can see it, interpret it, and act on it. When reports do not run, run slowly, or deliver incorrect data, the value of the underlying transactional systems is compromised regardless of how well those systems are performing.
The monitoring challenge is that the failures specific to this layer are not infrastructure failures. A server being down is obvious. A report that runs but delivers empty data is not. A publication that dispatches but delivers to the wrong recipient list is not. A rendering time that has doubled over three months is not. These are the failure modes that accumulate silently in BOBJ environments without triggering any of the standard infrastructure alerts.
Catching them requires monitoring that goes below the service state level: output validation for critical scheduled reports, queue depth tracking on processing servers, rendering time trends per report, session counts against license limits, and audit database queries that reveal patterns invisible to real-time polling. None of that is difficult to implement. What it requires is treating BusinessObjects as a system with its own specific failure modes, rather than as a server that is either up or down.
Redpeaks monitors SAP BusinessObjects environments including service availability, job instance success rates, rendering time trends, and license utilization, from a single agentless connection to both the BOBJ landscape and the underlying SAP systems. See the BusinessObjects monitoring coverage.
