Defining Access to Remote Systems


After completing this lesson, you will be able to:

  • Describe the technology used to virtualize data.
  • Explain the properties of a remote source.

Accessing Data from External Systems

When accessing external systems from SAP HANA Cloud or On-Premise, you establish a communication between two systems. Let's describe a basic scenario and provide the key concepts.

First of all, let's make the meaning of source and target clear in this figure. To make it simple, we generally consider that the remote system is the Source System, while the local SAP HANA from which we access it is the Target System.


SAP HANA data provisioning technologies do NOT restrict the data flow to a single direction (source to target), that is, reading from source system. Depending on the type of source, some scenarios might include writing to the source system.

A key artifact enabling access to remote systems is the Remote Source. This is a database object created in the target system (SAP HANA) and referencing a source system, for example, another SAP HANA database (cloud or on-premise), an SAP ASE system, or a file repository.

Finally, in a schema of the target database, you create Virtual Tables that reference a remote source AND a remote object in the source system that this remote source gives access to.


A remote source gives access to a single remote system, but you can create several remote sources in a single SAP HANA system.

Let's focus on security and keep it simple for now. A local user creates the remote sources and provides the credentials of a remote user. This remote user with its privileges is used to access the remote system and operate in it.

SAP HANA smart data access and smart data integration

To access external data from an SAP HANA Cloud or On-Premise system, you can use different technologies. In this course, we focus on two technologies that are used when SAP HANA is the target for federation or replication scenarios:

The two technologies are:

  • SAP HANA smart data access
  • SAP HANA smart data integration

These two technologies share many concepts, components, and interfaces. They share the same database objects on the target side (SAP HANA), security concepts, and so on. Especially for data federation (accessing data on-the-fly without replicating a complete data set), they offer very similar capabilities.

SAP HANA smart data access relies on built-in adapters that run on the SAP HANA database. There are mainly two types of adapters: ODBC and REST API adapters. The REST API adapters are only available in SAP HANA Cloud.

In SAP HANA smart data integration, two additional components come into play.

  • Data Provisioning Server

    This service is running in the SAP HANA instance. It needs to be enabled to support any SDI connectivity.

  • Data Provisioning Agent

    This component is an application running on-premise, in your company network. This agent connects to the Data Provisioning Server and exposes SDI adapters so that they can be used by remote sources.

    Note that OData adapters run on the Data Provisioning Server and don't use the Data Provisioning Agent.


    Technically, the data provisioning agent can run on the same host as an SAP HANA database, as shown in some demos in this course. However, depending on the planned workload and to comply with technical best practices, it's most often installed on a separate host.

Overview of Supported Source Systems

SAP HANA smart data access and SAP HANA smart data integration cover a broad range of source databases, located in the cloud or on-premise. For some of them, you have the choice between one technology and the other, depending on the specifics of your scenario.

Adapters can work at the database level, as is the case for SAP HANA adapters, SAP ASE, SAP IQ, SAP HANA Cloud Data Lake, and many more. For example: Oracle, Microsoft SQL Server, Azure SQL Server or Azure Data Explorer (ADX).

Other adapters can work at the application server level. This is the case for the ABAP Adapter available in SAP smart data integration. This adapter connects to the ABAP server and uses ABAP functionality to expose the data.

There are also a few SDI adapters to connect to an SAP ERP Central Component (SAP ECC) system. Compared with the ABAP Adapter, the connection is made primarily through the underlying database system (for example, SAP ASE or Microsoft SQL Server), but it also reads the SAP ABAP dictionary in order to properly access technical, ABAP-specific tables, such as cluster or pool tables.

As a last example, the source system could be another type of storage for sem-istructured or unstructured data, such as AliCloud OSS, Amazon S3, Google Cloud Storage, or Azure Blob Storage. In this case, you can check the complete set of SAP HANA adapters to check what can be used with each source system.


In some scenarios, it’s possible to consider a data import/export from cloud storage services such as AliCloud OSS to the SAP HANA database directly, or to SAP HANA, Data Lake. Although possibly limited in capabilities, this might be the simplest approach that serves your purpose.

SAP HANA to SAP HANA Capabilities

Let's discuss which virtualization scenarios are supported between two SAP HANA systems, with SAP HANA Cloud and SAP HANA On-Premise (version 2.0 SPS05, SPS06 or SPS07).

With SAP HANA smart data access and SAP HANA smart data integration, all scenarios are supported, regardless of whether source and target are cloud or on-premise. One scenario requires special attention: connecting an SAP HANA Cloud target to an SAP HANA On-Premise source with SAP HANA smart data access requires an instance of the SAP Cloud Connector, acting as a reverse proxy to enter the company network where SAP HANA On-Premise runs.


This information applies to virtualization scenarios only. If we consider data replication scenarios, the list of supported scenarios might be different.

Remote Source Properties

Defining a Remote Source

To connect SAP HANA to an external system, a remote source needs to be defined. A remote source has several properties:

  • Name

    The name of the remote source must be unique in the target database.

  • Adapter

    The adapter defines the type of source database or source system you want to access with the remote source, and indirectly the corresponding solution (SAP HANA smart data access or SAP HANA smart data integration)

  • Location

    The location of a remote source refers to where the adapter is located.

    • For SAP HANA smart data access, the adapters always run on the indexserver of the target SAP HANA instance.

      In an SQL statement to create a remote source, this property is just not mentioned.

    • For SAP HANA smart data integration, the adapters run on data provisioning agents, or on the data provisioning server (for OData adapters).
  • Configuration

    The configuration section of a remote source definition includes important information about the target system, including how to connect to it. This information is used as follows:

    • To identify the source system.

      For example, host and port, reference to a web service URL, or reference to a Data Source Name or DSN. This includes any additional setting specific to the remote system.

    • To identify the SAP Cloud Connector instance to be used, when connecting to an SAP on-premise system through the SAP Cloud Connector
    • To provide additional configuration for the remote source behavior, such as the Data Manipulation Language (DML) mode (read/write or read-only), or some performance-related settings
    • To pass some security-related information, such as certificates
  • Credentials

    The credentials define the way to connect a session through the remote source to the remote system.

    For example, this can be the name and password of a technical user, the mention of secondary credentials (mapping of technical users from the remote system to local users), or a certificate-based authentication method (X.509).

Remote Source and Target Schema

In contrast to many database objects in SAP HANA, such as tables, views, functions, and more, a remote source is not a schema object. So, it does not depend on any schema, and a given remote source can serve virtual objects defined in more than one schema.

The picture shows an SAP HANA Database connected to two different remote systems. Each of it is connected via a dedicated remote source. Several virtual objects located in different schemas or HDI containers of this database are connected each to a remote source.

In the figure, you see two remote sources, and each of them serves two or three schemas or HDI containers. Similarly, a schema or an HDI container can consume data from several remote sources, as is the case for Schema 2 and HDI Container 1.


Depending on recommendations from your IT organization, you might adopt an approach where remote objects are systematically located in a dedicated schema.

Preparation Steps to Create a Remote Source

Before you create a remote source, several steps are necessary. These steps are normally in the scope of a system administrator's role, but they are provided here for general interest.

Note that there is no particular technical or security prerequisite to create a remote source. The local user just needs the privilege CREATE REMOTE SOURCE. For a remote source created with an SQL statement, of course, the SQL statement must be syntactically correct.

Log in to track your progress & complete quizzes