Synchronous versus Asynchronous

Workflow & Updates

• A synchronous Workflow task must be executed before control is passed to the next step. It is used for tasks that do not involve required updates, because once the workitem is executed, control is passed on to the next step without checking the success or failure of any update that might or might not have taken place.
• An asynchronous Workflow task should be used when a successful update is required prior to control being passed to the next step. The task does not end when it is executed. The task ends when a terminating event is received. The terminating event requires a COMMIT WORK before it is triggered. From the SAP documentation:
  

  When do you define asynchronous methods?
  You define a method as an asynchronous method if you want a task that uses this method to be terminated only via events. The following are possible reasons for defining a method as asynchronous:

  The function within the method uses the update task - The method is terminated by an event generated when the update task is successful. If you nevertheless define the method as a synchronous method under these circumstances, the workflow data may be inconsistent with the current data in the database due to update terminations or delays.

  The method can also be called outside the workflow - If it is possible that a user may call the function encapsulated in the method outside the workflow although the object is also being processed under the control of a workflow at the same time, you should implement the method as an asynchronous method. It is therefore irrelevant whether calling the function takes place inside or outside the workflow system. The workflow continues after the event occurs.

  An asynchronous method with comprehensive functionality is called in the task - This task gets its specific character from the terminating events. e.g., In a task, a specific order is to be released for billing. In the task, call the (general) method Process order and enter the event Billing block deleted as the terminating event.

  It is also to be possible for the task to be terminated by events not necessarily from method processing - The task in which the method Process sales order is executed is also terminated by the event Customer unable to pay.

Dialog Programming & Logical Unit of Work

• Each dialog step in Dialog Programming is a Logical Unit of Work (LUW). A dialog step encompases the PAI of one screen followed by the PBO of the next screen. By default any updates in a dialog step will be committed to the database unless the updates are bundled together via:
  • CALL FUNCTION '<function name>' IN UPDATE TASK
    • Each of these function modules, which are defined as V1 (update with immediate start), will be treated as a single LUW within a transaction and will be committed to the database during the update processing.
    • Any function modules defined as V2 (update with delayed start) will be treated as separate LUWs within a transaction.
  • PERFORM <subroutine name> ON COMMIT
• These two commands have the effect of delaying their own execution until the ABAP command COMMIT WORK (asynchronous i.e., return control back to calling program prior to database commit/roll back) or COMMIT WORK AND WAIT (synchronous i.e., don't return control back to calling program until database commit/roll back) is executed. Since their execution is delayed and control is passed back to the calling program, the entire process is often called an asynchronous process.

Call Transaction

• Synchronous calls are slower but should be used for transactions that are updating the database because control is not passed back to the program until a successful database commit (or rollback) has been executed. Note this the real SQL commit at the database level not the ABAP command COMMIT WORK. Synchronous calls will set the return code (sy-subrc) if an error is encountered. There are actually two synchrounous update modes:
  • 'S', Synchronous update mode makes database entries describing the updates to be done and an update task (potentially running on a different computer) reads those database entries, does the update, and then deletes the entries describing the update task.
  • 'L', Local update mode describes the updates to be done in the memory of the current process. No entries are made in and then deleted from the database describing the update task.
• Asynchronous calls are the default if the UPDATE parameter is not specified. Asynchronous calls do not effect the return code (sy-subrc).
• Note - This is opposite of how synchronous/asynchronous workflow tasks behave, in the sense that control is returned to the workflow in a synchronous step even if there is no commit or rollback encountered!
• Question - Does a synchronous call transaction cause the ABAP to issue a COMMIT WORK AND WAIT command within the transaction?