CALL FUNCTION, STARTING NEW TASK

[former_member367551]

Dear forumers,

I ran into a runtime error, POSTING_ILLEGAL_STATEMENT because the SUBMIT command was used in an update task (when a purchase order is posted). More specifically, this SUBMIT command was executed from a calling method (implemented from the BADI, MB_DOCUMENT_BADI).

To resolve this error, I've created a new wrapper function module (with the attributes - Normal Function Module, Start Immediately) containing the SUBMIT command. The SUBMIT command is needed for calling an executable program.

However, I've a little doubt on this:-

Immediately upon executing the FM, how can I ensure that the calling method only continues with the next code lines only after the FM has completed its execution? Will the following syntax suffice?

          CLEAR LT_SRC_DEMAND.
          ......

          CALL FUNCTION 'ZZDT_DETERMINE_DEMANDS'
            STARTING NEW TASK 'UPDATE'
            DESTINATION 'NONE'
            EXPORTING
              IM_EXCL_SOURCED = ' '
              IM_NO_SHOW      = 'X'
              IM_MATERIAL     = LR_MATNR
              IM_WORK_ORDER   = LR_AUFNR
            CHANGING
              CH_SRC_DEMANDS  = LT_SRC_DEMAND.   
         " CHANGING had to be used above, as EXPORTING is not allowed

          IF LT_SRC_DEMAND IS NOT INITIAL.
              ......
          ENDIF.

          ......

" The FM source codes looks like this:-

FUNCTION ZZDT_DETERMINE_DEMANDS.
*----------------------------------------------------------------------
**Local Interface:
*  IMPORTING
*     REFERENCE(IM_EXCL_SOURCED) TYPE  XFELD
*     REFERENCE(IM_NO_SHOW) TYPE  XFELD DEFAULT 'X'
*     REFERENCE(IM_MATERIAL) TYPE  ZZDT_RESERVATION_MATNR_T
*     REFERENCE(IM_WORK_ORDER) TYPE  ZZDT_RESERVATION_AUFNR_T
*  CHANGING
*     REFERENCE(CH_SRC_DEMANDS) TYPE  ZZDT_SRC_DEMAND_T
*----------------------------------------------------------------------

** This is a wrapper function module to determine demands via the     **
** Sourcing program and is especially useful to be called from an     **
** update task.                                                       **

* Clear internal table first
  CLEAR ch_src_demands.

* For performance reasons, ensure that minimal data inputs are specified
  CHECK im_material IS NOT INITIAL OR im_work_order IS NOT INITIAL.

* Execute the Sourcing program to determine the relevant demands
  SUBMIT ZZDT_SOURCING AND RETURN
    WITH ex_srcd  EQ im_excl_sourced
    WITH p_noshow EQ im_no_show
    WITH sa_matnr IN im_material
    WITH sd_work  IN im_work_order.

* Return the list of demands via SAP/ABAP memory
  IMPORT t_demand_alv TO ch_src_demands FROM MEMORY ID 'SRC_DEMAND_LIST'.

ENDFUNCTION.

[former_member367551]

Also, to add on - the calling method is executed in background.

Do I need to add anything further in the CALL FUNCTION command (see above) so that the FM is run in background as well?

[SuhaSaha]

To resolve this error, I've created a new wrapper function module (with the attributes - Normal Function Module, Start Immediately) containing the SUBMIT command.

You need to make the FM as "Remote-Enabled" module. AFAIK you cannot start normal FMs asynchronously.

Immediately upon executing the FM, how can I ensure that the calling method only continues with the next code lines only after the FM has completed its execution? Will the following syntax suffice?

You can try using this variant of [WAIT|http://help.sap.com/abapdocu_702/en/abapwait_until.htm] statement.

BR,

Suhas

[former_member367551]

Suhas,

I tried to make the FM as "Remote-Enabled", but I had these warnings when changing the parameters to pass-by-value:-

Parameter IM_MATERIAL (type ZZDT_RESERVATION_MATNR_T) can reduce performance in RFC.

Parameter IM_WORK_ORDER (type ZZDT_RESERVATION_AUFNR_T) can reduce performance in RFC.

Parameter CH_SRC_DEMANDS (type ZZDT_SRC_DEMAND_T) can reduce performance in RFC.

All of these parameters are of internal table types.

Should I still proceed, or is there a more efficient way around this?

[Former Member]

Hi

It should be better to use TABLES parameter instead of an IMPORTING parameter based on table type

But it can't understand why you need to run the report in the posting process

Max

[former_member367551]

Max,

I had in mind that it is not advisable to use TABLES for the formal parameters - so I tried to avoid that as much as I could.

The report is needed to return the number of open demands, if there are any. And from what I know, calling the report (via SUBMIT) is the more efficient way to determine open demands quickly.

[former_member367551]

Dear experts,

Need some help again.

Another runtime error has occured - and this time on the RECEIVE RESULTS statement instead.

          CLEAR: lt_src_demand, gv_call_completed.

          CALL FUNCTION 'ZZDT_DETERMINE_DEMANDS'
            STARTING NEW TASK 'UPDATE'
            DESTINATION 'NONE'
            CALLING set_call_completed ON END OF TASK
            EXPORTING
              im_excl_sourced = ' '
              im_material     = lr_matnr
              im_work_order   = lr_aufnr.

          WAIT UNTIL gv_call_completed = 'X'.

" run-time error occurs here 
          RECEIVE RESULTS
            FROM FUNCTION 'ZZDT_DETERMINE_DEMANDS'
           IMPORTING
             ex_src_demands = lt_src_demand.

Details about the run-time error are as below:-

CATEGORY: Internal Kernel Error

RUNTIME ERROR: CALL_FUNCTION_RECEIVE_ERROR

APPLICATION COMPONENT: BC-MID-RFC

ERROR ANALYSIS: Internal error: Invalid RFC handle.

What can I do to resolve this runtime error?

The FM attributes ('ZZDT_DETERMINE_DEMANDS') are currently set as 'Remote-Enabled Module' and 'Start immediately'.

Does this need to be changed (i.e. as 'Update Module') to resolve the current runtime error?

Appreciate any help at all. Thanks.

[Former Member]

Tan,

>> Shift your Receive statement inside the subroutine and no need of using gv_call_completed Flag.

>> Why you use 'Importing' in Receive statement when you have 'CHANGING' in your FM call.

try .....

FORM result USING LV_FLAG TYPE c.  

RECEIVE RESULTS
            FROM FUNCTION 'ZZDT_DETERMINE_DEMANDS'
           CHANGING
             ex_src_demands = lt_src_demand.

ENDFORM.

Regards,

Diwakar

[Former Member]

Hi,

As said to ensure the FM execution completion , you can try like this..

CLEAR GV_FLAG.
CALL FUNCTION 'ZZDT_DETERMINE_DEMANDS' STARTING NEW TASK 'UPDATE' DESTINATION 'NONE' PERFORMING result ON END OF TASK
  EXPORTING
    im_excl_sourced = ' '
    im_no_show      = 'X'
    im_material     = lr_matnr
    im_work_order   = lr_aufnr.

WAIT UNTIL GV_GLAG = 'X'.

RECEIVE RESULTS FROM FUNCTION 'ZZDT_DETERMINE_DEMANDS'
CHANGING
ch_src_demands  = lt_src_demand.

*&---------------------------------------------------------------------*
*&      Form  result
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->COUNTER    text
*----------------------------------------------------------------------*
FORM result USING LV_FLAG TYPE c.  
  GV_FLAG = 'X'.
ENDFORM.

Regards,

Ravi.

[former_member367551]

Thanks, Ravi. This seems like something that could just work.