Skip to Content

Introduction

More and more standard SAP Interactive forms by Adobe will be used as a solution for customer’s problems regarding much simpler data entry and automating the manual processes. But also custom development will be involved in developing interactive forms. Because the technique is new, there will be a lot of pitfalls in the first projects of the new Developers. This web log will help the starting developer to avoid these pitfalls and help to build excellent performing interactive forms

Regarding a good you have to look at several parts of a SAP Interactive form implementation. For an online scenario these parts are:

  • Data Provider or Backend Application
    The data provider mostly is a backend system like SAP R/3 or other data providers like web services or files are possible.
  • Framework
    The integration possibilities of Interactive forms are implemented into a framework. Within SAP the following frameworks are available:
    – Internet Service Request (ISR)
    – Guided Procedures (GP)
    – Web Dynpro for ABAP (WDA)
    – Web Dynpro for Java (WD)
  • Adobe Document Service (ADS) component on the Java engine
    The ADS will generate the Interactive Form PDF based on a template and a data source. It also adds security possibilities and users rights to the form. It can also extract the data from an Interactive Form for data processing.
  • The Form
    The form is a container which contains the layout, data and logic. It also determines the interaction possibilities with the user
  • Internet Browser with an Adobe Reader
    These applications will display the interactive form and take care of the interaction with the user. The reader will render the form and react on the interaction possibilities in the form.

Performance issues

Not only the form and its reader are responsible for the performance, although the user is only experiencing these items. The performance of the backend and the network are also of great importance for an online scenario. If these parts aren’t properly working together an online scenario isn’t the right solution. When using an online scenario you have to optimize the information-traffic between the Interactive Form in the reader and the server.
Maybe an offline Interactive Form with batch processing will improve the user experience in this case. So chose the right solution at the right performance.

Also the size of the Interactive Form is important. If you have a bad performing network, downloading a 2 MB document will last for ages. You will keep this experience also for a large Interactive Form when it contains too much information. In this case, it is the challenge to keep the form as small as possible or to improve the performance of the network.

Performance optimalisation

You can optimise Interactive Forms, especially to online scenario’s,

  • to switch on Form Caching
    By changing the properties of a form. Especially activating the property ‘Allowed Form Rendering To Be Cached on Server’ the performance will significant improve
  • to chose the ‘Dynamic Forms’ type
    Dynamic PDF will be rendered on the PC of the user. Static PDF will be rendered on the server.
  • to use ‘Single Page’ for the page layout in the Reader
    Now only one page will be rendered, which will improve the users experience
  • to select the right image type and size
    For bitmap images only use ‘use image size’ for sizing property of a image. If the image does not fit, change the image with a tool in stead of changing the property.
    Marking the property ‘Embedded Image Data’ is only necessary if the form must be offline or the image is not online available. If you mark this property, the Interactive Form size will increase with the size of the image file. So for bitmap images use a low resolution and a compressed type like png or jpg.
  • using Scripting only when you need it
    – Formcalc is standard faster than Javascript
    – Looping the Document Object Model is time consuming
    – The best place to put your scripting is the Ready events
    – Minimize scripting, maximal 10 code lines per method
  • … by using implicit data binding and avoiding ‘wildcard’ characters
    If you don’t do this, you will read data every time from the root.
  • to use standard fonts
    ‘Myriad Pro’ en ‘Minion Pro’ will generate smaller PDF (‘font embedding’ not necessary) and will occur unknown letter type (‘faux fonting’) message when displaying the PDF on the screen.
  • upgrade to the highest NetWeaver release
    Don’t use NW04 sp16 or lower
  • upgrade the Reader to Adobe Reader 7.07 or higher
To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
    (0) 
  2. Alexey Dedevich
    How to distribute PDF generation of 1 form between several CPU on J2EE engine?
    If I try to produce large PDF (just for output as report) I’ve got a very long generation ( above 40 min. on 150 000 row’s in table ).
    Is it posible? May be I’m not right when try to produce large report’s from BW in PDF with helping ADS?
    (0) 
  3. Madhu Sudan Reddy B
    Hi Vani,

         i read on of the articles written by which deals with working of offline interactive forms. In that article you explained about how to send a mail with from as attachment and process the form data after receving the mail.In that You used single fields  and updated the bank details.
        Can u help me how to extract the data if it is in the form of Table(suppose material , quantity are the fields and have a tabular data) ?

    Regards,
    Madhu

    (0) 

Leave a Reply