topic Re: Unusual behaviour on multiple function modules using the same include in Application Development and Automation Discussions

Unusual behaviour on multiple function modules using the same include

adrianos_campanhola — Thu, 28 May 2015 13:52:14 GMT

Hi,

This is a more general question, but I'm first going to explain what motivates it, you can skip it since it's related to how I found the bug.

I've been testing two standard function modules: WS_DELIVERY_UPDATE and WS_REVERSE_GOODS_ISSUE. These FM's are used to post a goods issue related to a delivery and reverse it respectively. They are really simple FM's, I think I am using 2 or 3 parameters on them.

The problem is when they are executed in succession.

If in the same session, a user POSTS a good issue and then tries to reverse it, the system gives me the error that the used delivery doesn't exist, if I re-start the session, ws_reverse_goods_issue works normally. If we search on SDN, there's several topics on these two FM's and this exact problem.

Now, why does this happen?

There are 3 programs involved:

-The first FM, WS_DELIVERY_UPDATE, is on the Function Group V50L, this FG utilizes the include vblkdata.

-The second FM, WS_REVERSE_GOODS_ISSUE, is on FG V51W, this FG also utilizes the include vblkdata.

-both FM's, utilize forms of the module pool SAPMV50A, this guy also utilizes the include vblkdata.

The include has a variable, LIKP.

For the sake of writing less stuff, i'm gonna call FM WS_DELIVERY_UPDATE = A, and WS_REVERSE_GOODS_ISSUE = B

If I call FM B, somewhere in the main code it updates the variable (B)LIKP-VBELN, this also changes the variable (SAPMV50A)LIKP-VBELN and the program works normally.

If I call FM A, and then B, then what happens is, when the variable (B)LIKP-VBELN is changed, (SAPMV50A)LIKP-VBELN doesn't change.

Somehow, it seems that the first function module that uses a perform of SAPMV50A will also share a memory area with it.

Also, the FM B was DESIGNED to use such a feature, it doesn't work if it doesn't get hold of such "shared memory area".

My question is: Is this an intended design by SAP? what is happening here? I'm trying to understand what's the logic of this, what are the expected behaviours, etc etc

I'm not trying to solve the problem here, I know a few ways to do so. I want to understand what is really happening

TL;DR: 3 programs(A,B,C) use the same include, programs A and B use C. if I B changes a variable declared in the include, it also changes the value on C. If I call program A then B, B stops changing values on C.

Re: Unusual behaviour on multiple function modules using the same include

matt — Thu, 28 May 2015 13:57:47 GMT

In the include vblkdata there is the statement:

data: begin of common part likpcom.

This statement begins a block of memory call likpcom which is shared between all programs that have a common part with the same name.

Therefore this is an intended design by SAP. What you're experiencing could either be an unintended side-effect or (and this is what SAP will tell you) a consequence of using an unreleased function module.

Re: Unusual behaviour on multiple function modules using the same include

adrianos_campanhola — Thu, 28 May 2015 14:07:37 GMT

Matthew, thanks for the fast response.

That could be the case, but the variable in question is LIKP-VBELN, that's not part of the 'common part'.

Also, I've been able to reproduce this locally, using just a include with the declaration: TABLES: LIKP.

EDIT:

Mauricio Cruz sent me the following link: http://help.sap.com/abapdocu_70/en/ABENPROGRAM_GROUP_GLOSRY.htm

This agrees with the problem in question, but might raise another one.

So, as per de documentation, when i call function A, a program group is created and SAPMV50A is added to it. the FG of the FM A shares some data with SAPMV50A( the TABLES addition is included ).

when I call FM B, another program group is created, and SAPMV50A has been taken, so any changes of B won't affect the varibles in SAPMV50A.

Re: Unusual behaviour on multiple function modules using the same include

matt — Thu, 28 May 2015 14:30:22 GMT

Ah right - TABLES works in the same way as COMMON PART. I think I remember knowing that...

Re: Unusual behaviour on multiple function modules using the same include

sakshi_sawhney — Thu, 21 Jul 2016 09:44:20 GMT

This message was moderated.

Re: Unusual behaviour on multiple function modules using the same include

former_member149072 — Mon, 27 Apr 2020 10:05:20 GMT

Simple solution: use DESTINATION "NONE" command for first function module with parameter COMMIT = abap_false and separate call of "BAPI_TRANSACTION_COMMIT (also with DESTINATION "NONE").