Skip to Content
2

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

Feb 27 at 07:09 AM

236

avatar image

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.

10 |10000 characters needed characters left characters exceeded

Which _SYNCHRON parameter is passed to DEQUEUE_ALL ? If it's never passed or always false, then you could lock with SCOPE = '1'

1

Sandra - it's never passed in either case, I did lock with SCOPE = '1' and it still is removing my lock

0

In looking in the code to DEQUEUE_ALL, it appears it's passing a '3' when it does the actual work via a CALL statement so I think that means that it is to remove all the locks. I would debug that code as well, but one can't debug SAP system code - the debugger just steps over it even if you hit the "step into" button in the debugger

1

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

0

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. :)

0
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.

0
* Please Login or Register to Answer, Follow or Comment.

4 Answers

Best Answer
Sandra Rossi Feb 27 at 07:49 AM
4

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

Show 3 Share
10 |10000 characters needed characters left characters exceeded

To everyone - I am choosing Sandra's answer as the best answer because it definitely solved the problem of my lock being removed. When I added DESTINATION 'NONE' (see below and sorry I'm not used to the way questions work yet as this is my first one after all the changes were made so that's why it's below), the lock was not deleted. I purposely took a screen shot of the code that worked to illustrate what was done. I am going to close this for now, but what I will eventually do is create a blog post on the subject because there is a lot more to this and I wanted to illustrate what the issue is and how it was ultimately resolved.

1

Note that when calling using RFC NONE, if the function module you call uses some tRFC/qRFC or an update task, then you'll need to follow with a call to BAPI_TRANSACTION_COMMIT in "RFC NONE" otherwise the update task will not be triggered.

0

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'.

0
Mike Pokraka Feb 27 at 07:26 AM
2

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.

Share
10 |10000 characters needed characters left characters exceeded
Bruce Hartley Feb 27 at 01:23 PM
0

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

Show 1 Share
10 |10000 characters needed characters left 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.
0
Bruce Hartley Mar 01 at 02:30 PM
0

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


e41an.png (5.9 kB)
Show 1 Share
10 |10000 characters needed characters left characters exceeded

Thanks for an update, Bruce! If this question is answered then kindly close it (see this blog).

0