ABAP

Here is a comparison between the two largest print form formats.
All new forms delivered with the ERP will be PDF-based. So, it’s probably better to get ready to change.

Knowing those two print forms possibilities offered by SAP, you want to know more about what is the best technology to use.

Hopefully I’ll provide you some answers in this paper. I’ll probably write more complete comparisons as experiences with PDF forms grows.

Smart Forms architecture

The application program retrieves data from the database and is passed to the function module generated by the Smart Form. The application program, which collects data, has to be written. In many cases, a standard print program is copied, modified and then reused.

The Smart Form needs to be defined. With transaction SMARTFORMS, you can setup the layout you want. This is a powerful but quite old tool and its usage is requires some learning time.

PDF-based print forms architecture

At runtime, we notice the architecture is very close of the previous one.

In this case, a print program also needs to be written. The PDF form template, consuming data from its interface, is called by the generated function module. The call to the web service and the PDF is physically built during runtime.

The ADS component runs on the J2EE stack and exposes a web service allowing the rendering of PDF forms. This means extra calls between both stacks.

Note that you can use this web service to build other PDF forms.

Comparison: pro et contra

Development

Every form has layout problems at some point in time. Text is too low the page; the first name is not aligned with the last name, tables don’t display correctly etc. In both cases, there are a lot of tests („chipotages“, for the French-speaking people) to perform before a form version can be released.

There is a first advantage of PDF in comparison with Smart Forms. The Adobe LiveCycle Designer (ALD) is at first sight simple, yet powerful and comprehensive. So to build a layout is easier with PDF forms for people with limited experience.

When you have lots of forms to develop, you can enhance the custom objects in the ALD: you can add multiple UI objects and group them in one element which you can easily reuse. For instance, a ‚UserData‘ element that contains firstname, lastname, street, postal code and city. Element types as well as the layout are stored locally (in folder C:\Users\\AppData\Adobe\Designer\en\objects\), so exchange with other forms developers is quick and easy.

So, bottom line 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. This may result 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 NetWeaver 2004s SP12, is described in SAP Note 993612.

Smart Forms, which run fully on the ABAP side, can be 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 NetWeaver 2004 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 for 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.

Smart Forms require 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 Smart Forms for various reasons: your SAP system printing documents is R/3 4.7; you have plenty of qualified developers who know Smart Forms very well; you need very high performance rather than flexibility etc.

Courses

One reference course for Smart Forms: BC470 – Form printing with SmartForms.

The Adobe LiveCycle Designer embedded in an SAP environment offers a lot of possibilities. More information can be found in SAP course BC480 – PDF based print forms (3 days).

Conclusion

Smart Forms 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), my choice goes to the PDF for the reasons mentioned above.

© Francois Gendebien