Skip to content
Sep 19 16

New Features in ABAP 7.4 – Internal Tables

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

ABAPAnthony 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 ajcecchini@itpsap.com.

Internal Tables in ABAP 7.4

Internal tables are a core staple of programming in ABAP. In this blog, you’ll learn about some new ABAP functionalities that relate to internal tables.

Using Secondary Keys to Access the Same Internal Table in Different Ways

Internal tables are a bit like database tables, and with release 7.02 SAP began the long march of adding operations only possible for database tables into internal table processing as well. The process started with the idea that if database tables can have secondary keys, then why can’t internal tables have them as well? Traditionally, if you wanted to read an internal table in two different ways (e.g.,looking for a material by Material Number or by Reference Number), then you either had to keep sorting the table just before a read, which is a waste of processing time, or have two identical tables sorted differently, which is a waste of memory.

Secondary keys are now possible as of ABAP 7.02. For example, In a given query, half the queries will be on MATNR and half on BISMT. The internal table definition would be as shown below.
DATA: IT_MARA TYPE HASHED TABLE OF mara 
              WITH UNIQUE KEY matnr 
              WITH NON-UNIQUE SORTED KEY sort COMPONENTS bismt.

What we have done is created a secondary Index into the Internal Table, this is just like having a secondary Z index on BISMT in the database table definition. lets examine how this works… OK, you have a query coming in on MARA, you either have BISMT or MATNR specified, and you have to react accordingly. First of all we need to determine which of the two values have been passed in; if it is the material, then that’s great, and you can read the material internal table using the primary key(MATNR). However, if the BISMT has been passed in, then you cannot use the primary key, so you have to use a secondary key to get the record. The code would look something like the below…

IF lv_matnr IS INITIAL AND
   lv_bismt IS INITIAL.
      RETURN.
ENDIF.

IF lv_matnr IS NOT INITIAL.
    READ TABLE it_mara INTO wa_mara WITH TABLE KEY matnr = lv_matnr.
ELSE.
    READ TABLE it_mara INTO wa_mara WITH KEY sort COMPONENTS bismt = lv_bismt.
ENDIF.

Note that even though IT_MARA is a HASHED table it is also a SORTED table with the key BISMT, so when we go looking for the record using BISMT a BINARY SEARCH is automatically performed. That is not quite as fast as a hashed access, but it’s an order of magnitude better than a sequential search and a lot faster than the alternative of re-sorting the table each time the search changes.

Table Work Areas in ABAP 7.4

SAP decreed that header lines in internal tables were confusing and should not be used. This was because the use of header lines led to the existence of two data objects in your program with the exact same name, and this was viewed as confusing. For example, it wouldn’t be uncommon to find a program in which you had an ITAB variable that referred to the internal table as a whole and also a work area called ITAB that referred to the current line of the table being processed.

ABAP programmers were so used to the idea of the header line that it was a hard habit to shake. This was especially true because you had to explicitly declare a variable to act as the header line. The good news is that now you can avoid having to make that extra variable declaration and still have two differently named variables, one for the table and one for the work area. In release ABAP 7.4, the syntax for reading into a work area and looping through a table can now leverage INLINE DECLARATIONS, we discussed these in a prior ABAP 7.4 blog.

We learned that from 7.4 onwards you no longer need to do a DATA declaration for elementary data types. It is exactly the same for the work areas, which are of course structures. If you are looping into a work area called LS_MARA and the work area structure does not match the type of the table LT_MARA, you would get a syntax error. Therefore, the compiler knows the type it wants—so why do you have to tell it that type in an explicit data declaration? The answer is that now you don’t, and this change will remove all those extra data declaration lines you had to insert when everyone moved away from header lines (if they ever did…;-p) and had to explicitly declare work areas instead. Take a gander at the code below…

READ TABLE lt_mara WITH KEY matnr = lv_matnr INTO DATA(ls_mara).
LOOP AT lt_mara INTO DATA(ls_mara).

In the same way that you no longer need DATA declarations for table work areas, you also no longer need FIELD-SYMBOL declarations for the (common) situations in which you want to change the data in the work area while looping through an internal table. In ABAP 7.4, if you want to use field symbols for the work area, then the syntax is shown below…

READ TABLE lt_mara WITH KEY matnr = lv_matnr ASSIGNING FIELD-SYMBOL().
LOOP AT lt_mara ASSIGNING FIELD-SYMBOL().

Reading from an Internal Table in ABAP 7.4

What if I told you that you would never have to use the statement READ TABLE again to get a line out of an internal table?

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Aug 14 16

New Features in ABAP 7.4 – Conditional Logic

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

ABAPAnthony 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 ajcecchini@itpsap.com.

Conditional Logic in ABAP 7.4

In ABAP 7.40, the IF/THEN and CASE constructs you know and love keep on getting easier. let’s take a detailed look!

Functional Methods in Logical Expressions

One of the great features of ABAP 7.02 was the concept of functional methods and how you could use them in logical expressions. Functional methods allow you to eliminate the use of a helper variable. Thus, you can simplify the code. lets review a quick example…

Without Functional Method.

LV_HELPER = STRLEN( LV_STRING ).
IF LV_HELPER > 10 THEN…..

With Functional Method.

IF STRLEN( LV_STRING ) > 10 THEN…

And the same principle applies to return variables from method calls, so you can have code that looks like the statement below…

IF zcl_system=>is_production( ) = abap_false...

Omitting ABAP_TRUE

When functional methods were first introduced in ABAP, the idea was that this would make the code read like English. Over the years, the general consensus both inside and outside of SAP was that if you were creating a method that returned a value declaring whether or not something is true, then the returning parameter should be typed as ABAP_BOOL.

So you began seeing code that looked something along the lines below…

IF zcl_system=>is_production( ) = abap_true.
"In production we never want a short dump
    TRY.
      zcl_application=>main( ).
      CATCH cx_sy_no_handler INTO gcl_no_handler.
    ENDTRY.

Why do you need the = ABAP_TRUE at the end? It seems apparent what resukt we are looking for. The answer is that you had to do this, because otherwise the syntax check would fail. Well, as of release 7.4 (SP 8), you can now omit ABAP_TRUE.

IF zcl_system=>is_production( ).
"In production we never want a short dump
    TRY.
      zcl_application=>main( ).
      CATCH cx_sy_no_handler INTO gcl_no_handler.
    ENDTRY.

Why does this work? Well from a technical point of view, if we do not specify anything after the functional method, the ABAP 7.4 compiler evaluates it as IS_PRODUCTION( ) IS NOT INITIAL. An ABAP_TRUE value is really the letter X, so the result is not initial, and the statement is resolved as true.

That being said, you have to be really careful though when using this syntax; it only makes sense when the functional method is passing back a parameter typed as ABAP_BOOL.

Using XSDBOOL as a Workaround for BOOLC

Another common situation with respect to Boolean logic in ABAP, is when you want to send a TRUE/FALSE value to a method or get such a value back from a functional method. For instance, did you ever stumble over this one?

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Jul 18 16

New Features in ABAP 7.4 – Calling Methods and Functions

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

ABAPAnthony 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 ajcecchini@itpsap.com.

Calling Methods and Functions in ABAP 7.4

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.

Method Chaining

You can now directly pass the returning value of one method call to a next method call without using any helper variable. This is referred as method chaining. Previously it was 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 a helper variable. Normally, we would declare a helper variable, fill it with the result of a method call, and pass that helper variable into another method. When using this chain of method feature, we reduce a lot of helper variables. This should improve code readability. Lets take an example.

CATCH zcx_exception INTO lo_exception.
ld_helper = lo_exception->get_text( ).
zcl_my_screen_message=>output( id_text = ld_helper ).

By using Method Chaining, we can do away with having to declare the ld_helper variable by chaining the two method calls together.

CATCH zcx_exception INTO lo_exception.
zcl_my_screen_message=>output( id_text = lo_exception->get_text( ) ).

OK, I can hear you… Big Deal! At first this may not seem like much of a saving, but the benefit increases proportionately to the number of related method calls that are made one after the other.

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Jun 13 16

New Features in ABAP 7.4 – String Processing

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony 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 17 years of experience in SAP R/3 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 ajcecchini@itpsap.com.

String Processing in ABAP 7.4

Some fairly major changes to string processing were introduced with release of ABAP 7.2 and ABAP 7.4. But if you read this blog, you won’t have any problems answering ABAP string processing interview questions!

Here are some of the more important changes to string processing in ABAP 7.2 and ABAP 7.4:

» Chaining Operator: chain two character-like operands into one new character string.

» String Templates: the option to create a character string out of literal texts, expressions, and control characters.

» Character String Functions: built-in functions

Chaining Operator

The Chaining Operator && can be used to create one character string out of multiple other strings and literals. The use of the chaining operator largely replaces the CONCATENATE statement. In this example, three variables are concatenated together using the && chaining operator.

DATA: v_var1 TYPE char30, 
      v_var2 TYPE char30, 
      v_var3 TYPE char30.
DATA: lv_result TYPE string.   

v_var1 = 'Building'. 
v_var2 = 'A'. 
v_var3 = 'String'.   

lv_result = v_var1 && v_var2 && v_var3. 
WRITE: /(30) 'Using &&', lv_result
While this definitely saves a bit of room in your code, it does not seem to handle the spaces you often want between variables very well. Well, to solve that, we have String Templates…
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
May 15 16

New Features in ABAP 7.4 – Declaring and Creating Variables

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony 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 17 years of experience in SAP R/3 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 ajcecchini@itpsap.com.

Declaring and Creating Variables in ABAP 7.4

One of the main differences between ABAP and other languages is that in ABAP we have been taught to declare all our variables at the start of the program—for example, in the TOP INCLUDE. While this may be an Official ABAP programming Guideline, many of my ABAP brethren will declare a variable just before it is used. This helps with context and readability.

The good news is that as time goes on, changes in the ABAP language make this unofficial practice more and more acceptable. This blog will discuss several features that contribute to this shift.

Omitting Data Type Declarations

In ABAP the compiler knows what data type it wants, in fact it has to know in order to be able to perform a syntax check, so why not let it decide the data type of your variable and create it? This is the very feature now available to us in ABAP 7.4. In the examples ahead, you will see how letting the compiler decide the data type—instead of declaring it yourself—can save you several lines of code.

For instance, here is some code you are probably used to …

Before ABAP 7.4

DATA: lv_vehicle TYPE string.
lv_vehicle = 'Mercedes'.

What if instead, you could code this…

With ABAP 7.4

DATA(lv_vehicle) = 'Mercedes'.

OR this…

Before ABAP 7.4

DATA: lv_rows TYPE i.
lv_rows  = LINES( itab)

Becomes…

With ABAP 7.4

DATA(lv_rows) = LINES( itab ).

As you can see, this has the potential to dramatically reduce the number of lines in your programs. The new declaration operator DATA(…) is called an inline declaration.

What about field symbols? Well For field symbols there is the new declaration operator FIELD-SYMBOL(…) that you can use now. Lets look at the 3 examples of how to use this new operator below…

With ABAP 7.4

ASSIGN ... TO FIELD-SYMBOL(<fs>). 

LOOP AT itab ASSIGNING FIELD-SYMBOL(<line>).
...
ENDLOOP. 

READ TABLE itab ASSIGNING FIELD-SYMBOL(<line>) ...

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

Pin It on Pinterest

Share This