Use global variables from different Function Group

[philippdoelker]

Hello Community,

I am faced the following Issue:

Some FMs I use in an user exit provide data to the global variables of their Function Group A.

In the same user exit are also FMs from a different Function Group B called. The FMs semantically belong together, but they can not be included in Function Group A because there is no space left (restricted to 100 FMs).

Is there any possibility to use global data from Function Group A in a FM of Function Group B?

Thank you in advance,

Regards,

Philipp

[Former Member]

Philipp,

I guess one of the option would be to enhance one of the FM in FG'A' to call a FM in FG'B'. This way you can pass the required data from FG'A' to FG'B' and store it as global variables.

Thanks,

Vikram.M

[RaymondGiuseppi]

Can you create a Function Module or a Form in the Function Group with the informaiton, the Function Modules of the other Funciton Group just call this Funciton Module or Form to get the informaton abck.

Regards,

Raymond

[arseni_gallardo]

Philipp,

Declare all you shared global variables in one include and make use of the (obsolete) statements BEGIN OF COMMON PART and END OF COMMON PART.

DATA BEGIN OF COMMON PART [name].
  ...
  DATA ...
  ...
DATA END OF COMMON PART [name].

https://help.sap.com/abapdocu_70/en/ABAPDATA_COMMON.htm

Then use the same include in both function groups.

Kind regards

[matt]

COMMON PART shouldn't be used in new developments. You know how global variables are frowned upon and considered to be bad programming? COMMON PART variables are like uber-global-variables (universal? galactic?).

This is what the ABAP documentation says:

The use of common data areas in otherwise independent programs can be very problematic, with regard to both the maintainability and the functions. Therefore, common data areas should no longer be used. The parameter interfaces of procedures are available for exchanging data between programs.

Frankly. if you'vet got ~100 variables in a function group and you're using many global fields within the group, you've got an issue with program design that's crying out for refactoring.

If you want a bad workaround while you're planning your refactoring project create function group C with your global variables, and a host of getter/setter function modules in it.

[retired_member]

Yes, there's an interesting variant of ASSIGN (...). Check the documentation (under hints ...).

[matt]

But is it a good idea to use it? If you're in control of the development, you should create proper interfaces.

[retired_member]

No it isn't, but it's documented ...

[sapitr_entwicklung]

The dynamic assign 'ASSIGN ('(SAPL...)GV_...') TO <LV_...>' is surely not a good idea. It's grabbing items from somebody else's living room. It would be much nicer to ring the bell and ask politely for the item.

For this, however, the function group in question has to provide a GET_... function module, providing what others usually request for.

[Former Member]

And it's for internal use only. Or at least my documentation says so.

[retired_member]

For this, however, the function group in question has to provide a GET_... function module, providing what others usually request for.

And this can be a problem. From time to time one is forced to do unwanted things.

[retired_member]

Yep. The user has to take full responsibility for her actions.

[SuhaSaha]

Horst Keller wrote:

Yes, there's an interesting variant of ASSIGN (...). Check the documentation (under hints ...).

Oops! the variant-that-should-not-be-named

[Former Member]

Good morning friends.

Based on the ABAP documentation, you should use the functionalities of EXPORT / IMPORT in shared memory.

SAP provides this type of functionality to share information between different memory sectors that run in the same session.

Regards!!

[retired_member]

In fact, you better use shared objects then, because with those you don't need EXPORT/IMPORT.

[Former Member]

That's correct @Horst Keller..    and it is a better option too.

Here's some links about it:

Shared Objects - Implementation - ABAP - Shared Objects - SAP Library

How to Work with ABAP Shared Memory Objects | SCN

What are Shared Memory Objects? The Shared Memory Objects concept is available from release 6.40 onwards. It consists of storing data in SAP memory (much like the EXPORT/IMPORT statements before ECC6), for rapid data retrieval without the need for physically reading persistent DB tables. Unlike the “old” EXPORT/IMPORT technique, however, the Shared Memory Object concept also allows for business logic to be stored (for instance, sorting or calculations based on the stored data).

I hope this information can help with the original issue..

Best regards!!

Gio.

[Former Member]

I don't see any need to use shared objects, because i assume both FGs are part of the same internal session (when called within the same user exit). You could just use static attributes of a global class. That's less overhead than shared objects and data won't be visible to the whole AS.