BTP - External Entity (Performance)

Table of contents

• Introduction
• Performance Test
• Change
• Measurement
• Evaluation
• ODBC
• Current
• Future
• Conclusion

In this article, we'll examine the performance of current technologies in BTP and compare them to External Entities, exploring the remaining potential of these technologies.

 

Introduction

A while ago, we conducted an initial performance check and compared various technologies. These included the classic RFC function module, an OData service, calling Plain HTTP, and the different protocols in the OData version. External Entities and SQL Services are now also very effective tools. We wrote an article a while ago about how to connect to and use SQL Services.

 

Performance Test

In this chapter, we will conduct the performance test and examine the performance of the External Entity compared to other technologies.

 

Change

To do this, we will implement another method in our performance class. For the most part, we will adopt the logic that we have already implemented in the function module, namely the dynamic determination of the fields to be queried. We must also incorporate this logic into the method. Otherwise, we can directly perform the SELECT statement on our external entity and specify all parameters in the SELECT statement. This is therefore the simplest implementation when it comes to access.

DATA(fields_for_select) = ``.
LOOP AT request_data-fields REFERENCE INTO DATA(field_name).
  IF fields_for_select <> ``.
    fields_for_select &&= `, `.
  ENDIF.
  fields_for_select &&= field_name->*.
ENDLOOP.

IF fields_for_select IS INITIAL.
  fields_for_select = `*`.
ENDIF.

SELECT FROM ZBS_X_DemoSQLPerformance
  FIELDS (fields_for_select)
  ORDER BY identifier
  INTO CORRESPONDING FIELDS OF TABLE @result-data_sql
  UP TO @request_data-top ROWS
  OFFSET @request_data-skip.

 

Measurement

In this case, we run all test cases again. However, we aggregate the results and perform five runs of each individual test and calculate the average of these results to obtain a number for comparison. Should larger deviations occur again, as was the case with the HTTP issue, we would factor them out to obtain approximate values for the technology and to filter out buffer or framework problems.

 

Evaluation

Basically, a similar result is obtained as in the last performance measurement, at least for the other technologies. In this comparison, we'll take a look at RFC and ODBC, as these technologies are relatively similar and will form the basis of today's comparison. Essentially, RFC is still the fastest protocol in terms of implementation. However, in the next chapter, we'll examine why ODBC is currently lagging behind and what might happen in the future.

Looking at the numbers, ODBC is roughly ten times slower than RFC, but about one hundred times faster than the other technologies. This means that there is significant potential for achieving high-performance interfaces and data connections via ODBC. However, smaller outliers are noticeable again, which don't fit the figures and, for example, as in the first test case, are quite far apart.

This technology is still in its infancy. This means that errors can occur or incorrect access plans can be used. However, the correct data is generally delivered. SAP will certainly continue to optimize this technology in the coming years to enable better integration scenarios and also increase performance.

 

ODBC

Why ODBC? The technology currently has several facets when you look at it: It's implemented via External Entities, we use SQL services to access it on the other side, and the name SDA was also floated. But if we look at the connection itself, ODBC drivers are used to enable access.

 

Current

So why do we still see so much potential in the technology? Let's look at an overview of the current setup and access paths in our scenario.

On the left, we have the ABAP environment where we've set up the External Entity with the Communication Arrangement. This Communication Arrangement communicates with the virtual table on the HANA Cloud via the HANA ODBC driver. The HANA Cloud, in turn, performs authentication against the SAP system via the Cloud Connector using an ABAP ODBC driver. On the other side, we're using an SQL service and a Core Data Service. This means that currently we have two different drivers and a HANA Cloud that we don't actually need. Currently, the scenario with direct access is not supported; certain technical prerequisites must first be established for this to work.

 

Currently, Principal Propagation is also not supported. This means we always have Basic Authentication (or a certificate) involved in the communication, which in turn doesn't properly support Access Control. What would be the advantage of this? We access a standard Core Data Service, use Access Control, and only receive the data we are authorized to access. Therefore, we also need to implement an authorization concept in the interim solution.

 

Future

This means that at the moment we have an interim solution that already runs very efficiently, but again requires performance for access. In the future, the whole thing should work so that the Communication Arrangement communicates directly with the SQL service via the Cloud Connector and we only use the ABAP ODBC driver. This will allow us to eliminate the need for the HANA Cloud, the virtual table, the hop, and the HANA ODBC driver. This means that there is fundamentally high performance potential here.

 

This means that if the intermediate solution is deactivated in the future and we access it via principal propagation, we have a certain potential to save objects. We can directly utilize the access control within the system, and we have significant potential for improved access performance, which will increase modeling and usage many times over.

 

Conclusion

The technology already exists and promises high potential in terms of usage and performance for efficiently building side-by-side scenarios. However, this doesn't mean we shouldn't use it now; rather, we can consciously employ it to implement certain scenarios. The technology should definitely be kept in mind, as it offers the greatest potential for efficiently implementing more side-by-side scenarios in the future.