So, bottomline is that development time can be reduced by using PDF forms. Of course, this also depends on your developers’ skills.
Performance
As you know, every object-oriented language has performance problems. So does Java... The ADS component is also heavy and the rendering time of a very complex PDF form, with lots of scripting logic and data to display can take some time, and sometimes results in heavy documents. Another reason for the sometimes slow performance is the web service connection.
This performance issue must be taken into account when considering high volume printing and complex forms.
Of course, be aware there are possibilities to improve PDF rendering time. Form bundling is one of them (the bundling principle is to send multiple forms in one call to ADS); another one, valid as of nw04s SP12, is described in the SAP Note 993612 .
SmartForms, which run fully on the ABAP side, can be basically faster than PDF... for the moment. I'll probably post more about performance comparisons in the future.
Regarding stability, both technologies are equivalent and I personally never had problems regarding this. Feel free to provide your input!
Architecture
As said earlier, PDF requires a J2EE stack with ADS properly configured and with connections between both systems up and running. This is done in standard as of NetWeaver04 SR1 so don’t panic! Every recent SAP solution includes the J2EE stack including ADS.
There are web services calls between the ABAP and J2EE stacks, which makes additional connections to handle.
In terms of architecture, the PDF seems to require more attention. Although, the J2EE stack with ADS is installed and configured in standard as of the ERP2004 so there should be no particular worries about this.
Front-end and clients
The PDF requires Adobe Reader to display PDF forms. Nowadays, almost every workstation has Adobe Reader installed on it. Reader is not required to print forms: hopefully, the normal PDF drivers are supported in SAP systems as well as most of standard printer drivers.
SmartForms requires no additional installations on top of the standard SAPGui.
Compatibility
Customer examples
In this case, everything depends on your scenarios. Some examples for PDF: you need to respect a legal template, which is provided in PDF; PDF is already widely used in your company; you have all the other Adobe products; you need to send printed invoices to your customers automatically via mail with PDF format etc.
On the other hand, you can choose to use SmartForms for various reasons: your SAP system printing documents is R/3 4.7; you have plenty of qualified developers who know SmartForms very well; you need very high performance rather than flexibility etc.
Courses
One reference course for SmartForms: BC470 – Form printing with SmartForms.
The Adobe LiveCycle Designer embedded in an SAP environment offers a lot of possibilities. More information with BC480 – PDF based print forms course (3 days).
Conclusion
SmartForms is the faithful technology for those who know it. Still useful and reliable as well as very powerful.
On the other hand, the PDF-based print forms is highly appreciated for its comprehensiveness, compatibility, design possibilities. It’s also the future for form output in SAP solutions...
So, the choice is now yours. Personally (but as you may know, I’m not the most objective person when speaking about forms :wink: ), my choice goes to the PDF for the reasons mentioned above.
Related Content
- [Adobe Interactive Forms homepage on SDN | https://www.sdn.sap.com/irj/sdn/interactiveforms]
- [Adobe Interactive Forms forum on SDN | SAP Interactive Forms by Adobe]
- [Adobe homepage on Service Marketplace | http://service.sap.com/adobe]
- [SmartForms homepage on Service Marketplace | http://service.sap.com/smartforms]
7 Comments
