The name SAP Data Services is used for an entire family of products. The core is SAP Data Services itself, then there is SAP Data Integrator, SAP Data Quality and SAP CPI-DS.
The first three are the same product but differ from the enabled transformations. Data Integrator has all the base transforms plus typical data integration transforms like History Preserving. The Data Quality bundle consists of the base transforms plus Data Quality transforms like address cleansing. The SAP Data Services bundle contains all transforms.
Over the years Data Services grew to a very powerful tool and allows to implement every requirement efficiently and quickly. When I was part of the team, the development guideline had been to enable the customer performing even the most complex transformations with the combination of a few transforms. The tool also supports all SAP APIs available to pick the best suited one. Connecting to the database, generating Abap code for the extraction, call BAPIs/RFCs, send and receive IDOCs, use the modern ODP/ODQ API, web services, restful,… you name it.
Simplify integration
At one point in time, our team got tasked with a cloud version of an ETL tool – Cloud Platform Integration – Data Services or short CPI-DS. Its backend is still a normal Data Services but easier to install. Building a proper Web UI is expensive and, in some areas, not even possible.
Also, the goal was to simplify things. The easiest way to simplify a UI and keep development cost down is to remove functionality. CPI-DS can therefore be used for some specialized cases only.
SAP Data Services delivers on promises
All the marketing statements I heard recently have been supported by Data Services since the beginning. “Move the transformation to the data, not the data to the transformation” (SAP Data Hub) is called a pushdown in Data Services. “ELT instead of ETL” (SAP Hana) means to extract (E) the data first, then load (L) it into the target system and do the transformation (T) inside the database as follow up step.
Depending on the case, this is a good idea and therefore Data Services supports both approaches and the optimizer picks what makes the most sense.
Realtime Data Integration is supported also, but not implemented very well. It starts with the question “What data has been changed?” – a requirement for realtime streaming of changes. The philosophy of Data Services is to provide all techniques and APIs for any given source system and the user can choose which one to use. This makes sense as each has pros and cons.
There are other tools, SAP SLT for example, which can do a single method only, which reconfigure the source system to produce the changes and therefore getting changes in realtime is simpler. Both approaches have their merits.
The focus of Data Services on batch performance has downsides on transactional consistency, stability of dataflows running for multiple days as it would be required in realtime.