Varo (FLM) Administrators Guide

1 Introduction 

This document explains the functions of the Varo (FLM) application menu, and the general maintenance and monitoring of forms processes.To access this menu go through Cross-Application Components> Forms LifeCycle Manager.

 

2 Forms Processes Monitoring Tools

2.1 Forms Dashboard

The FLM Forms Dashboard allows you to:

  • view all forms contained in the system
  • change the status of a form or group of forms
  • change the owner of a form or group of forms

2.1.1 To access the Form Dashboard

From the SAP menu select the menu path Cross-Application Components->Forms Lifecycle Manager->Monitoring->Dashboard.

 

2.1.2 Viewing Current Forms Traffic

Select the Form Types under review and select the pushbutton ‘View Current Traffic’.

Alternatively, use the ‘Form Selections’ section for a free selection based on form type, owner, initiator, creation date or form ID.

Use the ‘Include Terminated Forms’ checkbox to include forms at the end of their lifecycle in the returned selection.

 

The returned pop-up report shows the number of forms by status, broken down by active forms and terminated forms, and broken down by on-line forms and off-line forms.

To drill-down further, select a row and then select the ‘Show Forms’ pushbutton.

 

The FLM Form List shows the detailed list of the forms selected, showing the Form ID and Form Variant.

To drill-down to see the details of the particular form, select a row and then select the ‘Display Form’ pushbutton.

2.1.3 Form status re-assignment

From the SAP menu select the menu path Cross-Application Components->Forms Lifecycle Manager->Monitoring->Dashboard.

Enter selections using the ‘Form Selections’ or ‘Group Selections’ section boxes.

Enter the current status in the ‘Status’ field within the ‘Form selections’ selection box.

Enter the target status in the ‘New Status’ field within the ‘Update’ section of the ‘Processing Options’ selection box.

If any forms to be updated are locked then the ‘Force Update of Locked Forms’ checkbox must be selected.

Execute using the ‘Change Form Status’ pushbutton. Several pop-up windows now appear:

1)    A warning pop-up window is displayed

2)    A confirmation pop-up window is displayed to confirm the change status action

3)    A pop-up window is displayed for each locked form, explaining that the form will be unlocked.

4)    The following final confirmation window is displayed:

 

Select ‘Accept Changes’ to continue.

5)    A final confirmation window is displayed when the changes have been posted.

2.1.4 Form owner re-assignment

From the SAP menu select the menu path Cross-Application Components->Forms Lifecycle Manager->Monitoring->Dashboard.

Enter selections using the ‘Form Selections’ or ‘Group Selections’ section boxes.

Enter the current owner in the ‘Owner’ field within the ‘Form selections’ selection box.

Enter the target owner in the ‘New Owner’ field within the ‘Update’ section of the ‘Processing Options’ selection box.

If any forms to be updated are locked then the ‘Force Update of Locked Forms’ checkbox must be selected.

Execute using the ‘Change Form Owner’ pushbutton. Several pop-up windows now appear:

1)    A confirmation pop-up window is displayed to confirm the change owner action

2)    A pop-up window is displayed for each locked form, explaining that the form will be unlocked.

3)    The following final confirmation window is displayed:

 

Select ‘Accept Changes’ to continue.

4)    A final confirmation window is displayed when the changes have been posted.

2.1.5 Unlocking a Form

To unlock a form enter the Form ID in the FLM Dashboard then in the  Processing Options section use the "Unlock Forms" button.

2.1.6 Viewing Form Data in the Dashboard

With the release of FLM 295 SP3 the 'Forms Dashboard' now allows the Form or the Form data to be shown in the display view.

2.1.7 Form Audit Trail

The Audit Trail dropdown allows you to select which variant of a form you wish the viewer to display.   By default, this will be showing the latest variant, but if you wish to view the form at an earlier point in the routing, you can select an alternate variant from the list.

The audit trail feature in the 'Forms Dashboard' has been subtly adjusted at FLM 295 SP3 to cope with changing UI types.  The original approach was that each selection referred to the data point immediately before the form-filler started entering data.   This has been changed so that the description in the drop down refers to the form at the actual point of submission.

2.2 Forms Archiving

The ability to Archive forms data was introduced at FLM 295 SP2.

As of FLM 295 SP3 you no longer need to restore forms from the Archive to view them in the Dashboard.

The FLM archiving suite comprises two main programs, one for archiving forms (/flm/form_archive) and one for reloading archived forms (/flm/form_reload).   The intention is to reduce the load on the main FLM tables to maintain system performance under increasing load conditions.

In each case you make a series of selections to filter out the set of forms you require (note that forms are selected according to the details they hold at their latest variant).

The archive program would normally run as a regular background job, and would move forms from the main FLM tables into a series of parallel but separate tables.  From there, forms can be reloaded by the other program as required.

The system archives the following tables:

  • /flm/fpe -> /flm/fpe_arc (main FLM Form index table)
  • /flm/fpe_h -> /flm/fpe_h_arc (main FLM form history table)
  • /flm/fpe_err -> /flm/fpe_err_arc (FPE message table)
  • /flm/fpe_exec -> /flm/fpe_exc_arc (FPE run details table)

In addition, form data, attachments and annotations are moved into a parallel set of repositories in the content server.  These must be configured in the FLM IMG activity 'link document types', for document types 'AR1', 'AR2' and 'AR3'. See the FLM Installation Guide for more detail.

2.2.1 Form Archive Program

Use the Archive program as a one time run or as a daily background job to move completed forms to the archive.

 

2.2.1 Forms Reload Program

Use the Reload Program to retrieve forms from the archive back into the main FLM tables so they can be viewed.

2.3 Free Form Generation

You can generate an offline form independent of any routing scenario using the ‘free form generation’ facility. Select the form type and version you wish to dispatch, and whether you would like to disenable prepopulation, then click execute.

 

2.4 Form History Report

From the SAP menu select the menu path Cross-Application Components->Forms Lifecycle Manager->Monitoring->History Report.

 

Enter selections as normal for any selection screen.

The report performs a simple selection on table /FLM/FPE_H and displays the form history for one or many forms.

 

2.5 Manually posting forms using the FPE

From the SAP menu select the menu path Cross-Application Components->Forms Lifecycle Manager->Forms Posting Engine->Invoke FPE.

 

Leave the Form Type selection empty and select the option ‘Reprocess Forms in Error’.

Posting Status

Each form variant attracts a 'Posting Status' (which is a different concept to a 'Form Status') which is set by the FPE each time a record is processed.   Each Form Variant is given an Initial Posting Status as it is first created and this status is updated each time an attempt is made to process the Variant via the FPE.

Initial Transfer

Selects forms that have never been previously processed by the FPE.

Reprocess Forms in Error

Selects forms that failed a previous FPE run and need reprocessing.  A failure may be triggered by a transient system situation (such as a dialog user locking a record or a network problem) and hence there should always be an FPE variant scheduled to reprocess errors at least once per day.

Locked Forms

The FPE administrator can manually Lock records during processing to remove them from reprocessing for business reasons.  If the FPE administrator wishes to subsequently Unlock these records, select this option and on the subsequent screen the administrator has the option to Unlock those records.  An unlocked record returns back to the Posting Status it was in before it was Locked in the first place.

Posted Forms

Form Variants may only be successfully processed once by the FPE. Selecting this option is useful for reporting on those forms, but no further action is possible.  Note that the report 'Posting Log' provides a similar function.

Partial Forms

Forms may be configured to enter a 'Partially Posted' state in the event of a transfer error; this is configured via the FLM IMG's 'No Fail' flag.  This allows the system to fail a form during FPE processing but for the failure not to automatically set the Posting Status to 'Error' which would then cause the form to get picked up during the 'Reprocess Forms in Error' variant (see above).

This may be required for a business scenario in which an FPE failure is expected under some circumstances and yet reprocessing is either not automatically required, or in fact, must be excluded from other forms in error to avoid obscuring more serious FPE errors.

Execute in the Foreground as shown.

 

Any failed forms are displayed.  The following options are available:

  • Background: Try to post the failed form in the background.  This is suitable for posting adapters that use BAPIs to update SAP.
  • Refresh: Reload based on initial selection criteria. 
  • Foreground: Try to post the failed form in the foreground.  This is suitable for posting adapters that use ‘call transaction’ (like a BDC session) to update SAP.
  • Lock/Unlock: Lock a form so that FPE stops trying to post it.  The form can be fixed later or removed using the clean-up utility as necessary.
  • Show Errors: Display any errors returned by the posting adapter.
  • Display Form: Show the form data to help understand why the posting failed.

Select the option as desired to further process the form.

 

3 FLM System Specific Settings

This activity is split into two areas: FLM Settings and Project Settings.  In each case the parameters are all organized by an SAP system ID in order to allow for the settings for a complete landscape to be defined in one system and then transported together through the landscape.

This is because certain important parameters, such as host names, vary naturally between the different systems in the SAP landscape (development, quality, production). This configuration table provides a system-specific way for those parameters to be maintained and easily transported.  This avoids having to open up downstream system in order to make changes to configuration tables locally.

Begin by adding entries into this table, one for each System ID in your FLM landscape.  Against each entry you can then make certain settings, detailed below, which can then be read locally against the local system ID by FLM (and customer code).

In the section called 'FLM Settings' there are maintained system parameters important for the functioning of the FLM framework itself, each of which is described in detail below.

In the 'Project Settings' section, parameters useful for the customer project are maintained - so-called 'Project Parameters'.  None of these are used by FLM itself and are all therefore entirely optional.  A method /flm/user=>get_pp is supplied to retrieve the values of these parameters should you require them in your user-exit developments.

3.1 External System Links

Main External RFC Destination

If you are using FLM on a separate system from your main SAP system, you will be using RFC connections defined in SM59 to collect data from the other system, and to push data back into that system.   Rather than hard-coding the RFC connection name in your user exits, read it from this table using the static parameterless method /flm/core=>get_rfc_dest().

This RFC destination can also be selected in the Forms Posting Engine activity, 'FPE Control'.

UME Ext RFC (User Management Engine External RFC)

If you manage your users and usergroups on a remote SAP system, enter the destination connection to that system here. If you require to derive this programmatically in one of your userexits, the method /flm/core=>get_ume_rfc_dest() is provided.

Note// you must maintain the name of the remote authorization-object in the customer settings in the local FLM system even though the actual check will be carried out on the remote system.

Alternate External RFC Systems 1 & 2

These do nothing functionally within FLM but are provided for customers who may be connecting their FLM system to more than one external SAP system and do not wish to hardcode references to them.

3.2 SAP EMail Address

Sender Email

This is the email address of this FLM system.  This can either be set globally at the customer level, or here at the system specific level.

3.3 FLM Portal Settings

There are a number of scenarios where Varo (FLM) will generate a URL (in notification emails for example) and those URLs will need to be accessed  via a reverse proxy or the SAP Web Dispatcher and therefore the hostname:port in the URL may need to be different from the hostname:port of the SAP system inside the DMZ.

To compensate for this in Varo (FLM) 300 and above use the SAP standard approach and create the necessary entries in the HTTPURLLOC table in SE16 as seen in the example below.

Note \\ When testing ICF services from the transaction SICF, the table HTTPURLLOC is NOT used.

For more details on using the HTTPURLLOC please see the SAP Documentation Configuration Table HTTPURLLOC.

Disable SSL for URL generation

Indicates whether portal URLs generated by the system will be http or https.

Use Standard host/port for dashboard access

Determines whether the system will use the standard host/port of the ABAP server when launching a form in the "Forms dashboard" or "Quick Viewer" transactions. If this checkbox is not ticked, configuration in table HTTPURLLOC and the DNS name field will also be taken into account.

Exit URL

This is the URL of the page you wish to navigate to after submitting a form via external access (for example after having launched the form via a URL).

Specify the target URL as for example www.google.com (do *not* specify the protocol).

There are also 4 special cases:

  • TOINBOX Return to user's inbox
  • TONEWFORM Return to the new form chooser page
  • TODRAFTFORMS Return to draft forms
  • TOTEMPLATEFORMS Return to Template Forms page
  • TOMYHISTORY Return to the My History page

User Mapping Active

This checkbox indicates that for this system ID, the FLM Portal users do not exist directly in the R/3 Backend ABAP system.   In this situation, a 'mapped' user is maintained as part of the portal user master record in the SAP Java database - this mapped user must exist in the R/3 backend and must hold the FLM roles and profiles to be used at runtime.

The mapping must be unique for each portal user.

Note//  under these circumstances, the user supplied into the various userexits in FLM is the mapped user and not the portal user, similarly, system events will be recorded under the mapped user id.

If your portal users do exist in the ABAP backend, which is the most common situation, do not tick this box for any system in your landscape. Also, be aware that utilizing this mechanism is only possible in conjunction with the SAP Enterprise Portal.

See SAP Notes 701205 and 1257108 for further information.

3.4 FLM Portal Details (Deprecated, Legacy Features)

Previously, the “DNS Name” field in has been used for url exceptions, for example when the SAP Web Dispatcher or a reverse proxy is in place. If the field is maintained it will continue to be used (as a legacy feature for customers upgrading) however the recommended approach is now to use the standard SAP approach and maintain an entry in table HTTPURLLOC as described above.

 For example: 'http://flm01.mydomain.com' and '50000'.

Please note that if a field is maintained in the “DNS Name” field the configuration from table HTTPURLLOC will be overwritten

3.5 System Logging

This refers to configuration relevant to the transfer of logging information from the FLM system to the SAP CCMS logging system hosted on the SAP Solution Manager.  The settings refer to the minimum message severity that should be transferred (typically error or abort) to the CCMS and how those messages are reported.

Min Log Level

This field sets the minimum logging level in the system as follows:

  • Level            Logs
  • Success         Success, Info, Warning, Error and Abort
  • Info               Info, Warning, Error and Abort
  • Warning       Warning, Error and Abort
  • Error            Error and Abort
  • Abort            Abort only.

Note// The minimum threshold here also determines which messages are sent to the CCMS monitoring framework.

Alert Mode

This setting influences the behavior of alerts within the CCMS infrastructure; specifically, it controls when an administrator alert is generated within that system in response to receiving an FLM message.   Messages are only sent to the CCMS infrastructure from FLM if they are of type 'Error' or 'Abend' and when they exceed the minimum logging level defined in the 'System Specific Setting' activity with the FLM configuration.

Please see the standard SAP documentation for a description of how to configure the CCMS system.

3.6 Tempary Resource Max Lifespan

Max Life

This setting controls how old unnecessarily allocated resources must be before they can be deleted during execution of the Form Cleanup report. There are three resources in question:

  • Entries in the table /FLM/FLOCK (ensures that the same form cannot be opened by a second user).
This value sets the maximum lifespan in minutes of these lock entries for on-line forms.   That is, the cleanup report will delete entries older than this length of time.  Offline forms are not affected.

The reason for this functionality is that sessions that have been disconnected by the user (for example by closing their browser unexpectedly) should not retain these old lock entries, which, if they were not removed, would stop other users from the group from opening the same form.

Set this value and then schedule the clean-up report (/FLM/FORM_CLEANUP) to run at a suitable interval, remembering to set the 'Cleanup Session Resources' flag.
  • Entries in the table /FLM/TEMP_DATA (FLM Multi-UI Portal writes temporary session data here).
  • Entries in table /FLM/PDF_ATTS with an attachment status of 'A' or 'C' (used for attachment handling).

Under similar circumstances to the above (ie user disconnecting their session unexpectedly) these entries do not get cleaned up.

This value should ideally be greater than the Java Idle Session Time Out (which is usually 30 minutes for non-SSO systems and 480 minutes for SSO systems), to ensure that sessions that are merely being ignored by the user are disconnected from FLM by SAP and not by this cleanup program.

Note// If you do not enter a specific value here, the system will use a default value of 60 minutes.

Max Excel Life

At FLM 295sp5 users have the ability to create FLM forms by uploading Excel spreadsheets. In order to facilitate downloading and re-uploading forms that uploaded in error (either because of a validation error or a more general one) data is written to tables /FLM/EXCEL_DATA and /FLM/EXCEL_MESS.

This setting controls how old (in days) this data must be before it is deleted during execution of the Form Cleanup report. Among other data (please see the documentation of the Max Life field for more information) this report will delete all entries in the above tables which correspond to a specific Tracking ID if the latest table entry corresponding to that Tracking ID is older than this value.

Note// If you do not enter a specific value here, the system will use a default value of 45 days.

3.7 Email Safe List Override

If this flag is checked the system does not respect the list of safe email recipients as maintained in the activity 'Define Approved E-mail addresses' for this system.

Therefore checking this flag in non-productive system should only be done with great care.  Note that this setting affects both FLM and, if installed, Aquiller.

Check the flag for each system from which you wish to send out emails in a completely unrestricted manner.

3.8 Customer Variables

These are provided to hold customer or project specific variables and are not used by FLM.


 

4 FLM Maintenance

4.1 FLM Configuration

For information on the Technical Setup, Configuration and Customizing of FLM please see the FLM Installation Guide and ADS Performance Tuning Tips.

4.1.1 High Availability Clustering & Adaptive Computing

The FLM-AddOn resides entirely inside of the SAP ABAP Instance. This allows FLM to be run on each node in al High Availability Cluster and can also to be migrated with each Instance in a virtualized environment without additonal configuration or reconfiguration.

Similiarly the FLM Portal resides entirely on a Java Instance and can operate on each node in a High Availability Cluster and be migrated with the Java Instance without requiring reconfiguration.

No additional configuration is required to take advantage of FLM in a High Availability or Virtualized environment.

4.2 Logs and Traces

For problem analysis please see the ADS Problem Analysis

4.2.1 FLM System Log

FLM-specific events are recorded in the general application log (SLG1).

In the current release of FLM the log level is set to Success by default for the /FLM/LOG entries. Currently there is no way to change this setting but the next release will provide a mechanism to set the log level for FLM.

Old log entries can be removed by using transaction SLG2 and object /FLM/LOG

As of FLM 295 SP2 the log levels and CCMS alert mode can be set in System Specific Settings.

4.2.2 FLM Portal Log

Java Errors and Dumps in the FLM Portal are written to the default.trc file on the Java Stack.

FLM Errors that appear in the FLM Portal are written to SLG1.

4.2.3 Forms Process Errors

Errors generated from a Form Processes are typically caught by FLM and written to SLG1.

Major errors in Form Processes that cause ABAP Dumps are written to ST22.

4.3 CCMS Configuration

Monitoring of FLM can be setup using CCMS in the following way.

// Please note if you have applied Note 0064 to 295 SP1 at least one message must be written to the log before the FLM will appear in the MTE tree.

In transaction RZ20

  • Go to Extra menu -> Activate maintenance function
  • Monitor (set) menu -> Create
    • Select the New monitor set option (default).
  • Select "FLM Alerts" and create new monitor
  • Change the Monitors name to "FLM Messages" by going to Monitor definition -> Change name
  • Select the "FLM Form Server" and "Alert Details" from the MTE Tree. 
  • Activate Monitor

    

4.4 Remote Access Support

To allow remote access support the FLM_READONLY role should be created in PFCG.

See FLM Authorizations and Security for additional information.

Errors should be logged under the BC-SRV-FP component.

4.5 Background Jobs

Typically the following jobs should run daily, depending on the business process requirements:

4.5.1 Form Escalation

Program: /FLM/WF_ENGINE

 

The form routing server should be run with the ‘escalate’ option for all form types.

The program can be run in this mode multiple times per day; for example it could be run hourly depending on the business requirements.

The output written to the spool shows all forms selected for escalation.

4.5.2 Form Reminder E-mails

Program: /FLM/WF_ENGINE

 

The form routing server should be run with the ‘Send e-mail reminders’ option for all form types.

The program must only be run in this mode once per day.

The output written to the spool shows all forms selected for e-mail reminders.

4.5.3 Form Posting

Program: /FLM/FPE_INVOKE


The Form Posting Engine should be run as a background job multiple times per day; for example it could be run once every hour depending on the business requirements.

The option ‘Initial Transfer’ should be selected for background processing.  The options ‘Reprocess Forms in Error’ and ‘Locked Forms’ should not be selected.

The output written to the spool shows all forms posted.

4.5.4 Form Clean-up

The Cleanup Program allows you to clean unwanted forms and associated table entries from your system to help keep the FLM tables optimized.

Program: /FLM/FORM_CLEANUP

It is recommended that the clean-up utility is run daily to remove unwanted forms.  In the majority of cases these will be forms which have been rendered but not submitted, so remain in their Initial status.

  • Setting a Form Status of "I" will remove all form ids that have not progressed passed the Initial Status.
  • Setting a Form Status of "*" would remove form ids for all Form Statuses based on the other selection criteria fields and therefore this option should be exercised with care.

For offline forms the deletion window (shown above as 30 days) should be set at the point in time after which no submissions are accepted for the form type.

For on-line forms the deletion window should be set to 1 day.

Typically there would be one variant for on-line forms and one variant for off-line forms for the clean up utility background job. Alternatively a separate variant could be used for each form type.

The output written to the spool shows all forms removed.  The form history table is not deleted and records that the form has been removed.

Forms deleted using the cleanup program will have a "Deleted Form"  history table entry in the TEXT field. The CREATED_BY field will have the user that ran the report.

As of FLM 295 SP2 a  "Clean Locks Only" variant can be set to clear out locks that didn't clear automatically due to timeouts or exit events that aren't caught. The locks will be removed based on their age and on the setting to set the lifespan the Lock Table Entry Max Lifespan in System Specific Settings. The "Days since form creation" should be set to "0".

If Max Life is left blank the system will use a default value of 60 minutes.

As of FLM 295 SP3 "Clean Locks only" has been updated to "Cleanup temp. resources only".  When forms are rendered temporary "session data" is written to table /FLM/TEMP_DATA. Moreover, if attachments are added, attachment meta-data is written to table /FLM/PDF_ATTS. These table entries are normally cleared automatically upon form submission, however if that does not happen (because the user shuts down his browser before submitting the form for example) they can be cleared by the cleanup report. For this reason, the "Max Lock Life" field described above has been renamed "Max Life" and apart from the locks, determines how old the above table entries must be before they are deleted. Similarly, the "Cleanup Locks Only" variant described above has been renamed "Cleanup temp. resources only". It is worth noting that unlike the form locks,  "session data" which is older than the "Max Life" field will be deleted regardless of whether the actual form it is associated with is deleted, ie regardless of the entries in the selection screen.

Be sure to apply FLM Note 0151.

If Max Life is left blank the system will use a default value of 60 minutes.

As of FLM 295 SP5 in order to facilitate downloading and re-uploading Excel forms that uploaded in error (either because of a validation error or a more general one) data is written to two new tables: /FLM/EXCEL_DATA and /FLM/EXCEL_MESS. A new field called ‘Max Excel Life’ has been created in the ‘System Specific Settings’ transaction which controls how old (in days) the data in the above tables must be before it is deleted by the ‘Form Cleanup Report’. The cleanup report will delete all table entries which correspond to a specific tracking ID if the latest table entry corresponding to that tracking ID is older than the ‘Max Excel Life’. If no value is maintained in the ‘Max Excel Life’ field, the cleanup report will assume a default value of 45 days.

If Max Life is left blank the system will use a default value of 60 minutes.

4.6 Backups

All configuration, customizing and form data for the FLM Add-ON is stored in the local SAP System Database and is covered by normal database backup procedures.

 

4.7 Restart and Recovery

Recovering from system failure follows normal SAP procedures given that all associated data is stored inside the SAP System Database.