Application Development 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: 

Call BAPI_ACC_DOCUMENT_POST in parallel processing - is this possible?

Former Member
0 Kudos
2,186

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

1 ACCEPTED SOLUTION

ThomasZloch
Active Contributor
0 Kudos
612

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

11 REPLIES 11

ThomasZloch
Active Contributor
0 Kudos
613

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

former_member214857
Contributor
0 Kudos
612

Hi Kuo

Other possibility is use ARFC technique and create your own queue

Best regards

Former Member
0 Kudos
612

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.

SuhaSaha
Advisor
Advisor
0 Kudos
612

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

0 Kudos
612

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

Former Member
0 Kudos
612

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

Former Member
0 Kudos
612

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

0 Kudos
612

> 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

0 Kudos
612

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

0 Kudos
612

Hello Thomas,

What do you think about my previous commentt?

BR,

Suhas

Former Member
0 Kudos
612

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