Somewhere between a canary and cannon fodder
For the last few years, I’ve been very fortunate/unfortunate (delete as appropriate, depending on your love of cutting-edge technology) to be involved in many ramp-up projects for new software. This has broadened my knowledge of not just our own solutions, but of related SAP functionality, and in some cases broader IT topics, most notably with our GDPR/data privacy applications. It's always nice to see something evolve, and sometimes your knowledge of the solution is enhanced by seeing the iterations happen as more feedback is received.
SaaS? Surely everything is standardised?
SAP is a particularly challenging space for developing software because it was designed specifically to allow a wide variety of organisations, from a wide variety of industries, to configure it to suit their business processes. So early stage code would be tested on demo data made available, but the moment it reached customer systems was when the learnings really started, as a result of a myriad of different options they may have invoked in the configuration.
In 2018, I embarked on an extension for our Data Sync Manager (DSM) solution to copy and scramble SuccessFactors data, and I genuinely thought this would be much simpler (a definite case of ‘the unknown unknowns’). The solution involves reading employee records from a SuccessFactors Production instance via the OData API, transferring those records along with the payroll information from ECP or an on-premise payroll, and then upserting it to the Test or QA SuccessFactors instance. The aim being to ensure that any scrambled values used to protect sensitive data are consistent across the hybrid HCM environment.
I – and I suspect many of my colleagues – vastly underestimated how challenging it would be. I didn’t expect anywhere near the amount of customisation to happen in Employee Central due to the fact that it is a SaaS offering. I also couldn’t have envisaged how different someone's Production instance could be from a test instance. I had almost zero knowledge of SuccessFactors when we began; and I would still profess to be far from an expert (as a result of only really seeing if from the technical side upwards). But as a result of the challenges posed by the API, I picked up a fair amount of domain knowledge in finding ways to resolve, or work around, specific issues. Which brings me, meanderingly I admit, to my point. I had stepped back from being involved in this particular area of our solutions, for a year or two, until recently.
Why an ebook?
When I did re-engage, two things stood out:
- The problem space is very challenging, but we bring a lot of technical capabilities with DSM which give the person leveraging it options to work with.
- I actually know a bit more about this than I realised, and I need to share that experience (see how I sidestep the word knowledge).
So I decided to document not just our solution, but the surrounding problem space of Test Data Management in a Hybrid SAP HCM environment where there is both SuccessFactors Employee Central and an SAP Payroll system.
If you have this set up at your organisation, or are considering it, please download our ebook which will help you to:
- understand the options for complying with SAP’s Data Processing Agreement after an Instance refresh
- gain an understanding of how to approach test data management in a hybrid world, and when an API error really is an error
- see how DSM can highlight configuration and picklist inconsistencies between Production and the Test/QA instance
- learn about the OData API, and how it can be leveraged en-masse and for specific entities
- see how OData entities have been absorbed into the DSM data model
- hear my troubleshooting tips for API messages and working around inconsistencies between the data and the configuration.
Leave a Comment: