The Application Life Cycle

Owned by Charles Evans (Unlicensed)
Last updated: Jul 21, 2020 by Adam Miles
6 min read

This explanation describes the FAB process flow and how it interfaces with ABAP and the SAP database.

It is a walkthrough of the most often traversed path taken during the FAB development process.  

During the development of a FAB application, there is both front end and backend development.

The front end development involves creating a form using the Create icon on the FAB Workbench.

The backend development is achieved using ABAP code that you provide within each of your FAB forms by way of an Implementation Class.

FAB provides the superclass with many ABAP methods for redefinition.

From any of these methods, the developer is free to branch out into their own ABAP code to cover their specific business scenarios.

Starting here is a typical scenario of a FAB for the development cycle.


1. To get started you need to do nothing more than give the form a Form ID and Description and hit the tick.

        


2.  Next, define your UI (User Interface) controls building on the defaulted template that the Create Icon provides.

     Bind the controls to variables. 

    


3.  After you have defined some or all of your form controls you may want to place some front end validation on them.

     For example, if they are changed i.e. a user enters data in the control.

     Add a Script control and place any front end validations into the script.

     

     When the system detects that an input control has changed it looks for instructions as to what needs to be done if the input has changed.

     The code executed is on a control by control basis.

      Each control can have its own front end code written in JavaScript that validates or manipulates the entered data.

      'Actions on change' tells FAB to execute the nominated function in the Script.

      For an amount field, you may want to test for it being positive or that it is a number and has no characters.

      If anything is found to be in error you probably alert the user and show an error.

      


4.  Next, you probably want to introduce a process flow to the form. This is achieved by using the Workflow Icon on the FAB Workbench.

     

     This allows you to describe the roles, levels, tasks, and overview of the process flow.

     

     

     

     

     

     


5.   During the defining of the FAB Workflow/Status Management (shown in step 4) the developer took the opportunity

       to tell the system to do more front end validations before handing the form over to any backend validations

       or updates that need to be done in ABAP.

       These final front end validations are done in a function within the FAB Script and they are written in JavaScript.

       In this FAB Workflow definition, the developer chose to have the function onSubmitvalidations() executed

       when the user hits the Submit button and before control is handed to ABAP.

       The code in the onSubmitValidations() is written by the developer and available in the Script.


6.    For saving a form as Draft no validations are usually defined.

       Therefore in step 4, there is no function assigned in the Validation Function column next to Draft.

       


7.    If upon Submit all of the front end validations have completed without error then FAB starts running the backend processes.


8.    FAB looks for the Implementation Class associated with the form in order to know where to find the code it must execute.

       You could have nominated the Implementation Class earlier but if you have not done so yet then now is the time to do so.

       It has been optional until this point.

       


9.   The order in which FAB executes the methods within the ABAP Implementation class is as follows:

      This snapshot can be found and referred at any time by hitting the Code Icon on the FAB Workbench.

      Discussed here are the ‘Form Saving’ methods. For an explanation of the ‘Form Loading’ methods go to step 13.

      


10.  Data Submission Processing methods are before and when the user hits Draft or Submit or Approve.

       FAB looks for any code to be executed first in the VALIDATIONS_ON_SAVE method.

       The code in this method usually does more in depth validations than those done by the JavaScript in the front end.

       Using an ABAP case statement the developer can control what code gets executed at what stage in the process flow.


11.  Next FAB looks to executes code in the ENHANCE_DATA_BEFORE_SAVE.

       In this method, you may want to manipulate the data into a format that you want for storing into the SAP database.


12.  Next FAB executes code in the PERFORM_ACTIONS_FOR_STATUS_CHG.

       If the form is being submitted then code in this method could be something along the lines of retrieving the next

       reference number in a series held in the SAP backend and storing it in a previously defined hidden form variable.


       The value of certain variables that control the visibility of screen controls can be changed from true to false.

       For example, depending on the action there may be a need to disable fields that an approver is not permitted to access and change.  


        A common scenario in the PERFORM_ACTIONS_FOR_STATUS_CHG method is to have a case statement and

        depending on the value of status and action variables, execute custom methods.

        For example, if the Current Action is ‘APPROVE’ then the developer can branch-off and run a custom-built

        method that updates the SAP database using a BAPI. 


13.  Next FAB executes code in the ENHANCE_SUCCESS_MESSAGE.

       Upon successful execution of the Action, a success message can be sent back to the screen.

       The contents of that message can be defined in this method.


14.  Having described the flow taking place when the form is submitted it now necessary to go back

       to describe the methods that are executed when the form is loaded.

       These ABAP methods enable the developer to leverage off data within your SAP database to supply important information to your FAB form.


        DETERMINE_INITIAL_FIELD_VALUES can be used to find data and default information onto your form the very first time a form is loaded.

        This may be used for picking up some information about the submitter that is to be shown

        on the screen so that at a later point in time the approver is shown any required details.

        For example: showing the status of the submitter as to whether they are set up in the system as a contractor or casual.

        Since you are now using an ABAP method you can include any existing code that describes your business rules and place it into this method.


         DETERMINE_FIELD_VALUES_ON_LOAD is executed each time the form is loaded.

         This can be used to interrogate FAB variables and adjust visibility on the form according to the stage at which a form is at.

         Once again it can be used to incorporate existing ABAP code that determines how you want data on the form to be manipulated and used.


15.   Finally FAB seeks to execute ‘Workflow’ processes that you may have setup. The methods that you may have redefined with your required code are:

        a.  DETERMINE_APPROVERS_ON_SAVE.

      Use this method to determine approvers based on level. 

      


 b.  DETERMINE_APPROVERS_WORKFLOW

      Use this method if a SAP workflow task is used to determine approvers via Rule with function /IQX/RULE_DETERMINE_AGENTS


 c. ESCALATION_PROCESS

     Use this method if you have setup FAB to do workflow escalations, See Workbench Workflow Icon.

     For escalation, you need a background job to check on your setting.

     In this method, you can add approvers or change approvers or do whatever is required for your escalation scenarios.