Evolve ERP data extract ETL’s to become SAP compliant
In previous posts we highlighted the risks of SAP Indirect Access and the increasing stringent nature of SAP licence audits in this area. As it turned out from the UK ruling in the SAP vs Diageo case – all SAP clients are at risk of unlicenced Indirect Usage access potentially exposing your organization to significant additional fees/penalties if their NON-SAP applications initiate access to SAP functions / services and those users behind the 3rd party application are not covered by appropriate named user licenses of the SAP system.
Think of any regular data warehouses or SAP connected BI systems, where ETL tools use SAP’s RFC_READ_TABLE or similar proprietary SAP functions to access and pull data from SAP ERP in order to feed the NON-SAP users with data. Most of these ETL tools use a shared “technical” SAP user account to connect to SAP, and no individual governs how the actual DWH / BI users are licensed on SAP in most cases.
Does this sound like your DWH / BI environment?
VirtDB can help to mitigate the risk of indirect access claims by enhancing your existing data management / ETL processes. We will use screenshots from Talend Open Studio as an example of the average SAP extractor ETL jobs – and will advice where to change those to remain compliant – but the same method should work for almost all ETL tools (think of Informatica, Oracle, IBM, Alteryx, Microsoft data integration).
Most likely you have workflows like this below (maybe a little more complicated) – an SAP component pulling out data from the ERP system and additional components doing something with the extracted data, like filtering, transforming, combining it and loading / writing to somewhere your end-users can access.
The problem is with the SAP marked component, when you set it up to connect to SAP ECC, you will use a “technical” user to login and access the data calling the RFC_READ_TABLE function (or any other SAP internal data access functions) – which is obviously a could be case of SAP indirect access.
On top of that,
“RFC_READ_TABLE puts a limit on the number of columns and rows you can extract.”
For example there is no chance you can extract a table like BSEG with one job using RFC_READ_TABLE. So how can you get past these limitations?
To change this, set up VirtDB to extract the data into a safe file store or to a database from SAP, (initiated by a licensed internal SAP named user) and connect your ETL jobs to the file store or database instead, of the SAP system. You may change your ETL jobs into something like this.
VirtDB file or database extracts are easy, you can use VirtDBs Mass Data Extractor to extract SAP tables (also with delta handling):
You can even simplify your ETL processes by extracting pre-processed data like using ABAP reports, SAP queries or views as data sources – enriching your data for your analytics or report builders on the SAP side. It is possible to schedule extraction of ABAP reports using the drop-down menu of VirtDB in the report itself:
By using VirtDB to change your existing ETL process you can expect to mitigate indirect SAP access risk and gain performance improvements in only a few days.