Re-Usable Approval Workflow

[Former Member]

This document describes the process to create an Approval Workflow which could be re-used across various processes.

Introduction:

Workflow designing and maintaince is a complicated process and it requires a special set of skills often, the workflows used in corporate scenarios involve approvals and its a very good idea to have all the workflows work in a similar way by following  this approach, new workflows can be rapidly deployed as well as maintaince is very easy with basic abap requirement.

Solution: 

To implement this solution the Workflow is designed using Classes. This helps us to use the OOPS concept of method Over-riding(Redefinition of the implementation of inherited method) to use the same method to perform different functionalities. Each Workflow will be uniquely identified by the Workflow Category.

The Instance id for this Workflow should be as below:

1.     Object Type        --> Main Class Name ( ZCL_WF_APPROVAL )

2.     Object Category  --> “CL”

3.     Object Key         --> Should be as below( Maximum 32 Characters ).

·         1st 4 Characters --> Workflow Category (from a mapping table ZWF_CATEGORY). This is very important as it’s used to determine the class to be used for performing various functions.

·         Next 28 Character is Free text. For ex: In case of FI Documents the key could be  <WF Category><BUKRS><Doc Number><year>

Mapping Table ZWF_CATEGORY:

Mapping table plays a very pivotal role in the design of this Workflow. This table links the Workflow category to the Sub-Class ( Classes derived from ZCL_WF_APPROVAL ). The fields of this table would be as below:

Field Description	Type (text / numeric)	Maximum field length	Value restrictions
Client	CLNT	3	N/A
Workflow Category	CHAR	4	N/A
Description of Workflow Category	CHAR	25	N/A
Class name to be used in the WF	CHAR	30	Should be derived from the WF Class ZCL_WF_APPROVAL

Standard Tasks in the WF:

All the standard tasks that are used in the WF, that have to be re-used should be calling the Method Name of the WF Class as below:

Refer Diagram --> WF Standard Task.png

How re-usability is achieved:

When ever a standard task(implemented using OO ABAP) in a Workflow has to be executed the method "BI_PERSISTENT~FIND_BY_LPOR" of the ABAP Class is called to get an instance. Here, while creating the instance of the class, we create an instance with reference to the Sub-Class rather than the Main Class. The Sub-Class is maintained in the Mapping table via the WF Category.

Refer to attachement "Instance Binding in Standard task.png" for how the binding is done to the Standard Tasks.

The Code is as below:

  DATA:
    lo_wf_appr  TYPE REF TO zcl_wf_approval,
    ls_instance TYPE gty_instance,
    lv_objkey   TYPE swo_typeid.

  DATA:
    lv_type        TYPE classname VALUE 'ZCL_WF_APPROVAL',
    ls_wf_category TYPE zwf_category.

  IF lpor-instid IS NOT INITIAL.

*-  instid is the key of the object
    lv_objkey = lpor-instid.

*   Get the Class Name for the Workflow Category
    SELECT SINGLE *
           FROM zwf_category
           INTO ls_wf_category
           WHERE wfcat = lv_objkey+0(4).
    IF sy-subrc EQ 0.
      lv_type = ls_wf_category-wfcla.
    ENDIF.

    READ TABLE gt_instances WITH KEY objkey = lv_objkey
         INTO ls_instance.
*   If there is no active instance then create it and store in a global table,
*   this would avoid creation of multiple instances for the class
    IF sy-subrc <> 0.
*     Create the Approval Workflow    

      CREATE OBJECT lo_wf_appr        

              TYPE        (lv_type)                                          " This type determines which WF Class has to be called.     

         EXPORTING       

             iv_objkey      = lv_objkey        

             is_wf_category = ls_wf_category.

      ls_instance-objkey   = lv_objkey.
      ls_instance-instance = lo_wf_appr.
      ls_instance-date     = sy-datum.
      ls_instance-time     = sy-uzeit.
      APPEND ls_instance TO gt_instances.
    ENDIF.
    result = ls_instance-instance.
  ENDIF.

Main WF Class:

The main WF Class is created with Interface "IF_WORKFLOW" included. This is required so that the class can be assigned to the Standard Tasks.

Each method in this class can be used to perform a certain activity in the Workflow. Each method can be called in the corresponding Standard task.

Refer attachment "WF Class with required Methods.png".

Steps to be followed for creating a new WorkFlow:

1. 1. Create a new class inheriting from the main WF Class.
2. 2. Create an entry in the Workflow Category class mapping the Category to the Sub-Class.
3. 3. Redefine the methods that need a different functionality for example method "POST_APPROVAL_PROCESS" could have different activities to be done for different functionalities.