CALL TRANSACTION ... UPDATE 'S' and Restartable Update Request

[Former Member]

Dear experts,

I have a program that calls a transaction by using the CALL TRANSACTION ... UPDATE 'S' statement. This transaction then performs a database update by using CALL FUNCTION ... IN UPDATE TASK statement. The database update may cause an error due to the primary key conflict.

One behavior that I notice of my program is when the database update raises an error, the corresponding update request in the update table log (SM13) will be flagged as error and non-restartable, eventhough the update module in question is restartable. Why is it like this?

To make my question clearer, I attach my transaction, program and update module below. They are very simple.

Update module:

FUNCTION z_121_15_update_module.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IMP_ZSCARR_CUSTOM) TYPE  ZSCARR_CUSTOM
*"----------------------------------------------------------------------
  INSERT into zscarr_custom values imp_zscarr_custom.

  IF sy-subrc NE 0.
    WRITE sy-subrc TO subrc.

    MESSAGE subrc TYPE 'A'.
  ENDIF.
ENDFUNCTION.

Subroutine in the transaction that calls the update module above:

FORM save.
  zscarr_custom-carrname = sy-uzeit.

  CALL FUNCTION 'Z_121_15_UPDATE_MODULE' IN UPDATE TASK
    EXPORTING
      imp_zscarr_custom = zscarr_custom.

  COMMIT WORK.

  LEAVE TO SCREEN 0.
ENDFORM.

The program that calls the transaction whose the subroutine above:

*&---------------------------------------------------------------------*
*& Report  Z_121_15_COMPLEX_LUW_19
*&
*&---------------------------------------------------------------------*
*& Program that calls a transaction.
*& Called transaction(s): Z_121_15_CLUW_20
*&---------------------------------------------------------------------*

REPORT z_121_15_complex_luw_19.

DATA:
  it_bdcdata TYPE TABLE OF bdcdata,
  wa_bdcdata TYPE bdcdata,
  subrc TYPE char10.

wa_bdcdata-program = 'Z_121_15_COMPLEX_LUW_20'.
wa_bdcdata-dynpro = '100'.
wa_bdcdata-dynbegin = 'X'.

APPEND wa_bdcdata TO it_bdcdata.
CLEAR wa_bdcdata.

wa_bdcdata-fnam = 'ZSCARR_CUSTOM-CARRID'.
wa_bdcdata-fval = '01'.

APPEND wa_bdcdata TO it_bdcdata.
CLEAR wa_bdcdata.

wa_bdcdata-fnam = 'BDC_OKCODE'.
wa_bdcdata-fval = 'SAVE'.

APPEND wa_bdcdata TO it_bdcdata.

CALL TRANSACTION 'Z_121_15_CLUW_20' USING it_bdcdata MODE 'E' UPDATE 'A'.

*IF sy-subrc > 0.
  WRITE sy-subrc TO subrc.

  MESSAGE subrc TYPE 'S'.
*ENDIF.

Thanks in advance.

Regards,

Haris

[krishnendu_laha]

Hello,

how did you figure out that update module is restart-able?

I think you have checked options below Update Module in FM attributes tab.

First 2 options are related V1 update request and second 2 options are related to V2 request.

Only V2 request are restart-able.

Thanks

[Sandra_Rossi]

Hi Haris,

First, I don't agree with Krishnendu, V1 only are restartable. For more information, see [SAP note 552300 (FAQ: Update)|https://service.sap.com/sap/support/notes/552300 ]

And this note maybe answers your question:

[5] Question: What should I do with terminated update records?
You must first determine whether an update record can be updated again. This is possible under the following conditions:
- All update modules of the update record can be updated again.
- The update record was not created using batch input ...

I think the idea behind this is that restarting update tasks is a little bit risky as the locks are not set, and maybe someone has changed the object since them, so, as the update was requested by an automatic program, it's better to restart this batch input rather than restarting the update task...

Sandra

[Former Member]

Dear all,

After further research, I notice that, regarding the restart-able V1 update module, any error in a synchronous update request will make the corresponding update request in the update request log table be marked as non restart-able, either the update request is issued by COMMIT WORK AND WAIT or CALL TRANSACTION ... UPDATE 'S'. Am I correct?

Thanks in advance.

Regards,

Haris

[Sandra_Rossi]

Hi,

I don't know what you did exactly, but a simple V1 restartable function module is restartable, except if it's in a batch input context as indicated by the doc I provided above. Maybe you are in the case where you have several function modules in the update task, where at least one is not restartable, in that case, the update task can't be restarted.

Sandra

[Former Member]

What I mean is, for example, when the called update module in the code below issues a type A message,

  .....
  CALL FUNCTION 'Z_121_15_UPDATE_MODULE' IN UPDATE TASK
    EXPORTING
      imp_zscarr_custom = zscarr_custom.

  COMMIT WORK AND WAIT.

then, in SM13, the corresponding update task will be flagged as non restart-able, eventhough the update module itself is defined as restart-able.

This also happens in the case follows: let the code below is a part of a transaction program that calls an update module

....
  CALL FUNCTION 'Z_121_15_UPDATE_MODULE' IN UPDATE TASK
    EXPORTING
      imp_zscarr_custom = zscarr_custom.

  COMMIT WORK.

and the transaction above is called by a program by using

CALL TRANSACTION 'THE_TRANSACTION_ABOVE' ....... UPDATE 'S'.

Am I correct? This is my conclusion so far.

[Sandra_Rossi]

Hi,

why don't you take 5 minutes to create a restartable update function module from scratch, make it send an A message, call it in update task, and see what happens? My own test shows it is restartable as expected, unless if you are in one of the 2 cases mentioned in the doc I pasted above (which answers your 2nd question about CTU).

So, if you don't understand the documentation above, please tell us what you don't understand.

Maybe the term "batch input" is not clear for you? It means either a CALL TRANSACTION USING (CTU) or a batch input session (SM35).

If none of the 2 possibilities correspond to your case, then contact SAP's support.

Sandra

[Former Member]

Hi Sandra,

Thank you for your answers and suggestions. I did everything from scratch and there is only one restart-able update request issued by my program.

I have tried again and again to issue a restart-able update request synchronously and when the update task issues an A message, then the update request will be flagged as non-restart-able in the update request log table (SM13). This is done either by using COMMIT WORK AND WAIT or CALL TRANSACTION <trans> USING <bdctab> UPDATE 'S'.

Since the behavior is different from your test, I start to question my conclusion about this matter. Could it be our SAP version difference that affects this? I'm using SAP Netweaver 2004s ABAP Trial Version v.7.00.

Does "the doc" here refers to the link to the 'SAP note 552300 (FAQ: Update)'? If so, unfortunately, I can't open the doc you attached since I don't have the SAP Service Marketplace account yet.

Regards,

Haris

[Sandra_Rossi]

Hi Haris,

I'm sorry about my previous answer(s), I must admit that your assumptions from September 23 seem to be correct : a synchronous update task can't be restarted. I guess SAP's idea is that the program is informed of the error (SY-SUBRC after the COMMIT WORK), so it should be able to handle the recovery process.

I'm a little bit confused as I couldn't find any reference in SAP's documentation.

So, the decision to use COMMIT WORK AND WAIT instead of COMMIT WORK is to handle with care as update task restarting doesn't work, SY-SUBRC must be absolutely tested with COMMIT WORK AND WAIT and we have to think about how the recovery process can be done (especially inbound file interfaces).

Thank you for your post, that was an important discovery for me

Sandra