Skip to main content
ComponentsEngineJS ProfilerMobile AppRPA Bot RecorderRUM JS
Availability2022.1 or later

Configure SAP Diagnostics

Detect SAP process failures

SAP Commerce Cloud

Monitoring by deployment type

Configure diagnostic-file parsing

Parse supported file formats

Configure categorization

Group failures consistently

​
Configure Crash and Diagnostic-File Monitoring for SAP

Configure GermainUX to detect SAP-related process failures and diagnostic files using accessible logs, files, process status, browser telemetry, and custom parsers. GermainUX can detect and analyze only the crash evidence made available through configured data sources. It does not automatically understand every SAP crash, ABAP short dump, or binary core file.

​
Supported capabilities

Depending on the available telemetry, GermainUX can:
  • Detect that a monitored process or service stopped
  • Detect the creation of a diagnostic or crash file
  • Collect approved file metadata
  • Parse supported text-based diagnostic content
  • Collect exceptions from accessible application logs
  • Categorize recurring and new errors
  • Correlate events using timestamps and available identifiers
  • Associate browser activity with nearby backend events
  • Alert when a new or recurring failure occurs
  • Report crash and failure trends

​
Components

The primary component for this page is the GermainUX Engine.

​
Prerequisites

Before configuring crash monitoring:
  • Deploy and start the GermainUX Engine.
  • Identify the processes, services, logs, and diagnostic directories to monitor.
  • Confirm that the Engine can reach the relevant hosts and files.
  • Create read-only credentials where possible.
  • Obtain representative examples of the diagnostic content.
  • Determine whether the files are text or binary.
  • Configure application and environment names.
  • Establish privacy and retention requirements.
  • Define which events should generate alerts.
RUM JS is optional but useful when you want to examine browser activity near the time of a backend failure.

​
Identify available crash evidence

Document the sources available in the target SAP environment. The exact sources depend on the SAP product and hosting model.

​
SAP Commerce Cloud

For SAP Commerce Cloud, formerly SAP Hybris, available monitoring depends on whether the environment is SAP-managed or customer-controlled.

​
Customer-controlled Commerce environment

GermainUX may monitor:
  • Java process availability
  • Java application logs
  • Web-server logs
  • Accessible diagnostic files
  • Host CPU, memory, and disk
  • HTTP and OCC endpoints
  • Supported databases
  • Storefront browser errors
  • Synthetic commerce journeys
The GermainUX Code Profiler may capture supported Java exceptions when:
  • The runtime is supported.
  • Agent installation is permitted.
  • The organization controls the Java process.
  • The deployment has been approved.

​
SAP-managed Commerce Cloud

Direct access to servers, JVMs, logs, and diagnostic files may be restricted. In that case, GermainUX monitoring is limited to the data sources made available to the customer, such as:
  • Storefront RUM
  • Browser errors and requests
  • Accessible APIs
  • Exported logs
  • Available observability integrations
  • Synthetic scenarios
Do not claim server- or JVM-level crash monitoring until access has been confirmed.

​
Configure process and service monitoring

Use the Engine to monitor supported operating-system processes or services associated with the SAP environment. Configure:
  • Server
  • Operating system
  • Engine
  • Credentials
  • Process or service name
  • Expected running state
  • Expected instance count
  • Collection frequency
  • Warning condition
  • Critical condition
  • Application
  • Environment
Potential conditions include:
  • Process missing
  • Service stopped
  • Instance count below expected
  • Repeated restart
  • Process unavailable after maintenance
A stopped process indicates an availability condition. It does not, by itself, identify the root cause.

​
Configure log-based crash detection

Use an accessible log when the application records failure evidence as text.

​
Configure the log source

Define:
  • Host
  • Exact path
  • File pattern
  • Encoding
  • Timestamp format
  • Time zone
  • Rotation behavior
  • Multiline rules
  • Parser
  • Application and environment
  • Privacy rules
  • Polling interval

​
Configure failure patterns

Potential patterns include:
  • Fatal exception
  • Unhandled exception
  • Process terminated
  • Out-of-memory condition
  • Startup failure
  • Service shutdown
  • Repeated restart
  • Critical integration failure
Use patterns validated against real examples from the target environment. Avoid generic keywords such as error or exception without context; they can produce large numbers of false positives.

​
Configure diagnostic-directory monitoring

Use a directory monitor to detect new diagnostic files. Configure: Avoid broad paths that contain unrelated files.

​
File metadata

Even when the file content cannot be parsed, GermainUX can use approved metadata such as:
  • File name
  • Path
  • Size
  • Creation time
  • Modification time
  • Host
  • Application
  • Environment
This can indicate that a diagnostic artifact was created without claiming to understand its contents.

​
Configure diagnostic-file parsing

Use a parser only when the file format is supported or a custom parser has been implemented and tested.
Crash and Diagnostic-File Monitoring for SAP (Configure): Configure diagnostic-file parsing

​
Text-based files

A generic or custom parser may extract:
  • Timestamp
  • Error type
  • Severity
  • Component
  • Message
  • Stack trace
  • Error code
  • Host
  • Process
  • Thread
  • Correlation identifier

​
Binary files

Do not ingest binary core files as ordinary text logs. GermainUX can detect their creation and collect metadata, but content analysis requires a compatible external tool or purpose-built parser.

​
ABAP short dumps

GermainUX does not natively retrieve or interpret ABAP short dumps merely because SAP monitoring is enabled. ST22 or other ABAP diagnostic data can be analyzed only when it is:
  • Exported through an accessible format
  • Retrieved through an approved integration
  • Supplied to GermainUX
  • Parsed by a compatible custom or supported parser

​
Configure Java exception monitoring for SAP Commerce Cloud

For a supported, customer-controlled Java runtime, GermainUX may collect exceptions through:
  • Java application logs
  • Code Profiler instrumentation
  • Process monitoring
  • HTTP availability checks
Potential Java failure evidence includes:
  • Unhandled exception
  • Out-of-memory error
  • Thread failure
  • Application startup failure
  • Process termination
  • Repeated restart
  • Failed downstream request
Code Profiler availability depends on runtime support and permission to install the agent.

​
Configure browser-side evidence

When RUM JS is deployed, GermainUX can capture the browser activity preceding or surrounding a user-visible failure. Available evidence can include:
  • User action
  • Logical page
  • JavaScript error
  • Unhandled promise rejection
  • Failed request
  • Resource error
  • Browser freeze
  • Session Replay
  • Application message
This evidence can show what the user experienced. It does not prove that the user action caused a backend process to crash.

​
Configure correlation

GermainUX can associate evidence when compatible identifiers or timing are available. Potential correlation attributes include:
  • Application
  • Environment
  • Host
  • Timestamp
  • User
  • RUM session
  • Request identifier
  • Correlation identifier
  • Transaction identifier
  • Process or service

​
Identifier-based correlation

Use a shared request or correlation identifier when available. This provides stronger evidence than time proximity alone.

​
Time-based correlation

Time-based correlation can identify potentially related events, such as:
1

User performs an action

2

Browser request fails

3

Application log records a fatal exception

4

Monitored process stops

5

Diagnostic file appears

This sequence supports investigation but does not automatically prove causation. Ensure that browser, Engine, SAP, server, and database clocks are synchronized.

​
Configure categorization

Go to: Germain Workspace -> Settings —>Analytics -> Categorization Categorize failures using stable attributes such as:
  • Error type
  • Normalized message
  • Stack signature
  • Error code
  • Component
  • Process
  • File type
Remove variable values such as:
  • Timestamp
  • User ID
  • Session ID
  • Request ID
  • Memory address
  • Thread ID
  • Dynamic business identifier
  • Generated file suffix

​
Exact and fuzzy matching

Where the parsed data supports it:
  • Use exact matching for stable attributes that must be identical.
  • Use fuzzy matching for normalized messages or stack information that can vary slightly.
Categorization can help distinguish:
  • New failure categories
  • Recurring failures
  • Increasing failures
  • Failures introduced after a release
  • Similar failures across multiple hosts
Categorization quality depends on the fields successfully extracted from the source.
Crash and Diagnostic-File Monitoring for SAP (Configure): Exact and fuzzy matching
Crash and Diagnostic-File Monitoring for SAP (Configure): Exact and fuzzy matching, image 2

​
Configure KPIs

Potential KPIs include: Create only KPIs backed by actual configured data sources.

​
Configure dashboards

Go to: Germain Workspace → Settings -> Dashboards -> All Search for applicable SAP, availability, error, or technology dashboards, or create a custom dashboard. Recommended views include:
  • Failures over time
  • New versus recurring categories
  • Failures by application
  • Failures by environment
  • Failures by host
  • Process and service availability
  • Java exceptions
  • Diagnostic files created
  • Affected users and sessions
  • Failures by release
  • Related synthetic failures
Provide drill-through access to the underlying evidence and related sessions where available.

​
Configure alerts

Create alerts for actionable conditions such as:
  • Critical process stopped
  • Required service unavailable
  • New diagnostic file detected
  • New fatal error category
  • Failure volume increased
  • Java process restarted repeatedly
  • HTTP endpoint unavailable
  • Synthetic scenario failed
  • Multiple users affected by the same failure
Use:
  • Consecutive-failure thresholds
  • Deduplication
  • Categorization
  • Cooldown periods
  • Maintenance periods
  • Warning and critical severities
Avoid generating one alert for every repeated log line.

​
Configure reports

Schedule reports for:
  • Failure trends
  • New and recurring categories
  • Failures by host or application
  • Process availability
  • Java exception trends
  • Diagnostic-file activity
  • Affected-user counts
  • Failures introduced after releases
  • Resolution and recurrence

​
Privacy and retention

Diagnostic content can contain:
  • User identifiers
  • Business-document identifiers
  • File paths
  • Hostnames
  • SQL fragments
  • Request data
  • Authentication information
  • Personal or confidential data
Configure:
  • Field masking
  • Pattern-based redaction
  • Attribute exclusion
  • File-content restrictions
  • Retention
  • Role-based access
  • Export restrictions
Do not collect complete diagnostic content unless it is required and approved.

​
Validate the configuration

​
Process and service validation

Confirm that:
  • The intended process or service is monitored.
  • Its expected state is correct.
  • A safe test condition produces the correct KPI.
  • Recovery clears or updates the condition.

​
File detection validation

Confirm that:
  • Only matching files are detected.
  • Existing files are handled as intended.
  • A new test file creates one event.
  • Restarts do not duplicate previously processed files.
  • Rotation behavior is correct.

​
Parser validation

Confirm that:
  • Timestamp and time zone are correct.
  • Multiline data remains one event.
  • Error type and severity are extracted correctly.
  • Variable values are normalized.
  • Sensitive data is protected.
  • Unsupported binary data is not treated as text.

​
Correlation validation

Confirm that:
  • Related evidence shares a validated identifier or plausible time relationship.
  • Unrelated events are not automatically joined.
  • Session Replay is linked only when an appropriate session exists.
  • The analysis does not imply causation without supporting evidence.

​
Limitations

GermainUX does not automatically:
  • Profile ABAP execution
  • Retrieve ABAP short dumps
  • Interpret every SAP diagnostic format
  • Parse arbitrary binary core files
  • Determine the root cause from file creation alone
  • Prove that a particular user action caused a backend crash
  • Correlate events without compatible identifiers or validated rules
  • Access restricted SAP-managed cloud infrastructure
These capabilities require accessible telemetry and, in some cases, a custom integration or parser.

​
Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your SAP environment. Contact GermainUX Support.

​
Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.