How both integrations work is described under Integrate DQC into SAP processes below.
Choose a connector
Option | Best for | Reads from | Availability |
|---|
SAP HANA | SAP BW and BW/4HANA, SAP Datasphere, HANA-based data marts; large analytical volumes | The HANA database, through SQL | Standard connector |
SAP RFC | S/4HANA and other ABAP systems on SAP_BASIS 7.54 or later, where tables, DDIC database views or CDS view entities must be read through SAP authorization checks instead of database access | The SAP application server (ABAP), through RFC | On request, not enabled by default |
SAP OData | Data exposed as OData services via SAP BTP Cloud Integration (CPI), SAP Gateway or S/4HANA | SAP BTP (CPI) or the SAP application layer, through HTTPS | Standard connector |
Third-party tools | ABAP extractors, BAPIs or delta logic that the options above do not cover | A SQL database the tool writes to | Through the matching SQL connector |
Which option fits?
You can get a read-only HANA database user and the HANA tables or views contain the data you want to check: use SAP HANA.
Direct database access is not an option, for example because your SAP contract or your security policy does not allow third-party tools to read the database, or because your SAP team wants every read to pass SAP's own authorization checks: use SAP RFC.
Your system runs on SAP_BASIS below 7.54 (for example SAP ECC 6.0 or S/4HANA 1809 and earlier) and DQC may not read its database: use SAP OData or a third-party tool.
Your integration standard routes external cloud connections through SAP BTP Cloud Integration (CPI) without the DQC Proxy, or an OData service already exposes the data you need: use SAP OData.
You need ABAP business logic, extractors or delta loads: stage the data with a third-party tool and connect DQC to the staging database.
Clarify the licensing of third-party access with your SAP account team for any of these options.
SAP HANA: direct database access
DQC connects to the SAP HANA database with a read-only technical user over a TLS-encrypted SQL connection, the same way BI tools such as Power BI read from HANA. The SAP application layer is not involved.
Ideal for:
SAP BW and BW/4HANA
SAP Datasphere
HANA-based data marts and reporting layers
Large analytical workloads: DQC runs its checks as SQL inside HANA
Keep in mind: DQC reads the tables as they are stored. ABAP application logic is bypassed, and access is controlled by database privileges instead of SAP authorizations. Client-dependent ABAP tables store the rows of all clients, so filter on the client (MANDT), ideally in a database view that DQC is granted instead of the table.
→ Setup guide: Connection to SAP HANA
SAP RFC: read through the SAP application server
DQC connects to one SAP application server (AS ABAP) over RFC with a dedicated communication user and calls a small DQC component that your SAP team installs through its normal transport route: four remote-enabled function modules and eight DDIC structures. The component creates no tables and stores no data in SAP.
The RFC connection runs from inside your network: the SAP RFC runner next to the DQC Proxy logs on to SAP with the SAP NetWeaver RFC SDK that you download from SAP, and the proxy's outbound tunnel carries DQC's read requests to it. No inbound firewall port is needed, and the SDK runs under your SAP license on your host.
Every source DQC may read is approved by its exact technical name in the communication user's PFCG role. DQC reads only the sources you select, in bounded blocks within the row limits and execution windows agreed with your SAP Basis team. The rules then run in DQC, never against the SAP system.
Ideal for:
S/4HANA systems (SAP_BASIS 7.54 or later) where database access is not available
Transparent tables, DDIC database views and CDS view entities without parameters
Landscapes where SAP authorizations must decide what DQC can read
Keep in mind: the DQC ABAP component must be installed through your transport landscape, the DQC Proxy and the SAP RFC runner need an x86_64 host in your network, SAP_BASIS releases below 7.54 are not supported, and every extraction reads the selected columns of the whole source (there are no delta loads).
→ Setup guide: Connection to SAP RFC
SAP OData: stay in the application layer (SAP Gateway or SAP BTP CPI)
SAP NetWeaver Gateway, S/4HANA, SAP BW, and SAP BTP Cloud Integration (CPI / SAP Integration Suite) expose SAP entities as OData v2 or v4 services over HTTPS. When your organization standardizes external cloud integrations on SAP BTP (CPI) and does not permit direct database connections or running the DQC Proxy, OData via SAP BTP is the recommended path. Unlike SAP RFC, it does not require installing the custom Z_DQC_* ABAP function modules.
Ideal for:
Landscapes where external cloud connections are standardized on SAP BTP Cloud Integration (CPI) with OAuth 2.0
Master data and transactional data that is already exposed as an OData service
Smaller to medium data sets where SAP application-layer security and business logic must apply
SAP releases (such as ECC 6.0) that the SAP RFC connector does not support
Keep in mind: OData has a higher overhead per request than direct HANA access and is less suited to very large extracts. When exposing custom OData services in SAP BTP Cloud Integration, ensure the CPI integration flow implements <EntitySet>/$count (returning > 0) and pagination (__next or $top/$skip). Prefer OData v4 over v2 where available for better schema metadata.
→ Setup guide: Connection to SAP OData via SAP BTP (Cloud Integration)
→ Setup guide: Connection to OData
Third-party tools (for example Theobald)
When none of the options above fits, for example because you need ABAP extractors, BAPIs or delta logic, an extraction tool can stage SAP data for DQC.
For this pattern, configure the tool to load SAP data into a database that a DQC SQL connector supports (for example PostgreSQL, Microsoft SQL Server or Snowflake). DQC then reads the staged tables through that connector, like any other SQL source.
Suitable tools include:
Theobald Xtract Universal (theobald-software.com): extracts SAP data into database destinations such as Microsoft SQL Server, PostgreSQL and Snowflake
Other ETL or replication tools that load SAP data into a SQL database
Integrate DQC into SAP processes
Check data before it is saved
SAP applications (Fiori, SAPUI5 or ABAP) send the record that is being created or changed to the DQC Validation API. DQC applies the ruleset and returns findings per field and for the whole record, so the user can fix them before saving. The rules are maintained by the business team in DQC, and the same ruleset monitors your existing data.
Call the API from the SAP backend or your integration layer (for example through an HTTP destination in SM59 or on SAP BTP), not from the browser, so the API token never reaches the user's device. You need a DQC API token with the permission "Read & write" (a read-only token cannot call the Validation API), access to the ruleset, and an outbound HTTPS route from SAP to the DQC Platform.
→ SAP integration guide: request and response format, an ABAP example and best practices
Write corrections back
Enrichment steps of a DQC improvement flow provide proposed values together with confidence scores and source information. DQC does not write to SAP. An SAP application on your integration layer (in the video: an app on SAP BTP) loads the results, lets users set a confidence threshold and review the selection, and posts the approved changes to SAP. This application is set up together with your SAP team for each process: contact us.
Best practices for SAP connections
Use a dedicated technical or communication user. Never use a personal account, SAP*, DDIC or SYSTEM, and never assign SAP_ALL
Grant access only to the tables, views, services or sources that the data quality checks need
Allowlist the DQC Platform's static IP address where your network policies require it, or use the DQC Proxy for SAP HANA. In DQC SaaS, SAP RFC runs through the DQC Proxy and its SAP RFC runner
SAP HANA: assign a workload class with memory, thread and timeout limits
SAP RFC: agree row limits and execution windows with your SAP Basis team
SAP OData: prefer v4 over v2
Document which option you use per data domain (for example master data through RFC, analytics through HANA), so the decision stays visible to future operators
