Skip to main content
ComponentsEngine
Availability2022.1 or later

Plan the deployment

Map SAP sources first

Prerequisites

Requirements before installing

Install the Engine

Separate identity per instance

Configure SAP log and file monitoring

Approved log and file sources

​
Deploy the GermainUX Engine for SAP

Deploy the GermainUX Engine to monitor SAP APIs, logs, files, databases, infrastructure, and integrations from a location that can securely reach the monitored SAP environment. This page covers SAP-specific Engine deployment planning and validation. For installation prerequisites, operating-system procedures, service management, proxy settings, memory, and upgrades, use the general GermainUX Agent and Engine deployment documentation.

​
What the Engine monitors

The exact sources available depend on the SAP products, operating systems, databases, APIs, permissions, and GermainUX version.

​
Plan the deployment

​
Inventory the SAP environment

Identify:
  • SAP products and versions
  • Application and environment names
  • SAP hosts and network zones
  • API and OData endpoints
  • Log and file locations
  • Database technology and connection details
  • Operating systems
  • Load balancers and proxies
  • Authentication methods
  • Connected middleware and external services
  • Critical business processes
  • Expected data volume
  • Availability and disaster-recovery requirements
Use distinct application and environment values for production, test, development, and separate SAP systems.

​
Choose the Engine location

Install the Engine on a host that:
  • Can reach the required SAP APIs, servers, databases, and files
  • Can reach the GermainUX platform
  • Meets the supported operating-system and runtime requirements
  • Has sufficient CPU, memory, disk, and network capacity
  • Uses synchronized time
  • Can run continuously
  • Is maintained according to organizational security policies
Do not install the Engine directly on a production SAP host unless the deployment has been reviewed and approved.

​
# Determine the number of Engines

One Engine may monitor several sources when network access, security boundaries, and capacity allow it. Deploy multiple Engines when required for:
  • Separate network zones
  • Production and non-production isolation
  • Geographic regions
  • High availability
  • Large log or metric volumes
  • Independent SAP landscapes
  • Restricted database access
  • Disaster recovery
  • Reduced network latency
Assign each Engine a clear, unique name, such as:

​
Prerequisites

​
Host requirements

Before installation, confirm:
  • Supported operating system
  • Supported Java or packaged runtime, as applicable
  • Required CPU and memory
  • Sufficient disk for application files, state, logs, and temporary data
  • Service-account permissions
  • DNS resolution
  • Time synchronization
  • TLS trust
  • Proxy requirements
  • Firewall rules
Size the Engine according to the number of monitored sources, polling frequency, log throughput, query workload, and retained local state.

​
Accounts and permissions

Use dedicated monitoring accounts with minimum required permissions. Do not use personal administrator accounts.

​
Network access

Allow only the required communication between:
  • Engine and GermainUX
  • Engine and SAP APIs
  • Engine and SAP hosts
  • Engine and databases
  • Engine and integration endpoints
  • Engine and proxy or authentication services
Document:
  • Source host
  • Destination host
  • Port
  • Protocol
  • Direction
  • TLS requirements
  • Authentication method
  • Proxy route

​
Create the Engine configuration

In Germain Workspace, configure or verify:
  • Engine name
  • Application
  • Environment
  • Location
  • Credentials
  • Proxy
  • Data sources
  • Collection schedules
  • Timeouts
  • Privacy rules
  • Alerts
  • Maintenance periods
Store passwords and secrets in the GermainUX credential configuration. Do not place credentials directly in scripts, URLs, configuration notes, or log-pattern definitions.

​
Install the Engine

Follow the general GermainUX Agent installation procedure for the target operating system. At a high level:
1

Create or select the Engine configuration in GermainUX

2

Download the generated installation package or command

3

Copy it to the intended host

4

Install the Engine using the approved service account

5

Apply any required proxy and TLS configuration

6

Configure the Engine memory allocation

7

Start the Engine service

8

Confirm that it connects to GermainUX

9

Verify that the expected Engine name appears in the Workspace

Do not reuse the same Engine identity or local state directory for multiple running Engine instances.

​
Configure the service account

The Engine service account should:
  • Have permission to run as a service
  • Read the required Engine files
  • Write only to the Engine’s approved state and log directories
  • Read explicitly approved SAP logs
  • Reach the required APIs and databases
  • Access the configured credential mechanism
  • Have no unnecessary interactive or administrative privileges

​
Configure proxy access

If outbound communication requires a proxy, configure the Engine’s supported proxy settings. Validate:
  • Proxy hostname and port
  • Authentication
  • Proxy bypass rules
  • TLS inspection behavior
  • GermainUX endpoint reachability
  • SAP endpoint reachability, if routed through the proxy
Do not repurpose operating-system environment variables without confirming that they are supported by the Engine deployment.

​
Configure memory

Allocate memory based on:
  • Number of monitored sources
  • Log throughput
  • File sizes
  • API response sizes
  • Database-query volume
  • Collection frequency
  • Parsing complexity
  • Concurrent tasks
Monitor memory after rollout and adjust it when sustained utilization, garbage collection, or collection delays indicate insufficient capacity.

​
Configure SAP API monitoring

Configure each supported SAP endpoint as an Engine data source or monitor.

​
Required settings

For each endpoint, define:
  • Monitor name
  • Application and environment
  • URL
  • HTTP method
  • Authentication
  • Headers
  • Approved request body
  • Schedule
  • Timeout
  • Retry behavior
  • Success status
  • Functional validation
  • Response extraction
  • Sensitive-data handling
  • Warning and critical thresholds

​
Functional validation

An HTTP success status does not always mean the SAP operation succeeded. Where appropriate, validate:
  • Expected response field
  • Expected object count
  • Service status
  • Business status
  • Error collection
  • Response schema
  • Maximum response age
  • Minimum or maximum value
Keep validation lightweight and non-destructive.

​
API security

  • Use read-only operations whenever possible.
  • Do not log authentication headers.
  • Mask tokens and personal information.
  • Avoid collecting complete response bodies.
  • Limit response processing to required fields.
  • Set conservative timeouts and polling frequencies.
  • Coordinate high-frequency requests with SAP administrators.

​
Configure SAP log and file monitoring

The Engine can monitor approved local or remotely accessible SAP logs and files.

​
Define each source

Configure:
  • Host
  • Exact directory
  • File name or pattern
  • Encoding
  • Timestamp format
  • Time zone
  • Rotation behavior
  • Multiline-event rules
  • Start and continuation patterns
  • Severity extraction
  • Event-name extraction
  • Application and environment
  • Inclusion and exclusion rules
  • Sensitive-data masking
  • Collection frequency
Avoid broad recursive patterns that collect unrelated files.

​
Log rotation

Determine whether SAP:
  • Renames active files
  • Creates timestamped files
  • Compresses archived logs
  • Truncates the active file
  • Reuses file names
  • Deletes old files
Validate the configuration during an actual or simulated rotation. Confirm that events are neither lost nor collected twice.

​
Multiline events

Configure multiline handling for:
  • Stack traces
  • Structured error blocks
  • ABAP dumps
  • SQL errors
  • Integration messages
  • Exception details
Use a reliable timestamp or event-header pattern to identify the beginning of each event.

​
Core dumps and diagnostic files

For large binary or diagnostic files, monitor metadata or creation events unless full content collection is explicitly supported and required. Useful metadata can include:
  • File name
  • Path
  • Creation time
  • Modification time
  • Size
  • Host
  • Related process
  • Application
  • Environment
Do not attempt to ingest large binary dumps as ordinary text logs.

​
Configure SAP database monitoring

The SAP database may be SAP HANA or another supported database technology. Use the corresponding GermainUX database monitor and deployment instructions.

​
Connection configuration

Define:
  • Database type
  • Host and port
  • Database or service name
  • Authentication
  • TLS requirements
  • Connection timeout
  • Query timeout
  • Collection schedule
  • Application and environment
Depending on database support, monitor:
  • Availability
  • Connection time
  • CPU and memory
  • Storage and capacity
  • Sessions and connections
  • Locks and blocking
  • Long-running queries
  • Failed queries
  • Transaction volume
  • Replication or backup state
  • Database errors

​
Database-account security

Use a dedicated read-only account that can access only the required monitoring views. Do not grant:
  • Schema modification
  • Table modification
  • User administration
  • Backup administration
  • Unrestricted access to business data
Review monitoring queries with the database team before production rollout.

​
Configure operating-system monitoring

Where required, monitor the hosts supporting SAP. Recommended KPIs include:
  • CPU utilization
  • Memory utilization
  • Swap or paging
  • Disk usage
  • Disk latency
  • Network availability
  • Process status
  • Service status
  • File-system capacity
  • System uptime
Configure SAP-specific process and service checks only after confirming the expected names and deployment topology.

​
Configure integration monitoring

SAP environments commonly depend on middleware, APIs, queues, databases, and external systems. Monitor:
  • Endpoint availability
  • Response time
  • Message backlog
  • Failed transactions
  • Authentication
  • Timeouts
  • Scheduled integration jobs
  • File exchanges
  • Data synchronization
  • Downstream dependency failures
Use correlation identifiers where available and approved to connect integration activity with SAP logs, API calls, and real-user activity.

​
Correlate Engine and RUM data

When RUM JS is also deployed, correlate frontend and backend data using compatible identifiers such as:
  • Application and environment
  • Timestamp
  • User identifier
  • Request identifier
  • Correlation identifier
  • Transaction identifier
  • Business-process identifier
This can connect a user action with:
1

Browser request

2

SAP endpoint

3

Integration activity

4

SAP log event

5

Database operation

6

User-visible outcome

Do not collect sensitive business-document identifiers unless required and approved.

​
Configure alerts and maintenance periods

After establishing a representative baseline, configure alerts for:
  • API unavailable
  • API response-time degradation
  • Functional validation failure
  • New or increasing SAP log error
  • Database unavailable
  • Database capacity threshold
  • Blocking or long-running query
  • SAP process or service unavailable
  • Integration failure
  • Engine collection stopped
  • Engine resource exhaustion
Configure maintenance periods for:
  • SAP upgrades
  • Planned restarts
  • Database maintenance
  • Network changes
  • Integration deployments
  • Engine upgrades
Maintenance periods should suppress expected notifications without discarding valuable monitoring data unless explicitly required.

​
Validate the deployment

​
Engine validation

Confirm that:
  • The service is running.
  • The expected Engine name appears in GermainUX.
  • The Engine reports a recent heartbeat.
  • CPU and memory remain within acceptable ranges.
  • Local state and log directories are writable.
  • No repeated connection or authentication error appears.

​
API validation

Confirm that:
  • Each endpoint is reachable.
  • Authentication succeeds.
  • Functional validation works.
  • Response time is reasonable.
  • Sensitive fields are not stored.
  • Failure conditions generate the correct KPI and alert.

​
Log validation

Generate or identify an approved test event and confirm:
  • It is collected once.
  • Timestamp and time zone are correct.
  • Severity is correct.
  • Multiline content remains one event.
  • Application and environment are correct.
  • Sensitive content is masked.
  • Rotation does not cause loss or duplication.

​
Database validation

Confirm that:
  • The connection succeeds.
  • Monitoring queries complete within their timeout.
  • The account is read-only.
  • Expected metrics appear.
  • Queries do not create material database load.

​
Correlation validation

If frontend monitoring is enabled:
1

Perform a test SAP user action

2

Locate the browser session

3

Identify the related request

4

Locate corresponding Engine telemetry

5

Confirm that the timestamps and correlation attributes align

​
Production rollout checklist

Before completing the deployment, verify that:
  • The Engine host and network zone are approved.
  • The Engine has a unique name.
  • Production and non-production data are distinguishable.
  • Service-account permissions follow least privilege.
  • Credentials are stored securely.
  • Proxy and TLS settings work.
  • Memory is appropriate for the expected workload.
  • API polling is non-destructive and appropriately scheduled.
  • Log patterns target only approved files.
  • Log rotation has been tested.
  • Multiline parsing is correct.
  • Database monitoring uses a read-only account.
  • Sensitive data is masked or excluded.
  • Alerts use representative baselines.
  • Maintenance periods are configured.
  • Engine backup, upgrade, and recovery procedures are documented.

​
Troubleshooting

​
Engine does not appear in GermainUX

Check:
  • Engine service status
  • Engine identity and configuration
  • DNS resolution
  • Firewall access
  • Proxy settings
  • TLS trust
  • GermainUX hostname
  • System time
  • Engine logs

​
API collection fails

Verify:
  • Endpoint URL
  • Authentication
  • Certificate trust
  • Proxy route
  • Required headers
  • Permissions
  • Timeout
  • Rate limits
  • Functional-validation rules

​
SAP logs are not collected

Verify:
  • Exact file path
  • File-pattern matching
  • Service-account permissions
  • File encoding
  • Rotation behavior
  • Timestamp pattern
  • Remote mount availability
  • Collection schedule

​
Log events are duplicated

Review:
  • Overlapping file patterns
  • Multiple Engines reading the same files
  • Rotation and rename handling
  • State-store persistence
  • File truncation
  • Shared paths

​
Database monitoring is slow

Review:
  • Query cost
  • Polling frequency
  • Query timeout
  • Network latency
  • Database load
  • Missing monitoring-view permissions
  • Engine concurrency and memory
Do not increase polling frequency or query complexity without coordinating with the database team.

​
Engine uses excessive memory

Review:
  • Log volume
  • Large multiline events
  • Oversized API responses
  • Database result size
  • Concurrent tasks
  • Collection frequency
  • Parsing rules
  • State-store growth
  • Configured memory allocation

​
Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your Salesforce Experience Cloud 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.