1 2 3 5 Previous Next

SAP Interactive Forms by Adobe

62 Posts

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.



Floe is a development tool which is an ABAP add-on, either for SAP NetWeaver of for S/4 HANA.

It delivers the management of e-mail templates within SAP, and provides the ability to add logic to tailor the content of the generated e-mail based on SAP data.



At run-time, Floe generates e-mails based on the selected template and SAP data, substituting the data into fields in the e-mail.  It provides the ability to define HTML blocks within the template that can repeat or have business logic to optionally include or exclude from the generated e-mail.

This makes it easily possible to build templates for document output like sales order confirmations; documents with repeating rows or nested repeating sections; the e-mail content is generated based on the data. 




The developer's job is to change the output program to call the Floe API, simply passing in the document data, and then add formatting logic (for date fields and currency fields, for example).  Then add in the HTML template as separate maintainable blocks.



At development time, a developer can generate several user-exits for each template. This means that there is a place to easily add business logic for:

  • Recipient determination;
  • Language determination;
  • HTML block determination;
  • Data (variable) determination;
  • Attachment determination;
  • Embedded image determination.


Floe delivers the ability to deliver complex requirements but simple notification e-mail can be built in minutes, as this video shows.




Floe can also be used for any notification e-mail, and for mass correspondence.  The benefit of using Floe over a tool like Mailchimp lies in

  • SAP 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.




Since we've started showing Floe to customers and partners we've seen great interest; it feels like a neat tool that can add value to any SAP Business Suite customer.


For more information and demonstrations check out www.floe.com



*Arch Aquiller provides an easy tool to build dynamic PDF output for employee contracts and many other business requirements.  It integrates with IFbA for PDF generation.

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:



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, FLM is used to deliver the form 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!

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,


SAP e-forms processes are great for collecting data for single transactions, but when multiple updates are required, users prefer an Excel approach to a PDF approach.  By combining both approaches with a single set of business logic, organisations can benefit from automatic validation, drop-down lists, workflow and SAP update logic across both approaches.  This means that the benefits of SAP Interactive Forms can be extended to data collection with Excel.


SAP e-forms are best used for data collecting for a single transactions or small number of transactions.  Great benefits include form pre-population, data validation on submission, form routing and form updates.  In situations like organisational re-structure or changes of HR benefits, it is not practical to submit hundreds of individual forms, and so a ‘file upload’ approach is a better fit.  The trouble with the common upload approaches is that the benefits of the e-forms processes are lost: there is no data pre-population, generated drop-down lists, data validation or approval workflow.  Instead, the spreadsheet is filled in manually, and the upload simply calls a BDC recording or a BAPI, and the user only sees posting errors.


FLM Excel forms share business logic with PDF and HTML forms.  This means that the Excel form is generated supporting logic such as:

  • Read-only and open fields
  • Date fields, text fields and drop-down lists
  • Mandatory fields

On submission the Excel form calls the same field validation logic built for the PDF form, and triggers single or multiple workflows so that pre-built approval processes are followed for the mass update scenarios.  The Excel form also uses exactly the same logic for updating SAP as the PDF form.  This makes mass update processes secure and powerful, ensures process compliance, and easy to build.  Any PDF form process can be initiated with an automatically-generated Excel form, and no extra development is required.

Let’s consider 3 scenarios:

Scenario 1: Organisational Change

Organisational Change can impact in 2 ways:

  • Mass updates of existing records: For example, updating personnel areas, position relationships or pay scale data across many employee records.
  • Mass intake of new data: For example, creating thousands of new employee records due to a merger or outsourced payroll arrangement


In both scenarios a PDF form can be used to handle individual transactions – Employee data change/transfer or New Joiner.   The individual form process may include not only the SAP HR update, but also secondary processes, employee correspondence and notifications to several departments or managers.
Using an Excel form the same business process can be replicated.  When existing employee records are being updated, the Excel form can be pre-populated with existing data.  For new employee records, validation and drop-down lists rules will be added automatically.


Scenario 2: Data Cleansing

Incorrect customer, vendor or employee records can lead to many issues with payments, reporting and communication.  A PDF form for customer master changes will contain drop-down list data and be pre-populated with key customer data.

The same logic can be applied to an Excel form, with the added logic to select multiple records for download.  The Excel form can then be pre-filled with thousands of rows of customer data, ready for checking and fixing in Excel.  Where no data is changed, the record will be ignored when subsequently uploaded.  Where data is changed, the normal form process can be triggered including complex updates and notifications.


Scenario 3: Periodic Tasks

Form-based processes are a great fit for many periodic tasks, such as employee performance reviews.  Instead of triggering each form manually, Excel form can be used to trigger hundreds or thousands of form processes for specific employees added into the spreadsheet.

The e-form processes by the employee may be HTML or PDF: The Excel form is just used to instigate the multiple processes.


VIDEO: Excel forms in action


Excel forms can complement the PDF form process or enhance it to reach more user communities and more business processes.  The combination of Excel and PDF form processing steps in a single process is what I call a simple ‘multi-UI’ process.   Organisations’ ability to consume multiple user interface technologies within a single process will give them flexibility and speed from which they can derive a competitive edge.


Find out more about FLM Excel forms

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.

This document includes some most common requirements of sap adobe forms.


1) To hide/display an Image at Run time


Adobe 1.pngAdobe 2.png

  • To add an Image, select and drag Image object from Object Library and give the path of the image in the URL field of the Object palette as shown above.

Adobe 3.png

  • As shown in figure above, suppose there are 2 images: – Image 1 and Image 2. One of these have to be hidden at run time based on a flag value say GV_FLAG.
  • To do so, wrap the 2 images and the flag into a subform as shown above and make the text field of the flag invisible.
  • Now click on the subform and write a script in the script editor as shown below.

Adobe 4.png

  • The image would be hidden based on the value of the flag passed as shown below.

Adobe 5.png


2) To display related information from different internal tables

  • Suppose there are 2 internal tables, GT_MARA having Material information and GT_MAKT having Material description.
  • Material description for a material in GT_MARA needs to be printed with the material information simultaneously having common field MATNR.


  • As shown above, first drag GT_MARA into the context of the form.
  • Then drag GT_MAKT into the data of GT_MARA as shown below.


  • Then double click on GT_MAKT and add the condition as shown below.


  • In the layout, position the fields from both the internal tables as required.

         A sample positioning is shown below.


  • The output that shall be displayed is shown below.


3) To remove Leading Zeros from a field value

  • Suppose a field consists of leading zeros as shown in figure below.


  • To remove the leading Zeros, first of all, change the type of field to Numeric Field.


  • Then from the Display patterns select a suitable pattern to be displayed (comma, without comma, percent, dollar, etc.)



  • The output would appear as per the selected pattern.


4) To display footer only on last page

  • Suppose there is a footer section, as shown below, that has to be printed only on last page.


  • Place the text field (here TextField3) in the Master Page and write the following JavaScript in the Script editor.


  • The text field shall only be printed on the last page.

5) To hide a Table Column and adjust width of other Columns

  • As shown in figure below, suppose we want to hide a column of a table at run time based on some condition and want to adjust the width of the other columns.


  • In order to do this, write the script to hide the individual row of the table at appropriate event and appropriate location as shown below.




  • At the table level in Initialize event, add the following script indicating the new widths of the columns to be displayed (along with unit) and Zero width of the column to be hidden.


  • The output shall appear with the appropriate columns.


7) Using sub form to create a table

Instead of using Table Designer, build this form design with a set of nested subforms and then set the accessibility role of the subforms to emulate a table. Use nested subforms instead of Table Designer because a table with multiple header and body rows is not accessible. As illustrated below, when a table has multiple rows, the form generates multiple lines of accessibility tags. The form design generates these accessibility tags even if the body rows are grouped in a table section.


  • To create Header subform


     1.  In the Hierarchy palette, create a text element for header text inside Line_item body page.

     2.  Wrap the text in a subform giving the accessibility as header row.


  • To create Body row

          Move the fields, which you want to view from data view on to the body page individually.


  • To set the accessibility role for each subform:


    In the Accessibility palette, select the Subform Role for each subform as follows:


  • To make multiple page table

          In the Object palette, click the Subform tab and select Flowed from the Content list.


  • To set the Header subform to appear at the top of each page:


        In the Object palette, click the Pagination tab. Under If Dataset Must Be Paginated, select Header from the Overflow Leader list.


  • Form shall be printed across multiple pages.



PDF forms have enabled many SAP customers to automate manual processes, remove paper forms and replace processes based on Excel/Word forms that require manual re-keying.
However, many form-based processes involve multiple processing steps, such as levels of approval, and these steps might be processed on a multiple of devices, where PDF is the wrong user interface or where the version of Adobe Reader does not support Interactive Forms.

The solution might involve a complex mixture of interactive forms, portal pages, mobile apps and even SAP Fiori, as one size does not fit all.


  • Portal pages based on BSP or web Dynpro can have limitations with mobile devices.  SAPUI5 is a much better alternative, but it takes a lot of extra development to create a SAPUI5 page that works on many devices.
  • Custom mobile apps overcome this issue, but they can be expensive to maintain.  Plus, users do not want to manage many mobile apps on their devices.
  • SAP Fiori has the advantage of acting as a container for multiple simple transactions, but users will not want to manage many tiles within SAP Fiori, and the standard transaction screens delivered within SAP Fiori will often not fit the business requirement closely enough.   Plus, SAP Fiori works only ‘on-line’ whereas custom apps can be developed to work off-line and synchronise data later.

Moreover, for many business processes, you do not know what device the user will use at each step of the process.  Processes may be triggered from desktop or mobile device, and approved in the office or on the move.  Users will have multiple devices and it is not realistic to expect them to install and manage a range of apps on a range of devices.

Let’s consider a simple real-life example.



Company A has 10,000 employees, all of whom have access to ESS.  Within ESS each employee is empowered to update their own personal data such as home address, next of kin and bank details.  The problem is that they don’t.  Many users only have a SAP ID for ESS access, and they don’t use it as they have long forgotten their password, or don’t realise that SSO is in place.

This leads to a variety of issues for Company A, with a high HR administration cost.

Company A also has 2,000 temporary employees who have employee records but no ESS access.  The personal data for these employees is also incomplete or incorrect.

No combination of mobile apps, SAP Fiori and portal pages is going to fix this issue: it is one of process compliance, and that’s where a forms-based process can add huge value.

A possible solution could be:


  • Process triggered by HR Admin, Manager or background job
  • For each selected employee a form is generated and they are sent a notification e-mail.
  • For employees with no SAP access, or with no recent activity in the SAP system, a PDF interactive form is attached to the e-mail.  This is pre-populated with their own data which they can confirm or correct and submit back.
  • For employees with active SAP users, then they can be presented with a link to an on-line version of the form, which can be rendered in HTML5, so that they can use any device to check and correct their own data.  Alternatively they can use ESS (or a custom app) to update their data.
  • When a form is submitted back then the employee data is automatically updated.
  • A background job can check for any unprocessed forms –and check whether the employee master record was updated – and if not, then trigger a reminder e-mail.  As time passes the employee’s line manager can be informed:  The system can ‘chase’ each employee until they have confirmed their own data.


So here a solution involving multiple UIs and many devices can solve a business problem without a large scale roll out of mobile apps or SAP Fiori.


Let’s consider another example:



Company A is processing a mixture of expense forms. Some employees are using an Excel spreadsheet, some are using SAP Portal.  Some employees are scanning receipts, others are posting the receipts.  It’s a mess.


The company wishes to introduce an expenses mobile app, whereby the employees can enter details and attach photos of receipts, taken on mobile or tablet.


As part of the expense form, the employee indicates the project or cost centre against each item, and then approval for those items has to be sought from the budget owner.


In some cases the form will need to be approved by a line manager or by an administrator to ensure receipts have been checked.  This might be a dynamic rule based on the form data or simply a governance rule (such as 5% of expense claims must be randomly checked).


Not all users will have mobile devices and not all users will have SAP access.   Users will want to be able to track the progress of their expense form through approval stages.  At any time the expense form can be rejected back to the user.


Users can be notified by e-mail and SAP Universal Worklist, and so there isn’t any value of adding an ‘inbox’ function within the expenses app.

Users who submitted expenses claims without using the app also need to track their forms, and so there isn’t any point in building the tracking capability into the app either.


So quickly we see that the best fit is, once again, a multi-UI process.


With a multi-UI process, employees with SAP access could elect to start the process using an on-line form, the custom mobile app.  Employees without SAP access could either be sent a PDF form each month, or could download a PDF form from the company intranet, or could use a published html form on the intranet.  The benefit of sending the form to the employee is that it can be pre-populated with their own data.


Wherever the form was submitted from the rest of the process should now be common.  Data from each form will be collated by cost center / project and routed to each budget holder for approval.  Only when all parts of the form have been approved will the form be moved on to the next stage of the process.   Users will be notified by Universal Worklist, E-mail or both.  Off-line users will continue to work with off-line forms. On-line users will work with on-line html forms.


The point for organisations to consider when introducing new UI solutions is that the mixture should be the norm. They should not design a single new process and manage all exceptions separately: the management of those exceptions is where a lot of hidden cost lies.  Designing the process first and the technology second will result in a better business fit, and greater overall process efficiencies.   I caution against selecting ‘web Dynpro’ (because that’s what we always do) or ‘SAP Fiori’ (because that is what SAP are selling us) or ‘custom app’ (because users are crying out to use their iPads).  That’s no way to start a project.

Some simple forms infrastructure, like Arch FLM, will provide the framework for easy development and management of multi-UI processes.  FLM provides common form services, such as device determination, pre-population, data validation and form routing, which can be re-used by a variety of UIs such that organisations can maintain their business logic centrally instead of replicating it to support each different UI.

When organisations adopt a multi-UI approach they future-proof their business processes from changing UIs.


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 Interactive Forms by Adobe Today and Tomorrow @sap TechEd online by peter barker, nikhil dhairyawan, jurger hauser(Adobe) - Oct 2013,


I attended the SAP TechEd  through SAP TechED online 2013. In this blog, I will share some of the notes I made during the session which I hope will be a quick read providing the audience with insights into what SAP Interactive forms by Adobe is all about.

Key Message: SAP has made the first clear step towards consolidating on the mobile technology, Sap script and smart forms support by sap until 2020.


Key Agenda are overview of SAP Interactive Forms by Adobe, important guarantees, mobile forms, ADS in the cloud , SAP HANA cloud platform,

evolution P7, P8, P9.

He explained about offline and online scenario Advantages of adobe forms like it supports bar-codes, populated with data.digital signatures.

(digital sign will lock the form, if we edit that form digital sign will be lost. and moreover adobe forms can be triggered in workflow,User validation also possible in forms.



1) Perfect interface between causal worker and sap.

2) Adobe reader is ubiquitous and free of charge.

3) Lower Total cost of ownership(TCO), printing archiving.

4) Less manual data entry fewer errors

5) High volume printing - Parallel processing

6) ZPL for label printing


Future of Adobe Forms - Mobile Forms (2014)

key feature :

1) Same template for PDF and HTML

2) Open XFA will be rended in HTML5

3) scribble signature

4) ADS Cloud

5) Floor Plan Manager

6) UI5



The ADS in the cloud will use SAP HANA cloud  platform. Moving ADS in cloud netweaver, ABAP Stack will call Https web service to connect SAP HANA cloud platform. By using this technology we have more benefits like save time and money, non-disruptive, simple, flexible and attractive licencing model.


Evolution of Adobe Forms : P7, P8, P9


Features in P7:

1) life cycle designer 10

2) It supports MICR fonts and OCR fonts

3) Native itanium support

4) rupee symbol support(Indian currency symbol)


Features in P8:

1) certificates,security

2) life cycle designer 10.6

3) ADS availability on windows server 2012

4) https URL graphics


Features in P9:

1) Hindi support in ads

2) Maintenance easy

3) Turkish currency support

4) Japanese postal bar-code support

5) Mobile + ADS in cloud



1) P9 only have to complete, Planning to launch in 2014.

2) Hybrid solutions for on-demand  and on-premise planned for 2014.


References sites



reference books




Often we come across the requirement of having the same layout of form for multiple languages.The best way to achieve this is by implementing the translations.


The following are the ways for translation of a original form (EN) to many other languages.

1.Translation available at the form level in SFP txn of the adobe forms.Menu-->Goto-->Translation.

2.Using Standard Texts (SO10)

3.Using Text Modules.(Smartforms)


The best way and easy maintenance in future, I suggest you to go for Textmodules.

These text modules can be created in the original language "EN" and can be converted in to differenet languages using txn SE63 using target language.


This way when you pass the the texmodule and the login language to the fileds of Text created in the Context node i.e.

Text Name -- 'ABC' (Name of the Text module created)

Textlanguage -- Langu. (This langu is the variable which is passed either from interface or from print pgm as import parameter where langu = sy-langu).


Now as you have converted all the text modules in the required languages,when you run the form in that particular login you get the necessary out in that particular language.


As per me this is the best and easiest way to proceed.


The second approach you can opt for is the standard text.(S010).But the probelm here is we need to be careful of insert the standard text in the Transport Request as the creation of standard text explicitly does not ask for TR.This is the only difference apart from that this is equivalent to textmodules.


The last option Translation at form level is not recomended as this needs the form to be developed statically.And when you have a requirement of translating the forms in multiple languages the form takes the changes fine for the first initial time.But when the changes are requested at later point of time to the translated text,we face issues with New text not getting reflected in the latest generated form(Not immediately).


Looking at all the available options,I suggest you to go for textmodules.

SAP TechEd 2013 just opened in Las Vegas. Do you use the current solution of SAP Interactive Forms by Adobe (IFbA) and would you like to hear about the new Mobile and Cloud functionality? Are you looking for a powerful and attractive document service that can be integrated seamlessly into your existing landscape?

Then you are in good company – the first session about IFbA generated a wave of excitement and useful feedback.

You have a
second chance to learn more about the current capabilities of IFbA including prefilling forms with data, offline usage, digital signatures, archiving options and integrations scenarios.

Is your company interested in using forms on mobile devices and/or in the context of an easy-to-consume cloud offering? Then come to the next session to find out about Mobile Forms and Cloud Forms.


There will be more opportunities to attend this lecture with demos in Amsterdam.


Filter Blog

By author:
By date:
By tag: