call function in update task empty variables error

[adrianos_campanhola]

Hello,

I'm experiencing a weird error while using the addition "In update task".

My Scenario is the following:

Use the bapi_goodsmvt_create -> if there are no errors, fill some values and call my function and then commit everything.

The problem is, when the function runs in update task, all import parameters are empty!

Also, this only happens in the following code structure

CALL METHOD run_migo( IMPORTING bapireturn = t_bapireturn).
IF t_bapireturn IS INITIAL.
  CALL METHOD save_custom_tables. "this runs my function 'IN UPDATE TASK'
  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
    EXPORTING
      wait = 'X'.
ENDIF.

if I commit inside the method SAVE_CUSTOM_TABLES, the data is passed normally to the function, if I commit like the code above, everything is empty.

[Former Member]

Try to use commit-work after "IN UPDATE TASK". I had the same problem while I made a test using FM, and it worked

[adrianos_campanhola]

It works, I tested it as well and this is the way that the code is running right now, BUT do you agree that it shouldn't have to be that way? when you call a bapi, several functions 'in update task' are enqueued and they don't have the same problem!

[SuhaSaha]

Adriano S. Campanhola wrote:

It works, I tested it as well and this is the way that the code is running right now, BUT do you agree that it shouldn't have to be that way? 

Can you explain what you meant by that?

A few additional questions:

• Is it possible to share the code inside the method SAVE_CUSTOM_TABLES( )?
• Did you try update debugging yet? If yes, what did you observer?

BR,

Suhas

[adrianos_campanhola]

What I meant is, the standard code calls functions 'IN UPDATE TASK' several times and they don't have to commit work right away.

I already did some update debug , inside the method SAVE_CUSTOM_TABLES, the information is filled in the header/item tables I need and I pass them to the function. When the function is called after, the table everything is empty.

I'll copy the code later for you

[adrianos_campanhola]

Here's the code:

METHOD save_partial.

  DATA: t_wegritm    LIKE gt_wegritm,
        t_tegrp_parc TYPE TABLE OF ztegrp_parc,
        w_tegrp_parc TYPE ztegrp_parc,
        w_tegrk_parc TYPE ztegrk_parc.
  FIELD-SYMBOLS <w_wegritm> LIKE LINE OF t_wegritm.

  t_wegritm = gt_wegritm.

  DELETE t_wegritm WHERE mengee IS INITIAL.

  CHECK NOT t_wegritm IS INITIAL.

*-->save xml iten
  LOOP AT t_wegritm ASSIGNING <w_wegritm>.

    MOVE-CORRESPONDING <w_wegritm> TO w_tegrp_parc.
    w_tegrp_parc-id = gw_tegrk-id.

    w_tegrp_parc-gr_docto = <w_wegritm>-gr_docto.
    w_tegrp_parc-gr_mjahr = <w_wegritm>-gr_mjahr.
    w_tegrp_parc-gr_zeile = <w_wegritm>-gr_zeile.
    APPEND w_tegrp_parc TO t_tegrp_parc.

  ENDLOOP.

  MOVE-CORRESPONDING gw_tegrk TO w_tegrk_parc.

  CALL FUNCTION 'Z_SAVE_PARTIAL'
    IN UPDATE TASK
    EXPORTING
      iw_tegrk_parc = w_tegrk_parc
    TABLES
      it_tegrp_parc = t_tegrp_parc.

ENDMETHOD.

I tried to re-create this scenario with a local class, but the code that I originally sent worked(the commit work outside of the routine).

[PeterJonker]

Maybe you should add the data to be updated explicitely as parameters to the method save_custom_tables.

[adrianos_campanhola]

What's the idea? I'm using local tables for the update, but it should still save the parameters to VBLOG.

[SuhaSaha]

Adriano S. Campanhola wrote:

... but it should still save the parameters to VBLOG. 

Only if you have not defined the update as local. (SET UPDATE TASK LOCAL)

[adrianos_campanhola]

Right, but since I had no need for a local update task that shouldn't be the reason.

[Former Member]

Hi

For me it looks as if, for some reason, the values passed to the update function got cleared after you left the method in which you called the update function. Are you by any chance passing local variables (declared in the method) to the update function?

If yes, make these variables instance ones in the class containing the method save_custom_tables and check then.

regards

[adrianos_campanhola]

Yes, the variables are all local, but that shouldn't matter since:

1 - The variables in an update function are all pass by value

2 - The parameters should be sent to table 'VBLOG'(Since it's not a local update task, as pointed by ).

[Former Member]

You are using TABLES parameter in Z_SAVE_PARTIAL FM.

Documentation says TABLES is pass by reference with the exception of RFC.

I did a wild search and found that only a handful of update FMs use TABLES parameter, and those FMs don't appear to be used anywhere.

Perhaps you can try passing the internal table as EXPORTING parameter of table type instead of TABLES. Try and let us know the result.

[adrianos_campanhola]

Hi Manish,

The code was just like you said before I messed it up since the tables addition is obsolete, it was just a try to see if something would change.

Anyways,

if that was the problem, the structure iw_tegrk_parc would have the values, but it doesn't

[Former Member]

There is no harm in trying out. Create a DDIC table type having line type as ztegrp_parc and use same table type in FM interface as well as to declare the local internal table.

[adrianos_campanhola]

What I meant is, the function call was just like you said when I first noticed the problem above:

  CALL FUNCTION 'Z_SAVE_PARTIAL'
    IN UPDATE TASK
    EXPORTING
      iw_tegrk_parc = w_tegrk_parc
      it_tegrp_parc = t_tegrp_parc.

I just got lazy and didn't revert it after the change to TABLES