1 2 3 5 Previous Next

SAP Interactive Forms by Adobe

62 Posts

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.

During the IFbA Roadmap sessions at TechEd last year there were a number of questions about HTML form generation.  HTML forms had been planned for IFbA but now have been removed from the roadmap.  Arch FLM provides the ability to render and manage dynamic HTML input forms, but there was also keen interest was really around document output scenarios, where the HTML output form would be sent as the e-mail body, meaning no need for any PDF attachment.


This got me thinking about how I get communication from many companies.  As a customer I regularly receive order confirmations, deliver confirmations and even invoices from lots of different customers.  So why do I need a PDF attachment for SAP document output?  Even with S/4 HANA.  It seems astonishing that there is no ability to maintain an HTML output template.  I spoke to a number of customers and SAP employees, and everyone was equally astonished.  It just isn’t there. Really!


In the SAP Business Suite we have SAPScript output, Smartforms and Interactive forms by Adobe.  All three options designed for print output in the first instance, with lots of print controls, support for barcodes and font printing etc.  When communication is sent by e-mail the document is sent as an attachment and there is little control over the e-mail body content without a lot of extra development.  Plus, when you trigger the e-mail the message subject in the SAP outbound queue (transaction SOST) is limited to 50 characters, which can be very irritating!


It seems to me that in the last 10 years the world has moved on but the SAP solution hasn't.  Today's companies have largely eradicated the use of paper. We don't use fax any more.  We don't need to physically print and sign documents. But we do receive e-mails on hundreds of devices of different sizes.  E-mails rich in graphical content; e-mails that responsively change based on the screen size; e-mails that look fantastic.


Of course there is a place for PDF output, especially for legal documents such as employee contracts, and actually one requirement I've seen several times recently is for multiple documents to be sent together as a pack.  But there are lots of scenarios where using HTML e-mail has great advantages over using PDF attachments:


  • Single system.

With no PDF rendering there is no need for a JAVA stack which means that the infrastructure is simpler and the performance is faster.

  • E-mail size.

With no PDF attachment the e-mail is much smaller, which provides benefits for space and performance in the SAP database, the e-mail server for both sender/recipient and the e-mail client)

  • Delivery confidence.

With no attachment the e-mail is less likely to be trapped by corporate firewalls or treated as SPAM.


Arch already provides HTML e-forms to complement IFbA in the shape of FLM, and a business requirement we often see for forms-based processes is to trigger a variety of notification e-mails at different processing steps.  This includes process notifications (to inform users that a form has been routed to them), and also to inform different departments and sets of users of process progress or resulting SAP updates.  There is often a lot of data from the form within the body of the e-mail and sometimes the entire form is attached in a 'flattened' PDF format.  This is a normal project task, but involves some development, and the management of HTML e-mail templates is not easy.


So last year we decided to build an e-mail solution to deliver the benefits for document output and handle e-mail templates much more easily.  (The result is Arch Floe, launched at Sapphire Orlando, May 2015.)


I see three main use cases for HTML e-mail output:


  • Process notifications.

Create professional notifications based on workflows, form processes, Fiori app submissions and system events, to recipients inside and outside the organization.


  • SAP document output.

Replace e-mails with PDF attachments with 'pure e-mail' content.

  • Mass correspondence

Generate mass communications to customers, suppliers and employees such as changes of terms and conditions, newsletters etc., with dynamic, personalized content.





The benefits of using a SAP-centric approach instead of a third-party tool like Mailchimp include:

  • SAP data integration

Any data from SAP can be included in the e-mail, and

  • Personalisation

As each generated e-mail can dynamically include different content, a single e-mail sent to many recipients can be personalised to each recipient, not only by simple data substitution but also in content too.

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:



Hi all


we faced Syntax Errors in Function Modules /1BCDWB/SM00000XXX and /1BCDWB/SM00000XXX_TEST (Missing Table FPTESTDATA)


the Table does not exist in the new Release any more.



Use SA38 Report FP_GENERATE_FUNCTION_MODULE to Fix the Error



worked nice for us



Who’s Afraid of the Big Bad Data?

Bad data is everywhere.  It’s like a virus in our organisations, which prospers unless we deal with it effectively.  It can crops up all over the enterprise and cause little irritations which add up to enormous hidden costs.  As we move into an era of Big Data, it is even more important to ensure that the data we collect is clean, so we don’t enter an era of Big Bad Data.

But here’s the thing: Bad data is both fixable and avoidable. It’s not like many other business challenges for which our tools are incomplete or which are caused by external factors out of our control.  I’ll go further: there’s no excuse for bad data in organisations any more, and IT Directors should take responsibility for ensuring data quality.  If your processes are not in place to manage data quality, then you’re not ready for small data, never mind about big data!

In this blog post, I identify 5 causes of bad data, and discuss how they can be rectified and avoided without a budget of $millions.

[1] Obsolescence

Have you ever encountered the scenario where you have to scroll through lots of records to find the one you are looking for, in the knowledge that many of those records flying by are not used or needed any longer? Perhaps you are participating in a transactional process or running a report and need to select that customer, material or GL account.  And you know the record you’re looking for is on the second or third page down.  You know that you haven’t used many of the entries on the list for years.

Never mind about data quality issues, you have a data inequality problem, where lots of data are obsolete and should be removed from the system.

I hardly need to say that data archiving solves all this.  20 years ago many SAP projects went live with a note that archiving would be tackled down the line, but these days all this should be in place, with regular archiving runs in place to remove the obsolete data.

[2] Out-dated Data

I make a careful distinction between obsolete data and out-date data.  ‘Obsolete data’ I define as the data that you don’t want in your core systems and should be archived.  ‘Out-dated data’ I define as data that has changed in real life but not on the system.  You work with the data records, but you know that are out-of-date.

Has your enterprise ever continued to pay an employee after they have left employment?  Or sent an account statement to the wrong customer address? Or send information by e-mails that bounce?  Do you run ESS but know that employees consume data without updating it?  I met one customer who didn’t actually know how many employees they had because they had a 3-month backlog of processing joiner and leaver forms.

These are all symptoms of out-dated data: data that describes how life used to be, rather than what it’s like today.

There can be a one-off or scheduled clean-up activity for this data, but really the solution lies in capturing changes as they occur.  This can involve:

i) Automatically triggering a form to capture data changes based on events.  For example, triggering a form to capture employee changes after each performance assessment meeting.  For example, sending a link for customers to check their own details when an order is placed after a period of inactivity.

ii) Automatically triggering a form to capture data changes based on a schedule.  For example, sending a link for employees to check/confirm their own data each year.

iii) Enabling the easy manual creation of a form to trigger master data updates when a user notices that something is incorrect.

[3] Erroneous & Missing Data

Do you ever hear people say that they don’t trust the system?  Or see users who keep their own files in Excel to check what the system suggests.  Do you see purchase orders where the ‘long text’ fields are used to describe the material or service to be purchased in great detail, because the description of the material master isn’t really what is wanted?

Have you seen a world in which the people responsible for the creation of master data are not the same people who work with that master data, and there’s a gap between how master data is expected to be used and how it is used in practice? Perhaps the data creation task is outsourced, and you are now finding a hidden cost of outsourcing?

There are many examples where the data is just plain wrong.  Users struggle with the system and try to find the closest match.   Sometimes the record is missing completely and users don’t request the new data record, but re-use an old one instead.

This type of bad data differs from out-dated data, because at least the out-dated data was right once.  In this type of scenario we are dealing with data that was never correct because it wasn’t captured correctly in the first place.

The solution relies on better data capture.  That means using integrated data capture e-forms, and throwing away Word or Excel solutions.  That means running validation rules at the point of data capture.  That means not only checking that mandatory fields are captured, but that they are filled with something meaningful.  It requires a mixture of automatic and manual data checks before the record is saved to the SAP system.

[4] Inconsistent Data

Do you get strange results when running reports, only to later realise that customer or material master records have been inconsistently defined? Do you use many different grouping fields on master records and then rely on them for reporting?  Do you see employees struggle because they don’t know what fields to use, or because they don’t know why they always have to fill particular fields?

Or do you see times when employees cannot find the right material to use because the descriptions don’t make sense to them?  (Of course this may lead to them requesting the creation of a new material record unnecessarily.)

Organisations’ use of master data changes over time, and fields may have been crucial for historical data upload, or EDI/ALE, or transfer to BW, or reporting through LIS or COPA.  However those same grouping fields may no longer have any relevance or any understood relevance.  You end up with inconsistent use of master data records, which can cause great user confusion.  And this isn’t master data management, it’s master data mismanagement.

You need to be clear and consistent in the use of fields such as grouping terms, search terms, description fields and product hierarchies, and of course for every other field.

With an e-form for automatic record creation, rules can be added for automatic generation of description fields.  Many fields can be hidden and filled automatically and consistently.  Validation checks can include checking the categorisation of similar records in order to throw out exceptions and suggestions to make the user’s task easier and deliver a bullet-proof master data request process.

[5] Duplication

I’ve separated out duplication as a separate cause of bad data as it’s a particular bug bear.  When employees see a list of vendors and do not know which one to use, the process is broken before it is started.  When the task of determining what record to use to difficult, employees may avoid this and simply ask for a new record to be created.  When the appropriate checks and balances are not in place, the creation of new records can spiral out of control.  And as soon as a customer, material, vendor or GL account has some transaction history it becomes troublesome to remove.

During master data request processing, a duplicate record check is essential. This might involve quite complex algorithms, to identify a list of suspected duplicates, in order to stop the process before it begins.  Where a process continues, request forms can be dynamically routed for a manual check of candidate duplicates before the form is accepted and the update made to SAP.

Fixable and Avoidable

I make no apology that all this seems obvious.  But I repeat, all these sources of bad data are both fixable and avoidable with modest investment.  Bad data is now a choice for organisations.   They can keep it at their own risk, and bad data isn’t free.

Of course there are many specialist tools and services available, but simple, integrated e-forms, together with robust business logic for validation, duplication checking, consistency checking, routing and SAP updating, can deliver the solution to all the above.  You can even use an e-form to request/approve a record to be archived.

So next time you see any issues resulting from bad data, note that someone has chosen to keep that issue, as it is all perfectly solvable.

The most common problem we often face when we have to dispaly the date format and Quantity format according to the User settings.


To overcome this problem the easiest way is




DATA : lv_date         TYPE  sy-datum,       

           lv_date1        TYPE  char10,

           gv_date         TYPE char10.


     CLEAR lv_date.

     CLEAR lv_date1.

     CLEAR gv_date.

     lv_date = sy-datum.

     WRITE lv_date TO lv_date1.

     gv_date = lv_date1.

     CONDENSE gv_date.


Adobe Form:


In the Adobe Form take the Date field as TEXT and bind it with gv_date





     DATA : lv_menge(16) TYPE p DECIMALS 3,

                lv_menge1 TYPE char20,

                gv_menge  TYPE char20.


       CLEAR lv_menge.

       CLEAR lv_menge1.

       lv_menge = <fs_mditems>-menge. "Quantity

       WRITE lv_menge TO lv_menge1.

       CONDENSE lv_menge1.

       gv_menge  = lv_menge1.

       CONDENSE  gv_menge.


Adobe Form:


In Adobe Form Take the Quantity field as TEXT and bind it with gv_menge .


Conclusion: Write makes the Quantity, Date and also time according to the current user settings.

After reading difficulties of several people on SCN posts regarding basic ADS configuration, I thought of writing this simple blog on ‘How to setup simple ADS between an ABAP and JAVA systems?’.

Use case:

  • ABAP system should be able to print PDF through ADS on JAVA stack.
  • ABAP and JAVA are standalone systems (not dual stack).
  • To be specific; SE38 > FP_TEST_00 > F8 > F8 > (Output device LP01 – Dummy printer) > Print preview > PDF should be displayed.See the screenshots below.


IMPORTANT: Please read and understand the document “Configuration Guide for SAP Interactive Forms by Adobe Adobe Document Services”. Below steps are not complete, they are in supplement to the steps given in the configuration guide.

When things don’t work even after following the configuration guide, you can use below steps to understand, double check and fix it.

First let’s make ADS working on JAVA alone.

    • Create user J2EE_ADSUSR (equivalent to ADSUSER) as described in the section “Creating the User ADSUser and Assigning the Security Role” in the configuration guide.
    • Visual Admin > Cluster tab > Server  > Services > Security Provide > User Management tab >Edit mode > Create User button. Make sure you add the user to ADSCallers Group.


    • On the Policy Configurations tab, in the Components area, select com.adobe/AdobeDocumentServices*AdobeDocumentServicesAssembly.jar.
    • On the Security Roles tab, select ADSCaller from the Security Roles list.
    • In the Mappings area, choose Add > assigns the J2EE_ADSUSR user to the ADSCaller security role



    • On the Policy Configurations tab, in the Components area, select the wsnavigator and make the change as shown below, so that wsnavigator service is accessible to all.


    • Change the user type of J2EE_ADSUSR to technical type.


    • Stop and start below two applications


    • Update URL, User & Password as show below in Server → Services → Web Services Security →Web Service Clients → sap.com.tc~wd~pdfobject → com.sap.tc.webdynpro.adsproxy.AdsProxy*ConfigPort_Document.


    • Restart Web Services Security by clicking on 1.png and then on 1.png



Let’s test if it works.

Open the URL http://<host>:<port>/wsnavigator in web browser

It should open without asking password.

Then open the URL http://<host>:<port>/AdobeDocumentServices/Config

Again without asking password a page like below should be displayed.




Click on Test > Then on rpData (test.types.p1.RpData parameters) > Then on Send button > Enter user as J2EE_ADSUSR and its correct password > Press Submit button


You should see the OK response as show below.




Congratulations! ADS standalone on JAVA side works correctly.


Next step is to create RFC in SM59 on ABAP side. Create the RFC named ADS as show  below.




And perform the connection test. You should get OK code.





Little more to do.

JAVA has to send back pdf after processing, therefore it needs a connection (JAVA to ABAP> and credentials.

Let’s do that now.


Create a user ABAP_ADSAGNT on ABAP side and assign the role SAP_BC_FPADS_ICF. If you don’t have the role, download and upload from any other systems if you have. Make sure PFCG > SAP_BC_FPADS_ICF > Edit > Authorization tab is green and User tab is green, else generate profile and do user comparison to make them green.


Make sure the user type as system or communication so that you are not asked to change the password while logging in.


Activate SICF services; /default_host/sap/bc/fp  and  /default_host/sap/bc/fpads


Go to Visual Admin > Server > Services > Destinations > HTTP > New button > FP_ICF_DATA_<SID>


In URL field enter as given below



The existing entries <server> and <port> refer to the AS ABAP. The ABAP HTTP port is provided in transaction SMICM; choose Goto -> Services.


Enter client where ABAP_ADSAGNT user was created.


Change Athentication to BASIC and enter user ABAP_ADSAGNT and password





Up to SAP NetWeaver 7.0x, choose 'Save and Test'; as of SAP NetWeaver 7.10, choose 'Ping Destination'.


You should see code 200.





IMPORTANT: Remove the /sap/bc/fp/form/layout/fp_test_00.xdp part of the URL. Means do not forget to change the URL back to http://<server>:<port>


And press SAVE button (NOT SAVE & TEST), only SAVE button please.


Congratulations! JAVA to ABAP connection is also done.


Time to test with SE38 > FP_TEST_00  as shown in the use case in the beginning of this blog.



Best Regards,



Filter Blog

By author:
By date:
By tag: