The Application Life Cycle

Owned by Charles Evans (Unlicensed)
Last updated: Feb 14, 2019

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

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

During 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 super class 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.

Staring here is a typical scenario of a FAB for 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. See ‘Actions on change’.

'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 some buttons to control the flow of the form.

This is achieved by using the Workflow Icon on the FAB Workbench.

This allows you to describe the buttons such as Draft, Submit, Approve, Reject etc.


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.     Usually for saving a form as Draft no validations are 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.   'Form Saving’ methods are executed 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 visibility of screen controls can be change from to 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 setup 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. 

 


IQX Business Solutions - FAB 2.40