Business logic - User-exit cycle

Overview

User-exits are defined at 3 levels:

i) Customer Code level.  These user-exits are called for all form types.

ii) Form Type level. These user-exits are called for a particular form type.

iii) Field level.  These user-exits are called for a particular field on a particular form.

User-exits are triggered before the form is presented to the user or after the form is received back after submission by the user.

 

 

The Customer-Level user-exits are:

  • Inbox.   This enables changes to the forms presented in FLM Inbox, used typically for group access scenarios.
  • Server-side Security.  This enables dynamic data to be added to a digital certificate
  • PDF size. This enables changes to the height and width of the iView in which the PDF form is presented within FLM Portal
  • Authorisations.  This enables the addition of rules to over-ride the standard authorisation check.
  • Logon Language.  This enables the addition of business logic to over-ride the logon language of the user.

The Form-Level user-exits are:

  • UI Type. Introduce at 295 SP3. This enables the selection of UI Type based on user-agent for the MUI Portal.
  • Language (Template).  This enables the selection of different language templates, for example based on the user language.
  • Version.  This enables different versions of form templates to be derived.
  • Pre-population.  This enables the pre-population of any field in the data schema.
  • Subform and Field Control.  Introduced in 295 SP2. This enables subform and field attributes to be set programmatically.
  • XDP/HTML.  Introduced at 295 SP3. This enables the manipulation of the form template before rendering.
  • Routing.  This enables the derivation of a new form owner and the ability to over-ride values derived from the routing table.
  • Index. This enables dynamic derivation of the 6 delivered index fields plus any customer-added index fields.
  • PDF.  This can be used to access the PDF file before sending to the user and when submitted back by the user.
  • E-mail.  This is used to derive the recipient e-mail addresses for off-line forms.
  • Enqueue. This is used to lock an object, typically used when an off-line form is sent.
  • Dequeue.  This is used to unlock an object, typically used when an off-line form is received.
  • Factory Calendar.  This is used to over-ride the factory calendar configured on the customer code or form type. Used for escalations.
  • FPE alert.  This is used to determine the e-mail recipient of an administrator in the case of a posting error.
  • Notification/Reminder.  This is used to determine the e-mail recipient for notification or reminder e-mails.

The Field-Level user-exits are:

  • F4.  This is used to determine a number of possible entries for a drop-down list field.
  • Pre-population.  This is used to pre-populate data into a single form field.
  • Validation.  This is used to validate the data in a field after form submission.
  • Substitution.  This is used to substitute form data after form submission.
  • Derivation.  This is used to derive data and add into data schema fields, after form submission.
Note:// Changes to Check-Cycles for the Validation, Substitution and Derivation user-exits.
  • These user-exits don't run during Check-Cycles for forms types created in FLM 295 SP3 or later.
  • These user-exits will run for form types created in 295 SP0 - 295 SP2 even after upgrading past FLM 295 SP3.
  • If form types created before 295 SP0 are run through the FLM Form Wizard they will behave as if they were created in FLM 295 SP3 or later.
  • The attributes C_FLM_VERSION and C_FLM_SP_LEVEL are used to determine the correct behavior.

Each user-exit includes a description of the import and export parameters, and an explanation of how to develop business logic into each user-exit.

Common User-exits

The most commonly used user-exits are:

Form-level pre-population

The form-level pre-population user-exit is always used to pre-populate a number of form fields based on the form initiator.  Typically, data from the user master record and/or employee master record and/or HR organisational structure (such as manager name) are included.

F4

Drop-down list selection values are not stored in a data schema, nor are they defined within the form template.  They are dynamically defined using the F4 user-exit and then added into the form template at run-time by FLM.

Form Routing

The Form Routing user-exit is always used to determine the new form owner in a form process.  It is also used to trigger standard SAP workflows and for integration to SAP Universal Worklist.

FLM XML table

Several user-exits and all posting adapters make the entire form data available.  When the data is available it is presented in an internal table, which FLM creates based on the XML data schema. The table has type /FLM/XML_TAB_T, and includes the following important fields:

NAME.  This is the field name as defined in the FLM Form Wizard.

VALUE.  This the the current value of the field.

PARENT.  This is the parent node in the data schema, the name of the subform as defined in the FLM Form Wizard.

PATH. This is the path of the XML from the root node to the field, used to reconstruct the XML file.

For example, the import parameter im_data and export parameter ex_data in the pre-population user-exit both have this format.

For updating the form data, then the table will be read using a field name, and then modified (or appended in the case of repeating rows).  The code will have the following form: 

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
DATA: l_data TYPE /flm/xml_tab.

READ TABLE ex_data WITH KEY name = 'TXT_NAME' into l_data.

IF SY_SUBRC EQ 0.

    l_data-value = 'My name'.

    MODIFY ex_data index sy-tabix from l_data.

 ENDIF.

For reading the form data, then the table will be read in the same way.

1:
2:
3:
4:
5:
6:
7:
8:
9:
CLEAR g_data_item.

READ TABLE forms_data INTO g_data_item WITH KEY name = 'H_PERNR'.

IF SY_SUBRC EQ 0.

    g_pernr = g_data_item-value.

ENDIF

Typically:

For pre-population, BAPI export parameters will be mapped to form fields using the FLM XML table

For posting adapters, form fields will be mapped to BAPI import parameters using the FLM XML table.

Form Indexing

Indexing is the process of adding metadata to the form as  it is stored in SAP to facilitate easy retrieval and reporting.  There are 6 fields for such data with FLM forms. These can be populated with form data through IMG configuration or dynamically  through the ‘Index’ user exit.

To configure form indexes, navigate to the IMG activity  /FLM/Interactive Forms/Setup forms/form types configuration, then select a form type and click ‘Setup forms for Indexing’.  Any non-repeating field can be used as an index. 

 Custom index fields can be added by changing the delivered structure CI_FLM_FINDEX.  These index fields can only be filled using the Index user-exit.