Skip to Content

Cancel workflow via SAP_WAPI_ADM_WORKFLOW_CANCEL leads to implicit commit work


I'm using functional module SAP_WAPI_ADM_WORKFLOW_CANCEL to cancel workflow.

Everything works OK except implicit commit work. It happens inside:


CALL METHOD lh_wfm->cancel( ).


where lh_wfm is an instance of CL_SWF_RUN_WFM class

then CL_SWF_RUN_WFM->cleanup method and CL_SWF_RUN_WFM->save method are called

CL_SWF_RUN_WFM->save method does inside:

CALL METHOD lh_transaction_manager->commit.

commit method does COMMIT CONNECTION (me->m_database_connection).

In my case it's DEFAULT connection and it leads to implicit commit of all data in my transaction even if it's not desired.

I would like to avoid such behavior.

What else I can use outside of WF to cancel it in a consistent and transaction manner (except events and specific handling in each of my workflows)?

I need an immediate workflow cancelation after my transaction commits.

Add a comment
10|10000 characters needed characters exceeded

Related questions

4 Answers

  • Posted on Mar 14 at 09:58 PM

    Hi, Sergei,

    SAP_WAPI_ADM_WORKFLOW_CANCEL has DO_COMMIT input parameter. Did you try setting it to ABAP_FALSE?

    I cannot check right now, but from its name, it looks like it should provide the desired behavior

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Mar 14 at 11:38 PM

    Of course I tried that, do_commit did not pass to the code I mentioned.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Mar 17 at 08:37 AM


    For controlling the canceliing of a workflow I generally use events. Most of my workflows start with a 1:2 fork. In one fork the whole business process and in the other a subflow with all of the wait for event steps which makes the process invalid (delete, change, etc.).

    Kind regards, Rob Dielemans

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Mar 17 at 09:20 AM

    Hi Rob,
    We know about that and we would like to avoid it. Because this approach brings unnecessary routine and complexity to our workflows.
    Also we have some tricky requirements in each WF from certain point it's not possible to cancel it (by the user). Each WF signals about that case depending on the own logic. So it's not a simple global 1:2 fork.
    Also we have complex framework for request processing, each request is tightly linked to own workflow (like in Process and Forms), also we have parent child request relationships in some cases we need to cancel all at once without any delays and undesired consequences (in case of cancelation via different LUW under tRFC in different WPs)
    The best case for us is to cancel all in one transaction and do roll back if something fails

    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.