Sales Document Locking

[Former Member]

Hello everybody

A little question,

We've made a BAPI to lock a sales document, we're using ENQUEUE_EVVBAKE for this locking.

When we test the BAPI, we enter the BAPIname in SE37, press F8, then we enter the ordernumber in the parameter field, and run it.

In a new session, we check with va02 to see if the order we entered is, in fact, locked. And it is.

However, when we press F3 in the BAPI-execution session, until we get back to the SE37 screen, and check the other session (on va02) again, the order is NOT locked anymore.

This is a problem, since we are using this BAPI as an RFC. It returns succesfully with a "order number xxx has been succesfully locked" message. But when we check in SAP with va02, it's NOT locked.

Is this normal behaviour of the ENQUEUE_EVVBAKE function?

If it is, does any of you know of another function that does keep the sales document locked until we execute a function that unlocks the document?

Thanks in advance.

Tim.

<b>Edit: I have found documentation in the SAP Help about this transaction locking mechanism. And it says right there, that the lock ends with the transaction.

So now, my question has turned into this one:

How does one lock a sales document, until you can programmatically tell SAP to unlock it?</b>

Message was edited by: Tim Schraepen

[Former Member]

Hi Tim,

I should think that this is standard behaviour. At the end of the program, all the locks that were issued will get released automatically. And if it were not the case, then imagine what would happen if you have forgootten to give issue the DEQUEUE at the appropriate point. Then the document will be locked forever!!

When you hit F8 on the Function module, the moment you get the result, the transaction isactually completed. Hitting the BACK button is not a part of the BAPI execution anymore.

So you can go ahead with your BAPI and test it wil the RFC. You should not encounter any problems is what I think. But in case you do, then please do get back.

Regards,

Anand Mandalika.

[Former Member]

Thanks for replying so quickly.

Please check my "edit" of the original message I posted.

By the way, we're using SAP 4.6c at our company. Maybe the transaction-method is slightly different in yours, because we DO need to hit back, until we're back to the SE37 screen. Even if the function already returned the result.

[nishanthbhandar]

Sorry,Tim.The locking concept in SAP works using lock objects.These lock objects are released once the program execution is complete.This means that as soon as you do F8 on the BAPI the execution is complete and the lock is removed from the order that you had locked in the program.There is no particular way of handling this programmatically except if the process invloves any database updates.See below info on the duration of locks.

Lock Duration

When you set a lock, you should bear in mind that if it remains set for a long time, the availability of the object to other transactions is reduced. Whether or not this is acceptable depends on the nature of the task your program is performing.

Remember in particular that setting too many shared locks without good reason can have a considerable effect on programs that work with database tables. If several programs running concurrently all set a shared lock for the same application object in the system, it can make it almost impossible to set an exclusive lock, since the program that needs to set that lock will be unable to find any time when there are no locks at all set for that object. Conversely, a single exclusive lock prevents all other programs from reading the locked object.

At the end of an SAP LUW, you should release all locks. This either happens automatically during the database update, or explicitly, when you call the corresponding dequeue function module. Locks that are not linked to a database update are released at the end of the SAP transaction.

Cheers

Nishanth

Message was edited by: Nishanth Bhandar

[Former Member]

Hello Tim,

The concept of a transaction <i>cannot be different</i> from system to system. If that were the case, then you simply can't imagine what the results would be!!

The SE37 transaction just gives you an idea to test the function module. We cannot defer he completion of the transaction / program till we reach the initial screen here.

I'm sure that you will be using the BAPI in your program at some point, right ? So why don't you write the program and test it ? Come back with any problems that you might face at that stage.

Regards,

Anand Mandalika.

[Former Member]

> Hello Tim,

>

> I'm sure that you will be using the BAPI in your

> program at some point, right ? So why don't you write

> the program and test it ? Come back with any problems

> that you might face at that stage.

>

> Regards,

> Anand Mandalika.

Anand, this is what I already wrote in my first post:

<i>This is a problem, since we are using this BAPI as an RFC. It returns succesfully with a "order number xxx has been succesfully locked" message. But when we check in SAP with va02, it's NOT locked.</i>

We already have the program that executes the RFC, and it's there that we noticed the issue.

When investigating it further (by using SE37 to test the BAPI), I noticed this locking-functionality.

We get the "Order number xxx has been succesfully locked" message, but ofcourse, when the RFC is done, the transaction is also done, and this is undesirable behaviour in our workflow.

Is there a way to keep the transaction "alive" with the RFC? This would probably solve our problem entirely.

Again thanks for the quick replies, I'm amazed by the responsiveness.

[Former Member]

Hi Tim,

If I understand it correctly, then what you are trying to do is not really the right way to do it.

When you say a BAPI, it should encapsulate the entire functionality for a single business transaction (which includes lock handling).

So, you cannot have one BAPI for doing the ENQUEUE which you will actually call in a remote system and then may be use some other BAPI for doing the update and finally use something else to DEQUEUE.

So for all this while, you want the object to be locked. That is not possible. You should redesign your BAPI in such a way that it handles everything -

1. There needs to be a single BAPI which you are going to call in the remote system.

2. There would be a call to the ENQUEUE within this BAPI.

3. You might want to do some updates.

4. You issue the DEQUEUE call to unlock the objects.

Hope I have been able to understand your problem correctly.

Regards,

Anand Mandalika.

[nishanthbhandar]

Hi Tim...As explained earlier the lock would disappear once the Logical Unit of Work is complete.If you are using the BAPI solely for the purpose of locking then it is not a good approach.Better try and place this in your program rather than using a BAPI.

Cheers

Nishanth

[Former Member]

> Hi Tim,

>

> If I understand it correctly, then what you are

> trying to do is not really the right way to do it.

>

> When you say a BAPI, it should encapsulate the entire

> functionality for a single business transaction

> (which includes lock handling).

>

> So, you cannot have one BAPI for doing the ENQUEUE

> which you will actually call in a remote system and

> then may be use some other BAPI for doing the update

> and finally use something else to DEQUEUE.

>

> So for all this while, you want the object to be

> locked. That is not possible. You should redesign

> your BAPI in such a way that it handles everything -

>

>

> 1. There needs to be a single BAPI which you are

> going to call in the remote system.

> 2. There would be a call to the ENQUEUE within this

> BAPI.

> 3. You might want to do some updates.

> 4. You issue the DEQUEUE call to unlock the objects.

>

> Hope I have been able to understand your problem

> correctly.

>

> Regards,

> Anand Mandalika.

Thanks, I understand now.

We were using the BAPI incorrectly.

I thought BAPI = RFC.

But let met get this straight now, what you suggest is this:

We create one single BAPI (procedure), and in it, are different functions or subroutines, which are called remotely through RFC.

We make these functions of the BAPI(2 different ones in our case, one for locking and another for unlocking, we won't going to be doing any updates) known to the Business Connector, so we can use them.

And that's it?

Here's some background information to make sure we're talking about the same thing:

We are indeed solely using the BAPI for the purpose of locking the Sales Document.

The idea is this:

Another application needs to be sure nothing is changed to an order, for a certain period (until the other application thinks it's safe to continue, and with safe I mean having consistent data).

So what we have right now is an EAI system that interfaces the other application with SAP. We would use a BAPI we created as an RFC procedure to lock a sales order, whenever an instruction is given from the other application. And afterwards, when we get the instruction to unlock the order from the other app, we would unlock that order in SAP.

And so now, we've bumped into this issue with the ENQUEUE_xxx procedure, because it wasn't made for that purpose.

Instead we're now supposed to create one bapi, with one enqueue function, and one dequeue function. And then make RFC's to these separate functions when the other app sends the instruction.

[Former Member]

Hello Tim,

A long time after your question, but I had the same issue. The thing is that this is possible but you may not release the JCO client immediatly after getting it. This is done in all standard examples and is also recommendedIf you keep the JCO client and release it manually after you are finished, your lock stays as long as you do not release the JCO connection.

from the JCO tutorial:

...

As long as our application is stateless – as far as SAP is concerned – we will always

release the connection back to the pool as soon as we have finished with the SAP calls

connected to one activity. Not necessarily after each SAP call, though. In other words, if

you need to call multiple RFMs in a sequence, uninterrupted by user or other external

interaction, you should keep the connection11, and return it after all your calls are done.

For a discussion of SAP state and commit handling, see Appendix A-5 on BAPIs, State,

and Commit.

Kind Regards

Koen Van Loocke

[Former Member]

Koen

Thanks for your reply.

It was very helpful.

Since we are calling the BAPI when we receive a message (through a messaging system) to lock the document, and we receive another message for unlocking the document, we will need to build an object that keeps the connection open until the unlocking message was received.

I'm sure we can work things out like this.

Thanks again everybody!