Test Data Refresh Questions - Public Cloud

[#1]

We are investigating the Test Data Refresh solution and implications that it will have on our test system. We have some questions that I haven't found the answers to on the help pages yet. I'm hoping that the community will be able to help us out.

1: DMS is excluded from the test data refresh, does this mean that only the actual document files are not included, or are the (empty) CV entries also excluded from the refresh?

2: What happens with workflows that are assigned to production users that don't exist in the test system? Will they be assigned to a random user? How does this work combined with depersonalisation?

3: How does the data copy work exactly? Is it a snapshot or a table by table copy? In the case of a table by table copy, how are possible inconsistencies handled that arise of production changes mid copy?

4: Is there any impact on the production system during the test data refresh? e.g. will users notice any difference in system performance? 

5: We're also looking into the parallel line. Can we use the test data refresh to copy data from the main line to the parallel line? I have read that there is a early adopter program, but other than that the information is quite limited.

Looking forward to your answers!

[Chris1973]

Good day @AFaro 

Thank you for your question

Question 1: DMS is excluded from the test data refresh, does this mean that only the actual document files are not included, or are the (empty) CV entries also excluded from the refresh?

Answer: The exclusion covers more than just the binary documents file. DMS documents, GOS attachments, and office documents are preserved in the target system and not in the overwritten by TDR. Therefore, if by “CV entries” you mean the DMS document records/DIR information, you should not expect production DMS records to be recreated as empty shells in the refreshed system. See KBA 3718104 and KBA 3734023 for more information.

Question 2: What happens with workflows that are assigned to production users that don't exist in the test system? Will they be assigned to a random user? How does this work combined with depersonalisation?

Answer: Production users are not simply mapped to test users at random. Business users, employees and contingent workers remain in the target system, while workflow definitions and runtime items are also preserved rather than copied from production.

Depersonalization mainly applies to copied personal data such as business partners, customers, suppliers, addresses and bank information. These objects are subject to pseudonymization rules. So, you should not expect the missing production workflow users to be automatically replaced with arbitrary test users.

Question 3: How does the data copy work exactly? Is it a snapshot or a table by table copy? In the case of a table by table copy, how are possible inconsistencies handled that arise of production changes mid copy?

Answer: I am not aware of any public documentation that confirms whether TDR uses a database snapshot or a sequential table by table copy. For this reason, I suggest you do not assume that changes made during the transfer can create cross-table inconsistencies. 

Question 4: Is there any impact on the production system during the test data refresh? e.g. will users notice any difference in system performance? 

Answer: The data transfer can take approximately 24 hours, during which the target system is unavailable. There is no corresponding production downtime for the production source system.

https://help.sap.com/docs/SAP_S4HANA_CLOUD/a630d57fc5004c6383e7a81efee7a8bb/b36365ad21d44ce58ede393e...

However, you should keep in mind that there is no guarantee that the production system will experience measurable performance during the transfer. If this is important for your production SLA, I suggest you confirm the expected system load with the support team before you schedule the refresh.

Question 5: We're also looking into the parallel line. Can we use the test data refresh to copy data from the main line to the parallel line? I have read that there is a early adopter program, but other than that the information is quite limited.

Answer: There is now a specific early adopter scenario for the parallel test line. You can use TDR from the main line test system T.100 to the Parallel test system T.120.

You need to make this request only after a branch or rebase, and you also need to make sure that both systems have consistent configuration before the refresh. See KBA 3739049 for more information.

So, this is not the standard production to parallel test refresh process. The documented early adopter flow is T.100 main line test → T.120 parallel test

Let me know if you have any further questions.

Best regards

Chris