1 2 3 5 Previous Next

SAP Interactive Forms by Adobe

66 Posts

There is a requirement that we need to render rich text of html in our adobe form. As we all know that adobe doesn't know HTML but we may need to render HTML tags, for the same requirement follow below steps.


Step 1). Passing HTML to our form and set DOCPRAM-DYNAMIC = 'X'.


I created one Exporting parameter to pass my HTML rich text. You can get your HTML from SO10 also, and assign to Exporting parameter of your adobe FM.


Step 2). Create field in adobe form and set Field formate as Rich Text and bind with R_HTML.

Untitled.png  Untitled.png


Step 3). Then Test.


Not expected output.


Step 4). Now add below javascript on docClose event of field.


var envelope = "<?xml version='1.0' encoding='UTF-8'?>" +

  "<exData contentType='text/html' xmlns='http://www.xfa.org/schema/xfa-template/2.8/'" +

  "><body xmlns='http://www.w3.org/1999/xhtml' xmlns:xfa='http://www.xfa.org/schema/xfa-data/1.0/' " +

  "xfa:APIVersion='Acroform:' xfa:spec='2.1'>" +

  "<p>"+ this.rawValue +"</p></body></exData>";




Step 5). Now Test.



Hope this helps.



I'm having one table with multiple headers.


I'm having three headers, i'm hiding second header, using java script it's looks good at first page




PAGE 2 (subsequent page) issue page.


Blank space is there in place of second header.


I tried too many thing for this, raise threads but no response.


So i found one alternative do perform this kind of scenarios.




You need one flag variable in your interface.



Set FLAG in Code Initialization of Interface. You can define your logic for setting flag.



Make use of ALTERNATIVE, (in your form)



After creating ALTERNATIVE, drag your table in TRUE and FALSE sections, and set Alternate condition.



Now Go to layout, and drag and drop ALTERNATIVE node from Data View. Two table created on your page.

Now add header rows according your requirements. and wrap them into Section. (Select rows -> right click -> Group as Section)

and check repeat on subsequent page and initial page


Set Content type of sub-form ALTERNATIVE, TRUE and FALSE toFlowed.


Set Overflow of sub-form ALTERNATIVE to Go To Page 1.


If flag = 0 it display 1st table with two headers, else 2nd with three headers.

Hope this helps.

Rendering HTML/Rich Text in Adobe Form is one of the common requirements people often have.

So here is the step by step process to achieve it. 


Do this in ABAP
1) Convert html to xstring - lv_html is your html string

DATA: lv_html TYPE string.
DATA(lv_len) = strlen( lv_html ).
DATA(lr_conv) = cl_abap_conv_out_ce=>create( ).
lr_conv->write( data = lv_html n = lv_len ).
DATA(lv_xstr) = lr_conv->get_buffer( ).

2) XFA doesn't support most of the HTML tags so do the XSLT transformation for the tags you need

          SOURCE XML lv_xstr
          RESULT XML lv_xstr.
   CATCH cx_transformation_error INTO DATA(lr_transformation_error).

3) Encode xstring to base64

CONSTANTS: lc_op_enc TYPE x VALUE 36.
DATA: lv_base64 TYPE string.
      ID 'OPCODE' FIELD lc_op_enc
      ID 'BINDATA' FIELD lv_xstr
      ID 'B64DATA' FIELD lv_base64.

4) Example XSLT


<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:sap="http://www.sap.com/sapxsl" version="1.0">
  <xsl:output encoding="UTF-8" indent="yes" method="xhtml" standalone="0" version="1.0"/>
  <xsl:strip-space elements="*"/>
  <xsl:variable name="vDelims" select="'- • # '"/>
  <xsl:template match="@*|node()">
      <xsl:apply-templates select="@*|node()"/>
  <xsl:template match="/">
  <xsl:template match="h2">
      <xsl:apply-templates select="@*|node()"/>
  <xsl:template match="ul">
    <p style="text-decoration:none;letter-spacing:0in">
      <xsl:apply-templates select="@*|node()"/>
  <xsl:template match="p">
      <xsl:apply-templates select="@*|node()"/>
  <xsl:template match="li">
    <span style="xfa-tab-count:1">         </span>
    <xsl:for-each select="ancestor::ul">
      <xsl:text>  </xsl:text>
    <xsl:value-of select="substring($vDelims,&#xA;              2*(1+count(ancestor::ul) mod 3) -1,&#xA;              2)"/>
    <xsl:value-of select="."/>


Do this in Adobe Form field's javascript

1) Create a global variable "Base64" and paste the script from below link



2) Write below code in the field's javascript to decode base64

var b64 = this.rawValue;
var xhtml = base64.Base64.decode(b64);

3) Make sure the script is set to Run At Server, if it's an interactive form


4) Make sure the field is rich text enabled





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 FormsEnterprise 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.
Good news for all who like to test SAP Forms as a Service by Adobe live: a free trial offering is now available within the official HANA trial landscape.

Simply logon to the SAP HANA Cloud Platform cockpit on trial landscape to access the service:
If you don't have a user to logon, you can register here:
If you are going to check it out, please keep in mind that there are a few limitations compared to the official version:
      • the trial period is 30 days
      • you can send up to 300 requests (max. 5 pages per request)
Once you are logged on, you can use a self-service to enable SAP Forms as a Service by Adobe (this self-service is only available on the trial landscape for external customers).

Choose Services from the navigation panel to access the list of available services. As you can see, SAP Forms as a Service by Adobe is still in status not enabled:

Click on the service to access the detail view. The configuration links at the bottom of the screen are still disabled. To activate them, just press Enable:
Now, after a short processing time, the service and the configuration links are enabled:
Choose the link SAP Forms as a Service by Adobe (Roles & Destinations) to access the Roles & Destinations view.

The user name you used to enable the service is assigned to the roles ADSAdmin and ADSCaller automatically:
For the remaining setup tasks just follow the steps described in SAP Forms as a Service by Adobe documentation and you can start exploring all the features that this service provides. See also my blog posts in SAP Forms as a Service by Adobe: Get off the Ground...

Chris Scott has kindly listed the general approaches to Adobe Interactive Forms performance optimization in his post. As it's mentioned in the post the main bottleneck is often ADS renedring. I'm going to tell about one possible way of ADS rendering and Data transmission time optimization. It was really helpful for me when I was developing Adobe forms for automotive business.


The customers have often strict requirements on the output forms layout and on the logos/images printed on the forms. There logos are part of the companies' brandbooks and have requirements on the colors, density, image quality and image proportions. As result the form developers must often use heavy true color images which increase form size and the time of ADS rendering and Form transmission from the ADS server to the client's PC.


As result the developers must be careful while using images on the forms. The images are the first things to be checked during Adobe forms performance optimization. Even a small pixel size logo can blow your form up making it considerably bigger. As result the user will wait for a long time till the form appears on the screen/printed on the printer.


You must check your image file size and optimize the image if it's big enough compared to the PDF form size.


First thing to be done is to convert the images to a proper image format. It should be JPG or PNG files, the uncompressed bitmaps (BMP) must be avoided. Personally I prefer to use JPG because it's usually smaller and the format provides more possibilities for optimization/size reduction.


The second step is to minimize the image pixel size. It must be so small as needed for the form image size. There enough free or standard Windows tools providing such functionality. Even Windows Paint application can do this.


After the logos are converted to JPG you should to optimize your image. There are several online JPEG compressor services available (JPEGmini, TinyJPG, etc.). They are free and intuitive easy to use. You have to upload your JPG file onto the online compressor and download the compressed file. The images are usually compressed saving 40%-70% of their original size with no quality loses! As result you can decrease your form size and the form generation time considerably.




Hope this small tip will be helpful for your performance optimization.

This year I will be traveling to SAP TechEd in Las Vegas to co-present with Jenny Lundberg.


We've talked about this before and this year we are super excited to present a new offering called SAP Forms as a Service by Adobe in the session ITM123 SAP Interactive Forms by Adobe Configuration for ADS on SAP HANA Cloud.


And of course we want to let you know about the latest IFbA improvements, new features and what our future plan looks like in the session DEV801 Road Map Q&A SAP Interactive Forms by Adobe - On-premise and in the Cloud.  The Q&A session is also your opportunity to ask questions, provide feedback and let us know what you would like to see in a future release.


Feel free to let me know upfront if you would like to meet me in Las Vegas.


Links to the sessions in Las Vegas:


Road Map Q&A: SAP Interactive Forms by Adobe – On Premise and in the Cloud

Tue 04:15 PM - 05:15 PM


SAP Interactive Forms by Adobe: Configuration for ADS on SAP HANA Cloud

Tue 05:45 PM - 06:45 PM


SAP Interactive Forms by Adobe: Configuration for ADS on SAP HANA Cloud

Thu 03:15 PM - 04:15 PM

Over the years the biggest bugbear that customers have with SAP Interactive Forms is performance: time and again I hear reports that the PDF forms render too slowly.  In this blog update I’m going to discuss what causes performance issues and what we normally analyse to overcome such issues.





The time it takes to open a rendered PDF form is comprised of several components:

  • ADS Render time;
  • Application logic time;
  • Data transmission time;
  • Adobe Reader launch time;
  • PDF rendering on the client / script running time.



Each of these components needs to be considered to determine where the delays are occurring.



ADS Render

Often the main bottleneck is the time the form takes to render in ADS.  The two major considerations in ADS performance is the underlying CPU architecture, and the design of the form template [overlapping objects, use of drop-down lists etc.].  Using the ADS trace can provide some insight.  Also consider:

  • Platform Architecture where ADS is deployed;
  • Java JVM version being used;
  • Use of web dispatcher;
  • Form template optimization.



Of course, the ADS component doesn't operate in isolation and overall system performance and bottle necks will impact its performance.  This can also include landscape architecture, SAP release and support packs deployed, and the physical locations of server hardware.  Consider:

  • Overall server load;
  • SLD setup;
  • Physical locations of ABAP and Java Stacks;
  • SAP Release and Java JVM version.



Application logic

The application used to call ADS and to serve the e-form to the user may also cause issues.  For example, the HCM P&F framework can be slow, or custom form applications may need optimising both in the ABAP application logic and in the portal page.  If a web Dynpro layer is used between the web front end and the back-end system then SAP software versions can impact results.  Traditional SAP tools for performance optimisation can be used in some cases.  Also consider:

  • Use of RFCs;
  • Custom ABAP code;
  • How ADS is called by the application program.



Data transmission

Another key factor in addressing any perceived end-user performance issues is network speed. Depending on the usage scenario slow network speeds can be have a serious impact on the usability of large and complex SIFbA processes. Consider:

  • Bandwidth Speeds;
  • Remote locations;
  • Firewall  / VPN constraint;
  • Form template size in bytes optimization.


Adobe Reader launch

An often overlooked aspect of ADS and SIFbA performance analysis is the user’s desktop configuration and ensuring that the combination of software being utilized is compliant with SAP recommendations.  Of particular interest are:

  • Desktop Speed and Windows Version.
  • Avoid Reader X prior to 10.1.2 as there is a network and JavaScript bugs that can affect performance.
  • Anti-Virus software.



Local Rendering

The final component to check is what processing is occurring within the form when it is rendered locally by Adobe Reader.  Check for:

  • Client-side JavaScript running during initialization and form ready events;
  • Web service calls without user action.



Consider the Process

When considering performance and sizing for SAP Interactive Forms you should consider the peaks in activity: Some form processes are not particularly time-critical and do not typically have activity peaks, whereas processes such as timesheets and expense forms may need to be submitted by a particular date/time, and may cause performance issues during specific time periods unless this has been considered properly.



Another potentially unforeseen issue is in the use of attachments.  If users attach many / large attachments to forms then this can cause performance issues due to the size of the data packet.  You can optionally remove the ability for users to add attachment files, or you can add a check to limit the size of attachments in order to combat this issue.



Finally, a multi-UI approach with Arch FLM will reduce the number of calls to ADS, improve render speed and enable process mobilisation.  FLM also includes an ADS Performance Workbench to help identify performance issues before they impact the business.



If you consider this checklist adequately there is no reason why SAP Interactive Forms by Adobe should run slowly any more.



Arch FLM is a SAP-endorsed business solution.

SAP-endorsed business solutions are complementary to SAP® software offerings, have been specifically integrated with SAP solutions and tested by SAP, and provide additional choices and flexibility for businesses running SAP software. SAP-endorsed business solutions are offered by SAP partners.

SAP Forms as a Service is a new PDF form rendering service on the HANA Cloud Platform (HCP).  It is a cloud service for the rendering and de-assembly of PDF forms, based on the Adobe Document Services (ADS) component that traditionally runs on an SAP NetWeaver JAVA stack on premise.  It is a version of SAP Interactive Forms by Adobe with the ADS component in the cloud.


SAP Forms as a Service2.png


Since the ‘Form Processing Framework’ and template repository remain on premise, this is a hybrid solution for delivering SAP Forms.


What does it do?

Functionally this provides the same scope as the on premise version:

  1. Render of non-interactive (‘print’) PDF forms for print, e-mail or archive;
  2. Render of interactive PDF forms for off-line scenarios;
  3. Render of interactive PDF forms for on-line scenarios.



The interactive forms can be ‘static’ in order to support annotations, or ‘dynamic’ to support client-side presentation logic.  The technology supports attachments, digital signatures and server signatures/certificates.


The only significant difference, apart from some restrictions on digital signatures (HSM / MSCAPI credentials) is that the HCP version does not support parallelization, which has been essential for some customers who need to generate very high numbers of documents.


How it works

Setting up the new service is straightforward.  The first step is to subscribe to the new service.  This allows you to assign roles and then configure the ADS service through the HANA Cloud Platform.

SAP Forms as a Service3.png


Then you re-point your on premise ABAP stacks by configuring a new ‘ADS’ RFC connection in transaction SM59, and import some certificates to the Trust Manager in transaction STRUST in order to establish an SSL connection to the cloud.

Finally, some scenarios require the HANA Cloud Connector, and so this also needs to be set up and configured.

SAP Forms as a Service1.png


Benefits of the new approach

SAP Forms as a Service provides a number of benefits:

  • Some customers will find that they no longer need to manage an on premise SAP NetWeaver JAVA stack if they move to HCP.  This means a saving on hardware and maintenance, and a simplification of the on premise SAP landscape.
  • Since SAP manages the ADS on HCP, customers do not have to handle any patches and updates.
  • SAP will handle the sizing, load balancing and hardware set up.
  • For periodic processes, or processes which have occasional activity ‘peaks’, the solution will automatically scale: customers no longer have to invest in hardware to support peak processes.


The licensing model is simplified and may benefit many but not all customers:  The on premise arrangement is that [i] print forms are free, and [ii] customers pay for the use of interactive forms that are not pre-delivered by SAP.  The cloud model makes no distinction between the types of form, but is based purely on a package of billable requests.


Our testing

Arch worked with SAP on a Customer Engagement Initiative and a Customer Validation Initiative for SAP Forms as a Service, and we conducted wide-ranging testing, which included:


  • On-line form testing
    • Simple form process using Arch FLM
    • Complex form template rendering and submission
    • Attachment capture and reproduction
    • Annotation capture and reproduction
    • Validation error handling
  • Off-line form testing
    • Simple off-line form process using Arch FLM
    • Off-line form with server certificate
    • Client-side digital signature capture on static off-line form
    • Server-side digital signature on static off-line form
  • Print form testing
    • Simple print form render
    • Letter generation end-to-end process using Arch Aquiller
  • Performance testing
    • Simple interactive on-line form template
    • Complex interactive on-line form template
    • Simple print form template


All the scenarios were validated successfully, and so we are content that our products FLM and Aquiller both support SAP Forms as a Service.


The performance test results, however, were disappointing for larger or more complex form templates.  We are hoping that this is an issue that SAP will address in the coming months, and hopefully an upgraded HANA Cloud Platform in 2016 will have a positive impact.

Use Cases

Our recommendation is that SAP Forms as a Service should be used for processes that use simple form templates, or processes where no user is waiting for the form to render.

The best use-case for SAP Interactive Forms as a Service is for standard output forms, where the printing or output is performed by a batch job, so that nobody is waiting.  On occasion, a render will be required for ‘print preview’, and ideally the ADS render should take less than 1 second.  This should be possible with careful form template design.

The other scenario that we recommend the service for is off-line interactive forms. Since off-line forms are normally either distributed by e-mail or rendered at design-time, there is no user waiting for the form to render.

HTML for on-line forms

We now recommend HTML forms for all on-line scenarios unless specific PDF functionality is required.  This is partly due to the rendering time for PDF interactive forms, but also due to diminishing browser support for on-line PDF forms.  Web browsers now support PDF reading as a standard feature, but do not support interactive PDF forms.  We see this on mobile devices such as iPads and Android tablets, in Google Chrome and now in ‘Microsoft Edge’ (the Windows 10 browser).

Arch FLM can help customers make the move to SAP Forms as a Service by providing the on premise form processing framework for ADS integration, and by providing the HTML alternative for on-line PDF forms which are approaching end-of-life.

My Recommendations

For SAP output scenarios, customers should consider moving to SAP Forms as a Service.  In addition, look at HTML e-mail output to replace some print or PDF attachment  scenarios.


For interactive forms scenarios, customers should urgently consider HTML forms to replace complex on-line PDF forms. 


Further Reading




At SAP TechEd && d-code recently I heard a question at the IFbA Roadmap session about support for forms in SAPUI5. 

Since the ‘standard’ approach for on-line e-forms is to publish them via a custom Web Dynpro, there was an assumption that this was the only way to use SAP e-forms.  Not so: Here I describe ten different ways we see SAP e-forms being used, and none of them require any Web Dynpro development.  Instead, the form is delivered through a URL hyperlink that can be embedded in many different places.

[1] SAP Enterprise Portal

For organisations making use of the SAP Enterprise Portal, links can be added in any page to launch new e-forms, or to the e-forms inbox, or to forms previously saved as draft.

sap ep.JPG

[2] HANA Cloud Portal

Similarly, where organisations are using the HANA Cloud Portal, e-forms can be easily embedded.


[3] Fiori LaunchPad

As companies start to embrace the Fiori LaunchPad as a work portal, tiles can be used to launch e-forms easily.



Where Employee Self-Service is used this is an obvious place for launching and HR form.


[5] OrgPublisher

When third party products like OrgPublisher are used, this is often the best way to launch a form for a particular SAP object in order to pre-populate the form for a particular Employee, Position, Org Unit etc.


[6] Direct e-mail link

Embedded links within html e-mails are often used for work in progress.  Notification e-mails can contain the link to open up for form for approval, for example.


[7] SAP Universal Worklist

When the SAP Universal Worklist is already being used then it makes sense to use this inbox for e-forms in process.


[8] FLM Portal (SAPUI5)

The FLM Portal includes an e-forms inbox, new form launcher and a variety of other functions.


[9] Web transaction (e.g. BSP, SAPUI5, Web Dynpro)

E-forms can be launched from any web-based transaction.

web dynpro.jpg


Finally, you can even access e-forms through the SAPGUI.


E-forms remain an important tool for process automation and better usability, and as the number of options and technologies from SAP grows, the number of ways we can access e-forms increases.

Next year watch this space for E-forms integration with SAP Fiori!

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:

IFbA use cases.PNG

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.

IFbA_Book_Cover_3rd_Edition_small.pngThis is only for readers who speak German: The famous team worked together on updating the book on Interactive Forms and published the 3rd German edition. The 3rd edition is an update that covers SAP NetWeaver 7.4 and Adobe LiveCycle Designer 10.40.


Besides the general update to describe the use of the latest software the team added new content (26 pages)! The book now covers PDF/A, printer options, print tickets, label printers (Zebra, Intermec, Datamax and Toshiba) and LiveCycle Designer improvements like defining keyboard shortcuts in Designer or the action generator to generate scripts.


In its  3rd edition and with 799 pages this book is the ultimate reference and provides step-by-step instructions not only for beginners but also for everyone who wants to learn what happened over the last four years in product development for IFbA at SAP and Adobe.


Check it out here: https://www.rheinwerk-verlag.de/sap-interactive-forms-by-adobe_3824/

The main advantage of using  scripting in Adobe forms is that we can improve functionality and usability of forms.

With scripting we can get full control over forms at run time.


Benefits of Scripting:

  • Display/Hide form objects based on Conditions while generating the PDF Form

        (Examples: Hide /Display Table or Page in generated PDF Form, Adding Back ground colours based on conditions )

  • Automatic calculation in Forms.

        (Examples: Sum,Avg,Percentage, etc.. )

  • Data validations.

        (Check existence of Data using flag conditions..).

        All the Actions written in Script editor will be executed at the run time.

Where should we have to write our Script in Adobe Forms:

        We can create our forms using Transaction Code SFP (Form Builder).

        Go to Transaction Code  SFP.

        Enter the Form Name

        Click on Layout.

        Menu Bar --> Pallets --> Script Editor

Script Editor.png


   Select the Script Editor.

   Select an Object in the Layout.

   The Script editor will be displayed as shown below.

2015-07-15 16_17_01-Form Builder_ Change Form ZAF_FORM_CALC.png




Objects are used to display the data in PDF Forms . Based on the data type we have to select Object from object library  and add it to layout.

Examples:  Amounts                   ---->      Numeric Field / Decimal Field.      

                    Date/Time                ---->      Date/Time Field.

                    Image                       ---->      Image Field 


We can divide the objects into two categories.

  • Objects supported by Scripting Languages.
  • Objects not Supported by Scripting languages.

Objects in Adobe Forms.png

SAP Adobe forms Supports two scripting Languages.

  • FormCalc.
  • JavaScript.

A Form can use both languages in the form at the same time but we can't use both scripting languages for single Object.



         FormCalc is the default scripting language in Designer. It is an easy-to-use calculation language.

         FormCalc is the best choice to work on functions like (date and time, financial, arithmetic , logical etc.)



  • Built-in-Functions

        FormCalc has many built in Functions that covers a range of Areas including Finance, logic, dates/times and mathematics.

  • Performance

        FormCalc usually provides better performance than JavaScript because it executes calculations and validations more quickly.

        FormCalc can be the best choice in many situations, regardless of programming experience.

  • Easier to maintain

        This scripting language is very useful for Non Programmers who need to add calculations for their forms.

        It is very similar to the Language that we use in  Microsoft Office like Excel, Most FormCalc scripts are one line long.



  • FormCalc is not as powerful or as ubiquitous as Java Script.
  • It will not work for HTML Forms ..
  • Not very useful for creating sophisticated interactive and dynamic forms.




      Go to SFP. Enter the Name of the Form and click on Create.

2015-07-15 17_24_00-Form Builder_ Entry Point.png


A pop will be displayed as shown below.Assign Interface for your form.


Interface is the place where we add code to fetch data from Data base tables.We can display the database

tables data by binding the Variables used in Interface  with the Objects in the Form(layout).


Context is the place where the connection is established between Interface and Form.

2015-07-15 17_27_53-.png

Click on Save.To design the layout(Form) click on Layout.




Example 1:

     FomCalc:  Sum of Multiple Numbers (Sum)


Drag and Drop a  Numeric Field from Object Library into the layout as shown below.. Select the Field. Go to Script Editor.

In Script editor select the event (form ready). We can see the Header line which represents the path of the form.





data.#subform[0].NumericField1::ready:form - (FormCalc, client)


  • #subform[0]                     ------>   Name of the Subform
  • NumericField1                 ------>   Name of the Field on the Layout
  • ready:form                       ------>  Event under which the script added will be executed.
  • FormCalc, client               ------>  ( Scripting language,Run at ) 


   After adding FormCalc Script,Click on Save,Activate,Execute.





Example 2:

    FormCalc: Annual Percentage of Loan(Apr)




     Example 3:

     FormCalc : To display the Number in Word Format ( WordNum )





Java Script:

Although FormCalc is default scripting language in designer, Java script is more ideal for creating sophisticated interactive and dynamic forms.


Advantages of Java script:


  • JavaScript is ubiquitous.

        JavaScript is a scripting standard that many programmers and designers already know.

  • Object -oriented.

         We can create JavaScript objects and custom functions, and use them through out Form.

         This function is not available in FormCalc.It has been scripting standard we can find sample scripts for almost we need to do.

  • Works for HTML and PDF Forms:

        We can use JavaScript for both PDF Forms and HTML Forms.


  • Performance

        Performance is lower than Formcalc.



  JavaScript:  Hide/Display entire column in a table if the total sum of the column is '0'.


    In debugging we can see the Entire column with zero values



   If the entire column doesn't have zero values set a flag as shown below. The last column SI_AMT1 doesn't have values.

   This flag value will be passed to  variable lv_si1 which is in our Java script.



    Now the added java script under the event ( Form ready) will be executed and the entire column with zero' will be removed from the table  in PDF Form  display.


     Output: We can see no entire column with zero's in table  in Output PDF Form.



Example 2 :

JavaScript:   Adding Back ground colors for the Table Fields and  field content should be displayed in Bold


  • In my table I have a Field POSID it the value of the field is Outcome then it should display all the data in  bold and back ground colors with following          properties.



  • Else if POSID field value is Output then it should display background color with following properties .



data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA.POSID::initialize - (JavaScript, client)

var numrows = xfa.resolveNodes("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA[*]").length;

var rowFillColor;

for (var i=0; i<numrows; i++)


posid = xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"].POSID").rawValue;

if (posid == "Outcome")


rowFillColor = "191,191,191";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").border.fill.color.value = rowFillColor;

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").POSID.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").POST1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").T_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").F_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").S_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").TH_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").FO_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").FI_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").SI_AMT1.font.weight = "bold"; 


else if (posid == "Output")


rowFillColor = "217,217,217";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").border.fill.color.value = rowFillColor;


delete outcome;




    All the Rows  which has  Outcome in first cell are displayed in Bold with the  assigned Back Ground Color.

    All the Rows  which has  Output     in first cell are displayed with assigned Back ground Color.


We have to decide the script language to be used in Adobe Forms, based on the Scenario/Functionality we need to achieve.

Hi Experts,

i need help in  Adobe Interactive Forms development. I want to group a table by using the control level at the context menu. And it works in every case out of one. If I use one specific column the group function doesn’t works correct any longer.

In Detail: I use a table like this one:




This Table is grouped by column a. And it works correct until I insert a value at column b then the table don’t summarized all equal values at column a but a is getting repeated at every record.

Does anybody know why or have an Idea ?


Thank you.

Best regards,


Merging internal table cells dynamically in SAP Adobe forms using Java script code

This blog describes how to merge cells dynamically in a table of SAP Adobe forms.


  • Basic knowledge on Adobe designing and
  • Adobe Java Scripting.


Customer requirement is to have the table format as per the below screen shot.


Observations from the above requirement:

  1. We can simply say it is an M x 9 matrix with different widths for each column.
  2. The first four table columns (table cells) change dynamically.
  • Column-1: Outcome
  • Column-2: Output
  • Column-3: Activity
  • Column-4: Estimated completion date


Depending on which we have to merge the first four table columns (table cells) dynamically..?


  1. If first cell (Outcome) contains data, then we need to merge the first 3 table cells and show the complete data related to Outcome only.
  2. If second cell (Output) contains data, then we need to merge the Output and Activity table cells and show the complete data related to the Output only.
  3. If third cell (Activity) contains data, then no action is required. Leave this cell as is.
  4. I just crop the last two rows from the above table provided in the customer requirement.



   In the above table, red border indicates that the first four cells are merged...why..?


   In this case Outcome, Output, Activity and Estimated Completion Date cells are empty.

   So, we need to merge all the four cells into a single cell.


Procedure on how to achieve this functionality:

In this requirement I am just giving you a brief overview of Java script coding part involved not the Adobe form table design.


1. After the completion of adobe table design, select the table cell (Outcome cell) as shown below and write the Java script code in the initialize event.


Here is the Java script coding part in the adobe initialize event related to Outcome.



2. Select the table cell (Output cell) as shown below and write the Java script coding in the initialize event.


Here is the Java script coding part in the adobe initialize event related to Output.


Step by step explanation of Java script coding part related to “Outcome”:


Calculate no of rows in a table using the following Java script coding:

My adobe table name: GT_PROJECT

My adobe table body: GT_PROJECT.DATA


Java script syntax to calculate no of rows in a table:

var numrows = xfa.resolveNodes("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA[*]").length;



Loop each row:


for (var i=0; i<numrows; i++)


First take the values from the four cells:

Cell-1 -> Outcome:

outcome = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").rawValue;


Cell-2 -> Output:

output = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").rawValue;


Cell-3 -> Activity:

activity = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").rawValue;


Cell-4 -> Latest finish / estimated completion:

latfinish = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].LATEST_FINISH").rawValue;



Use appropriate conditions as required:

if((outcome == null) && (output == null) && (activity == null) && (latfinish == null))


xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "4"; 

  xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].LATEST_FINISH").presence = "hidden";




if (outcome !== null)


xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "3"; 

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";




xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "1"; 

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "visible";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "visible";  



delete outcome;



Step by step explanation of Java script coding part related to “Output”:


Follow the first two steps as explained above.


Use appropriate conditions as per required:

if (output !== null)

{ xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").colSpan = "2";   xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";   






delete output;



Resultant PDF Output:




Filter Blog

By author:
By date:
By tag: