Comparing Business User Forms and Enterprise E-forms solutions

[chris_scott]

We have been asked many times whether we deliver an HTML form building tool with our software, and our reply has always been that any HTML editor can be used: One of the required skillsets to build HTML forms for SAP is HTML development!

When business users see some of the many different cloud-based form building products, which are designed for business users and easy to use, they sometimes expect the same development experience for building integrated SAP e-forms. However, such ‘Enterprise e-forms’ need to support robust SAP business processes, and are necessarily technical objects that require the same kind of IT expertise as other SAP UIs.  Business users don’t develop SAPGUI, SAPUI5 and WebDynpro, and nor should they expect to develop Enterprise e-forms.

There is of course, a place for business user-managed forms, and these represent a great way to collect data on-line for feedback, surveys, or any process with little or no SAP integration.  Google Forms has provided this functionality for a long time, and there are similar offerings from Adobe, Formstack, Cognito and others.

For other public-facing forms, such as applications forms, which have a deeper integration to your SAP back-end systems, then a tool like Varo is required, in order to manage the entire form process within your SAP system, enable deep process integration and business services such as data pre-population and validation.

This table shows a quick comparison of the functionality you can expect:

Business User Forms	Enterprise E-forms for SAP
Cloud-based Form Designer, with an object library.	Form design based on data schema or interface to SAP. Form template is technical object with field-binding to the interface. Changes to the form template are made hand-in-hand with changes to the back-end interface or business logic.
No pre-population from SAP.	Form data is pre-populated using APIs and business logic, based on authenticated user or ‘document’ number.
Static value support for drop-down list options.	Drop-down lists filled from static list or derived from the SAP system using business logic.
Some simple field validation available such as mandatory field checks.	Data validation can take place on the client-side (using JavaScript) or on the server-side, such that SAP data and APIs can be used to validate data pre-submission.
Publishing of forms to cloud server. Option to embed forms into other websites or applications like Facebook.	Forms are typically published on the SAP system acting as a web server. Publishing forms on a 3rd party web server is possible (i.e. for forms with no authentication), with a communication channel defined between the form and the SAP system.
Public-facing forms, either with no authentication or users managed in the cloud system.	Typically users authenticate to an SAP system to access forms. Anonymous access is possible, but likely to impact security design (publishing in the DMZ etc)
Submission of form data to cloud server.	Form data is submitted into the SAP system, and can trigger workflows and updates.
Simple notification e-mail generation.	Notification emails, reminder emails and escalations can be delivered using simple or complex business rules within the SAP system. Users can access forms through links or through an SAP Inbox.
Simple approval processes.	Simple or Complex dynamic workflows for multi-step processes and approvals are supported.
Manual data extraction, or API for reading data from submitted forms. Option to push submitted data to 3rd party systems using pre-delivered interfaces or ‘webhooks’.	Data can be integrated with SAP processes and non-SAP systems using any of the interfacing technologies supported by SAP.
Form processes are started manually with a blank form.	Form triggers can be built into SAP processes, passing in form data for pre-population, to deliver seamless process integration.