Technology Blog Posts by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
SafaBahoosh
Product and Topic Expert
Product and Topic Expert
1,089

In the previous post, we discussed data exposure using SQL services. In this post, we shift the focus to the data consumption scenario.

Picture1.png

Imagine an ABAP Cloud system that needs to access data located elsewhere, perhaps in an SAP HANA Cloud database, or even in another ABAP system. With SQL Services, an ABAP system can itself act as a database. To support such outbound data access in a clean and cloud-compliant way, ABAP Cloud introduces a new CDS modelling artifact: CDS External Entities.

 

What Are CDS External Entities?

CDS External Entities enable outbound SQL access from an ABAP Cloud system. This means you can:

  • Access data from a remote database
  • Load and process remote data in ABAP
  • Combine remote data with local data

In ABAP Cloud, classic secondary database connections are not available. CDS External Entities are their more powerful and cloud-ready replacement.

Conceptually, a CDS External Entity is comparable to an SAP HANA virtual table; it represents a local view of a remote table or view. The remote object and its fields may have different names, which can be mapped explicitly.

CDS External Entities can be consumed in two different ways:

- Dynamic Access

In the SAP BTP ABAP environment, a CDS External Entity can be used directly in ABAP SQL. You write a SELECT statement that accesses data from a remote database, loads it, and processes it in ABAP.

- Static Access

Starting with release 2508, CDS view entities and classic CDS views can be built on top of external entities. This allows you to integrate remote data seamlessly into your CDS view modelling and treat it like local data. This feature will be used in my next blog post of the series.

Logical External Schema

Alongside CDS External Entities, there is a second important artifact: the Logical External Schema which is based on SAP HANA Smart Data Access (SDA). The key features are as follows:

  • It represents a remote system at design time.
  • It is mapped to a concrete remote source at configuration time.
  • It contains connection-related information (host, port, user, etc.).

From a runtime perspective, the ABAP system sends the query to its own HANA database, which then federates the query to the remote system using SDA.

 

How External Entities Work at Runtime

External entities allow remote data access using a new ABAP SQL syntax:

SELECT FROM <external_entity>

  PROVIDED BY <logical_external_schema>

  INTO TABLE @DATA(result).

In this flow:

  1. The ABAP application sends the SQL query to the local HANA database.
  2. HANA performs query federation using Smart Data Access.
  3. Data is retrieved from the remote database.
  4. Results are returned to the ABAP application server.

The <logical_external_schema> is a design-time artifact that points to the remote system and is bound to an actual remote source during configuration.

 

Example Scenario

Let us build an example based on the travel scenario in which

  • SAP HANA Cloud acts as the remote database.
  • The ABAP system consumes data via Dynamic CDS External Entities.

It is crucial that

  • The external entity has the same name and field structure as the remote HANA table.
  • Field names and types must match exactly (HANA is case-sensitive).

Besides, to enable the access, an outbound service and a communication scenario are required.

Design Time Steps

1. Define a Dynamic CDS External Entity

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'external entity for travel'
define external entity ZI_EE_TRAVEL_000 external name TRAVEL
{
  key TravelID      : abap.numc(8)                external name "TravelID";
      AgencyID      : abap.numc(6)                external name AgencyID;
      CustomerID    : abap.numc(6)                external name CustomerID;
      @Semantics.amount.currencyCode: 'CurrencyCode'
      BookingFee    : abap.curr(16,2)             external name BookingFee;
      @Semantics.amount.currencyCode: 'CurrencyCode'
      TotalPrice    : abap.curr(16,2)             external name TotalPrice;
      CurrencyCode  : abap.cuky                   external name CurrencyCode;
      BeginDate     : abap.dats                   external name BeginDate;
      EndDate       : abap.dats                   external name EndDate;
      Description   : abap.sstring(1024)          external name Description;
      OverallStatus : abap.char(1)                external name OverallStatus;
      CreatedBy     : abp_creation_user           external name CreatedBy;
      CreatedAt     : abp_creation_tstmpl         external name CreatedAt;
      LastChangedBy : abp_locinst_lastchange_user external name LastChangedBy;
}
with federated data 
provided at runtime;

This entity models the structure of the remote table or view.

2. Define a Logical External Schema

This acts as a placeholder for the remote database and is referenced by the external entity.

steampunk_external_schema_01_010.png

3. Create Outbound Service and Communication Scenario

  • Create an SQL type outbound service for the logical external schemasteampunk_outbound_service_02_010.png
  • Create a communication scenario and assign the outbound service to it. Then save and publish the scenario locally.

scnario.png

This enables administrators to configure access to the remote system

4. Consume the External Entity in ABAP SQL

Create a class and write ABAP SQL code

Select * from my external entity provided by my remote into table my local table

CLASS zcl_travel_consume_000 DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_travel_consume_000 IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
     data: travel type table of zi_ee_travel_000.

    select * from zi_ee_travel_000 provided by z_travel_remote_db_000 into table @Travel.

    out->write( travel ).
    endmethod.

ENDCLASS.

In summary, what happens at runtime is as follows

  • The ABAP system sends the query to its HANA database
  • HANA SDA forwards the query to the remote database
  • Data is fetched and returned to the ABAP application
  • The local internal table is filled with remote data

Now we need to establish the connection between our development system and the SAP HANA Cloud database.

 

Configuration Time Steps

1. Create Communication Arrangement

In the SAP Fiori Launchpad:

  • Create a communication arrangement for the communication scenario you published in design time.

arrg1.png

2. Maintain a communication system for the remote database

  • Activate Remote SQL-Access
  • Choose HANA ODBC as the SDA adapter
  • Provide host, port, driver, and additional connection settings
    (These details are typically provided by the system administrator)

sys.png

save the communication system.

3. Maintain Remote Schema Information

In the communication arrangement:

  • Specify the schema name of the remote HANA database
  • Save the configuration and check whether the connection is successful

arrg2.png

4. Prepare the Remote HANA Database

In Visual Studio Code and using SAP HANA Database Explorer:

  • Create a table that matches the CDS External Entity exactly
  • Ensure field names, types, and sizes match as well

Remember that SAP HANA is case-sensitive.

Remote-HANA .png

What Happens Behind the Scenes

When you execute the ABAP SQL statement:

  • The ABAP SQL layer resolves the external entity and logical external schema
  • HANA automatically:
    • Creates a remote source
    • Creates the required virtual table
  • Query federation is handled transparently

In this sense, CDS External Entities act as a smart abstraction that automatically manages HANA remote sources and virtual tables via ABAP design-time objects.

Press F9, and the data is returned as expected.

data-in-pmd.png

In the next blog post I would like to build a RAP application in the cloud, based on data I read from an on-premises system. So, stay tuned!

3 Comments