Even after the RFC-based ODP access has been disabled, a whole range of legally sound connectors remains available. Different approaches are suitable depending on the scenario.

The SAP Table Connector remains the most reliable option when tables or views are to be loaded directly from SAP ECC or S/4HANA. It operates via the RFC framework, requires manual delta mechanisms, but delivers stable performance. With very large tables, memory issues may arise during loading – a problem that can, however, be circumvented by making appropriate adjustments to your pipelines. Overall, the SAP Table Connector is currently the best alternative, both from a legal perspective and in terms of technical practice.

Those working directly with the HANA database can use the SAP HANA Connector. This utilises ODBC, is extremely powerful and also supports complex data models such as calculation views. In practice, however, there are technical limitations with standard CDS views, and expensive SAP HANA Full Use licences are required for raw tables such as ACDCOA.

Finally, there is the OData Connector, which is based on the OData protocol and is universally applicable – particularly when smaller data volumes or flexible API-based queries are required. Its performance depends heavily on SAP’s implementation, but it is fully compliant and future-proof.

Even following the discontinuation of RFC-based ODP access, a whole range of legally compliant connectors remains available. Different approaches are suitable depending on the scenario.

The SAP Table Connector remains the most robust option when tables or views are to be loaded directly from SAP ECC or S/4HANA. It operates via the RFC framework, requires manual delta mechanisms, but delivers stable performance. With very large tables, memory issues may arise during loading – a problem that can, however, be circumvented by making appropriate adjustments to your pipelines. Overall, the SAP Table Connector is currently the best alternative, both from a legal perspective and in terms of technical practice.

Those working directly with the HANA database can use the SAP HANA Connector. This utilises ODBC, is extremely powerful and also supports complex data models such as calculation views. In practice, however, there are technical limitations with standard CDS views, and expensive SAP HANA Full Use licences are required for raw tables such as ACDCOA.

Finally, there is the OData Connector, which is based on the OData protocol and is universally applicable – particularly when smaller data volumes or flexible API-based queries are required. Its performance depends heavily on SAP’s implementation, but it is fully compliant and future-proof.

The solution mentioned and recommended by SAP in the SAP Note is to use SAP Datasphere as part of the SAP Business Data Cloud. SAP Datasphere enables organisations to load SAP and non-SAP data from source systems into target systems (e.g. SAP Business Data Cloud, Azure Storage Account, MS Fabric Lakehouse, etc.). scc has also successfully tested this approach in various projects. Whilst the technical feasibility is certainly there, customers who do not use the SAP Business Data Cloud are faced with the question of whether relying on yet another tool to transfer their SAP data into their target environment in a legally compliant and technically sound manner is really the most efficient and cost-effective approach. If, on the other hand, the SAP BDC is used, Datasphere may well be the optimal solution.

Microsoft Fabric is currently establishing itself as a new platform for data integration and analysis. The upcoming SAP Mirroring Connector will play a central role here, as it enables a stable and native connection to SAP systems – without the need for any additional middleware. Although it does not support a true CDC process, it offers ease of use and high stability. However, it remains to be seen whether, in future, it will offer the full flexibility required to load SAP tables and views in a delta-compatible manner, as is already possible with other connectors.

The key point is this: the Mirroring Connector will not introduce any revolutionary new functionality, but will instead simplify existing capabilities. The delta logic it uses internally can already be replicated today using the existing connectors in Azure Data Factory, Synapse or MS Fabric. So anyone who is already relying on clean and stable implementations is well prepared.