Skip to Content
author's profile photo Former Member
Former Member

Commit work after 'SWE_EVENT_CREATE'

hello frineds,

can any one of u tell me why we use commit work after the FM "SWE_EVENT_CREATE"?

some of the times my workflow was not triggering but when I used COmmit work it triggered.

but i am not getttng the significance of using the commit work.



Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Feb 14, 2008 at 06:41 AM

    Hi Romanch,

    Alternatively, you can use the function module 'SAP_WAPI_CREATE_EVENT' to publish an event. If you use the above said function module, then you will not require to enter 'commit work' after the FM is called.

    Hope this was of some help. Please award points if hint was useful.



    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member


      One thing keep in mind that, you should not use COMMIT WORK if you are trigerring the workflow into user exit or BADI or BTE. Since these are the enhancement techniques and the end of the user exit or BADI or BTE system always use COMMIT WORK we should not use in between.

      Please some reward point is useful.


      Prashant Raichurkar

  • Posted on Feb 14, 2008 at 06:25 AM


    Since the asynchronous RFC for calling the receiver function module is not triggered until after the next COMMIT WORK , you must initiate the command COMMIT WORK in your application after the function module for creating an event is called in order for the events to actually be created.

    The database commit performed automatically with a screen change does not trigger the asynchronous RFC.



    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Feb 23, 2008 at 03:46 PM

    Hello Romanch,

    the reason for the commit work to trigger a workflow event results from the business need that workflows should only run if an business situation was really reached.

    If you for example have an event for "entering new material" which is supposed to trigger a workflow informing other users to add data, check data. You first start the application (MM01 if i remember correctly) and fill the data. Then you save. The application writes things to the database, calls the function module for raising the event and at the very end the application makes a commit work to finalize the new data in the data base. Only when this happens the material was really entered and the event shall publish this to the workflow. If anything goes wrong the application will rollback everything and the event must not be raised. That's why a commit work is usually needed for the event else an event could be raised for a business object never written to database.

    But of course you are not supposed to write 'COMMIT WORK' after calling the function module. This would interfere with the application LUW handling. The commit should be called from the application whereever it is needed for ending its LUW.

    But the trouble seems to be that SAP is an developing/changing system so some new stategies of LUW handling were introduced to different modules but the workflow development does not keep up with this developments.

    The last change was introducing classes in workflow but this implementation was done 3 or more releses back in past and still it is far away from working properly. I needed some bugs fixed for module development and it took months to get the fixes. Other things are no longer changed, answer on bug report: "might be a bug, but system behaves that way since 3.1H so we won't do anything".

    That is quite sad as workflows really have potetial to improve systems and processes. But this situation will not change so it leaves you with the following options:

    - call the function module for the event w/o writing commit directly after it and trust in the applications that they set their COMMIT WORK correctly

    - write commit work after the function module and risk to crash the applications LUW handling

    - use the function modules allowing to raise the event w/o having a commit work (usually this can be set with a parameter). this might result in workflows running for objects not created / changed etc. in rare cases but you can cover that by existence checks in the workflows if necessary

    Best regards

    Roman Weise

    "Currently celebrating not getting the bug in <CNTN02> and <CNTN03> fixed as promised by workflow development for 5 years"

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.