Currently Being Moderated

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)

 

 

Comments

Actions

Filter Blog

By author:
By date:
By tag: