1. What is this all about?
I found some interesting facts behind the workflow event mechanism. Why should an open SQL statement “COMMIT WORK” should be defined/included after event is raised through ABAP program or from a Webdynpro component etc?
Then, found the answer that it’s because of the way workflow handles its calls through tRFC (transactional Remote Function Call) mechanism.
SAP Says…
“The workflow runtime system always executes its tRFC (transactional RFC) calls on the logical destination WORKFLOW_LOCAL_xxx (xxx stands for the three-digit number of the client).”
The above logical destination can be observed from the transaction SM59 under logical destinations folder. The logical destination will be created automatically, when you execute the activity configure RFC destination from SWU3 transaction. A background user WF-BACTH user will be assigned to the logical destination
The logical destination is client specific. So, make sure this activity has to be executed explicitly on each client.
2. Brief background about tRFC (transactional Remote Function Call)
The term “transactional” implies that the call to the function module is treated with Atomicity Property i.e. either whole transaction would be executed or if any failure occurred during the execution of the transaction then nothing is executed.
2.1 Significant notes about tRFC
2.2 How tRFC Calls are handled?
3. Coming Back to Workflow Event Linkage Mechanism
When a workflow has to act like a receiver after creation or specific changes done to the Business objects (Sales Order, Leave Request, Purchase Order etc...). For this, the respective business object and event needs to be activated. This activation is defined in the transaction SWE2. While configuring the event linkage you have the option of defining Receiver Function Module, Check Function Module and Receiver Type Function Module. When an event is raised through ABAP Programs by using SAP_WAPI_CREATE_EVENT or the Event class the following steps are executed in below sequence.
Since the asynchronous RFC for calling the receiver function module is not triggered until after the next COMMIT WORK, you must initiate the command COMMIT WORK in your application after the method for creating an event is called in order for the events to actually be created. The database commit performed automatically with a screen change does not trigger the asynchronous RFC.
3.1 How it works?
Consider a scenario where you try to raise an event either by using SAP_WAPI_CREATE_EVENT the following actions are performed in the background.
The call of the function module is as follows:
Conflicts in V1 update Mechanism.
SAP Says…
“During the processing of an update function module in the update work process, the statements SUBMIT, CALL DIALOG, CALL SCREEN, CALL TRANSACTION, COMMIT WORK, and ROLLBACK WORK, as well as all other statements that create a database commit, must not be executed.”
The event cannot be raised in update function module, because an explicit commit work is already executed to start the Update task and again in order to raise a workflow event, we should need another more commit work inside the update function module, to register and call the receiver function module in the respective logical system, which conflicts with the above statement.
This could be one of the reasons why the raising event of workflow is not done in update task. Instead most of the programming guidelines suggest that the workflow event raising should happen before the end of transaction.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 |