Release Notes for Varo (FLM) 300

Standards Compliance

  • Varo (FLM) is certified to run on SAP S/4 HANA.
  • Varo (FLM) is a SAP Endorsed Business Solution. Arch is one of only 35 companies that have been invited by SAP to become a SAP EBS partner.
  • Varo (FLM) is compliant with SAP Accessibility Standard v3.0

Introducing Floe and Stelo integration.

FloeFloe delivers outstanding e-mails using HTML content fully integrated with data from your SAP systems. Arch Floe can be used for any SAP e-mail communication and can be incorporated into existing business processes easily. Arch Floe provides impressive SAP integration, such that any data from SAP systems can be incorporated into the body of the e-mail. Moreover, recipients, images and attachments can be determined from business logic stored within the SAP system.

As organisations move to the SAP Fiori paradigm for user interaction, the need arises to manage tailor-made processes and user interfaces, beyond simply adding a new front-end to a SAP transaction or BAPI. Arch Stelo provides the framework for the development and management of custom Fiori processes, enabling organisations to easily build and maintain a suite of Fiori applications and the related business processes.

Learn More about Floe and Stelo

Bugs Fixed

  • FLM Note 185 (Applicable to Stelo users): When saving a Stelo App to draft, the "Draft Notes" entered by the user are not saved. Also, drop-downs with entries containing special characters such as ampersands get corrupted.FLM Note186: You have entries in the form lock table with a blank lock date which the clean-up report does not delete.
  • FLM Note 188: Escalations fail with the following error message: "[464] Form <customer code>-<form type>-<template option>-<version>-<form id>-<variant> cannot be submitted. Please try again or Contact SysAdmin".
  • FLM Note 189 (Applicable to Stelo users): You wish to perform an action on success or failure (after a posting run) or an escalation on your Stelo document.
  • FLM Note 190: When uploading attachments via the Multi-UI portal the full path to the uploaded file appears in the 'name' field in the portal rather than the actual filename.
  • FLM Note 191: In the "My History" page of the "FLM Forms Manager" you cannot see entries for form types for which you have "display authorization" but not "create authorization" in the "Type" drop-down.
  • FLM Note 192: You are using function module '/FLM/HTML_GENERATE_NEW' to programmatically generate an HTML form and certain characters in the data get replaced with their escaped form containing HTML entities.
  • FLM Note 194: The global "Subform and Field attributes" are not applied if status specific attributes have not been maintained for the status of the form.
  • FLM Note 195: After submitting a form you see the following message in the portal: "Form <Form ID> posted successfully with document &2", even though a synchronous posting has not occurred.
  • FLM Note 196: After a synchronous posting fails, the form is returned to the submitting user with the first message generated by the posting adaptor, even if that is a success message.
  • FLM Note 197 (Applicable to Stelo users): Your Stelo app does not render and you get an "XML parse error" in your browser console.
  • FLM Note 200: You are pre-populating an html form field with a value containing a special html entity (such as &). In an F4 user-exit parameter im_data contains the escaped version of this value.
  • FLM Note 201: The Form Transport Wizard does not transport "Alternate System Messages" correctly when choosing the "System to system central configuration" option.
  • FLM Note 203: When trying to delete a form lock via the "Forms dashboard Unlock Forms" option, you get an error message indicating that "The form lock is not older than the Temporary Resources Maximum Life setting" even though it is older.
  • FLM Note 206: Fields of the /FLM/FPE record of the form are not substituted correctly in your portal task instructions.
  • FLM Note 208 (applicable to Stelo users): Sticky dropdowns do not work correctly on your Stelo application.
  • FLM Note 209: Setting a form type to "Blocked" affects existing forms in the workflow and restricts access to historical forms in the "My History" view and "Forms Dashboard" instead of just restricting new instances of the form.
  • FLM Note 210: Running the form wizard for versions other than 00, resets the value of form options such as transport options, runtime options, the form category and security level to the value of version 00 options.
  • FLM Note 211: You are using a non-unicode system and drop-down and checkbox fields do not work correctly on your Excel form.
  • FLM Note 212: Your captions are getting lost when using the "Maintain Field and Subform Captions for HTML and Excel Forms" transaction.
  • FLM Note 213: You get the following error when submitting a form in the portal: "Attempt by &1 to access form owned by &2 via URL rejected. See long text."
  • FLM Note 216: You have configured a posting job which creates multiple instances of an offline form. The email body text is not cleared so that the n-th email contains the body text n times.
  • FLM Note 217: You are not able to update fields of the /FLM/FPE table (index fields for example) inside a posting adaptor.
  • FLM Note 218 (applicable to FLOE 200 users): A CX_SY_DYN_CALL_ILLEGAL_TYPE exception occurs when FLOE version 200 (or later) is used to send FLM emails.
  • FLM Note 219: The following items are not sorted correctly in HANA systems: Entries in the "Historical Events"/"History" portal tab and the available actions on a rendered form.
  • FLM Note 220: Forms are not sorted correctly in the FPE. As a result, later variants may be posted before earlier ones.
  • FLM Note 221: The form cleanup report is incorrectly deleting session data. As a result, you get the one of the following errors when submitting a form: "Attempt by &1 to access form owned by &2 via URL rejected. See long text." or "Session data can not be read. Contact System Administrator."
  • FLM Note 222: Text-areas on HTML forms are rendered with the wrong value.

 

Enhancements:

  • 1)The “My History” portal page can now display all forms the user has actioned (assuming he has display authorization) rather than just the forms he has initiated as is the current behaviour. The behaviour can be toggled by use of the “My History Page Content” drop-down in the “Set Customer Code” IMG transaction.  
  • 2) URLs generated by the system (for the “MultiUI portal” and “FLM Forms Manager”) now point to the “Portal” application rather than “Dispatcher” and can be configured to be http or https. (Previously, all urls where http and pointed to the “dispatcher” which then re-directed to “portal” in http or https via an alias. This approach did not work for all customers however as some customers don’t allow http traffic at all and the switch to the alias requires additional firewall rules and breaks EP iView integration. SAP web dispatcher and reverse proxy support has also been added via configuration in SAP table HTTPURLLOC where customers can determine the host and port for urls (globally). Because of this change the ability to access the portal differently depending on device has been lost but this was a feature which was not used and the recommended approach for mobile now is to use Stelo.
  • 3) A number of changes have been made regarding sticky dropdowns:
  1. Drop-down fields are set as “Sticky” by default in the form wizard
  2. F4s are always re-run at initial statuses (including “Draft”)
  3. A new “Refresh Sticky” checkbox has been included in the “Set Additional Pre-population Statuses” IMG transaction. Setting this causes the F4s to re-run at certain statuses.
  4. When forms are archived, only selected entries (at any variant) will be saved.
  5. Method /FLM/USER=>CONDENSE_STICKY_DD is now provided. This can be used to delete non selected (at any variant) entries for a single or all sticky drop-downs on a form.
  • 4) Function /FLM/DOCUMENT_GENERATE_NEW is now provided. This function can be used to create a new document of any ui_type (pdf, html or Stelo) specified by the im_ui_type import parameter.  Import parameter im_data can be used to pass data in and/or you can get the data by running the pre-population user-exit.
  • 5) Performance Improvements including a change to table buffering settings.
  • 6) A new BSP application /FLM/OUTPUT_PDF is provided. This can be used to launch a read-only PDF with pre-set data. (for printing the data in a html form for example). The data must be submitted to page pdf.htm of the BSP via a POST operation. New function /FLM/OUTPUT_PDF_OUT is called to render the PDF. The function creates a read-only PDF with the data passed in. Pre-population routines will not be run and no data will be saved in the cms or in any of the FLM tables
  • 7) Support for SAP PDF printing and preview. (functions /FLM/OUTPUT_PDF_PDL_OUT and /FLM/PREVIEW_OUTPUT_PDF and BSP application /FLM/PREV_OUTPUT_PDF
  • 8) A new “Stelo App Type” flag has been added to the form type configuration. Setting this flag indicates that the form type is a “Stelo type which ensures that it will not be available in the MultiUI portal and FLM Forms Manager
  • 9) The latest form version is now selected by default in the Form Wizard.
  • 10) You are informed by the Form Wizard when editing a form version which isn’t the latest.
  • 11) It is now easier to customize the MultiUI portal and “FLM Forms Manager” submission screens which users see after submitting a form that has been launched via a url. JavaScript snippets can be included in the “Portal Exit Text” standard text object (maintained in “Customer Code Settings” surrounded by an ampersand: &<SNIPPET NAME>&. Form fields and FPE fields can be referenced in the same way inside the snippet.
  • 12) A new “field access” access was added: “Fixed”. “Fixed” fields behave like “Non-Interactive” fields when the form is rendered. When the form is submitted however, a back-end check is carried out to determine whether the value of the field has changed compared to the value at the previous variant. In such a scenario the form is returned to the user with an error. The value of Fixed fields can therefore not be changed via JavaScript on the form. It is determined when the form is pre-populated at the initial status and remains unchanged throughout the forms’ lifecycle (providing of course that the field remains Fixed).
  • 13) When creating a new version of an existing form via the Wizard, users can now specify which configuration entries to copy to the new version, thus minimizing the time required to create a new version of the form.
  • 14) When HTML templates are generated by the form wizard, a new “maxlength” attribute is added to the “Add Row” button of repeating rows. Its value is the “maxoccurs” value of the corresponding repeating row and it can be used to limit the number of rows that can be generated.
  • 15) The length of field captions maintained in  the backend has increased from 30 to 60 characters.
  • 16) When FLM is using FLOE to send emails (notifications etc) the FLM safe recipient list is now ignored. Only the FLOE list is checked.
  • 17) The “Portal Task Instruction” column has been removed from the “My History” page of the MUI Portal.
  • 18) You can no longer render form variants which are not the latest in “change mode”.
  • 19) An XDP template is now generated by the “Form Wizard” only when required
  • 20) The “Include terminated forms” flag has been removed from the dashboard. The system will search for all forms which meet the rest of the selection criteria, including forms at a final status.
  • 21) Field captions (if they have maintained in the back-end) rather than technical names are available in the dashboard for index fields.
  • 22) The length of standard index fields has increased. The first 3 are now 40 chars long and the next 3 80 chars long.
  • 23) New program /FLM/FPE_RESET allows developers to reset a form posting so that they can test posting adaptors by re-posting without the need to create and submit a new form.
  • 24) FLM now supports the SAP un-installed via SAINT.
  • FLM Note 187: You are calling method /FLM/CORE=>TEXT_ADD_VARIABLES from a posting adaptor, but non-schema fields (also added by the adaptor) are not replaced with their value in the email body.
  • FLM Note 189: Actions on success and escalations now no longer cause a full render and submission. Instead, only the necessary steps (ie the creation of the new variant and routing) are performed. This improves performance and reduces the risk of errors relating to the template not rendering. It may have an effect on the data of the new variant as the following processes will not be triggered:
  1. The validation user-exits. No validation of the form data will be performed during the posting/escalation.
  2. No form will be rendered, so JavaScript onInitialization events will not fire.
  3. The substitution and derivation user-exits. This could affect the form data.
  4. The index user-exit. Index fields will have the same value as at the previous variant.
  5. The XDP user-exit: This could affect the form data.
  6. JavaScript injections: This could affect the form data.
  7. Pre-population (even if the status the form is escalated/posted at is configured as an "additional pre-population status". This could affect the form data.
  8. The template option and ui type user-exits: this means that the new variant will be displayed in the dashboard with the ui type/template option of the    previous variant.
  • FLM Note 193: has been backed out so that customers can see all messages in the spool when posting runs as a background process.
  • FLM Note 198: When a synchronous posting fails, you wish all messages from the posting adaptors to be returned to your Stelo app.
  • FLM Note 199: You wish to improve the performance of loading the form inbox in the FLM portal.
  • FLM Note 202: You wish to improve the performance of the "Form Archive Program" and the "Form Reload Program".
  • FLM Note 204: You wish to exclude Stelo documents from the MultiUI Portal and FLM Forms Manager "Draft View".
  • FLM Note 207: When setting the posting status of a form to "locked" in the FPE or when unlocking it, you wish for an entry to be created in the history table.
  • FLM Note 214: Aquiller support for dynamic logos and signatures.
  • FLM Note 215: In user-group scenarios you do not wish documents locked by other users to be displayed in the inbox.

 

FLM 295 SP6 -> 300 Upgrade Notes:

Installation Tasks:

Activity 1 must to be done in each system.

  1.     Upload and apply the following Add-On upgrades with transaction SAINT.
    1. The Varo (FLM) Add-On FLM_INST_300.SAR
    2. The Varo Form Manager (FLMUI5) Add-On FLMUI5_INST_300.SAR
    3. If the Stelo (Stelo) Add-On is installed then this ACP file is also required. STELO_INST_100_ACP2.SAR
    4. If the Aquiller (FLMCG) Add-On is installed then this ACP file is also required. FLMCG_INST_120_ACP.SAR
  2.     Optional: Run SGEN on FLM after the upgrade has been applied.
  3.     Apply all relevant Varo (FLM) Notes and Transport.

Post-Installation Configuration Tasks:

  • Activate new FLM Nodes.

Ensure all the FLM nodes are active.

  • In transaction SICF activate node /sap/bc/bsp/flm and all subnodes.
  • Activate FLMUI5 SICF Nodes.

If the FLM Form Manager Portal (FLMUI5) was installed as part of the upgrade please ensure the following SICF nodes are active.

  • In transaction SICF activate node /sap/bc/bsp/flmui5 and all subnodes.
  • For more details about the function and features on the Form Manager Portal wiki.
  • For Floe 100 and 105 users.

If version 100 or 105 of Floe is installed please apply Floe Note 0005.

  • Update URL Settings

If the updated installation has a custom change around URL generation or using the DNS Substitution feature in System Specific Settings an update to the configuration is required.

All settings for SAP Reverse Proxy, Web Dispatcher, Web Services and URL embedded in notification emails are now controlled using the SAP HTTPURLLOC table which is the SAP standard approach.

See the Varo (FLM) Administrators Guide for more details.