You are on page 1of 34


Defining Global Macros

by Joyjit Ghosh, IBM India

Most of the time we define macro in our program by DEFINE E%& DEFINE 'Name($ )'Name( * p+aceho+der for macro name ,tatement ,tatement $$ $$ END!"F!DEFINI#I"N$ -nd this macro can be ca++ed in the fo++owing way 'Name( par. par/ par0$ )par.

END!"F!DEFINI#I"N statement$

par0 * 1arameters, separated by spaces

#his abo2e definition is +oca+ to the program where it is defined i$e$ we cannot ca++ this macro from another program$ But we can create g+oba+ macro that can be ca++ed by any program$ G+oba+ macro can be created by maintaining entries in tab+e #3M-4$

Most popu+ar e%amp+e of standard g+oba+ 5system6 macro is B3E-7 which is defined in tab+e #3M-4 as shown in the screen shot be+ow$

From any program we can ca++ this macro as& B3E-7 'user id($ )'user id( * p+aceho+der for userid ,imi+ar+y if we want we can maintain our own g+oba+ macro in #3M-4 as shown be+ow& -dd new entry to #3M-4

4reate custom macro

4a++ this g+oba+ macro from a report


Caution: #ab+e #3M-4 is a system tab+e$ 3emo2ing or changing entries in this tab+e can mess up the system$

Macro to validate Date

Content Author : Abhishek Kumar Email Address : Website :

*======================================================================* * Programme : zdate_validate * * Title : Macro to validate Date * * Author : Abhishek Kumar * * Description : This program has t o macros and a sample code hich is * * sho ing ho to use that! * * Macro "! # $al_date * * Macro %! # $aldate * * &t return '()'ubrc value i* it + then the entered date * * is valid else either the date is invalid or the * * speci*ied *ormat is invalid * *))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))* * ,reated and Designed b- Abhishek Kumar in .ov %++"! * *))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))* *Abhishek is not responsible *or an- damages caused b- the use or * *misuse o* this program and cannot provide an- arrant- ith this * *program! /se it entirel- at -our o n risk! * * * *(ou are not authorised to make an- changes ithout prior ritten * *permission *rom the author! * *======================================================================* P0120AM 3DAT4_$A5&DAT4 ! * $alidation o* Date D46&.4 $A5_DAT4! ,54A0: 7_DAT4"8 7_DAT4%! 7_DAT4"9:; = <"! =(ear 7_DAT4">:9%; = <%! =Month 7_DAT4">?9%; = <@! =Date 7_DAT4% = 7_DAT4" ) "! 7_DAT4% = 7_DAT4% > "! &6 7_DAT4" A# 7_DAT4%! '()'/B0, = "! 45'4! '()'/B0, = +! 4.D&6! 4.D)16)D46&.&T&1.! D46&.4 $A5DAT4! *************************************************** * Passing Parameters: <" ) Date * <% ) Date 6ormat * * Date 6ormat: * DDMM(((( MMDD(((( ((((MMDD ((((DDMM * * '()'/B0, 0eturn $alue: * " invalid date * + $alid Date * % &nvalid 6ormat

*************************************************** DATA: 7_DAT4" 5&K4 '()DAT/M 8 7_DAT4% 5&K4 '()DAT/M 8 7_DAT4@9C;! case <%! hen DDDMM((((D! val_date <">:9:; <">%9%; <">+9%;! hen DMMDD((((D! val_date <">:9:; <">+9%; <">%9%;! hen D((((MMDDD! val_date <">+9:; <">:9%; <">?9%;! hen DMM((((DDD! val_date <">%9:; <">+9%; <">?9%;! hen others! s-)subrc = %! endcase! 4.D)16)D46&.&T&1.! *********************************************** * 'AMP54 /'4 o* above MA,01 * *********************************************** DATA: $_DAT49C;! $_DAT4 = D@++%%++%D! *=# $A5DAT4 $_DAT4 DDDMM((((D! *=# &6 '()'/B0, = +! E0&T4:F D$alid DateD! 45'4&6 '()'/B0, = "! E0&T4:F D&nvalid DateD! 45'4&6 '()'/B0, = %! E0&T4:F D&nvalid 6ormatD! 4.D&6! ********************************************************************* *)) 4nd o* Program

Macro in ABAP

* * Macro in ABAP * * 'ubmitted b- : 'AP Basis8 ABAP Programming and 1ther &M2 'tu** * http:FF !erpgreat!com * 04P10T 3MA,01! DATA: 04'/5T T(P4 &8 ." T(P4 & $A5/4 G8 .% T(P4 & $A5/4 ?! D46&.4 1P40AT&1.! 04'/5T = <" <% <@! 1/TP/T <" <% <@ 04'/5T! 4.D)16)D46&.&T&1.! D46&.4 1/TP/T!

E0&T4: F DThe result o* <" <% <@ isD8 <:! 4.D)16)D46&.&T&1.! 1P40AT&1. : > @! 1P40AT&1. % ** H! 1P40AT&1. .% ) ."! *)) 4nd o* Program

Y9030013: A macro (DEFINE ) Definition an proce!!in" int# ta$%e

A small macro should show that these interesting control statements can be inserted in quite different ways. In this example only scratches the surface of the macro possibilities. DEFINE VARTAB

&1 = The table name of the internal table is determined. &2 = A field name with the length ! of the type ". & = The table structure is specified by the rd parameter. #.g. of a macro call$ %&A'TA( IT1!! )I#*+,A-# T1!!.. -/&# &1 T/ &20 !. = The content of source field &1 mo1ed to the target field 2&20 !3 -/&# & T/ &24)I#*+,A-#. = The &2 parameter will be connected with %)I#*+,A-#.. A55#,+ &2. = The internal table &2 will be filled. #.g. of a macro call$ %)I**TA(1 T1!! IT1!! 6T1!! 78..


The parameters of the call of )I**TA(1 must refer to the parameters used in &A'TA( call. "onsequently the A(A5 interpreter %must already 9now. the real field names of the internal table when calling the macro )I**TA(. The internal table is only effecti1e on internal le1el. The same memory area is allocated for both tables.

A&A' 8()ource(Co e
:ou can cut and paste the source code directly into the A(A5 4;or9bench.

1 2 3 4 5 6 7

04P10T (I+@++"@ 5&.4)'&34 "@+!

=0elease @!"28 :!GA

************************************************************************ * ,op-right 9c; "III b- ,T)Team8 @@:"G $erl8 http:FF * * * * * (ou can use or modi*- this report *or -our o n ork as long !ct)so*t are!com

as -ou donDt tr- to sell or republish it! &n no event ill the author be liable *or indirect8 special8

&ncidental8 or conseJuental damages 9i* an-; arising out o*

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

* * onl- use

the use o* this report! ith the ,T)D4B/2_'imulator

************************************************************************ *B04AK)P1&.T! *FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF* M1$4: D0ead tables and use a $A0TAB 9D46&.4)Macro;D T1 '()T&T54! *FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF* *************** TAB54': (T"++! * *************** D46&.4 $A0TAB! DATA: B42&. 16 <" 1,,/0' +! DATA: <%9@+; T(P4 ,! &.,5/D4 'T0/,T/04 <@! DATA: 4.D 16 <"! 4.D)16)D46&.&T&1.! * D46&.4 6&55TAB"! M1$4 <" T1 <%>@+! M1$4 <@ T1 <%)6&45D.AM4! APP4.D <%! 4.D)16)D46&.&T&1.! * *FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF* ************* ) Main 'ection ******************* Macro de*initions ********************** 4Kternal tables **********************


34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59


*FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF* ************************************************************************ * 0ead and displa- a *e ro s o* T"++

************************************************************************ 610M 04AD)D&'P5A()(T"++! * /5&.4! 'K&P %! E0&T4: FG D'tep ": 0ead and displa- &T"++ D ,1510 G! *!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! * $A0TAB &T"++ 6&45D.AM4 (T"++! =macro

*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! '454,T * 601M (T"++ /P T1 G+ 01E'


60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
9sua++y, macros are not we+comed by de2e+opers, and in many teams they are banned in the programming guide+ines$ "b2ious+y, there are arguments that spea: against macros$ But in recent years, I +earned to appreciate their positi2e features$ I wou+d not recommend a genera+ macro ban in an -B-1 de2e+opment project$ In this b+og, I wi++ e%p+ain why$ No doubt: acros are no real modulari!ation techni"ue# like includes the$ are lacking an own e%ecution conte%t. And# $es# with the e%ception o& e%tremel$ simple macros# the$ are di&&icult to debug '( will come to that later). *he$ simpl$ are source code trans&ormations at a pre+compile stage. ,ut the$ ha-e a number o& ad-antages. #he positi2e points that I see with macros are&

%I D3M'2.0D8 @? DMessageteKt"D8 HH DMessageteKt%D! /5&.4! 'K&P! * 511P AT &T"++! E0&T4: F" &T"++)3'P0'58 C &T"++)3A0B2B8 %I &T"++)3M'2.08 @?9:+; &T"++)3T4OT"8 HH9:+; &T"++)3T4OT%! 4.D511P! * 4.D610M! ************************************************************************ ************************************************************************ ******************* 4.D 16 P0120AM *************************************

*he$ help to make code more readable. *he$ help hide implementation details &rom the code.s main intentions. *he$ help a-oid code repetition.

A Sample Refactoring Session

Consider the &ollowing# t$pical e%ample. (t is a piece &rom our codebase 'although /0 $ears old# i& $ou accept this as e%cuse...). 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. CLEAR ls_fieldcat. CLEAR ls_fieldcat. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos ls_fieldcat-hotspot = 'BEZCH'. = gc_tab_head. = 2. = gc_x. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos ls_fieldcat-hotspot = 'ABELN'. = gc_tab_head. = 1. = gc_x. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos = 'CHECKBOX'. = gc_tab_head. = 0. FORM alv1_fieldcat_create CHANGING ct_fieldcat TYPE slis_t_fieldcat_alv.

DATA: ls_fieldcat TYPE slis_fieldcat_alv.

APPEND ls_fieldcat TO ct_fieldcat. CLEAR ls_fieldcat.

APPEND ls_fieldcat TO ct_fieldcat.

APPEND ls_fieldcat TO ct_fieldcat.

25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47.

ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos

= 'STAT_FIELD'. = gc_tab_head. = 3.

APPEND ls_fieldcat TO ct_fieldcat.

CLEAR ls_fieldcat. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos = 'AUFAR'. = gc_tab_head. = 4.

APPEND ls_fieldcat TO ct_fieldcat.

CLEAR ls_fieldcat. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos = 'COUNT_POS'. = gc_tab_head. = 5.

APPEND ls_fieldcat TO ct_fieldcat.

CLEAR ls_fieldcat. ls_fieldcat-fieldname ls_fieldcat-tabname ls_fieldcat-col_pos = 'MESSAGE'. = gc_tab_head. = 6.

APPEND ls_fieldcat TO ct_fieldcat.


" alv1_fieldcat_create

What is the intention o& this code1 A &ield catalog has to be &illed: 2or each &ield# the column name and the position in the grid 'col3pos) are speci&ied. *wo o& the &ields are designed as hotspot &ields 'hotspot 4 .5.). #he code repetition is annoying$ It distracts the eye from the essentia+ part of the code$ "n+y the parts that are 2arying from b+oc: to b+oc:, are what is rea++y essentia+ in this code$ #he rest is inessentia+ boi+erp+ate code$ It is waste of time to be forced to study this repetiti2e code +ine by +ine, when this routine has to be inspected in a support or enhancement session$ -n ob2ious impro2ement wou+d be to parametrize the code and to use a modulari!ation unit + in this case# a subroutine:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

form add_field using iv_fieldname type c iv_col_pos type i changing ct_fieldcat type slis_t_fieldcat_alv.

data: ls_fieldcat type slis_fieldcat_alv. ls_fieldcat-fieldname = iv_fieldname. ls_fieldcat-tabname = gc_tab_head. ls_fieldcat-col_pos = iv_col_pos. append ls_fieldcat to ct_fieldcat.

11. endform. 12.


13. form set_hotspot using iv_fieldname type c 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. endform. "set_hotspot data: ls_fieldcat type slis_fieldcat_alv. ls_fieldcat-hotspot = 'X'. modify ct_fieldcat from ls_fieldcat transporting hotspot where fieldname = iv_fieldname. assert sy-subrc eq 0. changing ct_fieldcat type slis_t_fieldcat_alv.

Note the assertion in routine set3hotspot which makes the program crash i& a non+e%isting &ieldname has been t$ped b$ the de-eloper as actual parameter. *his tribute to the 6crash earl$6 principle helps a-oid t$pographical errors. With these routines a-ailable# A78/32(E79CA*3C:EA*E could be identicall$ rewritten as &ollows:

1. 2. 3. 4.

form alv2_fieldcat_create using ct_fieldcat type slis_t_fieldcat_alv. if list_var = 3. perform add_field using 'CHECKBOX' changing ct_fieldcat. 0

5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

endif. perform add_field using 'ABELN' 1 changing ct_fieldcat. perform add_field using 'BEZCH' 2 changing ct_fieldcat. perform add_field using 'STAT_FIELD' 3 changing ct_fieldcat. perform add_field using 'AUFAR' 4 changing ct_fieldcat. perform add_field using 'COUNT_POS' 5 changing ct_fieldcat. perform add_field using 'MESSAGE' 6 changing ct_fieldcat. perform set_hotspot using 'ABELN' changing ct_fieldcat. perform set_hotspot using 'BEZCH' changing ct_fieldcat. " alv2_fieldcat_create

22. endform.

;ith this change, we effecti2e+y sa2ed ./ +ines of code in comparison to the origina+ 2ersion$ Moreo2er, .< +ines of the new code, the two form routines, appear to be reusab+e in other programs as we++$ #hey cou+d be e%tracted into a genera+!purpose subroutine poo+ for fi++ing -=> fie+d cata+ogs$ In comparison, not a sing+e +ine of the origina+ code was reusab+e$ ,ut the real win is that the routine al-;3&ieldcat3create is now much better readable. Also# opening an e%tra stack le-el &or each add3&ield call is no per&ormance problem# since we are calling it onl$ &or a couple o& &ields 'and not thousands o& times + and e-en then: in the ma<orit$ o& the cases# not the call o& a routine is a per&ormance issue# but the code contained within that routine=). oreo-er# we do not need to e%plicitl$ initiali!e the workarea ls3&ieldcat an$ more# since we ha-e a little bo% with &resh# initiali!ed data &or each call. *he need to e%pliticitl$ initiali!e something is bad# since it could be &orgotten. (n &act# ( consider it as a code smell when ( encounter a 6C7EA: something6 statement se-eral times in the middle o& a code block: *he -ariable 6something6 ob-iousl$ is reused &or se-eral purposes in the same code block. (t is better to e%tract the code parts beginning with that 6C7EA: something6 statement into an own module '&orm routine# method# &unction module). ,ut ( am still not happ$ with A78;32(E79CA*3C:EA*E. *here is too much ado# too much 6code noise6 &or such a simple task as adding some rows with &ield names to an internal table. *he man$ 6per&orm add3&ield6 are still disturbing. ( would like to emplo$ the reall$ use&ul 6Colon/Comma6 notation in order to write 6per&orm add3&ield6 onl$ once. -pp+ying the ?4o+on@4omma? notation, gi2es the fo++owing&

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

form alv3_fieldcat_create using ct_fieldcat type slis_t_fieldcat_alv. if list_var = 3. perform add_field using 'CHECKBOX' changing ct_fieldcat. endif. perform add_field using : 'ABELN' 1 changing ct_fieldcat, 'BEZCH' 2 changing ct_fieldcat, 'STAT_FIELD' 3 changing ct_fieldcat, 'AUFAR' 4 changing ct_fieldcat, 'COUNT_POS' 5 changing ct_fieldcat, 'MESSAGE' 6 changing ct_fieldcat. perform set_hotspot using : 'ABELN' changing ct_fieldcat, 'BEZCH' changing ct_fieldcat. " alv3_fieldcat_create 0

24. endform.

*his is slightl$ better# but still contains unwanted repetition. (t.s clear that we are working with ct3&ieldcat. We don.t want our attention led e-er$ second line to this &act. >n the other hand# b$ the s$nta% rules# a C?AN@(N@ parameter has to come at the end o& a AE:2>: call and there&ore alwa$s is part o& the statement.s 6tail6 which can.t be abbre-iated awa$ with the Colon/Comma s$nta%. #his is where macros come into p+ay$ ;e cou+d use these two 2ery short macros for encapsu+ating the perform ca++s& 1. 2. define _add_field. perform add_field using &1 &2 changing ct_fieldcat.

3. 4. 5. 6.

end-of-definition. define _set_hotspot. perform set_hotspot using &1 changing ct_fieldcat. end-of-definition.

Note that these macros re"uire the e%istence o& certain named -ariables in the conte%t where the$ are called: (n this case# there needs to e%ist a -ariable with the name ct3&ieldcat. *his implies that these macros are not uni-ersall$ usable# but onl$ &or a speci&ic conte%t. ;ith these macros, the form routine now shrin:s to its minimum siAe and a+most ma%imum e%pressi2eness& 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. form alv4_fieldcat_create using ct_fieldcat type slis_t_fieldcat_alv. if list_var = 3. _add_field 'CHECKBOX' 0. endif. _add_field : 'ABELN' 'BEZCH' 1, 2,


'COUNT_POS' 5, 'MESSAGE' _set_hotspot : 'ABELN', 'BEZCH'. " alv4_fieldcat_create 6.

15. endform.

(& we add the code lines &or the macros# the sa-ings in lines o& code are not gigantic. ,ut that is not the important part. What reall$ matters is that the routine &or &illing the &ield catalog is now reduced to its intended parts: What $ou see written in A78432(E79CA*3C:EA*E is precisel$ what the de-eloper intended. Not more. *he rest is code noise# banned behind the scenes. (& the assignment o& the col3pos to the &ield is not used elsewhere 'and wh$ should it1)# ( could e-en think o& a -ersion which auto+generates the col3pos. Bince the code itsel& has a se"uence# it is not necessar$ to speci&$ this se"uence a second time with the col3pos parameter. #he routine addBfie+d cou+d +oo: +i:e this& 1. form add_field using iv_fieldname type c

2. 3. 4. 5. 6. 7. 8. 9. 10. endform.

changing ct_fieldcat type slis_t_fieldcat_alv.

data: ls_fieldcat type slis_fieldcat_alv. ls_fieldcat-fieldname = iv_fieldname. ls_fieldcat-tabname = gc_tab_head. ls_fieldcat-col_pos = lines( ct_fieldcat ). append ls_fieldcat to ct_fieldcat.


4orresponding+y, the macro passes on+y one parameter& 1. 2. 3. define _add_field. perform add_field using &1 changing ct_fieldcat. end-of-definition.

And &inall$ the e%plicit col3pos can be thrown out o& the code: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. endif. _add_field : 'ABELN', 'BEZCH', 'STAT_FIELD', 'AUFAR', 'COUNT_POS', 'MESSAGE'. _set_hotspot : 'ABELN', 'BEZCH'. form alv5_fieldcat_create using ct_fieldcat type slis_t_fieldcat_alv. if list_var = 3. _add_field 'CHECKBOX'.

16. endform.

" alv5_fieldcat_create

Bumming up# we ha-e re&actored b$ using a combination of reusab+e subroutines and macros, ta:ing ad2antage of both of these techniCues&

Bubroutines 'or methods or &unction modules) contribute b$ pro-iding an own e%ecution conte%t# with auto+initiali!ed local -ariables and clear parameters &or import and e%port. acros contribute b$ simpli&$ing the notation o& the call# impro-ing readabilit$ o& the client code '6client6 in the sense o&: being a caller o& the subroutines). -++ the three ad2antages I mentioned abo2e are achie2ed& Nobod$ would den$ that the &inal -ersion alv5_fieldcat_create is better readable than the original. *he implementation details 'here the 6boring6 population o& an internal table) has been e%tracted &rom the code. (nstead o& se-eral almost+identical code segments# we are now reusing code# and onl$ the -ariable parts are -isible in the top+le-el code block.

*appin" )tructure!
-nother e%amp+es for i++ustration& move-corresponding is a great statement &or mapping between di&&erent structures# i& $ou control the 99(C de&inition o& both source and target structure. At the edge between two di&&erent code parts# howe-er# this 6mo-e+b$+name6 rule will not su&&ice# and an e%plicit mapping o& structure components is re"uired. *his produces nois$ code 'again# a real+li&e e%ample with -er$ old# but still producti-e code): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. * 14. 15. * 16. * * gs_kundendaten-customer = gs_kundenauftragsdaten-partn_numb. gs_kundendaten-title_key = gs_kundenauftragsdaten-title_key. gs_kundendaten-title_p = gs_kundenauftragsdaten-title.

gs_kundendaten-firstname = gs_kundenauftragsdaten-name_2. gs_kundendaten-lastname = gs_kundenauftragsdaten-name. gs_kundendaten-secondname gs_kundendaten-street = gs_kundenauftragsdaten-street.

gs_kundendaten-house_no gs_kundendaten-postl_cod1 = gs_kundenauftragsdaten-postl_code. gs_kundendaten-city = gs_kundenauftragsdaten-city.

gs_kundendaten-tel1_numbr = gs_kundenauftragsdaten-telephone. gs_kundendaten-tel2_numbr = gs_kundenauftragsdaten-telephone2. gs_kundendaten-tel3_numbr gs_kundendaten-fax_number = gs_kundenauftragsdaten-fax_number. gs_kundendaten-e_mail gs_kundendaten-langu_p = gs_kundenauftragsdaten-langu.

17. * 18.

gs_kundendaten-langu_descr gs_kundendaten-country = gs_kundenauftragsdaten-country.

;hen I had to change another piece of the method which contained that code, I p+aced this +itt+e macro in the c+asses macro section& 1. 2. 3. define _move_from_to. &2-&4 = &1-&3. end-of-definition.

With this one+line macro# that code part could be rewritten in a more readable wa$ Csorr$ &or the screenshot# but ( see no wa$ to customi!e 6<i-e6 code sections with a monospaced &ont# as would be naturalD:

-s was the case in the origina+ code, mistyped co+umn names wi++ be detected at compi+e!time ! which is good$ Macro!based code on+y looks like free te%t, but is eCua++y strict concerning the synta% as any other -B-1 code$

Dec%arati+e pro"rammin": A $utton !tate! e,amp%e

Buppose# there is a number o& buttons re"uested &or a new web application. *he state o& these buttons + whether the$ are in-isible# inacti-e 'i.e. -isible but not clickable)# or acti-e# has been speci&ied depending on the current transactional mode 'create mode# change mode# displa$ mode). #he change reCuest might contain the fo++owing +itt+e tab+e&

;ith macros, it is possib+e to ta:e this tab+e o2er into the coding as it is written in the spec!

2or this# let us create a little dictionar$: We need a data t$pe &or the &code 'the user command 4 the button he pressed)# &or the transactional mode 'create# change or displa$)# and &or the button state 'acti-e# inacti-e# in-isible). Da2e in mind that such a dictionary wi++ be used throughout the who+e app+ication, it is not defined on+y for this particu+ar purpose$ It is good sty+e to define data types and structured constants for a++ the discrete 2ariab+es appearing in the data mode+ of the app+ication$ When using code instead o& 99(C &or illustration# the t$pes could look like this

1. 2. 3. 4.

types: ty_fcode type c length 4, " User command ty_state type x length 1, " Button state (active, inactive, invisible) ty_mode type n length 1. " Mode (create, change, display)

#o define the different 2a+ues these types may ha2e, we use structured constants$ In rea+ +ife, we wou+d p+ace these constants in a type poo+ or in a c+ass section$ -nyway, the dec+aration of the possib+e 2a+ues of a++ these data wi++ +oo: +i:e this&

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

constants: begin of fcode, actualize type ty_fcode value 'ACTU', save undo reject print type ty_fcode value 'SAVE', type ty_fcode value 'UNDO', type ty_fcode value 'CANC', type ty_fcode value 'PRNT',

end of fcode, begin of mode, create change type ty_mode value '1', type ty_mode value '2',

display type ty_mode value '3', end of mode, begin of state, active type ty_state value 0,

inactive type ty_state value 1, invisible type ty_state value 2, end of state.

=etEs say, we define a method which retrie2es the button state, depending on transactiona+ mode and button code&

1. 2. 3.

methods get_state importing iv_fcode type ty_fcode iv_mode type ty_mode returning value(ev_state) type ty_state.

#hen we can introduce the fo++owing macro&

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

define _set_button_state_per_mode. if iv_fcode eq fcode-&1. case iv_mode. when mode-create. ev_state = state-&2. when mode-change. ev_state = state-&3. when mode-display. ev_state = state-&4. endcase. endif. end-of-definition.

#his fina++y a++ows us to imp+ement the method simp+y by copy!pasting the change reCuestF

?ow is the change beha-iour o& this code when re"uirements will change1 #here wi++ hard+y e2er be a new transactiona+ mode$ #herefore, the macro definition wi++ a+most ne2er be changed$ But there may be new buttons in the future, and the gi2en state definitions may be changed in forthcoming 2ersions of the software$ #herefore, what is most +i:e+y to be changed, is the imp+ementation of the method get_state$ In this form, with the -B-1 code actua++y hidden behind the macro, the part that is most +i:e+y to be changed, can be changed with ma%imum ease, readabi+ity ! and safety$ #here are no direct 2a+ues +i:e strings 5where a typo wou+d appear at

runtime, not at compi+e!time6& the symbo+s in use ! +i:e active or reject ! need to be defined in the appropriate structured constant ! otherwise the method wi++ not compi+e$

,ince macros do not ha2e an own e%ecution conte%t, they cannot be disp+ayed proper+y in the debugger$ -++ the statements +isted in the macro wi++ be shown and e%ecuted as on+y one statement in the debugger$ It is not possib+e to sing+e!step through the instructions of a macro$ #his c+ear+y is a prob+em ! but on+y for high+y comp+e% macros which of course shou+d be a2oided$ - ru+e of thumb& If you find out that your macro spans more than three statements, you might consider to e%tract these +ines in a form routine or a pri2ate method, +ea2ing on+y the ca++ of this method in the macro$

)-m$o%! an .itera%!
,ince macros operate on a pre!compi+e +e2e+, they donEt distinguish +itera+s and symbo+s$ #he actua+ parameters can be used for bui+ding symbo+s 5+i:e method names or 2ariab+e names6 as we++ as for character +itera+s ! or both at the same time$ Just for i++ustration, thin: of the fo++owing macro& 1. 2. 3. 4. 5. 6. end-of-definition. define _set_field. ls_fieldcat-&2 = &3. modify ct_fieldcat from ls_fieldcat transporting &2 where fieldname = '&1'. assert sy-subrc eq 0.

It cou+d be app+ied +i:e this& 1. 2. 3. _set_field ABELN : hotspot 'X', scrext_m text-001.

?ere# E; and EF are replaced b$ a part o& a s$mbol name and a literal# respecti-el$. When using a subroutine or method instead# the component E; o& a structure would be accessible onl$ b$ d$namic programming + using a statement like ABB(@N C> A>NEN* ... >2 B*:GC*G:E ... *> ... + which is more complicated. Also# a t$pographical error in the macro would be detected immediatel$ b$ the compiler 'i& there is no component o& the gi-en structure). #he first macro parameter is specia+$ It is passed without Cuotation mar:s, but is used inside the macro to bui+d a string 5$$$ where name * EG.E 6$ #his wor:s, but is not safe$ ,omebody cou+d con2ert your code to +ower case$ #hen the modify statement wi++ fai+$ #o a2oid this, one can norma+iAe the case of the passed parameter first& 1. 2. 3. define _set_field. ls_fieldcat-fieldname = &1. translate ls_fieldcat-fieldname to upper case.

4. 5. 6. 7.

ls_fieldcat-&2 = &3. modify ct_fieldcat from ls_fieldcat transporting &2 where fieldname = ls_fieldcat-name. assert sy-subrc eq 0. end-of-definition.

#his macro wou+d be case!safe ! a+though it now e%ceeds three +ines of code$ 4+ear+y, in this case it is better to pass G. as a +itera+& 1. 2. 3. 4. 5. define _set_field. ls_fieldcat-&2 = &3. modify ct_fieldcat from ls_fieldcat transporting &2 where fieldname = &1. assert sy-subrc eq 0. end-of-definition.

*acro! a! &ui% in" &%oc/! for Interna% D).!

3ecent+y, my interest for macros was renewed, when I was reading Martin Fow+erEs boo: on Domain Specific Languages (DSL). ;hat is a D,=H Dere is a definition by Martin Fow+er& Domain-specific language 'noun): a computer programming language o& limited e%pressi-eness &ocused on a particular domain. Important points& ?e intentionall$ writes 6computer language6# not 6programming language6. >& course# there is logic and processing behind any 9B7. ,ut o&ten# a 9B7 &eels more declarati-e than imperati-e. *he te%t processing s$stem TeX and SSare e%amples o& 9B7s with a declarati-e taste# while S!L# regular e"pressions or the language o& makefiles are 9B7s that &eel more like a programming language. a$ this be as it is + at least# all 9B7s ha-e language &eatures: *he$ ha-e a grammar# a dictionar$ and a set o& allowed e%pressions. (mportant is the limite# e"pressi$eness o& the language. Hou can.t use a 9B7 to sol-e an$ so&tware problem. *his is an important di&&erence to programming languages like A,AA# Ia-a and so on. With *uring complete languages like A,AA# $ou can sol-e any problem# i& it is algorithmicall$ sol-able at all. ,ut $ou can.t use a 9B7 to sol-e an$ problem. A 9B7 is designed &or one particular problem# or a particular class o& problems. ,eing restricted to a particular domain# a good 9B7 re"uires a s$nta% which makes it as rea#able as possible for the e"pert of that particular #omain. Ke$words and statement structure should be chosen in such a wa$ that the code displa$s the intention with ma%imum readabilit$# minimum code noise. (n the e%amples abo-e 'CBB# make&iles and regular e%pressions)# de-elopers are the users. (n a so&tware &or business applications# the code should be business+readable. Martin Fow+er describes two categories of domain!specific +anguages&

*he &irst categor$# the e"ternal DSLs# are de&ined and parsed outside o& the host language# thus re"uiring an own parser. >n the other hand# the internal DSLs are in &act &ragments o& code written in the host language 'under certain rules). *he$ are parsed# compiled and e%ecuted like an$ other part o& the host language. *here is no separate parser necessar$. Dere is one of Fow+erEs e%amp+es for an interna+ D,=$ 9sing the ?$? member access operator, which is a standard feature of many +anguages +i:e Ja2a, Ja2a,cript, or 4@4II, he can write down a code fragment which configures a 14, fo++owing the so!ca++ed metho# chaining pattern& 1. 2. computer() .processor()

3. 4. 5. 6. 7. 8. 9. 10. 11.

.cores(2) .i386() .disk() .size(150) .disk() .size(75) .speed(7200) .sata() .end();

Due to the +anguage restrictions, there sti++ is some syntactic noise in this code& #he brac:ets, the dots, and the computer56 and end56 statement are not part of the code intention$ But e2erybody understands direct+y that this te%t is about specifying the parts of a computer$ Dow wou+d one design that part in -B-1H 9sing macros, we cou+d write& 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. disk 2 : size 75, speed 7200, type sata. disk 1 : size 150. processor : cores 2, type i386.

;e wi++ see in a minute how to imp+ement the under+ying macros$ For the moment, I just want to say that I find this 2ersion more e%pressi2e, more to!the!point than the Ja2a e%amp+e with method chaining$ "n+y the E.E and E/E, the numbering of the dis:s, is a sma++ technica+ debt 5why cou+dnEt the system increment such a counter behind the scenesH6$ #his is necessary because otherwise we cou+dnEt detect when the configuration of the first is finished, and the second dis: begins$ But we cou+d se++ this as a feature& Instead of E.E and E/E, we cou+d e$g$ use this parameter to assign names to the different dis:s$$$ E2erything in this code is under synta% contro+& If you typed E%ataE instead of EsataE, and %ata is not a supported dis: type, the compi+er wi++ send a synta% error$

)tructure Con!tant! a! Dictionar#he first techniCue for imp+ementing such a D,= is using structure# constants$ ,uppose we want to specify a dis: type from a gi2en +ist of dis: types, using a macro ?dis:Btype?$ ,o in the D,= we just want to type 1. disk_type sas.

#hen an appropriate fie+d of the semantic mo#el, +etEs say a component of a structure ls_#isk, shou+d be fi++ed with the dis: type, here E,-,E$ -+so, it shou+d be impossib+e to type others than the dis: types :nown to the system$ In order to specify the :nown dis: types, we use a structured constant& 1. 2. 3. 4. 5. begin of gc_disk_type, sata type string value 'SATA', sas scsi type string value 'SAS', type string value 'SCSI',

end of gc_disk_type.

Now# we can de&ine the macro 'a one+liner# as usual):

1. 2. 3.

define disk_type. ls_disk->type = gc_disk_type-&1. end-of-definition.

;e proceed simi+ar+y with a macro processorBtype for the different processor types 5iJKL, iLKL, 114,$$$6$ #he ad2antage of the structured constant is that it can be used e+sewhere in the code, too, as a rep+acement of a string +itera+ by a symbo+ic name 5which is good practice anyway6$

Name Compo!ition
#here is another usefu+ techniCue in this conte%t$ I wou+d +i:e to ca++ it name composition$ #he idea is to use one of the macro arguments to bui+d a :nown symbo+ic name ! e$g$ of another macro, of a method, subroutine, function modu+e$ In the e%amp+e abo2e, the instructions for the processor 1. 2. 3. processor : type i386, cores 2.

are using the co+on @ comma notation, which fits nice+y ! the co+on has an e%p+anatory meaning, in the sense& ?#he fo++owing parts specify in detai+ what is preceded by me$? #hat is e%act+y what is intended here$ #echnica++y, howe2er, this e%pands into two ca++s of a macro named EprocessorE& 1. 2. processor type i386. processor cores 2.

We will now use the second macro argument &or building the name o& a speci&ic macro that has to be emplo$ed instead. *his is name composition: 1. 2. 3. define processor. processor_&1 &2. end-of-definition.

Now, we can add macros for a++ the things we want to specify for the processor 5which is designed as a component of the object eoBprocessor here6& 1. 2. 3. 4. 5. 6. 7. define processor_cores. eo_computer->gs_processor-cores = &1. end-of-definition. define processor_type. eo_computer->gs_processor-type = gc_processor_type-&1. end-of-definition.

#his wor:s simi+ar+y for the dis: specification$ #he on+y point here is that there are se2era+ dis:s$ #herefore, we need the name argument 5the second argument6 of the macro, to get the right tab+e +ine, before the data can be ca++ed$ If we ha2e a +oca+ reference 2ariab+e +sBdis:, pointing to a dis: structure, the macro ?dis:? is written as fo++ows& 1. 2. 3. 4. 5. 6. define disk. if ls_disk is not bound or ls_disk->name ne &1. ls_disk = eo_computer->get_disk( &1 ). endif. disk_&2 &3. end-of-definition.

Dere, a method is ca++ed first to position or generate the correct entry in the tab+e of dis:s& 1. method get_disk.

2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

data: ls_disk type ty_disk. read table gt_disks reference into es_disk with table key name = iv_name. if sy-subrc ne 0. ls_disk = get_default_disk( ). ls_disk-name = iv_name. insert ls_disk into table gt_disks reference into es_disk. endif. "get_disk

12. endmethod.

#he fo++owing form shows how the interna+ D,= is embedded into the -B-1 code& It returns an instance eoBcomputer which carries the semantic mode+$ ,uch a routine 5or method, or function6 can be ca++ed by other programs in order to get the data of the configured 14$ #he D,= section is mar:ed with specia+ comments& #he part enc+osed by these comments cou+d be edited 5and changed6 separate from the rest of the program, if an appropriate editor too+ is used$ In a forthcoming b+og, I p+an to e%p+ain such an interna+ D,= editor too+ in more detai+$

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

form get_computer changing eo_computer type ref to lcl_computer.

data: ls_disk

type ref to lcl_computer=>ty_disk.

create object eo_computer.

* <<< BEGIN DSL processor : type i386, cores 2.

11. disk 1 : 12. 13. 14. size 2000,

speed 750, type sata.

15. 16. disk 2 : 17. type sas.

18. * <<< END DSL 19. 20. endform.

#he fu++ source code of this interna+ D,= e%amp+e can be inspected on m$ pastebin$

Or er of t0e parameter!
If a macro is ca++ed se2era+ times, there may be parameters whose 2a+ues 2ary freCuent+y, and others 2arying on+y rare+y$ #he macro shou+d be designed with the freCuent+y!changing parameters at the end of its parameter +ist$ #his, again, is for being ab+e to e%p+oit the co+on@comma mechanism$ "bser2e my choice of the parameter order in the _mo$e_from_to e"ample abo2e$ "n+y in the order chosen abo2e EG/! G< * G.!GJE, I can arrange the macroEs actua+ parameter in such a ways that the mo2e process is nice+y 2isib+e$ #his shows that the order of the macro arguments is important$ ,ometimes, a macro with the wrong parameter order ma:es the code worse than it was before$

For macro names, the same considerations are 2a+id as for any other symbo+ic name in programming& #hey shou+d be chosen in such a way that the code which uses them becomes as readab+e as possib+e$ #his is particu+ar+y important in the scope of a D,=$ 1refi%es& In my opinion, it is usefu+ to mar: a non!D,= macro 5which is on+y used for simp+ifying, sa2ing and c+arifying -B-1 code6 with a specia+ prefi%$ I use an underscore$ #he purpose of such a prefi% is to distinguish the macro on the first 2iew from an -B-1 +anguage :eyword$ For macros used in D,=s, howe2er, a prefi% wou+d be inappropriate, as the D,= idea is to separate away the ?technica+ +e2e+?$

)ummarMacros are a code reuse techniCue which, +i:e a++ the other reuse techniCues, ha2e the three ad2antages of impro2ing code readabi+ity, simp+ifying code, and remo2ing code dup+ications$ Macros come out to be particu+ar+y usefu+ as bui+ding b+oc:s of interna+ D,=s$ "f course, there a+ways is the possibi+ity of abuse, in particu+ar when the macro contains too many +ines$ But this is no reason to forbid them in the programming guide+ines$ -s a+ready the 3omans said& %busus non tollit usum$

Martin Fow+er with 3ebecca 1arsons& 9omain+Bpeci&ic 7anguages$ -ddison!;es+ey /M.M$ Debasish Ghosh& D,= ! grow your synta% on top of a c+ean semantic mode+$ ,log# &rom ;/;;/;0/0 4omp+ete -B-1 code for the 14 configuration e%amp+e&"Kd-LI

different types of macros

*his "uestion is Assumed Ans ered!

Kal$an N
Aug /M# ;0// J:;M A

hi all# what are the di&&irent t$pes o& standard macros1 when is the e%it and de&ault macro e%ecuted1 "elpful Ans er b$ Ada 7-

'0 ratings)

N;F 8iews

A-erage Gser :ating

Helpful Answer&e' #ifferent types of macros

Ada #v Aug /M# ;0// J:40 A ?ello#

'in response to Kal$an N)

Alease re&er to BAA note JM4;FO. ,est :egards# Ada

:eport Abuse

&e' #ifferent types of macros

7ike '0)

Sunit$a #an%ela Aug /M# ;0// P:FO A ?i#

'in response to Kal$an N)

*he acro,uilder contains &our e-ents + de&ault + le-el change + start + &inal or e%it when $ou load the selection in planning book s$stem calls de&ault and start macros. whene-er $ou press enter or an$ change in planning data s$stem calls de&ault macro. when there is drill down or drill up s$stem calls le-el change. at the time o& sa-e data s$stem calls e%it macro. As Ada suggested re&er to the note JM4;FO which e%plains in detailed about se"uence o& these e-ents. :egards# Bunitha

ABAP Macros
5osted in A(A5 Tutorial on !2<!1<2!12

If we want to reuse the same set of statements more than once in a program, we can inc+ude them in a macro$ ;e can on+y use a macro within the program in which it is defined$ Macro definition shou+d occur before the macro is used in the program$ ;e can use the fo++owing synta% to define a macro$

D46&.4 Amacro name#! !!! 4.D)16)D46&.&T&1.!

Demo program using Macro$

*Macro de*inition D46&.4 print! rite:F DLello MacroD! 4.D)16)D46&.&T&1.!

E0&T4:F DBe*ore /sing MacroD! print!


;e can pass up to 0 p+aceho+ders to Macros$

*Macro de*inition D46&.4 print! rite:F DLelloD8 <"8 <%! 4.D)16)D46&.&T&1.!

E0&T4:F DBe*ore /sing MacroD! print DABAPD DMacrosD!


;hen you modu+ariAe source code, you p+ace a seCuence of -B-1 statements in a modu+e$ #hen, instead of p+acing a++ of the statements in your main program, you just ca++ the modu+e$;hen the program is generated, the source code in the modu+ariAation unit is treated as though it were actua++y physica++y present in the main program$ Nee of *o u%ari2ation Impro2e the structure of the program$ Easy to read the code Easy to maintain the code -2oid redundancy and promotes code reuse 9se of Macros 9se of inc+ude fi+es ,ubroutines Function Modu+es

3ariou! *o u%ari2ation 4ec0ni5ue!

=ets +oo: into each of them in detai+ &

,-1! -B-1 Macro

If you want to reuse the same set of statements more than once in a program, you can inc+ude them in a macro$ Nou can on+y use a macro within the program in which it is defined, and it can on+y be ca++ed in +ines of the program fo++owing its definition$ Macros can be usefu+ for +ong ca+cu+ations or comp+e% ;3I#E statements$


DEFINE <macro_name> Macro Statements END-OF-DEFINITION

Macros can use 1arameters &N where N * .,/,J E%amp+e&!

DATA: number1 TYPE I A!"E 1# DEFINE increment. ADD 1 to $1# %&ITE $1# END-OF-DEFINITION# Increment number1# %&ITE number1#
"utput& /

Inc+ude 1rograms
Inc+ude 1rograms are so+e+y for modu+ariAing source code, and ha2e no parameter interface$ Inc+ude programs a++ow you to use the same source code in different programs$ #hey can be usefu+ if you ha2e +engthy data dec+arations that you want to use in different programs$ ,ynta%

Inc'u(e <)nc'u(e *ro+ram Name>

'oint! to Note Inc+ude programs cannot ca++ themse+2es$ Inc+ude programs must contain comp+ete statements$


IN,!"DE -I!.///0# %&ITE: 1 "ser23 SY-"NAME31 Date23 SY-DAT"M# 44444444444444444444444444444444 P&O5&AM -&PM///1# IN,!"DE -I!.///0#


,ubroutines are procedures that you can define in any -B-1 program and a+so ca++ from any program$ ,ubroutines are norma++y ca++ed interna++y, that is, they contain sections of code or a+gorithms that are used freCuent+y +oca++y$ If you want a function to be reusab+e throughout the system, use a function modu+e$ ,ynta%!

FO&M <Subrout)ne> 6<*ass>7# <Statement b'oc8># ENDFO&M#

',ubroutine( * Name of the subroutine 'pass( * 1arameters being passed 4-pe! of )u$routine! .$ /$ Interna+ ,ubroutine defined in same program being ca++ed$ 4an access a++ the data objects dec+ared in the main -B-1@< program$ E%terna+ ,ubroutine defined outside the program being ca++ed$ Need to use the 'pass( option or dec+are data objects in common parts of memory$

Ca%%in" a )u$routine Internal Subroutines

PE&FO&M <subrout)ne> 6<*ass>7

'subroutine( * Name of the subroutine 'pass( * 1arameters being passed Data dec+ared in main program is automatica++y a2ai+ab+e$ External Subroutines

PE&FO&M <subrout)ne>9<Pro+ram>: 6<*ass>7# PE&FO&M <subrout)ne> 9<Pro+ram>: 6<*ass>7 6IF FO"ND7# PE&FO&M 9<subrout)ne>: IN P&O5&AM 9<Pro+ram>: 6<*ass>7 6IF FO"ND7# PE&FO&M <)n(e;> OF <subrout)ne1> <subrout)ne<> <subrout)ne=> 6<*ass>7#
Points to Note Nested ca++s are a++owed in subroutines 5i$e$ 1E3F"3M within a F"3M 3ecursi2e ca++s are a+so possib+e$ #o define +oca+ data, use the D-#- statement after F"3M $ Each time you enter the subroutine, the data is recreated 5with an initia+ 2a+ue6 and re+eased at the end 5from the stac:6$ ENDF"3M 6$

#o define g+oba+ data used within a subroutine, use the ="4-= statement after F"3M $ #he 2a+ues are sa2ed when you enter the subroutine and then re+eased at the end 5from the stac:6

Function Modu+es
Function Modu+es are genera+ purpose -B-1@< routines that anyone can use$ Infact , there are a +arge number of standard function Modu+es a2ai+ab+e$ Function Modu+es are organiAed into Function Groups& 4o++ections of +ogica++y re+ated functions$ Function modu+e a+ways be+ongs to a Function Group$ ,ynta%!

F"N,TION <>unct)on mo(u'e> <Statements> ENDF"N,TION#

Important information A!!ociate 6it0 Function *o u%e -dministration Import@4hanging@E%port parameters$ #ab+e 1arameters@E%ceptions$ Documentation ,ource code O L<fgrp>U01 . 'fgrp( is the Function Group G+oba+ Data O L<fgrp>TOP $G+oba+ data for the function group! -ccessib+e across function modu+es in the function group$ Main 1rogram O SAPL<fgrp> $ 4ontains the +ist of a++ the inc+ude fi+es for that function group Ca%% a Function *o u%e #o ca++ a function modu+e, use the 4-== F9N4#I"N statement&

,A!! F"N,TION <mo(u'e> 6E.PO&TIN5 >1 4 a 1#### > n 4 a n7 6IMPO&TIN5 >1 4 a 1#### > n 4 a n7 6,?AN5IN5 >1 4 a 1#### > n 4 a n7 6TA@!ES >1 4 a 1#### > n 4 a n7 6E.,EPTIONS e1 4 r 1#### e n 4 r n 6E&&O&_MESSA5E 4 r E7 6OT?E&S 4 ro77#

Function Groups
Function groups are containers for function modu+es$ Infact, there are a +arge number of standard Function Groups$ -++ of the function modu+es in a function group can access the g+oba+ data of the group$ =i:e e%ecutab+e programs 5type .6 and modu+e poo+s 5type M6, function groups can contain screens, se+ection screens, and +ists$ 'oint! to Note

.$ /$ J$ <$

Function Groups cannot be e%ecuted$ #he name of a function group can be up to /L characters +ong$ ;hen you create a function group or function modu+e, the main program and inc+ude programs are generated automatica++y$ Function groups encapsu+ate data$ Goto #ransaction ,EKM$ ,e+ect 1rogram in the DropDown$ ;rite the name of the Function Group #hat you want to create$ Genera++y 9ser made Function groups start with )PQ$ e$g$ O 'PBF9N4#I"NBG3"91BN-ME( $ Dit Enter 7ey$ Note that #he #"1 Inc+ude is create by defau+t if the user chec:s the option of creating a #"1 inc+ude$

7o6 to create a Function 8roup

7o6 to create a Function *o u%e .$ /$ J$ <$ R$ L$ S$ K$ 0$ .M$ 4reate a function Group 5say )ZCAL)6$ 4reate a function modu+e, set the attributes +i:e 5Function group, -pp+ication, ,hort #e%t and 1rocess #ype6 and ,a2e$ Inc+ude fi+e )LZCALU01Q wi++ ha2e source code of first function modu+e$ Inc+ude fi+e )LZCALTOPQ wi++ ha2e g+oba+ data$ Main program )SAPLZCALQ contains G+oba+ data Inc+ude fi+e )LZCALTOP) Function modu+es inc+ude fi+e )LZCALUXX) 9ser defined Inc+ude fi+es )LZCALF$$Q, )LZCALO$$Q and )LZCALI$$Q Define interface parameters and E%ceptions ;rite the source code -cti2ate Function Modu+e #esting the Function Modu+e O ,ing+e #est G Debugging Documenting and 3e+easing a Function Modu+e

3ead more at http&@@www$saptraininghub$com@sap!macro!inc+ude!function!modu+e!group! subroutine@TEcUia9#,<3,"I79y$00 ample!report!lan8/ amplereport!am8lan! o! o.html