Sunroutine Pool

[Former Member]

Should I create/use a Subrutine Pool ?

During the last 5 years I have created over 40 programs design for running on Radio Frequency devices (RF terminals) running shop floor transaction using barcodes. All programs are stand-alone only sharing a few common function modules. When I stated I decided not to place the programs in the same Function Group because there are often changes made to the programs/new programs are created. We have a rather long test period on some of our projects and placing the code in the same function group would result in transport locking for other transport when code are to be transported to production.

We have now begun our upgrade project (Upgrade to ERP 2005/ECC 6.0) and I can see that there are a lot of the same subroutines in the programs (reading config tables, reading masterdata…..).

Should I place all these more or less static form routines in a Subroutine Pool ??

Message was edited by: Kim Ternstrøm

[Former Member]

Hi kim,

1. I would personally prefer this :

a) to put such FORMS in

INCLUDE programs

(and not subroutine pool)

b) in subroutine pool, we have to

call forms using

perform abc in program xyz.

c) U can use more than once include,

and group them as per the functionality.

2. If there is any change in future,

only one include at a time,

will be locked.

regards,

amit m.

[Former Member]

Own defined INCLUDES are not meant to be used in serveral program. Only to make a program more readable - and only 1 program - statement from Horst Keller on the TechEd. Internaly in SAP they have had a lot of trouble upgrading the application because INCLUDE programs suddently where used in a lot of other programs. I think thats why a Package (dev. class) now has a interface where you can decide what should be accessible from other programs/packages.

[Former Member]

Hi kim,

1. Own defined INCLUDES are not meant to be used in serveral program. Only to make a program more readable -

I agree for that.

But at the same time, suppose,

we use subroutine pool,

that too can be used in more than one programs.

2. Its upto our own discipline,

how we COMPARTMENTALISE our own

long program.

3. Readability is important.

Modularisation is best to achieve it.

4. For modularisation we can use

either subroutine pool, includes etc.

5. But if we use subroutine pool,

the syntax for calling the subroutine,

is entirely different.,

as compared to include.

(include is quite normal)

6. Hence, i would personally use

includes only, for modularisation purpose.

( it is performance effective as compared

to calling external subroutines in case of

subroutine pool)

regards,

amit m.

[Former Member]

HI

GOOD

YES YOU CAN CREATE AND USE A SUBROUTINE POOL

GO THROUGH THESE LINKS WHICH WILL GIVE SOME DETAIL ABOUT THE SUBROUTINE POOL.

Creating and Starting Temporary Subroutines

The dynamic programs discussed in the other topics of this section are created in the R/3 Repository. This topic describes how you can create and call dynamic subroutines in the main memory.

You write the source code of the subroutines as explained in Creating a New Program Dynamically into an internal table. To generate the program, you use the following statement:

Syntax

GENERATE SUBROUTINE POOL <itab> NAME <prog> [<options>].

This statement creates a subroutine pool in the main memory area of the running program. You pass the source code of the subroutine pool in internal table <itab>. The statement returns the name of the generated subroutine pool in field <prog> that should have type C of length 8. You use the name in <prog> to call the external subroutines defined in table <itab> through dynamic subroutine calls as explained in Specifying the Subroutine Name at Runtime.

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.

http://help.sap.com/saphelp_nw04/helpdata/en/9f/db999535c111d1829f0000e829fbfe/content.htm

http://searchsap.techtarget.com/tip/1,289483,sid21_gci783048,00.html

THANKS

MRUTYUN

[Former Member]

I would not use dynamic generated subrutine pool but static.

Message was edited by: Kim Ternstrøm

[Peter_Inotai]

I'd suggest to consider the ABAP Object approach:

You could also define a class for this and define methods to get the necessary data.

If the methods are static and public, you can call them directly without creating an object.

(eg methods in CL_GUI_FRONTEND_SERVICES).

Peter

[Former Member]

That I also have considered - BUT ABAP OO is new to us as we are upgrading from 4.0B and the time schedule is theight. We have 7.500 object / 800+ transactions to migrate so I don't get an accept/time from the project management to convert to ABAP OO

[Former Member]

Well, if time is tight, and you have no pressing technical or business <b>need</b> to convert, then don't convert. After the upgrade is complete and you have more time, you can re-visit this. This doesn't really sound like it needs to be part of the upgrade project.

Rob