2012 Jan 26 4:22 PM
Hi,
I have a dilemma of calling BAPI_ACC_DOCUMENT_POST in parallel processing and I hope someone can help me out here.
First, I understand that BAPI_TRANSACTION_COMMIT needs to be called after checking RETURN for successful posting message. However, since I call BAPI_ACC_DOCUMENT_POST with STARTING NEW TASK for parallel processing, the RETURN will be collected in the RESPONSE subroutine. Well, here is the dilemma. Based on SAP note 675042, I can not call another FUNCTION or issue COMMIT WORK in the RESPONSE subroutine.
Has anyone encountered the same issue and had it resolved? Any idea or this simply CAN NOT be done?
Kuo-Hsiung Huang
2012 Jan 26 9:34 PM
I did that some time ago, if I remember correctly I wrapped the call to BAPI_ACC_DOCUMENT_POST, some long text handling and a final COMMIT WORK into a remote-enabled Z-function module and called that one STARTING NEW TASK.
Worked well, nice to see 15 dialog processes working hard to post your stuff
Thomas
2012 Jan 26 9:34 PM
I did that some time ago, if I remember correctly I wrapped the call to BAPI_ACC_DOCUMENT_POST, some long text handling and a final COMMIT WORK into a remote-enabled Z-function module and called that one STARTING NEW TASK.
Worked well, nice to see 15 dialog processes working hard to post your stuff
Thomas
2012 Jan 27 11:32 AM
Hi Kuo
Other possibility is use ARFC technique and create your own queue
Best regards
2012 Jan 27 11:57 AM
Or:
have a global variable and set it to X or some flag in the return procedure.
outside the FM call,
wait until gv_flag = X.
then program waits till the gv_flag is set.. and you are setting this in the return module.. once it reaches the correct flag value. your next line would be the commit work.
2012 Jan 27 11:59 AM
Hello Kuo,
I think you can wrap the BAPI calls in a custom RFC & call this RFC asynchronously as mentioned by Thomas. Also you can try using the WAIT UNTIL command & issue the COMMIT outside of the callback procedure.
* Call the Accounting doc posting BAPI asynchronously
CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST' STARTING NEW TASK 'DOC_POST'
PERFORMING f_read_bapiret ON END OF TASK.
***Your code which can run independent of the bapi result***
* Program waits for the callback procedure to be executed
WAIT UNTIL gv_callback = 'X'.
IF gv_error = `X`.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ELSE.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
ENDIF.
*&---------------------------------------------------------------------*
*& Form f_read_bapiret
*&---------------------------------------------------------------------*
FORM f_read_bapiret USING task_id TYPE clike.
* RECEIVE results from the asynch-RFC(aRFC)
* Read BAPIRET & check error message
READ TABLE gt_bapiret WITH KEY type = `E`.
IF sy-subrc = 0.
* Set the callback flag
gv_callback = `X`.
gv_error = `X`.
RETURN.
ENDIF.
* Set the callback flag
gv_callback = `X`.
ENDFORM. "f_read_bapiret
BR,
Suhas
2012 Jan 27 12:37 PM
Does this really work? At the time when GV_CALLBACK is evaluated, we are no longer in the parallel phase, so how would the process know which one of the tasks should be rolled back or commited?
I might be missing an important bit, then please help me
Thomas
2012 Jan 27 1:30 PM
if the bapi has error but i still commit, whats the problem? any ways the doc wont be posted .. right?
but yes, if it has chained updated then yours would be a considerable case i think
2012 Jan 27 2:06 PM
Thanks for all the responses! Look like it's doable and there are options. I will give it a try and mark this thread as answered when a positive result is achieved.
Kuo-Hsiung
2012 Jan 27 3:27 PM
> At the time when GV_CALLBACK is evaluated, we are no longer in the parallel phase, so how would the process know which one of the tasks should be rolled back or commited?
Hello Thomas,
I suppose the OP is calling only one task(BAPI_ACC_DOCUMENT_POST) asynchronously, please correct me if i'm wrong
So when the program flow reaches the WAIT UNTIL log_expr statement (and finds the logical exp to be false) it'll wait for the execution of the call-back procedure & once completed it'll check the value again.
To be honest, i think the use of the flag GV_CALLBACK is redundant! Once callback routines of all aRFCs(which i suppose to be one in this case) have been executed, the program resumes after the WAIT statement.
Let me know if you think i'm misinterpreting something. Meanwhile let me cook-up a demo program to satiate our curiosity.
I get your point, Thomas. We're COMMIT'ing in a separate session than the one in which the aRFC was called. Theoritically(logically as well) this should not work, my bad!
@Kuo: I'm pretty sure the solution involving WAIT UNTIL won't work for reasons mentioned above. Try implementing the solution proposed by TZ!
BR,
Suhas
Cheers,
Suhas
Edited by: Suhas Saha on Jan 27, 2012 9:03 PM
2012 Jan 27 3:38 PM
I was assuming multiple tasks being started and running in parallel, in (available minus reserved) dialog processes...thinking that this is what our OP is up to. We will find out
Thomas
2012 Jan 27 3:59 PM
Hello Thomas,
What do you think about my previous commentt?
BR,
Suhas
2012 Jan 27 5:56 PM
It's a success! TZ's solution works perfectly. It's easy and straight forward. Thank you, Thomas.
In addition, I do want to thank everyone as well for all the responses. This is truly a community that gets things done.
Kuo-Hsiung Huang