Share memory between function groups

[mtews2]

Hello,

we are facing a problem with the limit of 99 function modules per function group. We have reached this limit and we had to create a new function group. The problem is, that we want to share the global data between those function groups. We have a lot of global variables and the values of those variables should be available in both function groups. Unfortunately the variables are getting cleared all the time when we are switching in the coding by calling the function module from one function group and afterwards calling a function module from the other function group. I know it is not a good way to work that many with global variables. But because of other aspects we decided to do it in that way.

The question is. Is there a way to share the complete memory (global data) between two function groups?

Thanks for any comments

Michael

[JozsefSzikszai]

hi Michael,

I think you can EXPORT the variables TO MEMORY from one FG and IMPORT FROM MEMORY in the other (and vice versa), but it is not a nice solution...

ec

[Former Member]

Hi Maichael,

i don't think that there's something your looking for.

I think the only thing you can do is create a global data function group where

you synchronize your global data from function group 1 and 2.

Build a class with public tables a attributes, and synchronize your global data

there.

my_itab = z_my_class=>my_itab.

and other way round.

A lot work to put that into all 99 FM's.

Regards Henner

[Former Member]

You might try declaring a COMMON PART. This works for forms, but I don't know about function modules.

Rob

[former_member194669]

Hi,

Try with

SE37--> Enter your function module > change mode> edit>interface>globalize paramter.

a®

[uwe_schieferstein]

Hello Michael

I agree with Rob Burbank that COMMON PART definition should work. Following is part of the ABAP keyword documentation:

<b>Effect </b>

DATA statements with the additions BEGIN OF COMMON PART and END OF COMMON PART define a global interface work area , that can be used jointly by the programs of a program group. All data objects declared between these statements using DATA are part of the interface work area.

<b>Program group </b>

An organizational unit of programs in the internal session. There is always a main program group and it is possible to have several additional program groups. Each program group has a main program. If an external call of a subroutine in a program belonging to a program group causes the framework program of the subroutine to be loaded, this is added to the program group. Loading a function group as a result of an external call from function modules and loading class pools, leads to the creation of an additional program group. All programs of a program group share the interface work areas declared with TABLES, NODES and COMMON PART . Within a program group, CALL SCREEN can only be used to call the screens of the main program.

For an example have a look at function group <b>XVED</b>:

- include LXVEDTOP -> include LXVEDTAP -> include LVEDACOM (contains COMMON PART definition)

I would try to use the same approach:

Put the COMMON PART definition into an include and include this include into both function groups.

Regards

Uwe

[Former Member]

Unfortunately, I tried this and couldn't get it to work for two function modules in two different function groups.

But the code was in the FMs, not performs. If the code is in performs, it may behave a bit differently. But I doubt it.

Rob

Message was edited by:

Rob Burbank

[Former Member]

Hello,

If you are calling a FM1 belonging to FG1 in FM2 Belonging to FG2,You can read variables from FM1 using the following statement.

ASSIGN ('(SAPLEDIN)GT_NEW_IDOC_IDENTIFICATIONS[]') TO <fs_idocs>.

where SAPLEDIN = FG1

and GT_NEW_IDOC_IDENTIFICATIONS is internal table in FG1 set by FM1.

Even if you do not call FM1 inside FM2 we can still access the data using the above mentioned assign satement.

Hope my explanation helps.

Regards,

Rajesh Alandur

[EloiBermejo_ElooooIT]

I know it is a very old topic, and sorry for resurrecting it, but someone (like me 😁) might still find this post nowadays while searching for a solution, or one "lucky" developer might be tasked with maintaining this code one day, so I think having a better suggestion to solve a similar problem would be helpful.

Yes, there was no solution using the data of that FG and the structure that was set up. I would not complicate things with memory assignments. A simpler solution (even available back then) would be to create "Private Class Data" objects to store all the common data you need (persisting if necessary) and then use public static SET/GET methods to access this data from any function or method you need.

Accessing global variables outside of the interface of the Form, Function or Method is always a source of potential errors and confusion. The recommended approach is that ONLY setter and getters should access data that lives outside of the present scope.

You could do a similar thing using a newly created FG with its own SET/GET FMs, but methods are far better and clearer for the task.

Of course if you had 99 FMs in your FG, it means they were not properly separated by topic or business needs. We should not try to build "mini applications" inside a Function Group, but logically separate and group all uses and needs when creating any code. That will definitely help us finding a better solution, when we face any problem.

Best regards, Eloi