CHANGING parameters not changed?

[Former Member]

We have a workflow task that runs in the background. It's supposed to update a custom log table Z_LOG. The table entries didn't get updated as expected, so I added a few log points and activated them globally in SAAB.

The function module calls a subroutine that gets the correct values from tables

Perform Get_Fi_Invoicedata_210 Using im_logdata-company_code

                                            im_logdata-fi_document

                                            im_logdata-fiscal_year

                                   Changing wa_log.

Just before ENDFORM, I have inserted a log point to check the values of wa_log (p_log).

log-point id ZMARTTI_OSLA fields p_log-refno p_log-amount p_log-amount_lc.

Then right after the subroutine call, I check the values of wa_log again

log-point id ZMARTTI_OSLA fields wa_log-refno wa_log-amount wa_log-amount_lc.

Now here's the weird thing:

in SAAB logs, I see that at the end of the subroutine, p_log-amount has a new value, say 132.00

but back in the main program, I see that wa_log-amount has the old value, 131.00

This happens occasionally, maybe one time out of three, when we run it in the background with WF-BATCH. In direct debugging, it doesn't happen.

If I have to decide which I rely more on, subroutine parameter passing or SAAB, I'd choose basic subroutine passing every time. Still, the actual results seem to agree with what SAAB shows: sometimes the new values are not updated.

[juan_suros]

I'd use IMPORT and EXPORT to move the data back from your perform to the calling function.

There is probably some timing issue with the parameter values. Marshalling? Asynchronous execution? Not sure of the jargon that applies here.

[Former Member]

Hi,

never heard of parameters not getting correct values after calling a method / perform.

are there any dirty assigns influencing the values? does the structure fit? maybe the result does not get populated into the correct field.

do you lock the z-Tabelle befor updating it, so parallel updates dont influence each other.

do you import/export from memory?

regards

Stefan Seeburger

[juan_suros]

Stefan,

Yes, IMPORT and EXPORT to memory with a key.

I like to use a GUID for the keywhen multiple batch jobs or threads may be involved:

DATA: guid TYPE guid_32.

guid = cl_system_uuid=>create_uuid_c32_static( ).    

There must be some issue with the runtime losing synchronization of the calls from one process to the next. Arto doesn't say, but I suspect the FM is called IN UPDATE TASK.

Juan

[Former Member]

The execution process is quite simple. The function is not called in parallel, nor in update task. It's just called from a workflow method, and thus executed in the background by WF-BATCH. That shouldn't change the way it runs, though.

If there's anything that has been thoroughly tested and widely used, that's parameter passing, so I guess I don't seriously think there would be an error in passing parameters from a subroutine. It must be something else, but can't see what.

We have the function module Z_IV_UPDATE_LOG_TABLE that calls the subroutine as below, with the log point right after the call.

Perform Get_Fi_Invoicedata_210 Using im_logdata-company_code

                                            im_logdata-fi_document

                                            im_logdata-fiscal_year

                                  Changing wa_log.

    endif.

    log-point id ZMARTTI_OSLA fields wa_log-refno wa_log-amount wa_log-amount_lc.

The subroutine signature is

FORM get_fi_invoicedata_210 USING p_bukrs p_belnr p_gjahr

                          CHANGING p_log TYPE z_iv_log.

and the last lines of the subroutine are

log-point id ZMARTTI_OSLA fields p_log-refno p_log-amount p_log-amount_lc.

ENDFORM.                    " GET_FI_INVOICEDATA_210

So there's not much room for dirty assigns

The logpoint in the subroutine shows the new value (for example 132.00) for parameter p_log-amount.

The logpoint in the FM shows the old value (131.00) for wa_log-amount.

But this doesn't happen every time I run this. Strange, indeed.

[Former Member]

As one could have guessed, there was nothing wrong with standard parameter passing or log points. It was my interpretation.

In the larger framework, there was another call to the subroutine that I had missed. In that latter call, the subroutine had the new values, and that log point obscured the results of the first call. I then misinterpreted that the subroutine had new values, but returned old values.

We fixed the leak by doing the same read and update routines again a bit further down the road. Admittedly, it's a bit stupid, and there are still some elements that I don't understand, but I ran out of time and budget in exploring. I believe most of it goes down to the standard invoice update functions not having completed database updates by the time the invoice was re-read from the database. As for the rest, I'll just have to shrug and let it pass...