Let’s start with an assumption, you’re here because you want to get rich business data from SAP, integrated with your enterprise reporting and/or external systems. While SAP is great at collecting and storing data but getting that data out for reporting and other uses is difficult to say the least. Our history moving data out of SAP into Databases, Data Lakes, EDW’S etc. goes back to 1995. You would think that in 30 years time, SAP would have solved this problem. Chances are you are looking for real time data from SAP. Not a bunch of asynchronous extractions.
There are a couple of reasons why SAP never will.
SAP wants to own your data and your entire stack. It’s your data but SAP doesn’t want to let you use it as you wish.
The push to keep all your data in the SAP Ecosystem and cloud, while maybe good for some simple applications is not a realistic enterprise solution. The vast majority of our customers use with Power BI or Tableau for final output along with other tools. The talent pool for these tools along SQL, Databricks, Snowflake etc. is enormous. Question — how many Datasphere developers do you know?
Just moving the data isn’t enough, raw SAP data is a pain and inefficient to work with. At our core we make data movement as simple as possible. Our approach is table based, with horizontal (i.e. limit the data to specific company codes) and vertical filters (bring only the columns that you need) . To add a table just type in the name, select columns and then which destinations (we support multiple heterogeneous destinations as a standard feature) —
If you don’t know the exact table you can find tables by functional area and then add them to replication.
If you don’t know the precise table you can use our
Using built-in work arounds is really a dead end. If it was great you wouldn’t be on this page looking for alternatives!
Using SE16N has multiple challenges, first a user must be granted access to the transaction , data selection criteria is opaque. Queries can’t include data from header and detail tables unless a join is created either in a CDS view or SE11. Downloading data into a spreadsheet and then loading into a database introduces risks of data corruption not to mention that when downloading multiple tables they are not time synchronous.
Go it alone and build your own ABAP Extractors??
At first glance this might seem like a reasonable approach. SAP has been around for over 50 years — if this approach was valid for large scale reporting it would be widely adopted by now. Sure, for some single table queries of calling a BAPI perfect. But for enterprise reporting — the internal support burden makes it a non starter.
Data Integration Tools
There are a ton of data integration tools that can connect to SAP. But as SAP professionals you know that given the importance of the data, multiple storage formats (transparent, pool, cluster etc. ) from different versions all mixed together, a generic approach to data movement isn’t sufficient. Even if a tool can handle all the table types, that is just the beginning. Technical names especially those in key functional areas like FI, MM, PP etc. have a rich history and the most important columns are limited to 5 character names. Non-technical users, with good business sense are stymied by this data.
We can help —
Go ahead and get ahold of us. We would be happy to learn about your particular needs and see if we can help you achieve your goals. If we can’t we will let you know right away…
