A Detail Description on Subroutine Pool

Added by Smita Gupta, last edited by Smita Gupta on Apr 16, 2009 (view change)

A Detail Description on Subroutine Pool Introduction: ABAP programming language (Advanced Business Application Programming) is basically driven for business application development which offers some unique features, such as dynamic programming for complex business scenarios.Dynamic programming is enable to perform data function & operations at runtime that cannot be determined at compile time.These dynamic programs are more powerful and flexible, and reducing the need for excessive custom programming. Dynamic programming is powerful and flexible, but this type of programming is very elaborate and the created programs are difficult to maintain that's why should be used wisely. In ABAP, dynamic programming is facilitated by: o Generic Data Types

These data types are determined at runtime only . This is the basis of dynamic programming where procedures can work with several types of transfer parameters. o Data objects(Strings & Internal Tables), whose size are not statically defined

Strings & internal tables size and type are defined at runtime.Generic internal tables are used to specify the types of field symbols and the interface parameters of procedures but cannot use them to declare data objects. o o Field Symbols and Refernce Variables Runtime Data Type Creation

In certain scenario, where the type of the data generated during execution can not be estimated beforehand,runtime data tyoes are being created. o Dynamic token specification Dynamic token specification creates tokens dynamically ,

For example:- The content of the internal table <itab> is displayed dynamically using class CL_SALV_TABLE. o Generating Subroutines dynamically

The statements for dynamic program development do not carry out authorization checks or other checks. There are following special function modules for authorization check.

The function module RS_ACCESS_PERMISSION carries out all authorization checks that are also carried out when the ABAP Editor is called. The function module TR_SYS_PARAMS and other function modules of the function group STR9 determine whether Repository objects can be changed.

Subroutine pools Subroutine pools, as the name implies, were created to contain collections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method - say - main connected to a transaction code! Syntax: To generate subroutine pool following command is being used. GENERATE SUBROUTINE POOL <itab> NAME <prog> [<options>]. This statement generates a temporary subroutine pool in the main memory area of the running program. The source code of the subroutine pool is written in internal table which is passed under <itab>.The generated subroutine pool is stored internally in the current internal mode under program name <Prog> that should have type C of length 8. You can use the following options <options> in the GENERATE SUBROUTINE POOL statement: Options MESSAGE <mess> INCLUDE <incl> LINE <line> Description In the case of a syntax error, field <mess> contains the error message. In the case of a syntax error, field <incl> contains the name of the include program in which the error possibly occurred. In the case of a syntax error, field <line> contains the number of the wrong line.

WORD <word> In the case of a syntax error, field <word> contains the wrong word. In the case of a syntax error, field <offs> contains the offset of the OFFSET <offs> wrong word in the line. TRACE-FILE If you use this option, you switch on the trace mode and field <trac> <trac> contains the trace output. If an error occurs during generation, SY-SUBRC is set to 8. Otherwise, it is set to 0. Internal Table Restriction: The line type for itab must be character type (prior to Release 6.10 flat). A source code line in itab may contain a maximum of 255 characters. Program Name Restrictions: The data object prog must also be character type (prior to Release 6.10 flat).Name can not exceed from characters. Subroutine Pool Restrictions: In an internal mode, a maximum of 36 temporary subroutine pools may be created. The subroutine pool only exists during the runtime of the generating program and can only be called from within this program. You can create up to 36 subroutine pools for one program. Error Handling If the source code that is passes through itab has a syntax error, the subroutine pool is not generated and initialized using <prog>.Using the addition error_handling, syntax and generation errors can be analyzed.. Syntax errors can either occur in the source code specified in itab or in the include programs included using the statement INCLUDE. Generation errors can occur, among other things, if the program contains errors in the declaration statements that are not recognized during the static syntax check.

Example of passing internal tables to an subroutine

Added by ravi r, last edited by Guest on Apr 30, 2007 (view change)

Submitted by: Ravi r April 30, 2007 Here is an siple program on how to pass an internal table to an sunbroutine

1) PROGRAM FORM_TEST. DATA: BEGIN OF LINE, COL1 TYPE I, COL2 TYPE I, END OF LINE. DATA ITAB LIKE STANDARD TABLE OF LINE. PERFORM FILL CHANGING ITAB. PERFORM OUT USING ITAB. FORM FILL CHANGING F_ITAB LIKE ITAB. DATA F_LINE LIKE LINE OF F_ITAB. DO 3 TIMES. F_LINE-COL1 = SY-INDEX. F_LINE-COL2 = SY-INDEX ** 2. APPEND F_LINE TO F_ITAB. ENDDO. ENDFORM. FORM OUT USING VALUE(F_ITAB) LIKE ITAB. DATA F_LINE LIKE LINE OF F_ITAB. LOOP AT F_ITAB INTO F_LINE. WRITE: / F_LINE-COL1, F_LINE-COL2. ENDLOOP. ENDFORM. The produces the following output: 1 1 2 4 3 9 You can define the types of the formal parameters of the parameter interfaces of procedures as internal tables. In the example, the subroutines FILL and OUT each have one formal parameter defined as an internal table. An internal table without header line is passed to the subroutines. Each subroutine declares a work area F_LINE as a local data object. Were ITAB a table with a header line, you would have to replace ITAB with ITAB[] in the PERFORM and FORM statements. 2) This example is provided for completeness. The TABLES parameter is only supported for the sake of compatibility and should not be used. PROGRAM FORM_TEST. TYPES: BEGIN OF LINE, COL1 TYPE I, COL2 TYPE I, END OF LINE. DATA: ITAB TYPE STANDARD TABLE OF LINE WITH HEADER LINE, JTAB TYPE STANDARD TABLE OF LINE.

PERFORM FILL TABLES ITAB. MOVE ITAB[] TO JTAB. PERFORM OUT TABLES JTAB. FORM FILL TABLES F_ITAB LIKE ITAB[]. DO 3 TIMES. F_ITAB-COL1 = SY-INDEX. F_ITAB-COL2 = SY-INDEX ** 2. APPEND F_ITAB. ENDDO. ENDFORM. FORM OUT TABLES F_ITAB LIKE JTAB. LOOP AT F_ITAB. WRITE: / F_ITAB-COL1, F_ITAB-COL2. ENDLOOP. ENDFORM. The produces the following output: 1 1 2 4 3 9 In this example, an internal table ITAB is declared with a header line and an internal table JTAB is declared without a header line. The actual parameter ITAB is passed to the formal parameter F_ITAB of the subroutine FILL in the TABLES addition. The header line is passed with it. After the body of the table has been copied from ITAB to JTAB, the actual parameter is passed to the formal parameter F_ITAB of the subroutine OUT using the TABLES addition. The header line F_ITAB, which is not passed, is generated automatically in the subroutine.

Subroutines And Their Use In SAPScript

Added by MANSI ASNANI, last edited by kishan P on Jan 13, 2012 (view change)

SUBROUTINES: A subroutine is an internal modularization unit within a program, to which you can pass data using an interface. You use subroutines to encapsulate parts of your program, either to make the program easier to understand, or because a particular section of coding is used at several points in the program. Your program thus becomes more function-oriented, with its task split into different constituent functions, and a different subroutine responsible for each one. As a rule, subroutines also make your programs easier to maintain. For example, you can execute them "invisibly" in the Debugger, and only see the result. Consequently, if you know that there are no mistakes in the subroutine itself, you can identify the source of the error faster.

Structure of a Subroutine : A subroutine begins with the FORM statement and ends with ENDFORM. After the subroutine name, you program the interface. In the FORM statement, you specify the formal parameters, and assign them types if required. The parameters must occur in a fixed sequence - first the importing parameters, then the importing/exporting parameters. Within the subroutine, you address the data that you passed to it using the formal parameters. You can declare local data in a subroutine : After any local data declarations, you program the statements that are executed as part of the subroutine. You define the way in which the data from the main program (actual parameters do1, do2, do3, and do4) are passed to the data objects in the subroutine (formal parameters p1, p2, p3, and p4) in the interface. There are three possibilities: 1) Call by reference (p1, p3) The dereferenced address of the actual parameter is passed to the subroutine. The USING and CHANGING additions both have the same effect (in technical terms). However, USING leads to a warning in the program check. 2) Call by value (p2) A local "read only" copy of the actual parameter is passed to the subroutine. Do this using the form USING value(). 3) Call by value and result (p4) A local changeable copy of the actual parameter is passed to the subroutine. Do this using the form CHANGING value (). You should use this method when you want to be sure that the value of the actual parameter is not changed if the subroutine terminates early. When you use internal tables as parameters, you should use call by reference to ensure that the system does not have to copy what could be a large internal table. The data objects that you pass to a subroutine can have any data type. In terms of specifying data types, there are various rules: 1) You may specify the type for elementary types.

If you do, the syntax checks returns an error message if you try to pass an actual parameter with a different type to the formal parameter. Not specifying a type is the equivalent of writing TYPE ANY. In this case, the formal parameter "inherits" its type from the actual parameter at runtime. If the statements in the subroutine are not compatible with this inherited data type, a runtime error occurs. Data types I, F, D, and T are already fully-specified. If, on the other hand, you use P, N, C, or X, the missing attributes are made up from the actual parameter. If you want to specify the type fully, you must define a type yourself (although a user-defined type may itself be generic). When you use STRING or XSTRING, the full specification is not made until runtime. 2) You must specify the type of structures and references. 3) You must specify the type of an internal table, but you can use a generic type, that is, program the subroutine so that the statements are valid for different types of internal table, and then specify the type: . Using the corresponding interface specification : TYPE [ANY|INDEX|STANDARD|SORTED|HASHED] TABLE, (TYPE TABLE is the short form of TYPE STANDARD TABLE) Using a user-defined generic table type: When you call a subroutine, the parameters are passed in the sequence in which they are listed. The type of the parameters and the way in which they are passed is determined in the interface definition. When you call the subroutine, you must list the actual parameters after USING and CHANGING in the same way. There must be the same number of parameters in the call as in the interface definition. The best thing to do is to define the subroutine and then use the Pattern function in the ABAP Editor to generate the call. This ensures that you cannot make mistakes with the interface. The only thing you have to do is replace the formal parameters with the appropriate actual parameters. If you pass an internal table with a header line, the name is interpreted as the header line. To pass the body of an internal table with header line, use the form [ ]. In the subroutine, the internal table will not have a header line. Formal parameters and local data objects that you define in a subroutine are only visible while the subroutine is active. This means that the relevant memory space is not allocated

until the subroutine is called, and is released at the end of the routine. The data can only be addressed during this time. The general rules are as follows: You can address global data objects from within the subroutine. However, you should avoid this wherever possible, since in doing so you bypass the interface, and errors can creep into your coding. You can only address formal parameters and local data objects from within the subroutine itself. If you have a formal parameter or local data object with the same name as a global data object, we say that the global object is locally obscured by the local object. This means that if you address an object with the shared name in the subroutine, the system will use the local object, if you use the same name outside the subroutine, the system will use the global object. Summary: Address global data objects in the main program and, if you want to use them in the ubroutine, pass them using the interface. In the subroutine, address only formal parameters and local data objects. Avoid assigning identical names to global and local objects. For example, use a prefix such as p_ for a parameter and l_ for local data. This example calls the subroutine demosub. It contains a local data object with a starting value, and alters the four formal parameters. The system allocates two memory areas p2 and p4 for the two call by value parameters d2 and d4, and fills them with the respective values. It also allocates memory for the local data object l_do, and fills it with the starting value. There is no VALUE addition for p1 or p3, this means that changes at runtime affect the actual parameters directly, and you can address do1 directly via p1. Here, the change to p1 directly affects the contents of do1. The formal parameter p2 is declared as a local copy with read access. This means that any changes will not affect the actual parameter do2 at all. The same applies to p3 as to p1. If you do not use the VALUE addition, USING and CHANGING have the same effect. The contents of do3 are affected directly by the changes to p3. As for p2, we have created a local copy for p4. Consequently, the changes to the formal parameter do not affect the actual parameter while the subroutine is running.

The changes are not written back to the actual parameters until the ENDFORM statement. If demosub is interrupted for any reason, do4 would have the same value afterwards as it had before the call. Now that demosub has finished running, the memory occupied by its local data objects is released. You now cannot address these data objects any more. Note that do2 still has its old value, even though p2 was changed in the subroutine. It is technically possible to call subroutines from other main programs. However, this technique is obsolete, and you should use function modules instead. Function modules provide considerable advantages, and are important components in the ABAP Workbench. For further information, refer to the unit Function Groups and Function Modules. Another typical use of subroutines is recursive calls. Although all other modularization units can, in principle, be called recursively, the runtime required is often excessive for small easily-programmed recursions. How to Call Subroutine in Sap Script:Calling ABAP Subroutines: PERFORM You can use the PERFORM command to call an ABAP subroutine(form) from any program, subject to the normal ABAP runtime authorization Checking. You can use such calls to subroutines for carrying out calculations, for obtaining data from the database that is needed at display or print time, for formatting data, and so on. PERFORM commands, like all control commands, are executed when a Document is formatted for display or printing. Communication between a subroutine that you call and the document is by way of symbols whose Values are set in the subroutine. The system does not execute the PERFORM command within SAP script replace modules, such as TEXT_SYMBOL_REPLACE or TEXT_INCLUDE_REPLACE. The replace modules can only replace symbol values or resolve include Texts, but not interpret SAP script control commands. Syntax in a form window: /: PERFORM <form> IN PROGRAM <prog> /: USING &INVAR1& /: USING &INVAR2& ...... /: CHANGING &OUTVAR1& /: CHANGING &OUTVAR2& ...... /: ENDPERFORM

INVAR1 and INVAR2 are variable symbols and may be of any of the four SAP script symbol types. OUTVAR1 and OUTVAR2 are local text symbols and must therefore be Character strings. The ABAP subroutine called via the command line stated above must be defined in the ABAP report prog as follows: FORM <form> TABLES IN_TAB STRUCTURE ITCSY OUT_TAB STRUCTURE ITCSY. ... ENDFORM. The values of the SAP script symbols passed with /: USING... are now Stored in the internal table IN_TAB. Note that the system passes the values as character string to the subroutine, since the field Field VALUE in structure ITCSY has the domain TDSYMVALUE (CHAR 80). See the Example below on how to access the variables. The internal table OUT_TAB contains names and values of the CHANGING Parameters in the PERFORM statement. These parameters are local text Symbols, that is, character fields. See the example below on how to Return the variables within the subroutine. From within a SAP script form, a subroutine GET_BARCODE in the ABAP Program QCJPERFO is called. Then the simple barcode contained there ('First page', 'Next page', 'Last page') is printed as local variable Symbol. Definition in the SAP script form: /: PERFORM GET_BARCODE IN PROGRAM QCJPERFO /: USING &PAGE& /: USING &NEXTPAGE& /: CHANGING &BARCODE& /: ENDPERFORM / / &BARCODE& Coding of the calling ABAP program: REPORT QCJPERFO. FORM GET_BARCODE TABLES IN_PAR STUCTURE ITCSY

OUT_PAR STRUCTURE ITCSY. DATA: PAGNUM LIKE SY-TABIX, "page number NEXTPAGE LIKE SY-TABIX. "number of next page READ TABLE IN_PAR WITH KEY 'PAGE'. CHECK SY-SUBRC = 0. PAGNUM = IN_PAR-VALUE. READ TABLE IN_PAR WITH KEY 'NEXTPAGE'. CHECK SY-SUBRC = 0. NEXTPAGE = IN_PAR-VALUE. READ TABLE OUT_PAR WITH KEY 'BARCODE'. CHECK SY-SUBRC = 0. IF PAGNUM = 1. OUT_PAR-VALUE = '|'. "First page ELSE. OUT_PAR-VALUE = '||'. "Next page ENDIF. IF NEXTPAGE = 0. OUT_PAR-VALUE+2 = 'L'. "Flag: last page ENDIF. MODIFY OUT_PAR INDEX SY-TABIX. ENDFORM.