Data Insight User Guides
Data Refresh – End-to-End Step-by-Step User Guide
This locked guide explains how to create a DDR Data Refresh template from start to finish, including source and target connection selection, date range definition, business object selection, custom table inclusion, advanced filtering, table exclusion, data scrambling, template locking, and preparation for execution.
Purpose of the DDR Data Refresh Function
The Dynamic Data Replicator (DDR) Data Refresh function allows SAP teams to copy selected data from a source SAP system to a target SAP system in a controlled, secure, and repeatable way. It is designed to reduce the need for full system copies by giving the user precise control over the scope of data being refreshed.
DDR Data Refresh is especially useful for non-production environments where teams need realistic business data but do not need the full production dataset. The refresh can be limited by time period, business object, transaction type, table, relationship, field value, range, exclusion logic, and scrambling policy.
QA refresh, project test data, regression testing, training systems, troubleshooting, and controlled non-production data provisioning.
Copy only what is required rather than performing a heavy full system copy or client copy.
Templates can be reviewed, finalised, locked, and reused with consistent controls.
What This Guide Covers
Access Data Refresh
From the DDR Central Console, select Data Refresh from the main navigation menu. This opens the Data Refresh workspace where templates can be created, maintained, reviewed, and prepared for execution.
The Data Refresh option is normally available to authorised DDR users. If the option is not visible, check that the user has the correct DDR application authorisation and SAP role assignment.
Expected Result: The Data Refresh template list or template creation screen should open, allowing the user to create a new refresh template or maintain an existing one.
Select Template Type
DDR provides multiple template options depending on whether the user wants to start from a predefined template, copy an existing configuration, or build a new template from scratch.
A predefined template containing standard DDR object selections and recommended settings. Use this when the refresh requirement is common and does not need heavy customisation.
A user-defined template where objects, filters, tables, exclusions, and scrambling rules can be configured based on the business requirement.
A completely empty starting point. Use this when the user wants full control over each configuration step.
Copies an existing template and allows the user to change only the areas required for the new refresh cycle.
Best Practice: For repeatable refreshes, copy a previously approved template and adjust only the date range, object filter, or scrambling settings. This reduces configuration risk.
Create the Template and Select the Connection
Enter a clear and meaningful Template Name. The name should help users understand the purpose of the refresh without opening the template. Include the module, target system, project name, date period, or business scenario where useful.
| Connection Type | Purpose |
|---|---|
| RFC | Used where DDR replicates data directly between SAP systems using RFC communication. |
| Webservices | Used where communication is handled using webservice-based integration. |
| File Export and Import | Used where data is exported to files and then imported into the target system. |
After selecting the connection type, choose the relevant configured connection from the dropdown list and click Next.
Define the Refresh Date Range
Select the From Date and To Date. DDR uses this date range to control time-based data selection. This is important because it allows the user to refresh only the data required for a specific period instead of copying the full dataset.
For example, a testing team may only need sales orders, purchase orders, financial postings, or HR transactions created during a selected time window.
Example: If the testing team only needs transactions from 05 November 2025 to 31 March 2026, the date range should be restricted to that period to reduce volume and runtime.
Select Master Data Business Object Group
Select the required Business Object Group. This determines the type of data that will be included in the refresh configuration. In this example, the selection is focused on Master Data.
The business object group should be selected carefully because it controls the object list and dependency logic that will be available in later steps.
Select Process Business Object Group
If the refresh needs process-related data, select Process from the Business Object Group dropdown. This provides process data options connected to SAP business activities.
This option is useful when the user needs supporting process records rather than only static master data.
Select Transactional Business Objects
For transaction-based refreshes, choose Transactional and select the required business object. In the example shown, S/4HANA FI Transactional Data has been selected and included.
The selected business object determines the main dataset that DDR will replicate. Each object can contain multiple related tables and dependencies depending on the configuration.
Important: Do not select objects that are not required for the refresh. Unnecessary object selection increases runtime, volume, and post-refresh validation effort.
Add Additional Tables
DDR allows users to include additional tables that may not be part of the standard business object selection. This is useful for customer-specific tables, enhancement tables, reporting tables, interface tables, and bespoke application data.
Option 1: Include Tables by Name
Enter the table name that should be included for the selected business object. This is useful where a specific additional table must be copied with the selected business object.
Option 2: Include Tables by Relationship
Relationship-based selection allows users to connect an additional table to a parent table using a field relationship. This helps DDR copy related records in a controlled way rather than blindly copying an entire table.
| Relationship Field | Meaning |
|---|---|
| Parent Table | The table already included in the object or refresh scope. |
| Parent Field | The field used as the relationship key from the parent table. |
| Included Table | The additional table that should be copied based on the relationship. |
| Included Table Field | The field in the included table that links back to the parent field. |
Open Object Filter
After selecting the required business objects and additional tables, open Object Filter. Object Filter provides granular control over which records are selected for replication.
This is where users can define field-level restrictions such as company code, document number, plant, material number, customer number, vendor number, posting date, document type, or any other available field depending on the selected object.
Why This Matters: Object Filter is the control point that turns a broad refresh into a precise dataset. It helps reduce unnecessary volume and ensures the copied data supports the intended test scenario.
Select Filtering Fields and Create Filter
When Add Filters is selected, DDR displays the available filtering fields. The user can choose key fields such as document number, company code, and fiscal year. After selecting the required fields, click Include and then Create Filter.
In the example shown, the key fields for table BKPF include BELNR, BUKRS, and GJAHR. These fields can be used to define precise filter logic for the refresh.
10.1 Advanced Option – Add More Line Items
The advanced option allows the user to add more line items to the filter selection. This is useful when a single filter condition is not enough and the refresh scope needs multiple values, multiple ranges, or a mixture of include and exclude entries.
Users can add additional rows and maintain the From and To values directly in the multiple selection screen. This provides a controlled way to build more complex selection criteria without changing the main template structure.
10.2 Select Option – Include Required Values
The Select option allows the user to define the values that should be included as part of the data replication. This can be used for single values, greater than or equal to, less than or equal to, greater than, less than, not equal to, interval, or outside range logic.
Use this option when the requirement is to copy only the records that match the defined values or ranges. For example, the user can include a specific document number, a range of document numbers, a fiscal year, or a company code.
10.3 Exclude from Selection – Avoid Unwanted Values
The Exclude from Selection option allows the user to define values that must not be included in the data replication. This is useful where certain records should be avoided or where the user wants to prevent specific data from being overwritten in the target system.
For example, the user may include a large document range but exclude one or more document numbers that are not required for testing. This gives DDR a more precise and safer refresh scope.
10.4 Filter Behaviour Summary
| Option | What It Does | When To Use |
|---|---|---|
| Single Value | Includes or excludes one exact value. | Use when one document, company code, material, vendor, customer, or fiscal year is required. |
| Interval | Includes or excludes a range using From and To values. | Use when a continuous range of records is required. |
| Multiple Lines | Allows several values or ranges to be maintained. | Use when the refresh scope contains more than one selection condition. |
| Exclude from Selection | Prevents selected values from being copied. | Use to avoid unwanted data or prevent overwriting specific target records. |
Important Filter Guidance: Filters should always be reviewed carefully before the template is finalised. Incorrect filter values may result in missing data, incomplete test scenarios, unnecessary data being copied, or important target data being overwritten.
Table Exclusion List
Once filters are complete, move to the Table Exclusion step. This allows users to prevent specific tables from being copied, even if those tables are part of the selected business object, custom table pattern, or relationship selection.
Users can upload or maintain exclusion lists and decide whether technical tables should be excluded from the refresh. This is useful where certain tables are not required in the target system, are too large, contain technical runtime data, or should not be overwritten.
- Open the Exclude Table section.
- Upload or review the exclusion table list.
- Tick Exclude technical tables if BASIS or technical tables should be avoided.
- Review the table list before proceeding.
- Continue only after confirming that excluded tables are correct.
Use Table Exclusion For: large tables, sensitive tables, obsolete tables, system-specific tables, temporary tables, technical tables, or tables that should not be moved into the target system.
Data Scrambling
After completing the table exclusion step, click Next to proceed to Data Scrambling. Data Scrambling protects personal, confidential, commercial, and regulated information before it is made available in a non-production system.
12.1 Select Scrambling Mode
DDR allows the user to choose how scrambling should be applied. The available options include None, Scramble at Source, and Scramble at Target.
| Scrambling Mode | Meaning |
|---|---|
| None | No scrambling is applied during the refresh. |
| Scramble at Source | Sensitive data is scrambled before it leaves the source system. |
| Scramble at Target | Data is scrambled on the target system before or during target-side replication processing. |
12.2 Include Scrambling Policy
After selecting the scrambling mode, choose the required scrambling policy. Policies can be selected from the available pattern list and then included in the selected pattern list. In the example shown, fixed text scrambling policies are selected and shown in the preview panel.
Scrambling policies can be designed for common sensitive fields such as names, addresses, bank details, email addresses, telephone numbers, employee details, customer data, vendor data, or other sensitive business fields.
12.3 Security Guidance
Scrambling should be used whenever sensitive data is copied into non-production systems. This helps reduce exposure of personal, confidential, commercial, and regulated data during testing, training, support, and project activities.
Reference: For detailed scrambling configuration, refer to the Data Scrambling User Guide.
Finalise and Lock the Template
Once all template configuration is complete, review the full setup carefully before locking it for replication.
Once you are happy with the template, click Data Replicator. This locks the template and marks it as ready for replication.
Important: Locking the template helps ensure the approved configuration is protected and cannot be accidentally changed before execution.
Data Execution
This guide covers the creation and finalisation of the Data Refresh template. Once the template is locked and ready for replication, the execution process is handled separately.
For execution steps, including starting the replication, scheduling, monitoring, reviewing logs, and validating copied data, refer to the Data Refresh Execute User Guide.
Delta Refresh Capability
DDR Data Refresh also supports Delta Copy. Delta copy allows only new or changed data to be replicated after an initial refresh has already been completed.
This reduces runtime, lowers system impact, reduces data volume, and helps keep target systems synchronised without repeating a full data load each time.
Important Guidance
- Always validate the selected date range before finalising the template.
- Review all object filters carefully to avoid missing required data.
- Use table exclusion where large, sensitive, obsolete, or unnecessary tables should not be copied.
- Apply data scrambling when sensitive or personal data is being copied to non-production systems.
- Confirm that the selected connection is valid and available before execution.
- Ensure the user has the required DDR and SAP authorisations.
- Use delta refresh where repeated refreshes are required after the initial load.
Summary
DDR Data Refresh provides a controlled and technically robust approach for copying selected SAP data from a source system to a target system. It allows teams to avoid unnecessary full system copies by using time-based selection, business object selection, custom table inclusion, relationship mapping, advanced filtering, table exclusion, data scrambling, and delta replication.
Once the template is reviewed and finalised, clicking Data Replicator locks the configuration and prepares it for execution through the Data Refresh execution process.