ABAP developers want to use views and database procedures that they’ve created in SAP HANA Studio in ABAP. Developers are also used to a high-performance transport system and expect consistent transport of native SAP HANA development objects via the Change and Transport System.

5Integrating Native SAP HANA Development Objects with ABAP

Chapter 4 illustrated how you can create analytical models (views) and database procedures using SAP HANA Studio. Now we’ll explain how you can call these native SAP HANA objects from ABAP.

We’ll also discuss how you can transport ABAP programs that use native SAP HANA objects consistently in your system landscape.

5.1Integrating Analytic Views

In the previous chapter, you learned how to model the different view types in SAP HANA Studio and how to access the results of a view using the Data Preview or Microsoft Excel. In Chapter 4, Section 4.4.4, we also explained how to address the generated column views via SQL.

This section describes how to access the views from ABAP. In this context, we have to differentiate between ABAP Release 7.4 and earlier versions. When working with earlier releases, only Native SQL can be used for access; this will be described briefly in Section 5.1.1. As of ABAP 7.4, you can import the views from the SAP HANA repository into the ABAP Data Dictionary (DDIC) and then access them using Open SQL (explained in detail in Section 5.1.2 and in Section 5.1.3). In the last section, you’ll find some recommendations, tips, and tricks for SAP HANA view modeling.

5.1.1Access via Native SQL

When activating any of the presented view types in SAP HANA, a column view is created in the database catalog in the _SYS_BIC schema with a public synonym, for example, 'test.a4h.book.chapter04::AT_FLIGHT'.

Using these names, you can access this view from ABAP. Listing 5.1 shows how the AT_FLIGHT attribute view created in Chapter 4, Section 4.4.1, is accessed via ABAP Database Connectivity (ADBC).

" Definition of the result structure
TYPES: BEGIN OF ty_data,
carrid TYPE s_carr_id,
connid TYPE s_conn_id,
fldate TYPE s_date,
route TYPE string,
END OF ty_data.

CONSTANTS: gc_view TYPE string VALUE
'test.a4h.book.chapter04::AT_FLIGHT'.
DATA: lt_data TYPE TABLE OF ty_data.

" Access to the attribute view
DATA(lv_statement) =
| SELECT carrid, connid, fldate, route |
&& | FROM "{ gc_view }"|
&& | WHERE mandt = '{ sy-mandt }' ORDER BY fldate|.

TRY.
" Prepare SQL connection and statement
DATA(lo_result_set) =
cl_sql_connection=>get_connection(
)->create_statement(
tab_name_for_trace = conv #( gc_view )
)->execute_query( lv_statement ).

" Get result
lo_result_set->set_param_table( REF #( lt_data ) ).
lo_result_set->next_package( ).
lo_result_set->close( ).
CATCH cx_sql_exception INTO DATA(lo_ex).
" Error handling
&& | WHERE mandt = '{ sy-mandt }' ORDER BY fldate|.
WRITE: | { lo_ex->get_text( ) } |.
ENDTRY.

LOOP AT lt_data ASSIGNING FIELD-SYMBOL(<l>).
WRITE: / <l>-carrid , <l>-connid, <l>-fldate,
<l>-route .
ENDLOOP.

Listing 5.1Accessing an Attribute View via ADBC

As you can see, this is a regular access using Native SQL. If an error occurs during execution, the text of the SQL exception points to the cause. In addition to SQL coding errors, which are also visible when accessing views via the SQL console, there may also be errors related to mapping the result to the ABAP data type. Recommendations regarding this topic are given in Section 5.1.4.

5.1.2External Views in the ABAP Data Dictionary

In ABAP 7.4, external views are a new view type in the DDIC. Using such views, you can import column views defined in the SAP HANA repository into the DDIC. These views are called external views because they aren’t fully defined in the DDIC but are used as a kind of proxy allowing the corresponding column view in the _SYS_BIC schema to be accessed from ABAP.

External views can only be defined using the ABAP Development Tools in Eclipse. To do so, you create a new development object of the Dictionary View type. Figure 5.1 shows the New Dictionary View dialog for the AT_FLIGHT attribute view.

Creating an External View in the ABAP Data Dictionary

Figure 5.1Creating an External View in the ABAP Data Dictionary

When the view is created, the system checks whether it can be imported into the DDIC. Note that not all SAP HANA data types are supported in ABAP. When defining calculated attributes or accessing tables from views that weren’t created using the DDIC, such potentially unsupported data types may appear. In this case, an error occurs when creating the external view, and the view can’t be imported. The supported data types are listed in Table 5.1 later in this section and are described in Chapter 3, Section 3.1.3.

After successfully importing the SAP HANA view into the DDIC, the editor displays the structure of the view together with the data type mapping (Figure 5.2). In addition, you can use the Synchronize button to synchronize the view after changing the structure of the corresponding view in SAP HANA Studio. Therefore, if you add attributes to the output structure, delete attributes, or change data types, you need to synchronize the external view to avoid runtime errors. Recommendations on synchronizing developments within a development team are provided in Chapter 14.

External ABAP Data Dictionary View Based on an Attribute View

Figure 5.2External ABAP Data Dictionary View Based on an Attribute View

As you learned in Chapter 3, Section 3.1.3, SQL data types and DDIC types can’t always be mapped uniquely. However, the data type is decisive for the correct handling of operations (e.g., the calculation of differences for a date). For this reason, the developer must manually map the correct ABAP data type.

Table 5.1 shows the possible data type mappings for some columns of the AT_FLIGHT sample view.

Column

SQL Data Type

Possible Dictionary Types

CARRID

NVARCHAR(3)

CHAR(3), NUMC(3), SSTR, CLNT, UNIT, CUKY

FLDATE

NVARCHAR(8)

CHAR(8), NUMC(8), SSTR, DATS

CARRNAME

NVARCHAR(20)

CHAR(20), NUMC(20), SSTR

Table 5.1Possible Type Mappings

For the external view shown in Figure 5.2, we manually mapped the FLDATE column to the ABAP DATS data type. This may appear strange at first glance because this information is already present in the underlying DDIC table; however, the attributes of column views in SAP HANA don’t have a reference to columns of existing tables that is recognizable by the DDIC. For instance, the FLDATE column could also be a calculated attribute.

The procedure for defining external views based on an analytic or a calculation view is identical to the procedure used for an attribute view. Note that external views in the DDIC currently don’t have a reference to the particular view type; that is, they are just pointing to an arbitrary column view in SAP HANA. The only prerequisite is that the view is defined via the SAP HANA repository. Column views, which solely exist in the database catalog (e.g., generated programmatically), can’t be imported into the DDIC.

The transport of external views (and other SAP HANA-specific developments) is described in Section 5.3.

5.1.3Options for Accessing External Views

The main advantage of external views is that you can use Open SQL to access SAP HANA views. This allows you to benefit from the following advantages:

Listing 5.2 shows how the access to the external view from Figure 5.2 is implemented. From a functional perspective, this corresponds to the ADBC access variant from Listing 5.1. As you can see, the ABAP code required for access is significantly shorter and corresponds to the access for a standard DDIC view.

REPORT ZR_A4H_CHAPTER4_VIEW_OPEN.

DATA: wa TYPE zev_a4h_flights.
" Read data from external view
SELECT carrid connid fldate route
FROM zev_a4h_flights
INTO CORRESPONDING FIELDS OF wa.
WRITE: / wa-carrid, wa-connid, wa-fldate, wa-route.
ENDSELECT.

Listing 5.2Accessing an External View via Open SQL

[ ! ]Possible Runtime Errors When Accessing External Views

When using Open SQL to access an external view, an SQL query is executed for the corresponding column view in SAP HANA. The same rules apply as when accessing the view using Native SQL.

As explained in Chapter 4, Section 4.4.4, you must consider certain limitations when accessing analytic views via SQL. An unsupported query via Open SQL leads to a runtime error. Because these errors rarely occur when accessing ABAP tables using Open SQL, ABAP developers should use caution when following this approach. The troubleshooting tools and possible runtime errors during SQL access are explained in more detail in Chapter 7, Section 7.2.

In addition to Open SQL, you can also address external views using Native SQL. This variant, which seems somewhat awkward at first glance, is useful if you want to use an SQL query to access an SAP HANA view in a way that isn’t supported using Open SQL, such as a fuzzy search in an attribute view (see Chapter 10, Section 10.4). Compared to accessing the generated column view in the _SYS_BIC schema via Native SQL, the external view has an advantage in that a suitable target structure for a selection via ADBC already exists in the DDIC.

5.1.4Recommendations

This section concludes with some recommendations for using SAP HANA views. These are limited to functional recommendations. Tools and recommendations for performance analysis are discussed in Chapter 7 and Chapter 14, where we’ll also deal with design aspects such as naming conventions.

If the scope of functions provided by standard DDIC views is sufficient for your purposes and you’ve used these views in the past, there’s no need to change your application using native SAP HANA views. The next chapter presents Core Data Services (CDS) views, which enable you to define complex views with calculated fields directly in ABAP.

The modeled SAP HANA views provide simple access for special analytical scenarios. The following questions can help to determine the best view type in SAP HANA for your scenario:

When modeling views, you should make sure that the client field is handled correctly. In particular, it’s advisable to add the client field as the first field of the view and to make sure that the client is included in the join definition. In most cases, the Session Client configuration value is the correct setting for views based on ABAP tables from the same system. If tables are replicated from a different system, it may be useful to use a fixed value for the client. Cross-client access is useful only in rare cases.

You should always choose the correct default schema for analytic views and calculation views. This schema is taken into account in particular for the relevant Customizing for conversions, that is, if no special setting was configured for the attribute. Specifying the correct default schema is even more important when dealing with the implemented variant of calculation views.

External views should only be defined for SAP HANA views that will be used for access via ABAP because these views have to be synchronized manually after changing the corresponding structures. Moreover, you should define a maximum of one external view for each SAP HANA view.

If error messages are displayed when activating an SAP HANA view, the error text usually includes information on the root cause. In some cases, however, you may need some experience to interpret the error message correctly. For this reason, we recommend following a heuristic approach to error analysis. As a first step, you should make sure that you mark at least one field of an attribute view as a key field and that you define at least one key figure for an analytic view. If your view contains calculated attributes, you should check if you correctly defined the corresponding expression.

If you come to a dead end during error analysis, you can try to remove the corresponding attribute (e.g., in a copy of the view). If an error message or unexpected data appears when calling the Data Preview, this is often an indication of a problem in the join modeling. For currency conversions, a missing client context may result in an error.

When accessing an SAP HANA view from ABAP using Native SQL, you should pass the name of the view (via the tab_name_for_trace parameter as shown in Listing 5.1 or via the SET_TABLE_NAME_FOR_TRACE method). This facilitates the error analysis in a support scenario.