FAQs: Data Sync Manager (DSM) Suite

System Builder and Client Sync can be used to rebuild the entire landscape with lean clients containing accurate test data, or one specific testing environment can be refreshed on a much more frequent basis. This provides a pool of accurate testing data that is closer to Production. In the cases where data has changed more recently in Production, Object Sync can be used to copy data down on demand in seconds. Together this ensures less defects get through the testing net, but when they do occur, the resolution can be swift and without the need for opening up Production.

DSM can be used to build a dedicated training system on site, or in the cloud, with a very small master client. Training teams can then modify the data to match their scripts while Client Sync automatically resets the training clients from the master overnight.

Object Sync can give DevOps teams access to production data on demand. This allows teams to accurately prototype and see challenges before the first transport is released. Client Sync can also provision additional clients on development to ensure the customizing used for the testing is accurate. Disposable clients can also be used where Scenario objects can slice out surrounding data to support the process being tested.

Client Sync can be used to create or refresh BW systems with a leaner set of data, or alternatively, BW teams can manage their own data directly with Object Sync for BW. This removes the dependency on the other testing environments and gives control of the BW test data to those that need it.

Data Secure can be used in-place on an existing test system, or automatically when Client Sync and Object Sync copy data back to test systems. It comes with over 1000 preconfigured integrity maps which link all the places where a particular data type is stored, and over 100 transformation functions that can be applied to those integrity maps to generate valid alternatives for all the common challenging datasets, such as government ID numbers and bank account formats, which will pass the validity checks in SAP. This allows real data to be used for testing without anyone being able to see the person’s real identity.

Client Sync and Object Sync use Data Secure’s masking policies to effective mask sensitive or identifying fields before the data extract leaves the production system. This ensures any data in transit is not identifiable, and sensitive fields are not correct values. Data Secure comes with pre-defined best practice rules which cover hundreds of different regions across the world. It is also designed to allow our clients to build their own masking logic and share it through Client Central, our interactive client-focused platform.

Projects tend to roll through the landscape one after the other, but often overlapping, leaving very small windows to refresh test systems. This means that the latest data doesn’t make it back to development and test systems, ultimately reducing the quality of testing. In many cases there are many interfaces to external systems, CRM, Point of Sale (POS), etc., making test refreshes particularly complex. And, of course, where there is B2C data in the systems, that data must be protected through masking and removal of sensitive data, without lowering the quality of the data for testing and training.

Reducing the window for test system refresh using a solution like Client Sync™ can enable more frequent test refreshes. It can also enable more landscape flexibility (for example, temporary clients for specific projects which can be disposed of when that project is complete).

Enabling analysts, DevOps and consultants to copy small sets of real data on demand to existing test clients can also relieve some of the pressure during key project phases. It also ensures that the tests carried out are realistic and more representative of what will happen when the project finally goes live. This can be achieved easily and in a repeatable, consistent manner with Object Sync™.

With both copy methods, it’s essential to have an intelligent data-masking solution - like Data Secure™ - which can provide accurate-looking values for masking without traceable patterns in the data. It also has the capability to create address masking which will pass postal code checkers.

When two systems have led a separate life for any period of time, putting them back together is a complex merger project. Imagine a Sales Order which is cancelled on Production, but was processed on QA. When the next rolling slice comes down, how would you undo all the impacts of that Sales Order in QA  - such as stock balances, customer credit limits, profitability analysis? How those happen is specific to each system. Any solution that attempts to do this would leave you with significant inconsistencies. 

Time-slicing means selecting all transactions from a specific date up to today, so you can exclude unnecessary older data from your Sync and therefore create a lean client. (Client Sync cleverly keeps the transactions in your time slice consistent, by bringing over any older related documents that your selected transactions depend on).

Enterprise-slicing means you can choose to include the data from just one company code or several company codes in your Sync, so you can avoid copying superfluous information.

No, over 1000 business objects are defined in DSM. Client Sync will slice a massive number of your SAP tables, based on the tables defined in the object definitions. This means slicing is done from a functional perspective, resulting in significantly smaller clients than other products on the market that target only the very largest tables.

No, there would be no way of knowing the balances, stock levels, number range pointers, etc. at the end of the time period. It is possible to do a file export at key points in case of a future requirement, e.g. take a one-year slice at the end of the financial year.

No, Client Sync copies data directly from source system to target system without the need for a 'middle tier' server. This is why it is faster than other available products.

No, Basis personnel only select the slice required and Client Sync ensures that a consistent client is built. Other products require the client to be defined in detail, necessitating considerable functional knowledge and introducing considerably greater risk of an inconsistent or incomplete resultant client.

Client Sync uses profiles, for example, Customizing, Master Data, InfoObjects Only, or HCM Only profiles, allowing you to copy a subset of client data, all at once, to create a leaner client. Object Sync is finer grained, allowing you to copy only specific data on the Business Object level, such as Employee or Vendor, thus saving disk space too. So, for example, you could create a new client with all the customizing and user Masters you need, using Client Sync, and then add just the master and transactional data for certain employees with Object Sync.

No, Client Sync eliminates the need for the BDLS transaction, as it looks for all logical system source values in the data at the same time, and makes changes while the data is in memory. For some big systems BDLS can take several days, so abolishing it is a big plus!

No, the master data is dependent on customising in many ways. Even something simple, like address numbers used with customers and vendors, would be inconsistent if master data was copied without the existing customising. Similarly, whenever Client Sync copies transactional data, it includes the relevant master data. The only Client Sync profiles that can append data to an existing client are 'Only HCM Data' and 'User Administration'.

No, Client Sync will only affect client-dependent data (e.g. RFCs, batch jobs, printers). No repository or client-independent data will be copied.