Tab Page Programming Exits 

Use

You can enter programming exits on this tab page. A programming exit is an ABAP class that the system executes at a specific time during the processing of a workflow. Programming exits enable you to implement your own enhancements and adaptations.

ABAP classes that you use as programming exits must not use the following elements:

●      COMMIT WORK

●      ROLLBACK WORK

●      Calling of function module DB_COMMIT

●      Any type of RFC calls

●      Any changes to a system element in the container

For performance reasons, SAP recommends that you only execute database selections that are entirely necessary.

Features

ABAP classes that you use as programming exits must implement particular interfaces. The system executes the classes in the specified order.

Depending on the implemented interface, the system executes the ABAP classes at different times during the processing of the workflow. The following table shows the different interfaces and the corresponding execution times:

Interface	Execution Time
IF_SWF_IFS_WF_CONSTRUCTOR	The system executes the method WF_CONSTRUCTOR prior to executing the workflow
IF_SWF_IFS_WF_DESTRUCTOR	The system executes the method WF_DESTRUCTOR when the relevant workflow work item has the status complete or logically deleted
IF_SWF_IFS_WORKITEM_EXIT	The system executes the method EVENT_RAISED when the status of the relevant workflow work item changes as defined in the interface

 

Container Access

To work with the container in an ABAP class, you have to include the include files <CNTN02> and <CNTN03>.

See also: Macro Instructions for Processing a Container

Dealing with Exceptions

For ABAP classes that implement the interface IF_SWF_IFS_WORKITEM_EXIT, in the method EVENT_RAISED you can raise an exception of the class CX_SWF_IFS_WORKITEM_EXIT_ERROR.

If an exception is raised, the relevant work item and workflow are given the status Error. Once you have corrected the error, you must trigger the continued processing of the workflow in transaction SWPR. Dialog work items are given the status Ready and are executed again.

You can define a T100 message for the exception (transaction SE91). If the exception occurs, the system writes the message to the workflow log.

The following table contains details about how to deal with exceptions depending on when exactly they occur.

When Exception is Raised	How the Error is Handled
When creating a workflow (BEF_CREATE and CREATED)	The workflow is not created. A workflow started manually by the user reports the error to the user. In workflows that are started by a start event, the error is visible in the event log.
When a workflow is being executed	The current work item and the workflow are given the status Error. If the current work item is not available in the database, the workflow log records the error for the preceding step.
When a work item is being processed (for example, forwarded, accepted, retained, set to completed, or undergoing a status change)	The changes are reset and the relevant function module returns an error.
When the status is being changed to Error or Completed.	The workflow log records the exception; otherwise it is ignored. Therefore, do not raise exceptions for the event STATE_CHG in programming exits. However, the programming exit can write an entry to the workflow log when you use the work item context.

 

Example

The following table shows examples of ABAP classes that implement the named interfaces:

Interface	ABAP class
IF_SWF_IFS_WORKITEM_EXIT	CL_SWH_WORKITEM_EXIT
IF_SWF_IFS_WF_CONSTRUCTOR IF_SWF_IFS_WF_DESTRUCTOR	CL_SWF_IFS_WF_EXITS (used as a constructor and destructor)

 

Another example of a programming exit can be found in the SAP Workflow Processing a Notification of Absence (AF_APPROVE, WS30000015). This realizes a process info system.

To call the process info system, choose Tools ® Business Workflow ® Development ® Demo ® Work Item Exits ® Process Info System.