Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at firstname.lastname@example.org.
This blog will discuss the new ABAP 7.4 functionalities that make calling functions and methods easier to code and easier to read. lets start with METHOD CHAINING.
You can now directly pass the returning value of one method call to a next method call without using any intermediate local variable. This is referred to as Method Chaining. Previously, we were only allowed to create a chain of statements using attributes of the class. Now you can include methods as well as attributes in a chained call. Method chaining is available since ABAP Release 7.0 EhP2.
Don’t get it confused with the chained statements, which You write using colon symbol colon symbol ( : ) .
We can directly pass the result of one method into the input parameter of another method without the need for an intermediate variable. Normally, we would declare a variable, fill it with the result of a method call, and pass that variable into another method. When using this new feature, we are able to reduce the amount of intermediate variables. This should improve code readability. Lets take an example.
CATCH zcx_exception INTO lo_exception. lv_error_txt = lo_exception->get_error_msg( ). zcl_my_screen_message=>display( im_error = lv_error_txt ).
By using Method Chaining, we can do away with having to declare the lv_error_txt variable by chaining the two method calls together.
CATCH zcx_exception INTO lo_exception. zcl_my_screen_message=>display( im_error = lo_exception->get_error_msg( ) ).
Avoiding TYPE MISMATCH Errors in ABAP 7.4
We have all been there… you are developing an SAP ABAP program and you declare some local variables to be passed into a method, cross your fingers, and hope you have declared the variable the same as the input parameter. If not, you get an error. Worse, if it was a function module, you get a short dump. Well ABAP 7.4 can address at least the IMPORT side of the problem, using the new DATA TYPE declaration operator DATA(… ) we learned about in New Features in ABAP 7.4 – Declaring and Creating Variables.
Lets take an example…
DATA: ld_number_of_items TYPE i, ld_po_number TYPE ebeln. lo_purorder=>get_items( EXPORTING id_po_number = ld_po_number IMPORTING ed_number_of_items = ld_number_of_items ).
With ABAP 7.4, we can accomplish the same thing by declaring the variables returned from the method not at the start of the routine but instead, at the instant they have their values filled by the method. Like so…
lo_purorder=>get_items( EXPORTING id_po_number = ld_po_number IMPORTING ed_number_of_items = DATA( ld_number_of_items ) ).
What are the advantages of using this feature?
-> You cannot possibly get a type mismatch error or dump.
-> If you change the method signature definition or formal parameter type of a function module, then the code adapts itself accordingly, again avoiding the type mismatch.
Therefore, this coding approach is easier to maintain, and safer. This approach really starts to make sense when creating ABAP object instances using factory methods; let me show you what I mean…
Here is some ABAP code to create a Mercedes Benz subclass .
DATA: lo_vehicle TYPE REF TO zcl_mercedes_benz. lo_vehicle = zcl_car_factory=>build_new_car( ).
Now instead of using the TYPE REF to decide what subclass lo_vehicle should be, let’s let the Factory Method Decide the Exact Subclass.
DATA( lo_vehicle ) = zcl_car_factory=>build_new_car( ).
What is a Constructor Operator? Well the SAP definition is “A constructor expression consists of a predefined constructor operator, a data type or object type that matches the operator and that can be derived implicitly from the operand position using #, and type-specified parameters specified in parentheses. Each constructor expression creates a result whose data type is determined using the specified type. The parameters specified in parentheses are used to pass input values”.
With this is mind, lets take a look at a specific situation – Often the result of one FORM, METHOD, or FUNCTION has to have its type converted before it can be passed into another FORM, METHOD, or FUNCTION. Lets take an example where we need to pass a name to the get_as_string method. We have a field im_delivery that is type vbeln_vl yet a string is expected. CONV # takes car of the conversion in-line. We can use the # character as a symbol for the operand type because data type required in an operand position is unique and fully identifiable. If it wasn’t then we would need to specify a non-generic data type.
lcl_text_reader( )->get_as_string( id = '0002' name = conv #( im_delivery ) object = 'VBBK' ).
There a more Constructor Operators that just CONV, take a look at the SAP ABAP 7.4 help for more information.
With the new code constructs in ABAP 7.2 and ABAP 7.4 we have the ability to create ABAP code with fewer statements with the same functionality, without compromising readability of the code. METHOD CHAINING can make our code shorter, easier to read, and easier to maintain. We saw the power of INLINE DECLARATIONS in a prior blog, but now we see how to avoid TYPE MISMATCH errors with this coding technique. Finally we saw how using a CONSTRUCTOR OPERATOR can save us time by eliminating lines of code while increasing the readability of our code.
While on the subject of saving time, I highly recommend you purchase Paul Hardy’s excellent book ABAP® to the Future. Click the image below to pick up a copy, it will definitively become your go-to reference as the new features of ABAP 7.4 and 7.5 are rolled out where you work!