Types of Methods in the Workflow Workflow terminology differentiates between synchronous and asynchronous methods.

These methods include the actual ABAP functions and can be provided vi a BOR objects or ABAP Objects classes. Methods are integrated with standard tasks and then used in dialog steps and background steps or called as secondary metho ds. Synchronous methods allow for directly returning export parameters to the calling program, and this program can then evaluate the triggered exceptions. Synchronous methods communicate directly with the calling program. Ideal ly, parameters, events, and exceptions are available after a short wait time. R egard ing content, the most important export parameter should be defined as a result parameter (R E SU LT container element). I f this result parameter refe rs to a DDIC domain with defined values, this method provides good support for the modeling o f workflows. The workflow designer then allows for automatic navigation using the result parameter. Asynchronous methods cannot return export parameters, because the responsibi lity for executing the actual program was handed over to an update task. I f the call ing program o f an asynchronous method receives an exception, it recei ves the exception merely from the synchronous part that tries to configure the update 534 Methods, Work Items, and Events task. Asynchronous methods must receive their results via result parameters from a workflow event. In real life, asynchronous methods are to be expected more frequently th an you might think. For example, i f the user navigates to one o f the modern, mor e com plex transactions (such as MIRO), you usually cannot determine i f the user act ually finished his work simply because he exited the transaction. You theref ore often have to respond to BOR events that are generated by this transaction. Onl y after they have been received can you continue with the workflow processing. While waiting for a terminating event, the calling program o f an asyn chronous method cannot assume that the container elements in the workflow contain correct values. After the event and the corresponding binding have been received, you should use the SWC_REFRESH_OBJECT macro to force the new formatting o f attribu tes and container content. Dialog steps are methods that require a user action. It doesn t matter i f the y were modeled synchronously or asynchronously. I f the method triggers exceptions, y ou have to model a follow-up step for this exception in the workflow. Ifyo u don

't do this, the work item remains in the SAP Business Workplace o f the processing agent in case o f temporaiy errors. System errors set the workflow to the E r r o r status. Background steps are methods that don't require user action, which mea ns they also don't require agent determination. The user who executes background steps is always the internal system user o f the Workflow Engine (WF-BATCH). Again, it doesn't matter i f the underlying methods were modeled synchronously or asy n chronously. I f the method triggers exceptions, you have to model a follow-up step for this exception in the workflow. Ifyo u don't do this, the system attempt s a new execution after some wait time in case o f temporaiy errors. This can be avoided by using a repeat counter. Ifyou model a repeat counter, the step is repeated accordingly. Only afterward d oes the system set the step to the E rror status or continue with a modeled follow -up step. This procedure is implemented by the SWWERRE background job. While a method is processed within the workflow template, it is monitor ed by the work item manager. Deadline monitoring implemented by the SWWDHEX background jo b is also active. You can even define a condition for creating or not 5 4Types of Methods in the Workflow | 4-1 creating a work item. This can be done in the Workflow Builder in the deta ils of a workflow method on the C o n d i t io n s tab.