The role of the controller
With Data Sync Manager (DSM) 5, we introduced the Control Center. Previously, with DSM4, Object Sync and Data Secure were mainly limited to ERP systems, so the amount of interconnectivity was limited. Once we needed to collect data across distributed Production systems and send it to the corresponding distributed target systems, it became clear that we needed one central place to configure and manage this.
Which system should be my controller?
This is something that clients and consultants have asked me a lot. If Data Secure is the main focus, or the Privacy apps, then I would typically use a development ERP system temporarily while I create any custom content and do basic unit testing. After that, I would then move to a Production ERP system. Or, if the project was Client Sync- or Object Sync-focused, then I would start with the Production ERP system. If there is more than one ERP Production system in the scope, I would pick the one with the most connections. From here, you can then register systems, configure all the applications and environments, and then assign systems and clients to environments and applications, controlling how they will interact with each other for masking and object copying.
What happens with Client Sync?
For now, Client Sync is still executed in each individual system or client. So, an ERP export is triggered from Production or Pre-production ERP, the same for CRM, BW and so on. We have considered allowing one system to initiate all of them, but this starts to blend into the domain of some of the orchestration solutions. There may also be additional activities outside of SAP which must be part of the process, perhaps for a successful outcome, but also in terms of regulatory requirements (for example, backing up systems, control of system users). There may also be other teams to liaise and coordinate with on timings of these activities. Launching from one place may make it harder to manage each landscape, based on its own unique parameters. Environmental checks – like space for files or on the target systems – may also be glossed over when the syncs are consolidated in one place.
Some of the solutions out there are also using a separate server to control the runs, not for usability but for actual engine activities, extracting data from source systems and sending to target ones. One of the joys of DSM is that the processing happens in the source and target client so you can fully leverage the resources of each source and target system. You are not constrained by one remote server overseeing and processing everything via the network, including potentially touching personal data.
If you are keen to leverage an orchestration solution, or would like us to recommend a good one, just get in touch with us. There are APIs available for triggering Client Sync and Data Secure runs which can be used.
I’d still like Solution Manager (SolMan) to be my controller
We have had some clients who use Solution Manager (SolMan) as the controller, even though it’s not involved in the copying or masking itself. This can be done. We’re actually going to make it even easier for companies to use SolMan as the controller in future when it is allowed to go across different parts of the network to talk to all systems. If you don’t have such network restrictions, and many systems already talk to each other, then I’d still recommend using the most connected ERP system as your controller. In my experience, this provides the best usability and easiest control of the DSM configuration.
Leave a Comment: