Introduction
In SAP landscape a nonproductive environment must closely and approximately be related to productive environment and be populated with accurate, consistent data so that the changes before moving into Production system will be tested more effectively in Quality systems, likewise the training system should have similar data to that of Productive system so that the training will be more beneficial for the new users. Similarly if the development system has more related scenario as that of a live system then the programming incapability’s can be minimized. These scenario add more pressure on the consultant to get there system refreshed from the Production system frequently. But limitations of available tools, most companies simply create a complete copy of the productive system, including the entire data repository and all administrative settings whether or not this information is required for testing purposes. This method duplicates the productive environment, so it’s both time-consuming and expensive in terms of infrastructure resources, and requires longer downtime for the system which is to be refreshed. So it is the requirement of the companies to have a tool which will help in refreshing the test system with the consistent business data from the live system keeping the repository of the test system as before. The Test Data Migration Server (TDMS) is the solution for them.
Technical Procedure
The SAP Test Data Migration Server (TDMS) is used for creating and refreshing non-production systems (particularly test systems) with a reduced, but still consistent dataset.
The rationale behind TDMS is as follows: Approximately 80 % of the data volume of a typical database is contained in less than 10 % of the tables. The biggest tables are normally transactional data tables. This means that there are two options for creating non-production systems with a reduced dataset:
• The transfer is limited to the tables containing customizing and master data. This option is implemented in the TDMS MD&C approach.
• Only a certain part of the transactional data is included in the transfer. To ensure that the dataset of the resulting non-production system is consistent, rules for delimiting the data for transfer must be defined. In the TDMS TIME approach, this is achieved by defining a “from date”. That is, all data that belongs to the time after the defined “from date” will be included in the transfer together with the customizing and master data, while the rest is left behind. More details about how to choose the “from date” are given below.
From a technical perspective, both options can be used for creating test systems, training systems and development systems. There is no general rule about which option to choose in which situation, because this choice depends on a number of project-specific factors. If you plan to set up a quality assurance (QA) system, however, you should always use the TIME approach, because a QA system must contain a certain amount of application data so that the required tests can be carried out in it.
For the MD&C as well as for the TIME variant, an initial setup is required when a non-production system is created for the first time in a given system constellation of sender and receiver system.
Once this has been done, an operator can refresh the non-production system at regular intervals following a simplified procedure.
System Landscape
The system landscape for a TDMS installation consists of the following elements:
• The system from which the data supply for the non-production system is taken (sender system). Normally, this will be a production system; however it might also be a quality assurance system that was set up as a full copy of the production system.
• The TDMS server, which acts as
o Central system on which the settings and customizing for the setup of the non-production system are stored
o Process control system.
• The non-production system (receiver system)
Prerequisite
TDMS System
The following minimum requirements apply for the central system (and consequently for the TDMS server):
• R/3 system with Web AS 6.20 and SAP ABA
• 4 CPUs
• 4 GB RAM
• Required disk space: min. 20 GB
Regarding the patch level, there are no specific requirements for TDMS.
Source System
• SAP R/3 4.6c or R/3 4.7 only
Target System
• SAP R/3 4.6c or R/3 4.7 only
The TDMS software must be installed on all systems that are part of the given TDMS landscape.
The Sender, Receiver and the central systems must be linked via RFC connections.
Business Benefits:
With SAP Test Data Migration Server your company can enjoy the following benefits that increase efficiency and reduce cost in your IT department:
• Decrease infrastructure and maintenance expenses by reducing the hardware and disk space needed for nonproductive systems with a test data set that can be 30% of the size of the complete productive data set
• Improve development quality by improving the quality, reliability, and consistency of test data used in nonproductive landscapes and by allowing developers to perform testing more easily and earlier in the process
• Provide increased control over the development process with SAP training that enables your IT department to refresh and create new nonproductive systems in the future and exercise more control over the operation of your test environments
Technical Benefits:
Simply creating a complete copy of the productive system, including the entire data repository and all administrative settings needs following manual work to be done until the system can be made available for the users:
• Interfaces (change/shut down)
• Creation of new users or blocking of existing ones.
• Copy saved objects back into the system (CATTS).
• Logical System Change (BDLS).
• Transport paths information.
With SAP Test Data Migration Server above mentioned manual work is not required to perform.
Conclusion
SAP Test Data Migration Server (TDMS) will facilitate the test system with the consistent business data from the live system keeping the repository of the test system as before.
This method of system refreshed duplicates the productive environment in the test system without any down time and also help companies from expensive infrastructure resources as compare to standard system refresh.