When does Business Object event gets triggered ?

[Sandra_Rossi]

Hi Experts,

Would like to know when exactly the business object events get triggered. Is it before database COMMIT or after database COMMIT. If there is any FM associated with this FM, does it get executed in same LUW or separate LUW ? Also can we use COMMIT WORK inside this new FM.

[Sandra_Rossi]

I see that you ask many questions to try understanding how things work around COMMIT WORK, LUW, tRFC, update tasks. I suggest that you do tests by yourself and see what happens. You only need to create little programs. Use a SQL trace too. And read the ABAP documentation to understand the concepts.

[bpawanchand]

Hi,

Well, to monitor the events within the system you need to activate the event trace by using SWELS and you can check the in SWEL transaction.

Every workflow event is triggered before COMMIT WORK. To put in other way workflow events are committed and fired in the system only after the COMMIT WORK statement. All the updates associated with LUW are committed or completed upon or after COMMIT WORK statement and my understanding is that the LUW gets completed.

May I know, what exactly you are looking for?

Thanks

Pavan

[kjyothiraditya]

Hi Pavan,

Thanks for explaining. I have to trigger an idoc immediately whenever an order ( pm notification) gets created or changed. I have found some customer exits like qqma*, but not sure if we can use that as the data could be changed in later stages. Also it is for check before save. I have checked in swel, but no log is there.

i am thinking to link it with business object event which trigger FM where i put in my IDoc building. So wanted to know if in such case the event execution/trigger happens before commit work of std transaction or after commit work.

[kjyothiraditya]

hi,

when i linked event with fm, no event in swel.

i have manually triggered event using fm sww*event*create* in my badi, and now i could see an event in swel. but the linked fm was not triggered.

i have to achieve this functionality https://answers.sap.com/questions/11812826/trigger-idoc-when-saving-or-changing-service-order.html

[bpawanchand]

Hi Aditya,

Did you write COMMIT WORK after calling the function module SWE_EVENT_CREATE ?

Regards

Pavan

[kjyothiraditya]

Hi Pavan,

No, I have raised an event in a badi of STD transaction just before commit work. The commit work was raised from STD program.

[anjan_paul]

Hi,

Also check fm SWE_EVENT_CREATE_IN_UPD_TASK .

Thanks

[bpawanchand]

Hi ,

Either you need to write the commit work statement immediately after calling the SWE_EVENT_CREATE or the other possibility is to call this function module by using the addition IN UPDATE TASK of CALL FUNCTION. So that as soon as the commit work is executed by standard program the event is triggered.

Regards

Pavan

[Sandra_Rossi]

SWE_EVENT_CREATE cannot be called directly in update task, instead use:

CALL FUNCTION 'SWE_EVENT_CREATE_IN_UPD_TASK' IN UPDATE TASK ...

[bpawanchand]

Thanks Sandra Rossi. Can you please elaborate ?

[Sandra_Rossi]

SWE_EVENT_CREATE is not an update function module, you can't call it directly in update task, you need a "wrapper".

[kjyothiraditya]

Hi Sandra,

I have used object linking and raised event in UPD mode. The event is now getting raised and the associated FM is also getting executed. But as I am triggering Idoc in Update mode, and in that again we would be having COMMIT WORK, would this pose a problem ? Right now we dont have any error messages. But if Idoc generation fails, what would be impact on other updates ?

Also i think this will run as V1 update, anyway we can make this as V2 ? Does 'start with delay' make this V2 ?

[kjyothiraditya]

I have used object linking and raised event in UPD mode. The event is now getting raised and the associated FM is also getting executed. But as I am triggering Idoc in Update mode, and in that again we would be having COMMIT WORK, would this pose a problem ? Right now we dont have any error messages. But if Idoc generation fails, what would be impact on other updates ?

Also i think this will run as V1 update, anyway we can make this as V2 ? Does 'start with delay' make this V2 ?

[Sandra_Rossi]

Using COMMIT WORK inside an update task will trigger a short dump (it doesn't make sense to use COMMIT WORK again because the update task is triggered by COMMIT WORK). So, just create and process the IDoc inside the update task (don't run it in "another" update task, that wouldn't work anyway), no need of using COMMIT WORK. IDoc is processed via RFC. Yes, V2 = start with delay, but why do you want to make it V2? (it's for logs and so on, whose failures would lead to database integrity errors which are considered as tolerable)

[kjyothiraditya]

Hi, Yes in update task i am using SUBMIT PROG_CREATE_IDOC AND RETURN which created the idoc and if i use COMMIT WORK in the same program, it is not giving any error. So do u think it is a good idea to use COMMIT WORK there ?