Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Call function background is not working

Former Member
0 Likes
2,294

Hi All,

I created an RFC function module with one import parameter and 2 tables.

I am calling this function module in baground

CALL FUNCTION "ABC" IN BACKGROUND TASK

Exporting

var = var

tables

tab1 = tab1

tab2 = tab2

i am passing var and tab1 and updating tab2 in FM

tab2 is not updating if i call in BACKGROUND

It is working fine in onlie mode.

Can anyone please through some light on this

Thanks,

Naveen

5 REPLIES 5
Read only

Former Member
0 Likes
1,028

Please cut and paste the real code you are using.

What exactly do you mean by tab2 is not updating?

Rob

Read only

0 Likes
1,028

Hi Rob,

Thanks for the reply. Here is the code

Here i am passking lv_flname, lt_binary_file and updating lt_objbin

in the function module i am going to update lt_objbin.

The reason i am doing this becuase if i use open dataset it failing authorization.

Thats why i want execute these statements in background. These report will be executed by many users, so they can not give authorization for everyone.

CALL FUNCTION 'ZFI_VIM_OPEN_DATASET' IN BACKGROUND TASK
        EXPORTING
          lt_flname      = lv_flname
        TABLES
          ls_binary_file = lt_binary_file
          ls_objbin      = lt_objbin
        EXCEPTIONS
          error_dataset  = 1
          OTHERS         = 2.

Here is the function module code

FUNCTION zfi_vim_open_dataset.

*"*"Local Interface:
*"  IMPORTING
*"     VALUE(LT_FLNAME) TYPE  CHAR80
*"  TABLES
*"      LS_BINARY_FILE STRUCTURE  TBL1024
*"      LS_OBJBIN STRUCTURE  SOLISTI1
*"  EXCEPTIONS
*"      ERROR_DATASET
 
  OPEN DATASET lt_flname FOR OUTPUT IN BINARY MODE.

  IF sy-subrc = 0.
    LOOP AT ls_binary_file.
      TRANSFER ls_binary_file TO lt_flname.
    ENDLOOP.
    CLOSE DATASET lt_flname.
  ENDIF.
  CLEAR: ls_objbin. REFRESH: ls_objbin.
  OPEN DATASET lt_flname FOR INPUT IN BINARY MODE.
  DO.
    READ DATASET lt_flname INTO ls_objbin.
    IF sy-subrc <> 0.
      CLOSE DATASET lt_flname.
      EXIT.
    ELSE.
      APPEND ls_objbin.
    ENDIF.
  ENDDO.

  DELETE DATASET lt_flname.

ENDFUNCTION.

Moderator message - Please use code tags to format your code

Edited by: Rob Burbank on Apr 1, 2010 3:42 PM

Read only

0 Likes
1,028

I don't see the exception ERROR_DATASET being set anywhere.

I think you should be doing more return code checking and raising more exceptions.

Rob

Read only

0 Likes
1,028

If they don't have open dataset "written in code", why would they have authorization for open dataset written in code but stuck inside a function module? I'd drop the in background task.... The background task is going to be triggered by the same userid, isn't it? I don't think you'll be able to evade security this way.

If they don't have open dataset, they can't run your program....You'll have to have your batch job processing ID run it (as a background job). Sounds like security overkill...what huge harm can be done with open dataset when the users can download anything they want in Word or Excel probably and misuse in any way they desire?

Read only

Former Member
0 Likes
1,028

Hi Naveen,

The [CALL FUNCTION ... IN BACKGROUND TASK|http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_BACKGROUND_TASK.htm] will only be executed once you do the [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm]. Please check if your coding contains the COMMIT after you triggered the tRFC call (i.e. in background task triggers tRFC calls).

As mentioned above, your RFC function should have some proper error handling. If an exception occurs, you could then find it in the outbound RFC queue.

Cheers, harald