Skip to Content

Any way besides code modification to get around total lock dequeue programming by SAP?

I have a large RFC enabled function module that creates BOM's, routing's, and documents for configured materials after the create sales process is done. Recently I ran into a chicken and egg problem with trapping errors from the process (it's quite lengthy) and we wanted to then have a report kick off from the same process that kicks off the order create RFC.

So I thought that creating a custom lock would do the trick, I created it and it worked ok for a bit, but then the lock would "disappear". I debugged the RFC and what I found out was that some of the SAP programmers merely used DEQUEUE_ALL just to blow away any locks currently set in the current LUW instead of carefully maintaining the code or going through the lock table and marking which ones were already there and then loop through each of them and DEQUEUE them individually.

There were two areas that "bit me" as follows:

1 - Inside FM CSAP_DOC_BOM_CREATE, if certain errors are discovered it does this and also they did this in FM CS_DI_HEADER_OBJECT_CHECK. Thankfully here they had code in place where if you pass an X to an external memory ID before calling CSAP_DOC_BOM_CREATE, it didn't do the DEQUEUE_ALL. What blew my mind was that they did the dequeue before any other locks were created in this case.

2 - In a form called routing_clearbuffer which is called during the commit which is invoked by BAPI_TRANSACTION_COMMIT after I called BAPI_ROUTING_CREATE, they did the same thing except this time there is no guard code and the comments (this is from version 617 SP 8 mind you - pretty recent) they stated that they worked around the issue that they weren't clearing all the locks and thus they did that instead of cleaning up the code and finding all the locks they created or as I said - get the contents of the lock table by the current user ID before more locks are created, then go through and DEQUEUE each one of them one by one leaving the ones that were there before the process.

I'm afraid what I am going to have to do for the 2nd case is to modify the code to not blow away all the locks, I will put in the same type of guard code in that I will only execute it if the external memory ID is set to X and if so I will remove the locks individually.

So what I am asking is that is there a better way to do this? What is happening is that because our custom lock is being removed by these DEQUEUE_ALL's, the report is missing data because it waits for the lock, the lock goes away early, and thus the report doesn't get all the errors.

I also would have expected that the documentation for the BAPI and FM CSAP_DOC_BOM_CREATE would have stated this side effect, but neither of them do. I had to debug the RFC the hard way to figure this all out.

Note - We are on SAP version 617 SP 8 (EHP7) - ABAP version 7.4

Please also note that the current process does work and it does create all of our things that are needed, it's just trapping the errors somewhere besides the CAPI log that is giving us the issue.

Add comment
10|10000 characters needed characters exceeded

  • Sorry, you're right, I had false information about _SYNCHRON for DEQUEUE_ALL. It's not related to your issue at all.

  • I might be missing something but how exactly do you utilize the locking mechanism to "trap the errors"?

    We had a few "process chains" too but used a Z table to track the status and reprocess errors if something failed in the middle of the process.

    As a side note - I think this could be a blog and a fine addition to Michelle's initiative. :)

  • Bruce Hartley Jelena Perfiljeva

    Jalena - I don't use the locking mechanism to trap them, I was using it to try and make sure that all the errors were discovered and properly stored before the report ran. I will look into that initiative as well.

  • Get RSS Feed

4 Answers

  • Best Answer
    Feb 27 at 07:49 AM

    I don't know if your lock is set at the beginning of your RFC-enabled function module and removed at the end, in this case you can do it this way :

    - Lock

    - SUBMIT or RFC NONE to call the function module in a different internal session : DEQUEUE_ALL removes the locks only in the current internal session.

    - Unlock

    Add comment
    10|10000 characters needed characters exceeded

    • Sandra - great reminder! - in my two particular cases, the first one is CSAP_DOC_BOM_CREATE which has it's own commit and then right after BAPI_ROUTING_CREATE I did call BAPI_TRANSACGTION_COMMIT with wait set to 'X'.

  • Feb 27 at 07:26 AM

    Interesting problem. If these are reached from a BAPI as a starting point, it should be supported and I would raise this with OSS. Ask if they are willing to implement the changes you propose, sometimes they can be quite accommodating if you can show this is a reasonable scenario, and especially if it's from a BAPI.

    Otherwise an alternative would be to implement your own 'guard function' to check and re-lock after returning form SAP's code back to yours. Although that does open up a few microseonds for someone else to nab it and change it, but it's a workaround.

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 27 at 01:23 PM

    Mike and Sandra - I will try Sandra's idea first and see how that works. Mike I do agree it should be reported as a bug as well because removing all locks is a very serious side effect in my book and unless it's clearly stated in the FM documentation (which ir's not - I checked and both function modules that the issue is in has documentation), I would think it's a serious problem.

    Sandra - you pretty much described how I have it currently working - the lock is indeed enqueue'd in my RFC and DEQUE'd as well or as you said - lock and unlock in my RFC.

    Thank you both for the replies - much appreciated! I will let you both know how this turns out

    Add comment
    10|10000 characters needed characters exceeded

    • Please prefer using "Comment on this answer" on both of our "answers". The button "submit an answer" is to propose a possible solution. Moreover, there's more chance that people are informed automatically if you comment on their post.
  • Mar 01 at 02:30 PM

    Thank you all for responding - much appreciated! I did implement what Sandra suggested about Destination "NONE" and that did work - the lock did not disappear. I would have to run a few orders to see if the behavior of the function modules still worked the same, especially CSAP_DOC_BOM_CREATE because if you want that to run synchronously (which I did), you have to call it this way:

    In working on this in other rounds of development, I found that if you didn't pass fl_commit_and_wait as "X", you never knew when it was done and you would get into horrid timing problems if you needed the document BOM for other things later on due to the way SAP implemented that function module.

    I will look into Michelle's initiative as well Jelena

    Add comment
    10|10000 characters needed characters exceeded