SAP Table vs. SAP Extractor - Comparison and Thoughts

/

Abstract

SAP Extractor concept is fantastic especially when it comes to delta enabled standard extractors. SAP also enables users to create generic extractors. In the whole SAP data extraction thought process, there have been a lot of articles explaining the “how”, which is about how to create generic extractors based upon tables like VBAK. However, one important missing factor is “why”. In the context of bringing SAP table content out without business rules, Extractor is not the silver bullet. Building a generic extractor has to be carefully justified. This article uses fact and data, through the comparison of table extraction and generic extractor extraction, to objectively explain the decision criteria for SAP data extraction.

Consideration

Instead of attempting to cover all aspects of SAP extractor, the focus is here is around SAP table content extraction through generic extractor which is most online how-to guides cover, and its comparison with direct table extraction. With such level set, we look at two aspects of Performance and Delta extraction.

The Performance aspect is explained through the comparison between generic extractor and direct table read on BKPF table through application layer. The Delta aspect is explained through the example of VBAK table.

Performance Comparison

System Preparation

Test setup: SAP IDES Ehp7 running on 16GB 8-core Hyper-V VM on a Xeon E5-2670 2.6Ghz workstation.

SAP source object: BKPF with 588448 rows, 112 columns

Data extraction setup: SSIS 2017 and AecorSoft Extractor and AecorSoft Table source components running on 16GB quad-core i7-3720QM laptop computer.

Network: 1Gbps.

Test 1: Table-based Generic Extractor

In transaction code RSO2, it is easy to create the generic extractor based upon table or view.

ZDSBKPF_TABLE.png

Result:

ZDSBKPF_TABLE_SSIS.png

Level of configuration and customization effort: Low.

Time taken: 123 seconds

Test 2: Function Module based Generic Extractor

At minimum, three items are required to build a function module based extractor:

  1. Custom extract structure via transaction code SE11;

  2. Custom function module leveraging the ABAP template RSAX_BIW_GET_DATA_SIMPLE or RSAX_BIW_GET_DATA;

  3. Data source creation via transaction code RSO2.

The most important part of the function module is the OPEN CURSOR WITH HOLD for the SELECT statement, which holds the cursor when the function module is executed through the extractor framework package by package. Because in the context here, there is no transformation or business rule required, the function module is mostly based on the standard ABAP template.

ZDSBKPF_SIMPLE.png

Result:

ZDSBKPF_SIMPLE_SSIS.png

Level of configuration and customization effort: Medium.

Time taken: 124 seconds

Test 3: Table based Extraction through SAP Application Layer

No configuration or customization in SAP is required per each source object.

With AecorSoft turbo function on SAP transparent table, the result is:

BKPF_SSIS.png

Level of configuration and customization effort: Minimal.

Time taken: 26.5 seconds

Observation

It is obvious that if the requirement is to extract SAP tables without business rules, then table based extraction is significantly faster than generic extractor based extraction. In the BKPF example, the table extraction performance is astonishingly 4.6 times of generic extractor performance!

Delta Consideration

One myth in SAP community is that a lot of people think extractor can magically deliver delta. The fact is that there is no magic. Within SAP standard extractors, there are a lot of logic doing the table look-ups and joins on transactional tables, master tables, change document tables (like CDPOS) and system BAPIs to figure out the delta. When it comes to generic extractors, developers have to carefully craft up the delta calculation algorithms in order to make the generic extractors delta capable.

Fundamentally it is the same rationale for the delta scenario in generic extractors. In the example of VBAK, ERDAT (created on) and AEDAT (changed on) need to be used for delta processing. Although this is simple delta rule, function module based generic extractor has to be developed to handle the WHERE clause in the Open SQL SELECT statement, in order to track and filter by the create date and changed on date.

In comparison, such filter rule can also be easily implemented on table based extraction. Under such context, from the aspects of engineering productivity and operational efficiency, generic extractor still does not have advantage over direct table extraction.

Conclusion

SAP extractor concept is great, but it should not be mystified. In the context of SAP table content extraction without complex rules, we can see through those examples that the direct table based extraction has clear advantage over generic extractor based approach.

However, we must point out the context has a big assumption that the raw table content can meet the requirement. When there are business rules required, the function module based extraction will offer more flexibility.

Technically speaking, a simple rule of thumb would be that when there is business rule or complex logic involved to derive values, then use extractor; otherwise, use direct table for its simplicity, efficiency, performance, and supportability. In reality, there is no simple statement applicable to everyone. For those who have strong extractor developers on the team, strategically reinforcing a data extraction policy solely depending on extractor could be a viable option. For those who have deep knowledge in SAP physical data models, going with pure table based approach could be also successful. For the majority of customers, a hybrid of the two would be the most feasible to get the best values from both approaches. In the end, it is all about what makes most sense to the business.

With the fact and data explained in this article, our general advice to readers is to ask more “why” when it comes to the decision point of the extraction techniques, and form an attainable data extraction strategy best for your businesses, which includes architectural guidance, project management methodology, decision trees, and engineering standards, to drive towards the sustainable modern SAP data extraction solutions.