Modularization techniques

[Former Member]

Hi,

sorry, I don't know if this is the best place for my question, I still have difficulties finding my way around the SCN and finding the appropriate sub-forum.

I have just written my first ABAP program and I am trying to modularize it - to keep the whole thing flexible and easier to care for - and at the same time I am trying to flexibilize the whole thing by using variables.

So, there are of course several possibilities I can use to modularize my program. What I'm currently using are INCLUDE structures - the appeal of those is mainly that they are not part of my main source code, but separate pieces. However, I am not quite sure: The official Help says they have no data link, so it might not be possible to use the variables - which is just what I need to do.

Could someone please shed some light on this and tell me definitely whether it's possible to use global variables (from a selection screen, ultimately) or not?

Another possibility which I am thinking of using is subroutines (the ones called with PERFORM) - they have a data link, so I think the use of selection-screen-variables is possible in subroutines. One thing I cannot quite wrap my brain around, however, is the fact that they are directly appended to my main source code - in my eyes, that goes contrary to the basic idea of modularization?

Can someone please shed some light on this also?

There might be another possibility, mainly in connection with object-oriented programming - but that is something I really don't understand, so I won't mess with it for the moment.

Many thanks!

Best regards,

Sapperdapper

[dirk_wittenberg]

Hi,

what about function groups / function modules? They offer data links and are separated from your main source code.

Regards,

Dirk

[Former Member]

Friedrich Hofmann wrote:
.................
So, there are of course several possibilities I can use to modularize my program. What I'm currently using are INCLUDE structures - the appeal of those is mainly that they are not part of my main source code, but separate pieces. However, I am not quite sure: The official Help says they have no data link, so it might not be possible to use the variables - which is just what I need to do.
.................

Can you give more info about above

Max

[Former Member]

Hello,

I will try to be as precise as possible:

@ Dirk:

I am not sure - function modules seem to be the ideal combination of separating my code into modules and having a data link from the main program to its parts.

The long-term goal is calling the program from outside, so ideally it should all be packed inside one function module - but I wonder whether that would be doable anyway. Even if I ended up having to use several, one function module holding my main program and calling on the others, that would be fine.

I guess I will have a look at those.

@ max:

Sure I can give you more info - about what? Quoting an entire paragraph and asking for more info is not quite clear to me - about the INCLUDEs I am currently using or about my approach with the variables?

Best regards,

Sapperdapper

[Former Member]

Hi

About how you're using INCLUDE and about this affirmation:

The official Help says they have no data link, so it might not be possible to use the variables.....

I'm not sure to understand it

Max

[Former Member]

Hi max,

okay, now it's clear:

Currently in my report, on the "uppermost level", there are only several INCLUDE statements: One holds the declaration of an internal table to hold the fields I want (from four DB tables); Another one then does the actual SELECT with several Joins and fills all the data into my internal table using

INTO CORRESPONDING FIELDS OF TABLE itab01.

The long-term goal is getting the data out of SAP, but for the time being I have a third INCLUDE with a WRITE command generating a screen list so I can check the results.

So far, all seems fine. But now I have to consider using variables - only filters for starters, later all the table and field names will be variables - so I think - correct me if you know otherwise - that INCLUDE structures have no data link, so if I declare a variable v_BUKRS in my main program, I cannot use that for my SELECT (in an INCLUDE).

@ Dirk:

I have already tested using subroutines in my program. That works nicely. Now I want to try with function modules as it seems that both would be possible - I'll have to proceed to find out which is the better alternative. I have a question on that behalf (I have no F1 help available, so excuse me if this is actually easy):

On the "Import" tab of my function module, I have entered the two variables I am using, v_BUKRS and v_KUNNR, in the field "type" I have selected "TYPE" and in the field to its right I have given the name of a field in a DB table (KNA1-KUNNR and KNB1-BUKRS) which the declaration of those variables should be based upon.

I also have an internal table - I have declared that already - that I need to pass on to that function module because that module has to fill the data gathered from the DB tables into that internal table. So I have given the name of the inttable, selected "TYPE" again - and in the field "reference" (left of the check box "Optional"), should I write the declaration ("STANDARD TABLE OF zeile01_typ")?

Thanks a lot!

Best regards,

Sapperdapper

-

P.S.: @ Dirk

OK, it seems I got it right, the function module seems to be okay, at least I could save it, there were no syntax errors and I could activate it.

I inserted the entire CALL FUNCTION command as a pattern. Now I get a stupid error message: "The sentence ending on "...=" was unexpectedly closed"

That line - the linenr is also given in the message - is the last line of the CALL FUNCTION pattern:

CALL FUNCTION 'ZFH_INTTAB_JOIN4_SEL_FCT'

* EXPORTING

*   V_BUKRS       = 0001

*   V_KUNNR       = 0000001000

  TABLES

    ITAB01        =

          .

Can you tell me what that message means?

[Former Member]

Friedrich Hofmann wrote:
...................
so I think - correct me if you know otherwise - that INCLUDE structures have no data link, so if I declare a variable v_BUKRS in my main program, I cannot use that for my SELECT (in an INCLUDE).
......................

Why not?

After inserting an INCLUDE in the main program, this INCLUDE became a part of same main program, that means all global data defined in the main program can be used by piece of code defined in an include.

It's important the position where the include is in main program: it has to be place after the declaration of global variable or selection-screen.

Max

[dirk_wittenberg]

Hi,

the error message means that,

after the = the actual parameter for the formal parameter ITAB01 is missing:

CALL FUNCTION 'ZFH_INTTAB_JOIN4_SEL_FCT'

* EXPORTING

*   V_BUKRS       = 0001

*   V_KUNNR       = 0000001000

  TABLES

    ITAB01        = gt_tab01 " or what ever the name of your table is

Dirk

          .

[Former Member]

Hi,

@ max:

If I understand you right, I can use includes when working with variables - then what does the official SAP help mean by saying that INCLUDE structures have no data link?

If that is true and I can use variables with INCLUDEs as well, that would leave me stranded once again with three possible options and no idea which is best suited for my purpose.

I have done some experimenting with subroutines, too, but I seem to have be stuck there: When using a subroutine to declare the line_type for my internal table - and the internal table itab01 itself - I do not know how I have to implement that internal table so that it becomes known to my main program and the consecutive subroutines - I get an error message lateron that "field itab01 is unknown".

Reading the SAP online help, I have gathered that USING and CHANGING are actually interchangeable, only for clearer understanding it is good practice to use both for the respective purpose. Both, however, are, as I have understood it, meant for fields that exist already when calling the subroutine - but my declarations do not. Do I have to use an INCLUDE for the DATA-type declarations then?

@Dirk:

I will also try getting that function module to work once more. Thanks for helping!

Best regards,

Sapperdapper

[Former Member]

Hi

Can you post the SAP Help you're mentioning?

Max

[Former Member]

Hi max,

no - I have read it in a book, "Discover ABAP" by SAPPress, p. 468: "Procedures have a data link, contrary to source_code_modules", source_code_modules being INCLUDE structures, no?

Best regards,

Sapperdapper

[Former Member]

Hi

I don't think

Sincerly I don't know that book so I can't know the subject of the page where you've extracted the help, I mean I can't know the meaning of source_code_modules.

I don't know if it speaks about the MODULE or other kind of object or routine.

An include is just like a paper can be inserted into a program: it can't live alone.

The main scopes to use an INCLUDE can be:

- To write a program with a simple form to read: for exampla all declarations are in an include, the subroutine in other one etc., etc......It's easier to manage a program written well.

- To use a piece of code in several programs: in this way it writes the code once.

- There's a limit (but I don't know if it's valid in the last SAP releases): a program can have a certain number of lines of code, if it exceed it, it needs to split it in the includes.

So there's no reason not to use a variable, data,....in an include

Max

[IanStubbings]

Hi Friedrich

It is quite commonplace to see the use of INCLUDES when separating out the data part of a program, the selection screen and the subroutines.  However, this is not to say that is best practice - not now anyway. This was a technique that I used myself 10 years or more ago but I encourage others to steer away from it now as you end up having to effectively manage multiple programs (and their associated versions) plus the potential for transporting (or not) the includes in separate requests.

If you are not going down the OO route and creating a local class, I would stick to using a single program and creating subroutines as required. Create the data at the top, selection screen next and then in the START-OF-SELECTION have a subroutine such as GET_DATA to house all of the database selections and then another for the manipulation and one for the output etc. in the END-OF-SELECTION.

The selection screen variables will be global anyway so you can use them within the subroutines.

I'm not sure what you mean by this though

"One thing I cannot quite wrap my brain around, however, is the fact that they are directly appended to my main source code - in my eyes, that goes contrary to the basic idea of modularization?"

Cheers

Ian

[Former Member]

Hi Ian,

your comments are very interesting and relevant - I have read that using INCLUDEs to modularize programs is discouraged because it accumulates problems once you have multiple programs making use of the same INCLUDEs - I can confirm that 100%, I have lots of experience with so-called "common subscripts" - needless to say, mostly bad experiences;

However, in my scenario, I am absolutely sure that will not happen - there will be only one program and I doubt that any customer will write a program and use one of the subprograms we made.

[To clarify: I am working for a company offering a program and I am developing a link to SAP, we are not actually doing SAP-development, so I don't bother about transporting my stuff.]

That is why I consider doing that - but it's not state_of_the_art anymore, that's very right, so maybe I'd rather stay clear of that practice.

Function modules are nice, but I don't need any bits to be usable across the entire SAP system, only within my own program, so they seem to be more complex than what I need.

So I think I will stick with subroutines - but that brings me back to a problem I encountered yesterday: I have a few variables - ultimately coming from a selection screen - and hand them down into a subroutine (using USING) where I do all my declarations for an internal table itab01. Somehow I have to hand that table "back up" into the main program so that and the following subroutines can use it - so far I get an error message (in an INCLUDE lateron generating a screen list with WRITE) saying "field itab01 is unknown."

Can you shed some light on this? I have so far found nothing useful in the available online help.

With that sentence you quote, I meant that I define "modularization" as having separate pieces of code - in the company where I worked before, we had scripts and subscripts for example, several different ASCII files. Subroutines are part of one "file" I create as they are appended to the source_code of my report. I find that a bit less orderly, but I guess it is still a lot better than having all in one piece of spaghetti-code.

Best regards,

Sapperdapper

[dirk_wittenberg]

Hi,

do I understand you right, that you're declaring an internat table itab01 in a FORM-routine? In this case the table is local to this routine. If you want to use it in the main program and other subroutines you  have to declare it globaly in the main program itself.l Then you can pass it down into subroutines.

Regards,

Dirk

[Former Member]

Hello Dirk,

I had an inkling that that might be so. Thanks for confirming this!

Well, then I am facing the question of using an INCLUDE structure or a function module for my declarations - or just doing it in the main program. I would actually prefer the INCLUDE structure, that would have the same effect as if I did it in the main program, no?

I understand from my ABAP book - and it seems sensible to me - that on the "first level" of a program, there should be no actual logic. That way, everything can be kept tidy and orderly.

Currently I have three sub-structures:

- The first one declares all the parts for an internal table, using some variables for the technical fieldnames encompassed in the linetype.

- The second one does the actual SELECT.

- The third one does the - temporarily necessary - WRITE so I can check results.

- A fourth one (to come) will then send the internal table to an XML transformation routine.

Thanks a lot!

Best regards,

Sapperdapper