Getting the vbkey during update task

[Former Member]

Hi,

does anyone know if it´s possible to get the vbkey from table vbhdr of your own update task during the update task.

Any help appreciated.

PS: I tried 'TH_DISPLAY_UPDATE_DATA' but this one seems to me doing nothing.

[christian_wohlfahrt]

Hi Hans-Jürgen!

You can try a dynamical ASSIGN to field VBKEY in report RSM13000.

But this is normally a parameter, which isn't needed. What do you try to do (maybe there is an easier way)?

Regards,

Christian

[Former Member]

Hi,

I have to change an object (cs_order) after it was updated. I do this by using "perform on commmit" in BADI Workorder_update~in_update (I have the ordernumber there).

Problem is that a perform on commit in update task creates not a new LUW. So the order has not been written to DB at this moment. Therefore I start an call function in background task which has to know if the update of the order is completed. I wanted to do this by reading the vbhdr.

I know there are some other possibilities which will fullfill my needs e.g. "Starting a workflow". So the question is a little bit scholastical.

[christian_wohlfahrt]

Hi Hans-Jürgen,

you have to avoid (implizit) commit works in update task. Also call function with new sessions can cause a commit, so your program design is not good.

Did you already try to select the DB in your exit? When your are in the same session, this can be successfull and changes with UPDATE will work, too.

As alternative to workflow is an own change pointer / report workflow possible. Reports can run periodically or be trigger with BP_EVENT_RAISE.

Your BADI isn't document in detail about the commit question, have a look at docu of MB_DOCUMENT_BADI concerning the 'forbidden' actions:

"If this business add-in is not set up properly, it may result in an inconsistency between the documents and the stocks and between the material documents and the accounting documents. Inconsistencies like these may be caused by the following elements in the business add-in:

COMMIT WORK

Remote function call (CALL FUNCTION ... DESTINATION)

Own updates in document tables or stock tables (for example, update in tables MBEW, MARD, MSEG)

The unlocking of data (for example, via DEQUEUE_ALL)

Before the two business add-ins are called up, data is already flagged for the UPDATE. If a COMMIT WORK or a Remote Function Call is transmitted in the enhancement, these are written in the database. If another error occurs after the business add-ins are processed, you cannot carry out a complete ROLL BACK, as the data up to the COMMIT or Remote Function Call has already been written in the database. This can result in an inconsistent status (for example, material document without accounting document), which can only be repaired with considerable cost and effort."

Regards,

Christian

[Former Member]

You are completly right, but I don't use the extension "destination" and so I think its no RFC.

Regards

Hans-Jürgen

[Former Member]

One possible work around would be using the below logic.

Inseide your called function module set

do

enddo loop.

Inside this loop use Function Module ENQUEUE_READ to get a status of the lock(of course you need to pass the right input values to the FM) .If there is no lock then logically the previous LUW is commited.Hence come out from this do .. enddo and code your logic.

[christian_wohlfahrt]

Hi!

@Sekar: the exit of Hans-Juergen is in update task -> he will hold the lock and so a wait cannot help to end current lock.

@Hans-Juergen: could you use a dynamical assign? I couldn't find any hint, if my first proposal was of any help to you.

Regarding our 'of-topic' discussion: looks like a call function .. in background does not cause a commit - on contrary it is triggered by the next commit work. And here I'm wondering, when will this be. At the end of all update booking, at the end of this update part,...?

And will the current VBHDR entry be deleted before your background task can access this line?

Maybe a wrong question, of course you can forward your information with the call function, probably you just want to wait -> here Sekar's tip can come into use.

Regards,

Christian

[Former Member]

Hi Christian,

I dont' know what you meant when you told about a dynamical assign on VBKEY in RSM13000. I don't want to modify anything especially not RSM13000 ;-). How could I do a dynamical assign and pass the value to my FM. Did you mean - assign RSM13000(VBKEYID) to . I didn't try till yet. The commit work will be raised implicit on the end of the LUW. It's always needed for DB to commit the data and to clear the rollback segment.

I will try your suggestions later

and if it works reward you the points.

Thanks,

Hans-Jürgen

[Former Member]

I meant wait statement is in out side update task Fm.

some thing like this.

In side Up date task FM

place this code block.

{

Call FM XX starting new task 'NEW'.

}

FM XX will have the the code for enque_read and wait statements.

[christian_wohlfahrt]

Hi!

Thanks Sekar, I was too much concentrated in finding something inside update task, so I didn't understand you design immediately.

Hans-Jürgen, it is possible to change variables with a dynamical assign, but not necessary. Just create the pointer and use - but not change! - the vbkey.

Regards,

Christian