Background job not collecting data

[former_member844813]

So im assigning my program as a background job to collect data and store it to ztable, in sm37 says the background job is finished but when i check the database, there's 0 data entries. anyone can help me with that ?

*&---------------------------------------------------------------------*
*&  Include           ZGETFBL01
*&---------------------------------------------------------------------*
FORM F_GET_DATA.

  IF SY-BATCH EQ 'X'.
    SELECT HKONT A~BUKRS AUGBL A~WAERS A~BUDAT DMBTR SHKZG A~BELNR BUZEI A~BLDAT KOSTL SGTXT DMBE2 WRBTR
         FKBER PRCTR BSCHL ZUONR B~BKTXT B~USNAM B~GJAHR B~AWKEY CPUDT
    FROM BSIS AS A
    INNER JOIN BKPF AS B
    ON B~BUKRS = A~BUKRS
    AND B~BELNR = A~BELNR
    AND B~GJAHR = A~GJAHR
    INTO TABLE ITAB
    WHERE A~BUKRS = '1200' AND HKONT eq '0006105001' AND ( A~BUDAT BETWEEN '20230101' AND '20230131' ).
    DELETE ITAB WHERE DMBE2 EQ '335.34'.
    SORT ITAB BY BUDAT.

    LOOP AT ITAB INTO WA.
      IF wa-shkzg = 'H'.
        wa-dmbtr = wa-dmbtr * -100.
      ELSEIF wa-shkzg = 'S'.
        wa-dmbtr = wa-dmbtr * 100.
      ENDIF.
      MODIFY ITAB FROM WA TRANSPORTING dmbtr.
    ENDLOOP.

    LOOP AT ITAB INTO WA.
      IF wa-shkzg = 'H'.
        wa-wrbtr = wa-wrbtr * -100.
      ELSEIF wa-shkzg = 'S'.
        wa-wrbtr = wa-wrbtr * 100.
      ENDIF.
      MODIFY ITAB FROM WA TRANSPORTING wrbtr.
    ENDLOOP.

    LOOP AT ITAB INTO WA.
      IF wa-shkzg = 'H'.
        wa-dmbe2 = wa-dmbe2 * -1.
      ELSEIF wa-shkzg = 'S'.
        wa-dmbe2 = wa-dmbe2 * 1.
      ENDIF.
      MODIFY itab FROM wA TRANSPORTING dmbe2.
    ENDLOOP.

    DELETE from zdatagl2.

    LOOP AT ITAB INTO WA.
      MODIFY TABLE ZDATAGL2 FROM WA.
    ENDLOOP.

    IF R_TABLE IS BOUND.
      LO_AGGRS = R_TABLE->GET_AGGREGATIONS( ).
      TRY .
          CALL METHOD LO_AGGRS->ADD_AGGREGATION
            EXPORTING
              COLUMNNAME  = 'DMBTR'
              AGGREGATION = IF_SALV_C_AGGREGATION=>TOTAL.

        CATCH CX_SALV_DATA_ERROR CX_SALV_NOT_FOUND CX_SALV_EXISTING.
      ENDTRY.
      TRY .
          CALL METHOD LO_AGGRS->ADD_AGGREGATION
            EXPORTING
              COLUMNNAME  = 'DMBE2'
              AGGREGATION = IF_SALV_C_AGGREGATION=>TOTAL.

        CATCH CX_SALV_DATA_ERROR CX_SALV_NOT_FOUND CX_SALV_EXISTING.
      ENDTRY.
    ENDIF.
  ENDIF.
ENDFORM.

[DominikTylczyn]

Hello demaauliansyah

demaauliansyahWhy don't you replace the condition

IF SY-BATCH EQ 'X'.

with a parameter from the report's selection screen, e.g. call the parameter "collect data"?

This way you can run the report online, with the parameter set and debug how the data is collected. Once the issue is solved, you can schedule a background job with a selection variant and set the parameter there.

I don't think it is a good practice to make a report processing differently in background as compared to online. That makes debugging a nightmare.

Best regards

[cmilkau]

Does it work if you run the report directly?

[cmilkau]

Maybe you want to add some logging to your job in order to investigate what is going on. You can do so using the "message" statement with message type 'S'. You can check these logs in transaction SM37, function "job log".

[matt]

Bit of a poor man's debugging.

Instead go to SM37, type JDBG in the command field, place the cursor on your job and press enter. Now you are debugging in the background job.

[cmilkau]

It is not intended as debugging. I think it's always good practice to provide enough logging in background processes to get at least an idea of what's going on when something goes wrong, and to see if anything has been done at all.

That said, debugging is probably the best option in this case. Why not turn your comment into an answer?

[matt]

I think it's always good practice to provide enough logging in background processes to get at least an idea of what's going on when something goes wrong

You are entirely right!

[raymond_giuseppi]

Agree, it's good practice to provide information in the job log (SM37) or even in the application log (SLG1) in order to analyze any error that might occur (and therefore will occur)

[former_member844813]

Hi Milkau

No, it didnt collect any data either

[matt]

Then run it in debug and see what happens.

[Sandra_Rossi]

To complement Carsten and Matthew, because your program does IF sy-batch = 'X', you should execute it in dialog and debug it through SM37 > command field "JDBG" (it's explained in the forum).

[VXLozano]

That code hurts in so many ways that I guess I will not be able to explain all of them.

• I will assume it's just a piece of code, and because that, there are no local data declarations (itab, wa...)
• a form called GET_DATA should only retrieve data, if you want to add that data to a table, add a new form SAVE_DATA
• If you are expecting that form to be executed only in background, do an initial CHECK and you'll save a level of indentation.
• All those literals (not the fields ones, but the dates and the account number) will ruin the maintenance of the program

Anyways... if you are still in the development phase, just add WRITE statements around the code, like

after the SELECT:

write:/ |{ lines( ITAB ) } collected|.

after the deletion by that "random number":

write:/ |{ lines( ITAB ) } remain after deleting 335.34|.

Etc. Then you'll have your log and will be able to see where (if you had some once) your data was lost.

[former_member844813]

sorry to dissapoint, i'm new to this abap development so im using what works as i wanted in this code

[Sandra_Rossi]

Just consider the comments to improve your code, everyone has been a newbie.

Now concerning your program, you should just debug it. It's impossible to help more, based on the information you have given.