Skip to Content
avatar image
Former Member


In a .net program, according to the messages returned from SAP, I am getting a Purchase Order created using BAPI_PO_CREATE1. In fact every time I execute, I get a new next higher number PO. That seems to be working fine.

Also, Immediately after the BAPI returns to my .net program I am then executing BAPI_TRANSACTION_COMMIT.

However when I look in SAP, the PO does not exist.

The RETURN structure from the BAPI_TRANSACTION_COMMIT is initial. So there are no errors there.

I've tried this with the same results for both WAIT = X and WAIT defaulting in BAPI_TRANSACTION_COMMIT.

Is there a special place in the process where this BAPI_TRANSACTION_COMMIT should be called? I "assumed" immediately after the CREATE PO BAPI is called would have been the correct time and place.

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

4 Answers

  • Best Answer
    Apr 15, 2012 at 06:58 AM

    Hi Wardell,

    If I am getting your question correctly , its a two step process. first u call bapi PO to create PO then

    u call BAPI_TRANSACTION_COMMIT to commit work.

    After the first step when the call returns back to .net program , the data of buffer in sap got refreshed and when u call commit in second step , there is no data in buffer to write to database.

    if u want to achieve this functionality then u have to write a customer RFC , in which u call PO bapi then u call BAPI_TRANSACTION_COMMIT. Now call this RFC in ur .net program.

    Many Thanks,


    Add comment
    10|10000 characters needed characters exceeded

  • Apr 15, 2012 at 06:41 AM


    What are the messages that you receive in the return table of the bapi 'BAPI_PO_CREATE1'?

    Check the import parameter 'TESTRUN', this parameter must be blank inorder to create the PO.



    Add comment
    10|10000 characters needed characters exceeded

  • Apr 15, 2012 at 07:07 PM

    Hi Wardell,

    From my experience using external calls to BAPI's that need commit, here's how I managed to solve that problem:

    1. I created a Z copy of the original BAPI;
    2. The Z_BAPI calls the original BAPI and BAPI_TRANSACTON_COMMIT at the end;

    And that's it! Of course I'm not very proud with this solution, but it works. Another solution would be using an implicit enhancement point of the original BAPI (at the end) and test the session parameters (user, user type, etc) in order to decide wheter or not call BAPI_TRANSACTON_COMMIT - it works too!



    Add comment
    10|10000 characters needed characters exceeded

    • Former Member
      All, Thanks to everyone for their replies. However I was able to find the solution. The solution was to wrap the BAPI_PO_CREATE1 function object into a Transaction object, then commit the transaaction after calling the BAPI to create the PO. I ended up NOT calling Commit BAPI (at least not explicitly). C# code snippet follows: ........... RfcTransaction transaction = new RfcTransaction(); //Create a transaction object transaction.AddFunction(function); //Add BAPI_PO_CREATE to the transaction object ........... RfcSessionManager.BeginContext(destination); //Begin the transaction function.Invoke(destination); //Call BAPI_PO_CREATE transaction.Commit(destination); //Transaction object RfcSessionManager.EndContext(destination); //End the transaction ........
  • Apr 22 at 07:39 PM

    Creating a custom RFC with built-in commit is not the right approach for this problem: you're doing server-side ABAP changes while the issue is with the C# client needing to call the stateful BAPI RFC in the same context as the commit call so that the right LUW is understood by SAP to complete. Often client side programmers don't have dev access to SAP server to change or add to RFCs. The problem is that by default the connection is stateless, the BAPI RFC is never matched with the commit and vice versa. The commit returns a dummy success that just indicates that SAP committed the default empty transaction. Instead the two calls needs to be bound together. The approach of using an RfcTransaction object for that is correct. Another approach may be to pin the context on the RfcDestination with BeginContext, then call the BAPI RFC, then explicitly call the BAPI COMMIT, then optionally call EndContext (will work without but nicer to JCo / Nco to allow clean up of the contexts it keeps track of).

    Markus Tolksdorf did I get this right?

    Add comment
    10|10000 characters needed characters exceeded

    • Using an RfcTransaction implies that it is executed as asynchronous request and the application will not get response parameters. Hence, if a synchronous processing is desired, using RfcSessionManager.BeginContext/JCoContext.begin to start a stateful sequence in which both the BAPI and BAPI_TRANSACTION_COMMIT are invoked, is the only valid approach. Hence, you got this right, but I am not considering the RfcSessionManager.EndContext/JCoContext.end optionally, because if not using them you would delay the release of backend resources to the point in time the session is finalized on the connector side and this all open connection associated with this session are released. Good coding style will release resources as early as possible.

      Best regards,