The use of Internet Explorer has declined rapidly over the past 10 years, while the use of Chrome and Safari has become widespread, driven in part by web consumption on mobile devices.
With the launch of Microsoft Edge, which will not support on-line PDF forms, and with the ending of plug-in support by Google Chrome, the days of the on-line interactive PDF form are surely numbered.
IFbA is compatible with Internet Explorer and Firefox, which together represent only around 25% of the browser usage – and falling. Latest figures on w3schools.com show IE use falling from 88% in 2003 to just 6.5% in 2015. Firefox use peaked at 47% in 2009 and is less than 22% today.
With built-in PDF readers available on every device, as part of PC operating systems and web browsers, the once-ubiquitous Adobe Reader is becoming conspicuous by its absence. For most people there is no need for Adobe Reader any more.
Adobe is telling customers to move away from PDF-based forms and use HTML forms instead.
Faced with growing evidence and increasing customer anxiety, as a long-term IFbA evangelist I am forced to re-examine whether I should still recommend ‘SAP Interactive Forms by Adobe’ for data capture, and consider the use cases that the technology supports best.
What are the concerns?
1. On-line Interactive Forms
The over-riding problem with on-line interactive PDF forms is the diminishing browser support. There was a time when Internet Explorer was everywhere, but this is no longer the case, particularly with the introduction of Edge.
In enterprise e-form scenarios, organizations have lost control of what browsers are being used to consume web content as they have rolled out mobile devices or BYOD policies.
Consumer e-forms must, of course, work on any device.
Although Adobe’s LiveCycle product has been able to support Chrome until now, Chrome, like Safari, has never been officially supported for IFbA (see SAP Note 1918612.)
Microsoft Edge support is not planned for BSP, SAP GUI for HTML and all UI technologies with active components (see SAP Note 1672817.)
Since IFbA is not compatible with Edge, Chrome and Safari, and does not work on mobile devices, the ability for users to consume on-line interactive forms is enormously restricted.
Adobe’s advice to LiveCycle customers is to upgrade to ‘AEM Forms’ in order to abandon PDF in favour of HTML. (As an interim measure Adobe also suggests changing each business process to use off-line PDF forms: this is not a recommendation that I would advocate!)
SAP has not provided any specific advice other than to use Internet Explorer 11. (See SAP Note 1672817.) And further, SAP will stop supporting browser versions of Internet Explorer lower than IE11 on January 12, 2016.
SAP recommends Arch FLM for mobile forms scenarios. (See page 9 of the IFbA product roadmap). This approach involves moving to HTML forms, which not only delivers forms on mobile devices, but on any web browser.
2. Off-line Interactive Forms
Off-line interactive PDF forms do not require any web browser plug-in, and so are not impacted by the diminishing browser support issue.
However, they do rely on Adobe Reader being installed locally on each user’s PC, and this represents a different concern.
At one time Adobe Reader was found on almost every PC, and in many cases was actually shipped with new PCs. But these days both Apple and Microsoft include a native PDF reader application as part of the operating system.
Mobile devices also are able to display PDF documents without the need to install PDF reading software.
Quite simply, there is no need for Adobe Reader anymore. And without Adobe Reader, off-line forms won’t work.
Moreover, if a user decides to install a different PDF reader on his/her PC or device, there are many PDF applications to choose from. But these applications do not support fillable PDF forms; only Adobe Reader will do the job.
Despite some support on Windows tablets, the Adobe Reader mobile apps for IOS and Android also do not support fillable forms. So off-line forms on mobile devices isn’t an option: Each user needs a PC with Adobe Reader installed.
If off-line forms were aimed at users within the enterprise then this might not be a particular issue for many organizations. However, the main benefit of off-line forms is to extend business processes to external user communities and non-SAP users, reaching beyond the corporate firewall.
So the problem in a nutshell is that the use scenario requires desktop pre-requisites for external user communities. This greatly restricts the number of realistic processes that can be delivered using the off-line forms approach.
3. Document Output
The third use scenario is output or ‘print’ forms for document output.
Since 2004 SAP has supported three different output technologies (SAPScript, SMARTFORMS and IFbA), all of which designed in the first instance for the production of printed transactional output, such as purchase orders, delivery notes, order confirmations, invoices, labels etc.
Notwithstanding the use of EDI for regular B2B traffic, over the last decade the de facto mode of business communication has become e-mail as the use of printed output has declined.
One advantage of IFbA is that the generated PDF can not only be sent to a print spool but also attached to an e-mail, such that paperless communication can be delivered without changing the output template.
However, the world has moved on again.
Consumers who place web orders for goods, or who book trains, flights and hotels, don’t expect a plain e-mail with a PDF attachment.
Organizations who purchase on-line services, for example, from Amazon, Mailchimp or LinkedIn, don’t expect a plain e-mail with a PDF attachment.
In these scenarios we expect the detail of the order confirmation to be contained within the body of the e-mail itself, and for the e-mail to look great on different devices.
Many other business documents no longer require the production of a PDF document, as the recipient can self-serve via a web portal or receive process notifications by e-mail.
IFbA can only generate PDF documents, not HTML e-mail content. This means that there are lots of use cases that it’s the wrong technology for. Astoundingly, there is no way to maintain HTML e-mail templates within SAP. That’s why we built Floe and launched it earlier this year. (See my blog post HTML E-mail output from SAP ERP & S/4HANA.)
Ongoing support for IFbA
The two central components of IFbA, Adobe Document Services (ADS) and LiveCycle Designer, are parts of the Adobe LiveCycle product suite built into NetWeaver.
Adobe has now stopped investment in LiveCycle and is encouraging its customers to move to the cloud-based alternative, AEM Forms. The latest version of LiveCycle (ES4) will be supported until March 2018, with extended support ending in March 2020. (See Adobe’s End of life matrix.)
SAP ships Adobe components from a previous version (10.4) with NetWeaver 7.4*, which Adobe will support until March 2017, with extended support until March 2019. The versions of LiveCycle from which the IFbA components are taken for earlier versions of NetWeaver are no longer supported by Adobe, but SAP customers will still get support from SAP in line with their existing licensing arrangements. (See SAP Product Availability Matrix.)
Since SAP are committed to supporting Business Suite applications like ERP 6.0 and CRM 7.0 until 2025, then we must deduce that SAP and Adobe have or will make a special arrangement to safeguard Adobe support for IFbA until then.
*SAP support for NetWeaver 7.4 will end in 2020.
What is SAP doing with IFbA?
Looking again at the latest product roadmap, it is clear that SAP have plans for further ‘continuous improvements’ and a shift to the cloud.
SAP maintain that their forms strategy is based on IFbA, and that they are continuing to ‘invest heavily in IFbA’.
“SAP Forms as a Service” was launched this year (see my product review), which enables customers to move to a SAP-hosted version of ADS for PDF rendering.
The planned innovations include:
- Improvements to SAP Forms as a Service to support multi-tenancy and S/4HANA;
- Support document archiving using latest version of PDF/A;
- Print support for CAB printers and ZPL label printing;
- Support password encryption for generated documents.
No HTML form rendering is planned for IFbA. The focus continues to be on document output rather than data capture functionality.
Is E-forms dead or thriving?
As consumers we are surrounded by e-forms: Booking forms (trains, flights, restaurants, theatres, museums, exhibitions, theme parks, sporting events etc.); registration forms; feedback forms; application forms; tax forms; forms to sign-up for services; survey forms; insurance forms; healthcare forms; and many local/central government forms.
Such e-forms are generally embedded into websites: they are HTML forms, with graphics delivering a rich user experience.
Businesses continue to rely on e-forms for many processes, both internally and externally facing. Some organizations have heavy use of forms (e.g. police, government authorities, utilities, social care, insurance, healthcare, pharmaceuticals).
Some organizations rely on forms for particular business processes (e.g. proof of delivery capture, new customer application). Other organizations use forms for complex HR processes (joiner/mover/leaver), shared service provision (change of benefits, pensions, payroll etc.), master data management, purchasing approvals, work order completion etc.
These e-forms can be delivered in a number of ways: built into web applications or mobile applications, pop-up forms triggered on demand or standalone e-form processes.
So, far from being dead, e-forms are thriving!
SAP delivers the ability to create e-forms in each different UI technology, since the e-form concept for SAP is merely a data capture mechanism that ‘front-ends’ a back-end transaction: In the standard SAP model, the e-form is linked to a BAPI; it is just a different UI.
Adobe and Arch take a different approach: Their e-forms products enable the development of end-to-end e-forms processes. This means that a single technology can be used to manage all enterprise e-forms processes. At various points of the process the e-form is integrated with SAP systems for searches, validation and updates, for example. Since Arch FLM is installed with the SAP system, integration is much easier than third party products that require many interfaces to work with SAP data.
The need to deliver enterprise e-forms processes is clear, but the standard SAP toolkit does not lend itself to the building and management of many e-form processes.
Ongoing need for PDF: Use cases
I see three types of use-case for large-scale enterprise use of generated PDF forms and documents:
1. Transactional Document Output
Organizations cannot replace all printed output with electronic output. There is an ongoing need for label printing and for invoice printing where electronic communication is not possible. So where PDF is used for delivery notes and labels, for example, the requirement is clear, as is the need to support printers, character sets and barcode printing.
Secondly, there are specific output documents with legal requirements for retention. Customer invoices, for example, may need to be saved in an archive or document server for retention for several years, depending on the country of issue.
PDF remains the golden standard for archiving.
Although a lot of SAP document output could be replaced with an HTML e-mail approach, the PDF lends itself for archiving in a much better fashion than an HTML or e-mail file.
Such documents might be generated in different ways to support a variety of use cases:
- En masse generation using SAP document output, sent to printer or by e-mail.
- En masse generation and published to web server for self-service access.
- Individual generation on request from web server: E.g. Generate tax receipt.
2. Download and Print Forms
I still see scenarios in which users or consumers are asked to ‘download the form’, fill in the details, sign and send by post. Although in general I expect this kind of use case to continue to diminish, there are situations when it remains necessary:
- When electronic communication is not possible
- When a ‘wet signature’ is legally required
The capability of PDF forms for printing make this the best approach to deliver such forms, and the same form could be designed to work as an off-line e-form, in order to support more than one use case: Users or consumers could be given the choice of either printing the form to fill in and send manually, or installing Adobe Reader in order to submit the form electronically.
3. Dynamic Document Generation
A third set of use-cases, which is greatly under-used with SAP, is the production of documents with dynamic content: Rather than the production of a brochure, contract or letter with the same content, the content can be built dynamically based on business logic. Typically this is not associated with a single transactional document within SAP but generated as part of a process. Examples include:
The opportunity exists for large-scale dynamic document generation driven by SAP data and generated by IFbA.
In summary, there are many output scenarios for PDF, many of which are under-exploited. However, PDF for data collection in the future is much less viable, which is why both Arch and Adobe are saying that now is the time to make the move to HTML e-forms.
Options for SAP customers
Let’s consider the various types of on-line deployment: SAP customers may be using a mix of:
- Pre-delivered e-forms from SAP supporting various transactions (E.g. CRM, EHSM, HCM).
- Custom-built e-forms using web dynpro containers, linking to BAPI or Workflow.
- Custom-built e-forms processes using Arch FLM.
For FLM processes the transition is easy, and simply requires the definition of an HTML form template.
For web dynpro based forms, extra work is required: You can keep the web dynpro screen and embed an FLM HTML form to enable the switch, or implement the e-form process within FLM, replacing the web dynpro. Both scenarios involve defining the business logic to support the form process within FLM, which involves a mixture of configuration and user-exit development. Alternative approaches could include the development of a custom Fiori app (if the e-form requirements are very simple), or the deployment of Adobe AEM Forms (if no SAP integration is required).
Replacing the pre-delivered SAP e-forms scenarios will require the most effort since the move away from the standard SAP transaction will inevitably involve business process change. This provides the opportunity to consider whether an e-form process is the best model for the requirement or whether a web application is a better fit.
In the meantime, customers should use Internet Explorer 11 and Adobe Reader 11 for as long as they are supported. Note that Reader 10 end-of-life is November 2015 and Reader 11 end-of-live is October 2017. (See Adobe’s End of life matrix.)
Off-line PDF forms has become a specialized use case for particular business process scenarios. Organizations who have deployed off-line forms should consider the possibility of offering an on-line alternative using an HTML e-form, unless they are serving a closed community of users who all have Adobe Reader installed.
For existing output forms there is no need for urgent action, as PDF documents can be read by just-about any device. However, there are opportunities to improve the business process and user experience:
- Replace PDF attachments for SAP document output scenarios with HTML email.
- Note that PDF documents are often not the best media with which to send data to smart phones. E-mails or web-based content is better suited.
- Consider building PDF-based solutions for self-service scenarios and for dynamic document generation, using SAP data and business logic to dynamically drive and personalize the generated content.
SAP Interactive Forms by Adobe customers who use PDF on-line forms need to ‘upgrade’ to HTML forms, and in some cases urgently. The technology does not have a long-term future for enterprise data capture.
SAP Interactive Forms by Adobe as a technology remains an important tool for SAP customers to generate transactional document output such as purchase orders and invoices. It can also be used to create contracts and letters, document packs and mass communication: There are many opportunities for customer to use IFbA for dynamic document generation.
There are many, varied use cases that the technology can support. However, customers should focus on dynamic document generation opportunities and move to HTML forms for electronic data capture.