Recap
For code push down, meaning pushing analytics from the ABAP application server to the database server, you can use open ABAP features that run on any database. Those are Open SQL that was enhanced widely in ABAP 7.40 with analytic capabilities like SQL expressions or by removing restrictions from joins and the ABAP Core Data Services (ABAP CDS) for advanced view building in the ABAP Dictionary.
If the functionality offered by the open features is not sufficicient to cover your needs, you have to switch to Native SQL (sounds familiar?). This is especially true for SAP HANA, that offers analytical features not covered in standard SQL, as e.g. calculation views. If your ABAP programs should run on HANA only (or if you want to offer special implementations for HANA and alternative implementations for other databases), database procedures written in SQLScript offer a convenient access to the capabilites of HANA. In order to facilitate this Native access to HANA, in 7.40, SP05 the concept of ABAP Managed Database Procedures (AMDP) was introduced, that allows you to code SQLScript in special methods of normal ABAP classes and the runtime environment does the rest for you. (But please note that a single SQL statement does not become faster if you code it in an AMDP, how should it? As long as you can stay open, stay open. There is no drawback in performance if you can express the logics in single statements or in CDS views. You use AMDP to avoid unnecessary data transfers between database and application server when using several statements or when you need access to fuctionality not covered by SQL).
News for ABAP 7.40, SP08
With ABAP 7.40, SP08, AMDP was enhanced as follows:
Tabular Changing Parameters
Although Native SQLScript procedures do not offer INOUT parameters, you can define CHANGING parameters for AMDP methods now. The trick is, that the database procedure generated from AMDP gets an additional IN parameter of the same name as the chaniging parameter with the pstfix __IN__ while the CHANGING parameter becomes an OUT parameter. When calling the procedure, the OUT parameter is filled implicitly with the CHANGING value passed to the IN parameter. Normally, you don't have to care about the implicit IN parameter. Only if you want to call such a procedure from another database procedure, you have to supply it.
AMDP method definition
METHODS
get_carriers
CHANGING
VALUE(carriers) TYPE t_carriers
RAISING cx_amdp_error.
AMDP method implementation
METHOD get_carriers BY DATABASE PROCEDURE FOR HDB
LANGUAGE SQLSCRIPT
USING scarr.
carriers = select s.*
from scarr as s
inner join :carriers as c
on s.mandt = c.mandt and
s.carrid = c.carrid;
ENDMETHOD.
A good example where AMDP is not needed at all, but KISS here.
Call from ABAP
TRY.
NEW cl_demo_amdp_changing(
)->get_carriers( CHANGING carriers = carriers ).
CATCH cx_amdp_error INTO DATA(amdp_error).
...
ENDTRY.
Class Based Exceptions
As shown above, you can handle exceptions that occur during processing an AMDP now. Before you got runtime errors only.
AMDP BAdIs
Special AMDP BAdIs allow you to implement BAdI methods as AMDP methods. These transfer the effect of the switches from Switch Framework to the implementation of database procedures in the current database. When an AMDP procedure calls another AMDP procedure managed by an AMDP BAdI, the implementation is executed that is prescribed by the current switch setting. (for calling AMDP procedures from ABAP no special BAdIs are necessary, because ABAP calls of normal BAdI methods are goverened by the switch framework anyway).
