ABAP Classes in Process Steps 

Use

In process steps you can use methods and attributes of ABAP classes in the same way as methods and attributes of Business Object Repository (BOR) objects. You can call these methods in the process context.

Features

You can use ABAP class methods in process steps in the same way as methods of Business Object Repository objects. These methods may contain dialogs, they can be synchronous or asynchronous, they may appear in the workflow log, and so on.

In general, you can use any method that is implemented as a public method. The method can be implemented in the class itself, in one of the superclasses of the class, or by way of an interface.

The maximum permitted length for methods that are implemented by way of an interface, for example IF_WORKFLOW~FIND_BY_LPOR, is 30 characters. If the method name is too long, you can choose a shorter name for the method by defining an alias. If the method is implemented in the class or in a superclass, the name of the method cannot be longer than 30 characters, so this limitation does not apply.

Parameters

You can assign values from the workflow container to the method parameters. Conversely, export parameters can be entered as workflow container values. The following overview shows how the individual types can be used as parameters:

·        Simple types (string, integer, and so on)

·        Data Dictionary types (structures, tables, complex types)

·        References to objects from the Business Object Repository

·        References to ABAP classes (supporting the IF_WORKFLOW interface)

You can transfer method parameters that represent a persistent object ( IF_WORKFLOW or BOR Object) in the following ways:

·        ABAP classes (with IF_WORKFLOWinterface)

¡        TYPE SIBFLPORB

Object is transferred using the persistent display

¡        TYPE REF TO <Class name>

Object is transferred as object reference

·        BOR objects

¡        TYPE SIBFLPORB

Object is transferred using the persistent display

¡        TYPE SWOTOBJID

Object is transferred using the persistent display; this display is only valid for BOR objects

¡        TYPE SWC_OBJECT

Object is transferred as object reference

Exceptions

The SAP WebFlow Engine can deal with exceptions that are triggered by the methods. It differentiates between application exceptions and temporary exceptions. The two exception categories are differentiated by the exception in the class hierarchy or by naming conventions. In the case of a temporary exception, the SAP WebFlow Engine attempts to execute the method again. In the case of a permanent error the status for the workflow is set to error.

Class-Based Exceptions

To create a temporary exception, you can use, for example, the CX_BO_TEMPORARY class or a corresponding subclass. It can be helpful to trigger an exception for dialog methods when the user cancels the dialog. Here, for example, you could trigger the CX_BO_ACTION_CANCELED exception (subclass of the CX_BO_TEMPORARY class).

Exceptions Not Based on Class

You can also trigger exceptions not based on class. The SAP WebFlow Engine can differentiate between the two exception categories (temporary and permanent) by the name. If the exception begins with TMP or TEMP, it is a temporary exception; otherwise it is a permanent exception.