Clear static data?

[Clemenss]

Hi folks!

in some userexits our developers use either global data in a function group or static data in form routines.

OK, by now all developers believe that a 'commit work' never clears any variables. But in some situations in mass- or IDOC-processing we would prefer to be sure that everything is cleared.

Is there a way of clearing just everything or to have everything initial by re-loading the modules - actually I don't know how to enforce a reload.

Is a possible solution processing in separate task?

Thanks for any useful hints,

C.

[Former Member]

Hi

Perhaps you can create a routine to clear all and call it after commit:

PERFORM CLEAR_ALL ON COMMIT.

In this way the routine runs only once time after commit is being called.

Anyway let us know more details, because a good solution depends on the flow of process.

Max

[Clemenss]

I'd like to give more details if I knew them...

Just got on the project a few weeks ago - interfacing a navision system via IDOCs to R/3 46C.

Our IDOCs create sales documents first. From there deliveries, invoices and financial documents are created. Some processes create IDOCs again which are send to other company codes creating vendor invoices.

BUT: There are many processes, none of them documented sufficiently. And we have an unknown number of active user exits, some or more of them coded not what I might call 'state of the art'.

I got nervous when I noticed that in processing inbound IDOCs subsequent IDOCs carried errors of previously processed ones and vice versa - triggered by user exits in pricing procedure of sales document.

This originated from global data in user exit functions. The (ir-) responsible developer tried to convince me that 'Commit work' would fix the problem as a new LUW would start. He learned that 'Commit work' won't clear any data.

But I don't know who else did what in which user exit. To make sure everything works as desired I would rather know how to start from scratch with each IDOC. As I don't know all active userexits for all processes and document types, a Form to clear on Commit is a nice idea if I even knew what to clear.

A simple solution would be to enforce a reload of all programs involved but I don't no how to enforce.

Any other ideas welcome!

C.

[Former Member]

Hi Li,

Put all your processes for each IDOC in a RFC Function Module and then call it as follows,

LOOP AT <Your IDOCS>.

CALL FUNCTION <Your Function Name>

STARTING NEW TASK <Task Name>

DESTINATION 'NONE' ...

....

....

....

ENDLOOP.

Hope this helps..

I am adding this explanation for better understanding..

In the above RFC fm that I have mentioned you can have all your PARSE IDOC logic and then all calls to sales orders, deliveries etc..

Alternatively, I think you can have every thing in a report and then use SUBMIT REPORT technique. Even this will start a new LUW each time.

Sri

[Former Member]

Hello Clemens,

Your problem seems to me like some kind of a jigsaw puzzle. You've got a few pieces and are trying to figure out which other pieces would fit in where....:-)

But I think it is reasonably clear that the errors are all arising out of User-Exits. Since you have said that there's some global data which is not getting cleared and which is causing problem subsequently, it is a good point to start off with analyzing what global data is being used at which point. Modularization - splitting the code into subroutines and ensuring that all data is being passed through clearly defined interfaces (use pass by <i>value</i>) should certainly solve the problem.

Trying to restart/reload the whole process would work, but it can only be a makeshift solution. It is certainly not what I would call "state-of-the-art"!

Think about it.

Regards,

Anand Mandalika.

[Former Member]

Hi

It's right: COMMIT doesn't clear the global data of a program, but it releases only database updating, database lock and i think log rollback too, but not program data.

They are automatically cleared when program is finished: when a program is downloaded from memory. So commit and end of program could not coincide.

So these user-exit aren't probably made very well: after a process is finished all global data should be cleared and if the programs aren't downloaded from memory (because they aren't finished), they have to be cleared by programs.

If you run a process in debug, you could see which program (user-exit) are used (are uploaded in memory) and then to deicede where it needs to clear the data.

Max

[Clemenss]

thank you everybody for the very good hints. Clearly I would prefer to solve it analytically by finding out what user exits are active and what they do with which static data.

But this will be impossible for me within the scope of this project.

So Srikanth Pinnamaneni's proposal clearly is a fail-safe-solution. I tried to reassign from very helpful to solved what makes some problems...

The downer remaining is that for every STARTING NEW TASK all the modules get reloaded - unfortunately people created (among others) one huge function group with roughly 100 functions for database access. So we will have to try around with possible speed issues.

Also I'm not quite sure how to get back the table parameters contents (BAPIRETURN). We have to use them for assigning the correct status to the IDOC processed.

I knew about CALL FUNCTION <Your Function Name>

STARTING NEW TASK <Task Name>

DESTINATION 'NONE' but I never worked with it - I'll give it a try!

Thanks again! - no more input required at this point.

C.