topic Re: Function data clashing with BADI data in same LUW in Application Development and Automation Discussions

Function data clashing with BADI data in same LUW

Former Member — Thu, 14 Jul 2011 14:19:06 GMT

Hi All

I implemented IF_BADI_HU_SAVE_{SAVE and run BAPI_HU_GETLIST from it. But the strangest thing happens - the IT_HEADER and IT_ITEMS exist in IF_BADI_HU_SAVE}SAVE parameter list as well as within BAPI_HU_GETLIST forms. The Function Module actually overwrites the BADI's tables with it's own.

We don't have the luxury of ECC environment, so shared memory is not an option. What I can do in the interim is to store the tables upon entry and populate them again at exit, but out of interest. How would one go about creating another LUW/instance that would not affect the current? I tried calling the Function Module from a static method or instance method, but the same happens. The only place where it did not interfere with the BADI parameters was when I call it from a program and SUBMIT AND RETURN. But the problem there is that it did not allow me to IMPORT parameters/tables from MEMORY IDs within the OO context. So a solution would be SHARED MEMORY in ECC environments.

Any ideas would be appreciated.

Best regards,

Adrian

Re: Function data clashing with BADI data in same LUW

Former Member — Thu, 14 Jul 2011 15:24:07 GMT

Hi Adrian,

I am not sure if I got ur problem right , but when the control is returned from BAPI , the calling program's (in this case its method SAVE) variables will re-gain its previous state unless we are passing it to importing or changing parameter of the FM. So I think it_header should have its original state when the control is returned from BAPI.

Regards

Pawan

Re: Function data clashing with BADI data in same LUW

Clemenss — Thu, 14 Jul 2011 21:01:45 GMT

Hi Adrian,

I do not understand. Please post some code lines.

Note that parameters are passed by reference so maybe you better copy values to local fields before passing them.

Regards,

Clemens

Re: Function data clashing with BADI data in same LUW

Former Member — Fri, 15 Jul 2011 05:55:25 GMT

Hi guys

The theory listed I'm aware of, thanks. You'll notice that the parameters of the BADI are not flagged as pass by value. Neither is it passed in the called BAPI as parameters. And if you programatically try and change IT_HEADER or IT_ITEMS, you'll get a compilation error. This is what is so strange about the whole thing. Nowhere am I changing the IT_HEADER or IT_ITEMS tables explicitly, and as mentioned - it is impossible to compile the program if you attempt this. But once you call the BAPI, these values are messed up. And when you drill down into the BAPI, you'll see that it has tables within the function group forms that have the same names as the ones in the BADI interface/parameters. So for some obscure reason, the values are changed at runtime by the BAPI/Function Group, and they do not "have their original state" as suggested/expected when returning. I've implemented probably 100s of BADIs, but never had this problem before. You can implement and test yourself to see what I mean.

The only way around this is to start another logical unit of work which will ensure that the "own data" on both sides do not get affected by one another - ensuring "encapsulation". This is possible with a submit statement, but then I cannot use IMPORT MEMORY ID in the BADI, because of OO context limitations. And as mentioned, SHARED MEMORY is not possible, because we're on 4.7c. And writing temporarely to Z tables is way to risky and ugly.

Best regards,

Adrian

Re: Function data clashing with BADI data in same LUW

Former Member — Fri, 15 Jul 2011 06:23:17 GMT

This is the BADI's interface/parameters:

IF_SYNCRON Importing Type XFELD Synchronous Update

IS_HEADER51 Importing Type HEADER51 General Header Data for Processing

IT_HEADER Importing Type HUM_HU_HEADER_T Handling Unit Headers

IT_ITEMS Importing Type HUM_HU_ITEM_T Handling Unit Items

IT_HISTORY Importing Type HUM_HISTORY_T Handling Unit History Records

So, because all of them are IMPORTING parameters, in theory they should be unchangeable, but BAPI_HU_GETLIST changes their content.

Adrian

Re: Function data clashing with BADI data in same LUW

SuhaSaha — Fri, 15 Jul 2011 06:28:21 GMT

Hello Adrian,

Sorry to hear that you're on 4.6C!

Anyway since Shared Memory is not an option, did you check if there is an option to move the data to cluster tables(e.g., INDX) via the IMPORT FROM / EXPORT TO DATABASE construct?

You'll notice that the parameters of the BADI are not flagged as pass by value

That's the problem with this BAdI + BAPI combo. If i understand correctly the BAPI changes the "actual" internal tables & hence the formal params get changed

Why don't you copy the contents of these tables to some local internal tables?

BR,

Suhas

PS: Please bear with me 'coz i don't have access to SAP

Edited by: Suhas Saha on Jul 15, 2011 11:59 AM

Re: Function data clashing with BADI data in same LUW

Former Member — Fri, 15 Jul 2011 06:53:05 GMT

Yes Suhas, not as sorry as I am on not having ECC!!!

I'll have to look into the IMPORT FROM / EXPORT TO DATABASE options. Haven't attempted that yet.

You're 100% correct. The BAPI changes the actual internal table content. I did copy the contents to internal tables, but used that in my evaluation. The problem is that it is impossible to change it back at the end of the BADI, because the tables are Import parameters and when you attempt to change the content programatically, compilation fails.

I'll read up on your IMPORT FROM / EXPORT TO DATABASE option. The IMPORT/EXPORT to/from MEMORY IDs fails to compile in OO context, so I'm not too sure if the TO/FROM DATABASE option will be any different.

Regards, Adrian

Re: Function data clashing with BADI data in same LUW

Clemenss — Fri, 15 Jul 2011 09:34:22 GMT

Hi Adrian,

it was my suggestion and also Suhas wrote

Why don't you copy the contents of these tables to some local internal tables?

Is there any reason not to do so?

Post some code lines, please.

Regards,

Clemens

Re: Function data clashing with BADI data in same LUW

Former Member — Fri, 15 Jul 2011 10:30:48 GMT

As mentioned, that's a pointless exercise,

because the badi parameter tables are erroneously overwritten in the background and can't be changed back. The Delivery can actually not be saved after a call to the BAPI.

I'm closing the post now. Thanks for everyone attempts and suggestions.