SAP ABAP Workflow Technology

There are two faces of workflow in R/3. One is the business oriented workflow design as it is taught in universities. This is implemented by the SAP Business Workflow. However, the workflow is also a tool to link transactions easily. It can be used to easily define execution chains of transactions or to trigger user actions without the need to modify the SAP standard code. This can even be achieved without laboriously customising the HR related workflow settings.

Workflow event linkage allows the execution of another program when a transaction finishes.

The workflow event linkage mechanism can be easily used without customising the full workflow scenarios.

This way we use the workflow engine to chain the execution of transaction and circumvent the setup of the SAP Business Workflow.

There are several independent ways to trigger the workflow event linkage.

Workflow in R/3 and Its Use for Development :

SAP R/3 provides a mechanism, called Workflow that allows conditional and unconditional triggering of subsequent transactions from another transaction. This allows you to build up automatic processing sequences without having the need to modify the SAP standard transactions.

The transaction to enter the graphical model, to define the events and objects, and to develop necessary triggering and processing objects is SWO1 (It is an O not a zero).

Fortunately, the underlying mechanism for workflows is less complex as the formal
overhead. Most major transactions will trigger the workflow via SWE_EVENT_CREATE . This will make a call to a workflow handler routine, whose name can usually be customised dynamically and implemented as a function module.

Contrary to what you mostly hear about R/3 workflow, it is relatively easy and mechanical to define a function module as a consecutive action after another routine raised a workflow event.For example, this can be used to call the execution of a transaction after another one has finished.

The whole workflow mechanism is based on a very simple principle. Every workflow enabled transaction will call directly or indirectly the function module during SWE_EVENT_CREATE update.

The function module SWE_EVENT_CREATE will then consult a customising table.
For a simple workflow coupling, the information is found in the table SWETYPECOU . The table will tell the name of the subsequent program to call, either a function module or an object method.

This way of defining the subsequent action is called type coupling because the action depends on the object type of the calling event.

The call to the following event is done with a dynamic function call. This requires that the called function module has a well-defined interface definition. Here you see the call as it is found in SWE_EVENT_CREATE .

CALL FUNCTION typecou-recgetfb " call receiver_type_get_fb

EXPORTING

objtype = typecou-objtype
objkey = objkey
event = event
generic_rectype = typecou-rectype

IMPORTING

rectype = typecou-rectype

TABLES

event_container = event_container

EXCEPTIONS

OTHERS = 1.

Call Function 'CHANGE_POINTERS_READ'