Professional Documents
Culture Documents
Data Declarations
In ABAP you have many operand positions, where the value of the operand is changed by the statement. The
most typical of these "write positions" is the left hand side lhs of an assignment.
lhs = rhs.
But of course there are more. The data objects you can use at these write positions are either writable formal
parameters of the procedure you are working in or variables declared with DATA in front of the statement.
In many cases the variables filled by a statement are helper variables that you only need close to the
statement. For each of these helper variables you had to write a data declaration with the DATA statement and
of course it was your task to give the variable an adequate type.
Well, the operand type of most write positions is statically fixed and well known to the compiler. And this is why
ABAP can offer inline data declarations with Release 7.40. The ingredients are so called declaration positions
(write positions with fully known operand type) and the new declaration operator DATA(...).
Let's look at some examples.
With 7.40
LOOP AT itab INTO DATA(wa).
...
ENDLOOP.
With 7.40
FIND ... IN ... MATCH COUNT DATA(cnt).
Declaration of a result
Before 7.40
DATA xml TYPE xstring.
With 7.40
CALL TRANSFORMATION ... RESULT XML DATA(xml).
= cl_ixml=>create( ).
stream_factory = ixml->create_stream_factory( ).
document
= ixml->create_document( ).
With 7.40
DATA(ixml)
= cl_ixml=>create( ).
DATA(stream_factory) = ixml->create_stream_factory( ).
DATA(document)
= ixml->create_document( ).
This example is my favorite. When working with class libraries as the iXML-Library you don't have to care
about the data type of the reference variables too much any more. You simply create them inline and use them.
As you will see in the 7.40 version of the ABAP Example Library, this feature has facilitated my writings of
example programs considerably.
Field Symbols
For field symbols there is the new declaration operator FIELD-SYMBOL(...) that you can use at exactly three
declaration positions.
ASSIGN ... TO FIELD-SYMBOL(<fs>).
LOOP AT itab ASSIGNING FIELD-SYMBOL(<line>).
...
ENDLOOP.
READ TABLE itab ASSIGNING FIELD-SYMBOL(<line>) ...
I guess it is clear to you what happens here.
Outlook
In my upcoming blogs I will make use of inline declarations when introducing other new features. Be prepared
for code like this:
TYPES t_itab TYPE TABLE OF i WITH EMPTY KEY.
DATA(itab) = VALUE t_itab( ( 1 ) ( 2 ) ( 3 ) ).
Yes, this is ABAP 7.40 ...
37576 Views Tags: abap
...
endloop.
But then again this is down to the developer to manage. The same mistake is possible with a regular DATA
declaration up front.
Mike Pokraka in response to Horst Keller on page 6
3 Feb, 2016 1:53 PM
Understood, and that is exactly how an old-style DATA statement works.
But, since 'it will never do', can/should an inline DATA not be made more tolerant and just be local to the
method all the time?
If a global element of the same name already exists, it will be overshadowed (current behaviour).
If a local declaration (method, function module) already exists, the same element will be reused - as if the
data() statement were not there.
Just an idea that, to me at least, makes more sense than ever with inline declarations.
Horst Keller in response to Mike Pokraka on page 6
3 Feb, 2016 1:32 PM
I'd rather say big annoyance. An inline declaration is like a DATA statement at this position with all well known
drawbacks. But as already discussed here from time to time, ABAP does not support local data contexts in
control structures and I'm afraid it will never do.
Mike Pokraka
3 Feb, 2016 1:18 PM
Small annoyance: Why are multiple inline declarations not permitted in the same block? Would it not make
sense to just ignore something that's already declared and reuse it?
My main use case is an inline declaration that can be conditional and/or inside a loop.
if some condition.
read table x into data(wa) index 1.
endif.
...
if some other condition.
read table x into data(wa) where ...
endif.
It just seems awkward to have to use wa1 and wa2 here.
Regards,
Mike
Horst Keller in response to Suhas Saha on page 7
I always wondered, why do FMs get such love from the syntax checker?
Now i know
Oh yes, and in regard to the current situation ... it's a bug, bug, bug, bug, bug.
Horst Keller in response to Suhas Saha on page 9
3 Feb, 2016 10:37 AM
Is this somewhere specified in the ABAP documentation?
See CALL FUNCTION ...
(And the the last point here, hehe)
Horst Keller in response to Marc Cawood on page 8
3 Feb, 2016 10:34 AM
In theory, yes. But good ol' function modules are "different".
Remember, there's no ABAP syntax for defining a function module's interface as it is for methods.
Marc Cawood in response to Horst Keller on page 8
3 Feb, 2016 10:26 AM
In theory you (ABAP Product Management) could make a new keyword (or syntax variant) to call FMs
"strongly".
EXEC FUNCTION 'MYFUNC'.
or
CALL FUNCTION MYFUNC. " Instead of 'MYFUNC'
It's always been a weaknes of FMs that they compile when they're definitely gonna dump.
Horst Keller in response to Paul Hardy on page 9
3 Feb, 2016 10:21 AM
I suppose that is why, when you pass the wrong type of variable into a function module, the
normal syntax check doesn't say boo, but you get a short dump when you run the program.
And if a function module has three compulsory IMPORTING parameters and I only specify
two, no syntax error either.
Yes,, sure ...
I will now be told millions of reasons
One important reason is, its too old to be changed. There are miilions lines of code lying around worldwide that
call FMs wrongly but are never executed (dead, dead, dead), Now you go and make syntax errors out of that
and have some fun.
In fact, there are also fans of the lax checking. The reason is that you do not break a system if you change
an interface in an incompatible way as you do with methods. A true story that happened to me: I changed the
interface of a method of CL_ABAP_DOCU and forgot to adjust its callers before activating. As result callers
became syntactically incorrect and since CL_ABAP_DOCU is called far deeper in the system than I ever
expected, you could not logon to the system any more due to syntax errors in central modules. Unfortunately,
there was a customer presentation running on that system in SAP Arena, Mannheim that afternoon - no lie!
The presenter wasn't amused. And correcting the error also wasn't to simple (remember, no logon possible).
Admin had to import the old version of the class. Wouldn't have happened with a function module. I am not a
fan of lax checking but had to learn to be more careful the hard way.
Problem is that calling a function module other than calling a method is always a dynamic call. You specify the
function module as a field and never directly. The compiler doesn't know the function module.Specifying it with
a literal is pseudo static so to say. Then, some test tools (extended program check) evaluate the name, but not
the compiler.
Marc Cawood in response to Horst Keller on page 10
3 Feb, 2016 8:08 AM
How do you mean "constructor"?
Theoretically, if the parameters of a Function Module are strongly typed then the compiler can know the type...
Horst Keller in response to Marc Cawood on page 10
1 Feb, 2016 4:55 PM
See EXPORTING:
a1, a2, ... are general expression positions. In other words, functions and expressions can
be passed as actual parameters, alongside data objects.
-> You can pass your myStringMethod( ).
Unlike in , types cannot be specified generically (#) when a is specified. This is because the
typing of the parameters is not determined until runtime.
-> That's why you have to specify type string explicitly (or call a method).
Marc Cawood in response to Marc Cawood on page 10
1 Feb, 2016 3:43 PM
OK, gottit:
CALL FUNCTION 'LOAD_SOMETHING'
EXPORTING
customer = CONV kunnr( get( 'customer' ) )
Pretty cool - ABAP arrivoing in the 21st century at last!
Shai Sinai in response to Marc Cawood on page 10
1 Feb, 2016 2:41 PM
Do you mean CONV (ABAP News for Release 7.40 - Constructor Operators CONV and CAST)?
You must set the expected type explicitly though.
Marc Cawood
1 Feb, 2016 2:33 PM
Any way to dynamically cast inbound parameters of FUNCTION modules?
DATA: lv_s TYPE STRING VALUE '0000'.
Best,
Horst
Dionisio Ambrona
12 Sep, 2015 8:49 PM
Dear Horst Keller,
in a first place, thanks a lot for your blog. I'm just starting to learn about new ABAP 7.40 capabilities, so I find
it quite usefull and interesting.
Regarding your first example in this post,
Before 7.40
DATA text TYPE string.
text = `...`.
With 7.40
DATA(text) = `...`.
I have the following question: what is the data type in the second dclaration with 7.40, is it a type string
variable or is it a type c variable? Is there any rule so the system determines this?
I know by reading the blog that online declarations are specially meant to be used for calling methods
avoding extra code lines to declare help variables, but I'm just curious.
Thank you and best regards!
Dionisio
Jose Antonio Blanco de Cordova Diaz-Madroero
4 Jul, 2015 12:23 PM
I am full of happiness. Functional programming at last
Horst Keller in response to Sudhi Karkada on page 12
3 Jul, 2015 8:15 AM
Works as before, eg.,
Double clicking struct1, struct2 leads to the respective declaration, where you can double click the type.
Sudhi Karkada
2 Jul, 2015 7:16 PM
Thanks for the article and for introducing us to new ABAP.
I am sorry if this question was already asked and answered in the 5 pages of Q&A, but how does the doubleclick navigation work with this type of inline declarations? If the variable is a structure, would I be able to
eventually navigate (just by double-clicking a few times) to DDIC and see the structure components?
When I first started programming, many languages were sneered at because they did not require explicit data
declarations. Agreed, inline declaration is different, but still the trend is unsettling.
Horst Keller in response to Raphael Pacheco on page 13
2 Jul, 2015 6:38 PM
Would it be possible to write, for example, ADD 1 to DATA(i)?
Best
Horst
Raphael Pacheco
2 Jul, 2015 6:22 PM
Horst,
I have a basic question of this inline declarations.
How could I create a counter using the inline declarations? It would be possible to make, for example ADD 1 to
DATA(i)?
Warn regards,
Raphael Pacheco.
Michael Fritz in response to Nishant Bansal on page 13
4 May, 2015 7:47 AM
Hi,
no you can't use DATA(wa) again.
However after writing this inline declaration above, you can now use
LOOP AT itab INTO wa.
...
ENDLOOP.
anywhere in your coding. No need to declare wa again.
Michael
Nishant Bansal
4 May, 2015 7:30 AM
Dear Horst Keller,
First of all thanks for sharing this blog.
I have one question regarding this. Below i am taking one simple example.
With 7.40
LOOP AT itab INTO DATA(wa).
...
ENDLOOP.
After defining the WA using DATA(WA).
Can i define the same name WA variable again in the current session?
Actually i don't have system to test it.
Thanks and Regards,
Nishant
Sougata Chatterjee in response to Sougata Chatterjee on page 14
4 May, 2015 3:46 AM
Sorry, I take that back - it does work for exporting params. Thanks!
Sougata Chatterjee in response to Rdiger Plantiko on page 14
4 May, 2015 3:04 AM
Thanks but it will not work for me as I'm on SP05.
Rdiger Plantiko in response to Sougata Chatterjee on page 15
3 May, 2015 5:33 PM
Hi Sougata,
you want to pass a data object to the called function module, where it will not be changed (since you are
EXPORTING it).
The only case where this makes sense in my eyes would be that the inventor of the function module declared
an import parameter to be obligatory although not strictly needed in the code (i.e. although being optional in
fact), and you want to pass an initial value to it, just to satisfy the interface.
You can't do that with a DATA operator, but you could do it with VALUE:
https://ldcialx.wdf.sap.corp:44318/sap/public/bc/abap/docu?sap-language=EN&sapclient=000&format=STANDARD&object=ABENTYP
"The formal parameter or field symbol can be used as operands anywhere that is
not excluded by this typing. However, operands that expect particular internal
tables are an exception to this rule. Here, only formal parameters or field
symbols typed as internal tables with the appropriate table category are allowed."
Dominik Krmer in response to Horst Keller on page 16
8 Apr, 2015 4:45 PM
Hi Horst,
not sure if I fully understood your point.
In the debugger the type is correctly deduced as Sorted Table, only in the ABAP editor this is not recognised /
throws the error message: "." expected after "<FS_DT_DATA>"
Regards,
Dominik
Horst Keller in response to Dominik Krmer on page 17
8 Apr, 2015 4:21 PM
If no type can be deduced, the field symbol declared inline is typed with ANY. You never could/can use fully
generic field field symbols at operand positions of internal tables. That's the rule.
Horst Keller in response to Horst Keller on page 17
8 Apr, 2015 4:15 PM
The nonsense is independent from expressions
TYPES:
BEGIN OF t_flights,
scarr TYPE t_scarr,
END OF t_flights.
Thanks!
Michael Fritz
10 Mar, 2015 4:06 PM
You see I'm still learning those new inline declarations since we recently upgraded our ERP to 7.40 (SP08)
I wonder how to create an internal table without using any default values.
Previously I would have written a statement like this:
data: lt_w3head type STANDARD TABLE OF w3head.
Now I tried to get the same result using inline declaration, to no avail so far.
I need this internal table as a result table for a function module, hence I don't have any rows available so far.
The function module will return them instead.
Would it be possible to use those inline declarations for this purpose, too?
Michael
Horst Keller in response to Michael Fritz on page 19
10 Mar, 2015 9:40 AM
That means it does not matter if the IF condition is met or not and the program
execution immediately jumps into the ELSE branch?
Yes, but that's also kind of dangerous. Because there is no local context for data in control structures, the
declared objects are statically visible everywhere behind the declaration and dynamically (ASSIGN (name ) ...)
even everywhere in front of the declaration. Therefore, it needs some discipline when working with that, see the
guideline.
Michael Fritz in response to Horst Keller on page 20
10 Mar, 2015 9:34 AM
Horst,
thanks again for your reply.
That means it does not matter if the IF condition is met or not and the program execution immediately jumps
into the ELSE branch?
That's cool indeed!
I've just checked this and it works perfectly! Never thought of this! At the very end no short dumps or similar
when accessing the reference from the ELSE branch.
Thanks,
Michael
Horst Keller in response to Michael Fritz on page 20
10 Mar, 2015 8:38 AM
Well that's simple
IF NOT l_notif_no IS INITIAL .
DATA(o_reference) = NEW zcl_customer_service_base(
i_order_number
= ''
i_notif_number
= l_notif_no
i_use_notification = abap_true
i_no_notif_buffer
= abap_false
i_no_partner_init
= abap_true
i_remove_deleted_items = abap_true
).
ELSE.
o_reference = me. "<<-- ERROR here
ENDIF.
Note that
DATA(o_reference) = NEW zcl_customer_service_base( ...
The following will not work because of error "o_reference is already declared" when using the second inline
declaration in the ELSE branch.
IF NOT l_notif_no IS INITIAL .
DATA(o_reference) = NEW zcl_customer_service_base(
i_order_number
= ''
i_notif_number
= l_notif_no
i_use_notification = abap_true
i_no_notif_buffer
= abap_false
i_no_partner_init
= abap_true
i_remove_deleted_items = abap_true
).
ELSE.
DATA(o_reference) = me. "<<-- ERROR here
ENDIF.
Michael
Amol Vakhare in response to Horst Keller on page 22
23 Feb, 2015 9:12 AM
I see your point now.. With it I am more clearer on its usage. Thank you so much!
The DATA operator for inline delcarations is designed for being used at declaration
positions where the operand type is completely known and not for declaring variables of
any types before using them. So if you have e.g. a method retrurning a packed number, of
course you write
Why? Operator VALUE is not possible for elementary types except for the initial value.
Therefore, either initial value:
TYPES pack TYPE p DECIMALS 3.
DATA(val) = VALUE pack( ).
or the conversion operator:
TYPES pack TYPE p DECIMALS 3.
DATA(val) = CONV pack( '1.1' ).
But in fact the question remains, why you want to do this at all?
If you want to declare a packed number, simply do so by using statement DATA or TYPES. The DATA operator
for inline delcarations is designed for being used at declaration positions where the operand type is completely
known and not for declaring variables of any types before using them. So if you have e.g. a method retrurning a
packed number, of course you write
DATA(val) = get_packed( ... ).
This is a use case. Constructs as above are possible but more as side effects ...
Adi Sieker in response to Amol Vakhare on page 22
22 Feb, 2015 10:18 PM
Hi,
I would use a type from the data dictionary.
Cheers
Adi
Arrrrrgh
I think, if that is necessary to make the scope (method/function/form) readable then it's too complicated/long
and should be split up.
Paul Hardy in response to SAP ITR ENTWICKLUNG on page 27
19 Feb, 2015 11:56 AM
I agree there is a big bonus with making code shorter (leaner)
In Java and so forth everyone is sed to the good old { }.
However for good or for bad ABAP programmers are used to things like ENDIF, and I wonder if } is more
readable e.g.
is
ENDIF.
ENDCASE.
ENDMETHOD.
better than
}
}
}
When it comes to the readability stakes?
I presume in Eclipse when you hover over a "}" sign it tells you in a hover text the start of the code block the
sign is closing? In ABAP the official recommendation used to be to add a comment such as
ENDIF."Is the fish blue?
Cheersy Cheers
Paul
Rdiger Plantiko in response to Adi Sieker on page 26
19 Feb, 2015 11:41 AM
My rule of thumb is: The implementation part of a method should be visible completely on my screen, with
the signature part expanded => max. at about 30-40 lines of code per method, including blank lines and
comments.
Horst Keller in response to Adi Sieker on page 26
19 Feb, 2015 9:08 AM
I also think that 150 executable statements is to much. I think it should be around 50-70.
Yes, that's the factor you can gain by using expression enabled ABAP
In my opinion this is the number one thing that should be hammered into every developers head. I also think
that 150 executable statements is to much. I think it should be around 50-70.
Horst Keller in response to Linkin Pereira on page 27
19 Feb, 2015 8:51 AM
Well one argument would be with inline code you would not have 1000 lines of code
anyway
Linkin Pereira
18 Feb, 2015 9:21 PM
Thanks for this Blog post Horst. I haven't started playing around with 7.4 yet but sure looks interesting.
One thing scares me though is this.
Rule
Only use inline declarations locally
Only make inline declarations in processing blocks that support . Use them as if they were local declarations in
the current statement block.
Details
If used correctly, inline declarations are an excellent way of making programs leaner and easier to understand.
-----The IF used correctly part in the Details.
-------Don't you feel the code would be much difficult to maintain if the program is a 1000 lines code and some where
way up in the top there is an inline declared variable ( defined globally -- by mistake I may add) and you have
to debug this chunk of code to figure out where exactly is this variable defined.
With the usual declaration statement you know that the declaration is made with the TYPE statement.
-- Well one argument would be with inline code you would not have 1000 lines of code anyway.
Comments.
SAP ITR ENTWICKLUNG in response to Horst Keller on page 29
18 Feb, 2015 4:30 PM
Maybe with a new syntax element for scoping blocks like {... scoping block } as we know it from Java, C++...
Additionally there could be a scoping version of other block building statements like
If x = Y { ... }
loop at lt_a into ls_a { ... }
case y { when a. ... }
replacing the end[something] with the block closing sign. This would at the same time make the code leaner
and more readable.
Horst Keller in response to Sayantika Bhattacharya on page 28
21 Nov, 2014 5:58 PM
http://scn.sap.com/community/abap/blog/2014/10/08/abap-news-for-740-sp08--open-sql
Uwe Fetzer in response to Sayantika Bhattacharya on page 28
21 Nov, 2014 3:58 PM
Inline declaration within open SQL comes in SP8.
Sayantika Bhattacharya
21 Nov, 2014 3:57 PM
Hi,
My system is on Release 7.40 SP006. Inline declaration is giving syntax error.
My Code:
REPORT zr_opensql_01_aggregation.
SELECT bp_id,
company_name,
so~currency_code,
SUM( so~gross_amount ) AS total_gross_amount
FROM snwd_so AS so
INNER JOIN snwd_bpa AS bpa
ON so~buyer_guid = bpa~node_key
INTO TABLE @DATA(lt_result)
GROUP BY bp_id, company_name, so~currency_code.
Sayantika.
Saurabh Kumbhare
24 Oct, 2014 2:51 PM
Thanks!!
Franz Seidl
24 Oct, 2014 10:00 AM
Good posting! Thank you!
Horst Keller in response to Adi Sieker on page 29
14 Oct, 2014 11:05 AM
The backward compatibility trap. Building new features in old ABAP. There is no local context in old ABAP and
it seems to be impossible to enable it without breaking existing code.
Adi Sieker in response to Horst Keller on page 29
14 Oct, 2014 10:41 AM
Horst Keller wrote:
I know, I know, I know, ... sigh
ideally the scope of inline declarations would be the block they were defined for.
That was the first question most colleagues asked me when I showed them inline declarations.
i.e.the following would cause a syntax error on the last line, stating that ls_struc is unknown:
LOOP AT lt_table into DATA(ls_struc).
"Do something with ls_struc.
ENDLOOP.
add 1 to ls_struc-counter.
Horst Keller in response to Lokesh Balajee on page 30
14 Oct, 2014 9:03 AM
Hi Lokesch,
But, when I try this, I get an error.
PARAMETERS: p_from TYPE /sapapo/locno.
DATA(g_from1) = DATA(g_from) = p_from.
But seriously:
Inline declarations influenced the way we looked at those things and we tackled that as follows
Programming Guideline for Inline Declarations
Horst
Lokesh Balajee
13 Oct, 2014 9:13 PM
Hello Horst,
I recently started exploring 7.4 features and its fascinating.
This works well
PARAMETERS: p_from TYPE /sapapo/locno.
DATA(g_from) = p_from.
DATA(g_from1) = g_from.
http://help.sap.com/abapdocu_740/en/abennews-740-operand_positions.htm
But PERFORM is too outdated to be supported with the nice things ...
Volodymyr Shcheglov in response to Horst Keller on page
4 Oct, 2013 11:15 PM
Horst Keller wrote:
Hi Custodio,
This example is slightly irrelevant because you can use string templates. Since ABAP version 7.02 one is able
to write the code such as:
data: lv_str type string value 'initial'.
lo_api->method( iv_bname = |{ lv_str }| ).
This is applicable only to methods. Unfortunately, you can't do the same for function or procedures calls.
By the way, question to Horst: why isn't that feature implemented for older constructions such as CALL
FUNCTION or PERFORM, or macro calls? Was it too difficult, or it was just assumed there was no demand for
such things?
As for Rdiger's example, the real problem is with other convertible types, say, P or N. For example, we have
a method's parameter is defined as IV_PAR(8) TYPE P DECIMALS 4, and an actual parameter, as LV_VAL(6)
TYPE P DECIMALS 2. It's obvious that this variable can be easily converted to the formal parameter's type but
right now you will get a syntax error trying to call this method as:
LO_OBJ->METHOD( IV_PAR = LV_VAL ).
So,
CONV #( lv_bname ) would be handy.
Rdiger Plantiko in response to Paul Hardy on page 35
4 Oct, 2013 12:03 PM
[START DIGRESSION]
>It was better than the VIC20 even if that had much more memory
Disagree. The VIC20 had the better CPU: MOS Technology's 6502 was by far the best CPU available in the
market in those days - better then the 8080, and much better than the Z80 anyway. It's a pity that the x8...
family won the race, although its concepts are worse. BTW - see here an impressive page of a 6502 fan,
emulating the currents inside the processor during execution! http://www.visual6502.org/JSSim/
[END DIGRESSION]
Horst Keller in response to Paul Hardy on page 35
4 Oct, 2013 11:57 AM
http://en.wikipedia.org/wiki/List_comprehension
Paul Hardy in response to Horst Keller on page
4 Oct, 2013 11:04 AM
Hooray!
In 7.02 in about 2011 you let ABAP have expressions ike A = ( B + C) a construct BASIC could do in 1981, so
if someone had jumped forward 30 years in a "Back to the Future" car they would have been comfortable with
the language.
Now in 2013 we have the good old FOR NEXT LET LOOPS which again look just like the ZX81 syntax when I
started to program when I was 14. I'm 45 now.
I'm not complaining - this is a good thing, I loved programming the ZX81 even if it only had 1K of memory. It
was better than the VIC20 even if that had much more memory the programming language onthe VIC20 had
lots of holes in it, and workarounds e.g. PEEK / POKE.
Programming languages must be like the fashion industry. Don't throw anything out of your wardrobe, in thirty
years it will be fashionable again.
Cheersy Cheers
Paul