Skip to Content

5 lessons for SAP e-forms

Since SAP announced their endorsement of Arch’s Form Lifecycle Manager (FLM) in July 2011, there has been a huge increase in interest in SAP e-forms.  And that’s quite right, as after all, Gartner say that 85% of processes require forms, and Forrester say that 72% of consumers prefer on-line self-service.  So whether processes are designed for employees, business partners or external user communities, the intelligent use of e-forms can extend the reach of your core SAP system.  This delivers 3 huge benefits:

  • Much greater usability;
  • Improved data quality;
  • More efficient processes

Having delivered SAP e-forms solutions since 2003, we’ve learned a great number of lessons.  I’ve chosen five to help clarify some of the confusing messages we sometimes see.

1. You need robust process management with a fantastic user interface.

It’s the combination of high-quality robust business processes together with an easy-to-use, professional, user-friendly interface where the best results are driven.

That’s why we seek to ground the forms processes and all the associated business logic in SAP technology, so that all your business logic is in one place, and in the right place.

SAP is great at building enterprise software, and there is already a huge amount of data already in your SAP systems, and so the form logic should all reside inside SAP. 

The best user interface for forms traditionally has been PDF, but now with a mix of new devices being more widely used, HTML forms are increasing in relevance.  So you need a solution that can serve forms onto smart phones and tablets as easily as onto PCs. 

2. Best results come from an integrated form server. 

A form server embedded into SAP beats an external one in so many ways.  For example:


  • Low software footprint + deep data integration

An external form server requires its own hardware and database, together with the related on-going maintenance and support.


low footprint, high integration


  • Asynchronous updates 

Because the form data is already stored within SAP tables, any updates to SAP functions can be de-coupled from the final user submission. In this way the user is protected from any update error messages, and the system can automatically re-try later and/or inform an administrator.


  • UWL integration

For work in progress, the SAP Universal Worklist can be used, so that users don’t have to manage multiple inboxes.


  • Form process administration and reporting

Since the form data and the form process data is stored within SAP, you can administer those processes within SAP, and report on forms in process.


  • User authentication and authorisations

Many forms contain sensitive data, or you might want to restrict which users can use which forms; for example, perhaps all users can access employee self-service forms, but a limited number of users can use finance forms. With the embedded form server you can use SAP authorisations to control all this.


  • Impact on system performance

An external forms system will necessitate a high number of calls to the SAP system, typically using web services.  An internal form system can pre-load the forms with business logic from SAP, to reduce the amount of data traffic and database calls. 


3. Web-services can be a bind!

There is a place for web services in on-line forms, and that’s for triggering server-side validation or for making database searches, typically for master data selection on a form.

Web-services are great, but you have to build them and you have to bind them. Building them can sometimes be a technical feat, and binding them has its own set of issues:  For example, if a form template in the development system is bound to a web-service hosted on the development system, then when the form template is migrated to the production form server it needs to be changed to re-point the web-services to the SAP production system.  This adds risk, since the result is different form templates in your development, test and production systems.*

Forms often use cascading drop-down lists, where a selection of one drop-down list option defines the list of available options in a related drop-down list. And these might be 4 levels deep (for example payscale type/area/grade/level in SAP HCM).  In a scenario where that form relies on web service, then each drop-down list has to be bound to three different data sources, and triggers a separate web service and database call.


cascading dropdown list


There is a myth that using web services is easy, and some people even peddle the line that business users could build forms based on web-services. The truth is that web services can be difficult to build, difficult to manage, and if the number of forms or number of uses is high then the work processes will be taken up, and this can dramatically affect system performance. 

4. Front-ending is flawed.

If you’re trying to build a form to replace a SAP transaction, then you’re starting from the wrong place.  A form isn’t a different type of GUI to sit in front of a SAP transaction, a form is a method of data collection from users that requires no training, and is designed to maximise the data collection experience.  So where the SAP transaction in SAPGUI or webdynpro is likely to have lots of drop-down lists for all the SAP objects required for the document posting, a form should deliver a much simpler and intuitive experience.  For example, often the SAP terminology will be replaced on the form for field captions with language that non-SAP users understand.

Even if ultimately the form process will trigger an SAP update of some kind, a lot of the data required for the update can often be derived and doesn’t need to be on the form template or in the form data model.  So basing a form on a transaction recording is a fundamentally flawed design methodology.

Using an SAP transaction call on form submission is generally a bad idea, even if it’s wrapped in a web service.  A major problem is error handling in the event of the SAP transaction failing.  So for example, many forms processes involve a 1-step approval, where a lot of the form fields are locked at the approval stage.  If the form process is designed to post an SAP update when the manager approves the form, and there is something wrong with the data, then it’s quite wrong to send back errors to the manager. Beware of any forms with ‘Update SAP’ pushbuttons!

5. Codeless forms are a myth.

The focus of the form template design should be on usability. This often requires a lot of dynamic form behaviour to present the required form fields in the most attractive and logical way, driven by choices the user has made, data they have entered, or logic derived from SAP. Propositions that suggest that form template development can be delivered by business users enormously limit the functionality of the resulting form.  High-quality business forms require form template development that is beyond business users.

With the complexity of SAP data, solutions that suggest that forms can be built easily without code, rely on either:

i)  the production, management and over-use of a huge web-service library,

ii) pre-delivered SAP integration that is inflexible, or

iii) a set of configuration tables that are so complicated to maintain it requires a functional and technical guru to produce even simple results.

Instead of striving for codeless forms, you should strive for modular approaches for building form templates, business logic and form logic in order to maximise re-use, reduce maintenance and minimise coding of JavaScript.  The SAP e-forms approach puts form development into the hands of developers with traditional skillsets – simple ABAP user-exits in the main.  These are skills you already have or you can get readily and cheaply from your SI partners.


 (*Technical Note: FLM overcomes this issue by automatically re-pointing web-service definitions at run-time)



You must be Logged on to comment or reply to a post.
  • Very nice blog! It’s will be interesting to see how well adopted eForms are. I have to ask….due to “painful” Adobe experiences…..what is the licensing like for this if you happen to know?

    Thanks for the blog and keep them coming!

    • Thanks Chris!

      On licensing my offical position is that ‘I don’t know and you need to talk to SAP.’

      However, there has certainly been a shift in the SAP licensing position, and we’re seeing more reasonably priced deals.  The list price is still high, and this makes it difficult for customers in some countries where the discount level is capped. I am seeing a softening of the approach to limit the licence to a number of forms, so you don’t get killed that way.  There’s definitely still room for improvement!

      FLM is separately licensed and comparatively cheap, as there is no forms/user matrix that pushes up the price.

      For HTML forms then you’re looking at PUL licensing for new SAP users but no SAP Interactive Forms license.  For my next blog entry I’m planning to drill down into the differences between HTML and PDF forms.

  • Chris, I have a question here, when SAP HCM already has HR Processes and Forms, what extra benefit the FLM provides over HRASR design time?. And is there any benefit of e-forms over HCM Processes and Forms?.

    Thanks, Raghavendra

    • Hi Raghavendra,

      Many thanks for the question – it is one we hear often!

      There are many differences, but here are some highlights:

      1) FLM enables you to build any e-forms process, not just HR processes.  Having said that, more than 50% of the use cases are for HR forms, and the majority of those customers have tried HCM P&F first, and then found FLM.

      2) FLM enables process mobilisation: Since it can use either PDF or HTML form templates, or a mix, FLM can enable you to extend forms processes to mobile devices such as iPads very easily.

      3) Building custom processes with HCM P&F is difficult – it involves a number of skillsets, including the interface/service definition, SAP workflow and the HR action + P&F framework configuration.  With FLM you need simpler IMG configuration + ABAP user-exit skills.

      4) The web Dynpro user interface for launching the forms with HCM P&F doesn’t provide optimum usability – in some cases you see SAP menus at the top, the process diagram at the bottom and a ‘letterbox’ in the middle of the screen that the form is displayed in.  With FLM the form always takes up the entire screen.

      5) I don’t have empirical evidence, but customers have reported that the time to render a form takes longer with HCM P&F, as the framework is quite ‘heavy’.

      6) HCM P&F relies on web Dynpro, so you have the combination of the browser, SAP and Adobe software all to keep in line.  Problems can occur if, for example, a user updates their version of Internet Explorer or Adobe Reader because their is always a timelag before everything is supported.  With FLM you can overcome software compatibility issues by rendering forms via BSP or by using HTML instead of PDF templates.

      So although both are form-serving frameworks, the approach is very different: The HCM P&F approach was designed to minimise ABAP development for simple forms, and to pre-deliver some processes and forms.  However there is a price in terms of the flexibility, performance and usability. 

      With FLM we provide common pieces of the jigsaw such as drop-down lists, cascading drop-down lists, JavaScript snippets but we don’t deliver out-of-the box forms, since in our experience the form template design is so quick it’s easier for us to start with a blank ‘master’ template than with an existing form template, given the great differences in customer requirements we see.  But of course, since we’ve delivered so many HR forms over the past few years, we often show people different approaches to tease out the best approach/design for a particular customer.

      It is much easier for customers to understand the relative benefits of FLM if they have already tried to build custom form processes using HCM P&F first.

      • Thanks Chris for your time and putting things very clearly.  I cannot see any useful documentation on this new stuff other than your blogs, where do I start and what are the steps to be followed. If this is better than HCM P&F then that is great, I have been working on HCM P&F for quite some time and yes I agree there are performance bottle necks.