Data Insight User Guides
Monitoring Step by Step User Guide
This guide explains how to use the DDR Monitoring function to review refresh templates, check execution progress, compare source and target data volumes, analyse source and target logs, and confirm whether a data refresh has completed successfully or requires investigation.
Purpose of DDR Monitoring
DDR Monitoring is the operational control area used after a refresh template has been created, released, scheduled, or executed. It gives the user visibility of what has been processed, what is still pending, and whether the source and target systems are aligned.
Monitoring is important because data refresh activities often involve many tables, business objects, background jobs, work processes, filters, and dependency rules. Without a central monitoring view, it becomes difficult to confirm whether the source export and target import have both completed correctly.
The Monitoring function helps business and technical users answer key questions such as: Which template was executed? Which export ID belongs to the run? How many records were processed? Did the source system send the data successfully? Did the target system receive and process it? Are there any warning, information, or error messages that need investigation?
Access Monitoring from the DDR Central Console
From the DDR Central Console, select Monitoring from the left hand navigation menu. This opens the Monitoring workspace where completed, running, or previously executed refresh templates can be reviewed.
The screenshot below highlights and zooms into the Monitoring button so users can clearly identify the correct menu option. This is useful because Monitoring sits close to Dashboard, Admin, Data Refresh, Object Refresh, and System Refresh in the same menu area.
Understand the Monitoring Workspace
The Monitoring workspace is divided into key areas. On the left side, the user can search and select a template or export run. On the right side, DDR displays a summary of source and target record counts and memory usage. Below the summary area, DDR provides detailed source and target logs.
When the screen is first opened, the user may see a blank monitoring view until a template, export ID, or business object is selected. This is expected behaviour and allows the user to search for the correct execution before reviewing details.
To search for refresh executions, open template runs, validate source and target counts, and review processing logs.
It is not used to build a new template. Template creation is handled from Data Refresh, Object Refresh, or System Refresh.
Search and Select the Correct Template or Export ID
Use the search fields to locate the execution that needs to be reviewed. The user can search using details such as connection name, export ID, template ID, or business object. Once the correct template is found, expand the template tree and select the relevant export run.
Each execution should be reviewed using the correct export ID. This is important because a single template may be executed multiple times, and each run may have different results, dates, filters, or processing messages.
| Search Field | Purpose |
|---|---|
| Connection Name | Use this to find runs linked to a specific source and target connection. |
| Export ID | Use this when the execution reference is already known. |
| Template ID | Use this to find a specific DDR template run. |
| Business Object | Use this when the user wants to find runs linked to a specific object or process. |
Review the Summary Section
After selecting the execution, the Summary section is populated with data classes, source record counts, target record counts, and memory usage. This gives the user a fast comparison between what was extracted from the source and what was processed into the target.
This comparison helps validate whether the refresh has moved the expected volume of data. Differences between source and target counts may be acceptable in some scenarios, for example where filters, exclusions, transformations, or scrambling rules are applied. However, unexpected differences should be investigated before the refresh is accepted as complete.
| Summary Column | Meaning | How to Use It |
|---|---|---|
| Data Class | Groups the processed data into categories such as master data, transaction data, organisation and customising, cluster tables, or BW dimension tables. | Use this to understand which type of data has been processed. |
| No. of Records Source | The number of records identified or processed from the source system. | Use this as the source baseline for validation. |
| Memory Used in KB Source | The memory footprint used by the source processing side. | Use this to understand source side processing impact. |
| No. of Records Target | The number of records processed into the target system. | Compare this against the source record count. |
| Memory Used in KB Target | The memory footprint used by the target processing side. | Use this to understand target side processing impact. |
Analyse the Source Log
The Source Log shows the messages generated by the source system during export and preparation. It helps users confirm whether the source system received the export instruction, created the background job, received template details, processed filters, and prepared the selected business object or table data.
Typical source log messages may include export instruction received, primary tables received, background job created, filter instruction received, filter condition processed successfully, and processing started for a selected business object.
Best practice: Review the Source Log first. If the source did not prepare or export the data correctly, the target system cannot be expected to receive a complete dataset.
Analyse the Target Log
The Target Log shows how the target system received and processed the exported data. It helps confirm whether records were received, work processes were available, splits were identified, import workers were started, memory was cleared, and records were processed successfully.
Target log review is essential because the source side can complete successfully while the target side may still have processing issues. The Target Log gives visibility of the import stage and helps technical users identify target side bottlenecks, processing errors, memory issues, or split related failures.
Important: Always review both logs. A successful source export does not automatically mean a successful target import.
Validate Source and Target Alignment
Once the logs are reviewed, compare the source and target record counts in the Summary section. This validation helps confirm whether the refresh has achieved the expected result.
If the source and target values are aligned, and the logs show successful processing messages, the run can normally be treated as successful. If there are differences, warnings, cancelled jobs, missing imports, or unclear messages, the run should be investigated before it is accepted.
Source and target logs show successful processing, and record counts are aligned with expectations.
Counts differ but there may be a valid reason such as filters, exclusions, or technical table handling.
Logs show failures, cancelled processing, missing target records, or unexplained record count differences.
Recommended Monitoring Checks
Before confirming that a refresh is complete, users should carry out a controlled monitoring review. This ensures the execution has been checked properly and avoids accepting incomplete or partially processed data.
- Confirm the correct template and export ID have been selected.
- Review the Summary section for source and target record counts.
- Check source memory usage and target memory usage for unusual spikes.
- Review the Source Log for export preparation, filter processing, and job start messages.
- Review the Target Log for import worker, split processing, record receipt, and completion messages.
- Investigate any warning, failure, cancelled, or incomplete processing messages.
- Confirm whether the result matches the expected business scenario.
- Document any issues before rerunning, rescheduling, or closing the refresh activity.
Monitoring Outcome
DDR Monitoring provides the visibility required to manage data refresh execution with confidence. It gives users a single place to review template selection, export references, data class summaries, source processing logs, target processing logs, and source to target alignment.
By using Monitoring correctly, SAP teams can reduce uncertainty, identify issues quickly, validate completed refreshes, and maintain a stronger audit trail across non production data refresh activities.