This blog contains some information regarding TDMS HCM 4.0
Sender system, from which the data for the non-productive system are taken, the production system is usually used as the sender system.
TDMS Server, which includes:
Central system, wherein the configurations and customizing are performed
Control system, system in which the majority of SAP TDMS activities are performed and monitored.
Receiver system, the target system is not productive, which will receive the data. This system can also be a Shell or a complete copy of the production system. If you need to use the type scenario Business Process Library, additionally necessary RFC connections in both directions between the sender system and receiver system.
SAP Test Data Migration Server (SAP TDMS) is used to create and refresh unproductive systems (test systems, training systems, development systems) with reduced data volumes. It is worthwhile emphasizing that it means not to be used for the creation of productive systems.
SAP TDMS works on a client, the data that is selected from original client are copied to the receiving client in an existing system (non-production system).
In the current standard configuration SAP TDMS, covers the following requirements:
q Time-Based Reduction.
q Company Code and Time-Based Reduction.
q Transfer of Master Data and Customizing Data.
q Full Transfer of Client-Specific Data.
q Client-Specific Data Deletion.q Object-Based Reduction for Industries.
q System Shell Creation.
q Bussines Procces Library (BPL).
q Transfer of SAP ERP HCM Data.
q Stand-Alone Scrambling.
q Data Import Through Files.
Application-Based Transfer has the following configurations for HCM:
Transfer of PA Data for SAP ERP HCM: Data transfer personnel management from SAP ERP Human Capital Management.
Transfer of PD and PA Data for SAP ERP HCM: Data transfer management organization and personnel management from SAP ERP HCM.
Transfer of PD and PA Data for SAP ERP HCM (Expert): Full Data Transfer management organization and personnel management from SAP ERP.
For these three scenarios it is possible to apply the masking rules for data transfer in order to ensure that sensitive data (such as employee personal data or confidential financial information)
is encrypted and is not accessible to users of the destination system.
SERVICES TO SET.
For the correct display of WebDynpro and other new processes in version 4.0 you have to activate the following services:
• BTP_PCLPACKAGE_OIF / sap / bc / WebDynpro / sap / btp_pclpackage_oif.
• BTP_LANDSCAPE_OIF / sap / bc / WebDynpro / sap / btp_landscape_oif
• BTP_PROJECT_OIF / sap / bc / WebDynpro / sap / btp_project_oif
• BTP_BLUEPRINT_OIF / sap / bc / WebDynpro / sap / btp_blueprint_oif
• BTP_DOCUOBJECT / sap / bc / WebDynpro / sap / btp_docuobject
• BTP_PCLACTIVITY_OIF / sap / bc / WebDynpro / sap / btp_pclactivity_oif
• BTP_PEMBLOCK_OIF / sap / bc / WebDynpro / sap / btp_pemblock_oif
• BTP_BLUEPRINTS_POWL_TDMS / sap / bc / WebDynpro / sap / btp_blueprints_powl_tdms
• BTP_CONTMGMT_TDMS / sap / bc / WebDynpro / sap / btp_contmgmt_tdms
• BTP_LANDSCAPE_POWL_TDMS / sap / bc / WebDynpro / sap / btp_landscape_powl_tdms
• BTP_PORTFOLIO_TDMS / sap / bc / WebDynpro / sap / btp_portfolio_tdms
• BTP_PROJECT_POWL_TDMS / sap / bc / WebDynpro / sap / btp_project_powl_tdms
• All strings containing the following:
CNV * TDMS * services / sap / bc / WebDynpro / sap / cnv * TDMS *.
• HELP CENTER / sap / bc / WebDynpro / sap / wdhc_help_center.
SAP TDMS HCM CONFIGURATION
SAP TDMS Once installed on the system that will act as the central system will execute the transaction TDMS “TDMS“ to access the main panel of TDMS. This transaction launches WebDynpro tasks makes input menu where you launch the setup and execution processes. In version 3.0 was accessed using transaction CNV_MBT_TDMS. This transaction is still valid but SAP does not recommend direct use as through WebDynpro can access the extended monitor to display any faults with the old transaction usage no benefit.
This is the message that appears when you launch the old transaction:
The grouping of the different scenarios in version 4.0 changes with respect to the 3.0. Final configuration still exists as the “Migration Package” dependent on a sub and a project, but in this version there is only one sub-project by project. No element has been removed subproject configuration tables but its usefulness within a project itself.
For better organization of projects has created the concept “Template“, in addition to the organization are used to determine all processes that must be performed on a project. While version 3.0 each “package” could only contain an application in version 4 can configure a number of concatenated applications.
You can also reuse scenarios thereby creating the RFC‘s for each package is no longer a mandatory requirement. Designing a “Landscape“ and assigning it to each project are set up connections between systems for this project. It is in the creation of Lanscape where systems have to define central receiver and sender to be used in the project.
The configuration settings will be discussed in next posts