SAP Print Workbench and SAP Interactive/ Print Forms by Adobe
The purpose of the document is to provide information on conventional methods for forms in SAP like SAPSCRIPTs and SMARTFORMs and to describe the problems faced in using those methods. In the second part the document explains about the solution domain i.e. SAP Print forms and SAP Interactive forms by Adobe.
The document also explains the multiple ways in which these forms can be used. The document covers the areas where these forms can be applied.
Along with these details document covers the benefits of using this technology and pre-requisites for this.
Key Words: SAP SMARTFORMS, SAPScript, SAP Print forms and SAP Interactive forms.
The document aims at providing information on SAP’s print workbench and multiple technologies available in SAP to print and process data.
In the first part it describes about various print methodology available with SAP for printing data in SAP system. The document moves step by step from conventional methods to modern methods of print methodologies.
Each method has some benefits and some drawbacks over the modern methods. The document describes that part by comparing the older technologies with the newer one.
The main emphasis of the document is on capturing the benefits of SAP Print forms and SAP Interactive forms by Adobe over the conventional methods SAPScripts and SMARTFORMS.
We can say SMARTFORMs were replacement tool for SAPScripts and SAP Print forms by Adobe are replacement tool for SMARTFORMS. SAP Print forms are easier to design, easy to handle and easy to integrate. Following sections covers all these benefits.
SAP Interactive forms provide much more than printing and previewing data. We can say SAP Interactive forms act as a transport between the end user and SAP Database.
Also we can design a complete SAP transaction using an interactive form and that can be used without having access to SAP system and SAP GUI on user machine. The only thing the user requires is Adobe reader to view and interact with form. These forms are beneficial in terms of data security as well. These forms provide digital signature. The digital signature guarantees a unique identification of the signer of the form. These forms can be applied in multiple SAP processes and multiple technologies of SAP Applications.
The Print Workbench is a central development environment for creating standardized outgoing correspondence. To configure the forms, the Print Workbench uses the SAP standard components for configuring forms – SAPScript, Smart Forms, and PDF-based forms.
The Print Workbench is subdivided into the following sub objects:
Form classes:
Form classes are defined by SAP applications and contain a modelling as well as access instructions for all of the data that belongs to an application or an application process. You can use form classes to create application forms where you access the data defined in the form classes. Invoices, dunning notices, and account statements are examples of form classes. The form classes are delivered with each application component that uses the Print Workbench. Changes to form classes delivered have modification status.
Application forms:
You create application forms based on the form classes delivered. You can define several application forms for each form class, for example, different invoices for different business partner groups. SAP delivers example forms that you can use as a reference for your own application forms. You can use user exits to adjust the application forms to your requirements. Numerous help functions simplify form creation.
You can call up the Print Workbench via the area menu PWB.
The Print Workbench (CA-GTF-PWB) is a component of SAP Web Application Server and it can be used with no further prerequisites by every other SAP application. In the Print Workbench you can use Smart Forms (BC-SRV-SSF), SAPScript (BC-SRV-SCR), or PDF-based forms (BC-SRV-FP) alternatively.
Architecture of the Print Workbench
In most of the processes SAP uses SAPSCRIPTs and an enhanced but a separate tool called SMARTFORMs. SAPSCRIPTs are the oldest technology in area of forms with SAP. These are very problematic in terms of designing and integration. To overcome such problems SMARTFORMs were introduced and they are much more efficient but not up to the mark. SMARTFORMs do have some limitations in designing as well as integration. Sometimes it has been observed that they are incompatible with the legacy systems where SAPScript integration was possible.
In this section SAPScripts and SMARTFORMS will be covered.
SAP’s first form technology was the SAPScript technology.
Often there are instances where an output from a SAP program is required on a physical paper in a pre-designed format. Using normal ABAP code this is not possible. Instead SAP provides an object called SAPSCRIPT to generate such kind of documents which can contain logos, tables and other objects and which can look like pre-printed documents.
To use forms efficiently, it is essential to understand the interdependencies between the individual components of SAPScript.
SAPScript comprises these five components:
In short, form maintenance means to allocate to a text document a form that contains the information on how to layout the text (formats, fonts, layout, and so on). The print program retrieves the required data from the form and from the database and controls the output. You use certain function modules to activate the SAPScript composer, which is responsible for processing the form.
Not every user of the SAP system works with every component of SAPScript. Depending on the task, a user is confronted with different components.
In release 4.6, SAP introduced Smart Forms, which eased the creation of form output by allowing modelling of logic and output using graphical tools.
SMARTFORM is a template that simplifies the process of designing business forms. You need SMARTFORMS to print, distribute or display business forms. SMARTFORMS tool includes utilities for designing forms and for defining the interface to the application programs that use forms for data output. The output of application data is placed into a dynamically expandable table where the size and layout of the output table is determined by the number of records being retrieved.
SMARTFORMS are used for designing and printing various types of application documents across the various SAP modules like SD, FI, PU, IM, WM etc. SMARTFORMS are used for mass printing like monthly invoices sent by telecom companies or salary statements.
If you have many forms already built in SAPScript, you may migrate them into Smart Forms to avoid building the Smart Forms from scratch and save development time. Two types of migration are available: individual migration and mass migration. You can migrate a SAPScript form into a Smart Form and convert a SAPScript style into a Smart Style.
Smart Styles contain the formatting information for the text. In Smart Style, you take the smaller components (paragraph and character formats) for conversion individually, whereas for Smart Forms, you take the entire Smart Form for conversion. Each conversion of a Smart Form requires a separate conversion of the accompanying Smart Style; some of the steps, however, are the same. The first phase of the migration is the download.
Advantages over SAPScript:
SAP Smart Forms have the following advantages:
In release 6.40, SAP introduced Adobe forms, where the graphical editor was much more easy-to-use and had many more functionalities, and output was rendered exactly the same as what was designed in the editor (PDF).
SAP Interactive Forms by Adobe is the latest form technology which is rendered by SAP and Adobe. It aims to automate and streamline forms-based communication to support customers who create reusable forms for their business processes. This solution uses Portable Document Format (PDF) and software from Adobe Systems Inc. that has been integrated into the SAP environment.
You can create interactive forms in PDF format that allow users to fill out the form on the screen and save their entries in XML format in the form. When the SAP system receives the PDF form, it extracts the data saved in the form, and can process it further. You can also merge a form template with current system data to generate a PDF document that can then be printed or sent by e-mail. If the form is not interactive, it can also be called PDF-Based Print Forms.
Software Requirements:
Server Requirements
b) Adobe Document Service (ADS) installed on the Java stack and configured
Developer Requirements:
a) Adobe Live Cycle Designer is installed in the desktop.
b) Adobe Reader 7.* or higher is installed.
End User Requirements
Purpose:
PDF-based forms are part of the SAP Interactive Forms by Adobe solution. You use this solution to create and edit PDF forms for printing in SAP systems. As well as standard output on printers, and the option of archiving documents, you can also use your application to send a PDF to the Business Communication Services (BCS). Here, you have the option of faxing or e-mailing your documents.
The following gives you an overview of how a PDF-based form is structured, and also tells you how to create a PDF-based form in the development environment of ABAP Workbench. The integrated Adobe Live Cycle Designer™ software supports you when you do this. This software must be installed on your front end before you can create a layout. To see a print preview of your form, you first need to install Adobe Reader or a complete version of Adobe Acrobat.
You create and edit interactive forms in the development environment SAP Netweaver Developer Studio. To create interactive forms here, you use the interface element Interactive Form in Web Dynpro for Java.
This documentation does not discuss how documents are printed and controlled on printers. Instead, it discusses the whole process up to when a file is sent to output management functions, such as the spool system in SAP systems. Note that, for printing and previewing PDF-based forms, you need to use a PCL, Postscript, or ZPL printer and an appropriate device type (such as POST2, HPLJ4, HP9500, PDF1, AZPL203, or AZPL300). You cannot use a printer with the device type SAPWIN/SWIN. More information is available in the SAP Printing Guide (BC-CCM-PRN), under Printing PDF-Based Forms.
Integration:
An activated PDF-based form corresponds to a callable function module in the SAP system. The complete logic of the form is represented by this function module. When a form is printed, it is called by an application program, which collects the relevant application data. The application program uses the function module interface to send the data. Therefore, the data collection process is split from the logic of the form. This means that you only need to adjust the form when you modify the logic or layout.
Features:
To develop a PDF-based form, you use the Form Builder tool that is integrated with ABAP Workbench. This tool enables you to create a complete form description, even if you do not have extensive programming skills. The tool supports you in the following tasks:
Here, you use the Adobe Live Cycle Designer to design pages or create the layout.
In the form context, you specify which data, tables, texts, and graphics are sent to the form.
By migrating Smart Forms, you can reuse them as PDF-based forms. You can find the Smart Form migration tool in transaction SMARTFORMS.
This tool is integrated into Adobe Live Cycle Designer and enables you to use your own templates for your form.
Adobe Live Cycle Designer uses the script languages JavaScript and FormCalc. FormCalc is a simple Adobe script language for typical form calculations, including mathematical and logical functions, and date and character string functions. For more information about FormCalc, and a FormCalc language reference, see the online help of Live Cycle Designer.
To achieve the best level of performance when processing forms, use as little scripting as possible in the form. If possible, perform all calculations and data analysis in the application program, before the form is called.
You can use output parameters to specify print and archive settings, and so adapt the output to your requirements. These parameters are not viewed in Form Builder. Instead, you control them with function modules that you integrate in your application program.
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 to perform before a form version can be released.
There is a first advantage of PDF in comparison with SMARTFORMS. The Adobe Live Cycle 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 ‘User Data’ element which contains first name, last name, street, postal code and city. Element types as well as the layout are stored locally (in folder C:\Documents and Settings\<username>\Application Data\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.
Suppose 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. In this case also PDF- based forms will be more useful as SMARTFORMS have always the problem of layout alignment.
Following table compares all the forms technologies provided by SAP:
Parameter | Sap Script | SMARTFORMS | Adobe Print Forms | Adobe Interactive Forms |
Multiple Page Format | Multiple page format is not supported | Multiple page format is supported | Multiple page format is supported | Multiple page format is supported |
Client dependency | Client dependent | Client independent | Client independent | Client independent |
Drag and Drop | Drag and drop for designing is not available | Graphical tool for designing is available | The graphical editor is easy-to-use and has many more functionalities | The graphical editor is easy-to-use and has many more functionalities |
Access to SAP | Reads data from SAP and displays it on SAPGUI | Reads data from SAP and displays it on SAPGUI | Reads data from SAP and displays it in PDF format | Reads data from SAP and updates or saves data to SAP |
Usage | Used for print output | Mainly used for print output | Can be printed and sent via email | Data can be entered and saved in the form and passed to SAP. These can also be printed |
Development Time and complexity | Development is time consuming | Comparatively takes less time | User-friendly tools reduce the time and costs associated with creating form layouts | User-friendly tools reduce the time and costs associated with creating form layouts |
Appearance | The appearance might change while printing | The form appearance might change while printing | Form retains its appearance regardless of the environment it is used in | Output is rendered exactly the same as what was designed in the editor (pdf) |
This section mainly focuses on the complex areas where SAP Interactive forms can be applied.
Following are some of the solutions in some of these complex areas:
1. SAP Interactive forms through Guided Procedures in Portal.
2. SAP Interactive forms using web services.
3. SAP Interactive forms using Web Dynpro applications.
This section elaborates step by step procedure to create a guided procedure integrated with SAP Interactive Form to achieve the offline scenario to send a form to an external e-mail Id and receive the filled form back. The process would be having following steps:
Preconditions
Configurations mentioned in the following document should be completed before creating this Guided Procedure:
The step by step procedure:
Guided Procedures and SAP Interactive Forms by Adobe Integration
This section describes how we can create web service from an existing function module or BAPI and how we can use it in a SAP Interactive form based on some Business Scenario.
Creating Web Service based on Function Module/BAPI
Creating Web Service from Function Modules/BAPIs & Integrating with SAP Interactive Forms
The third area where SAP Interactive forms can be used is Web dynpro applications. These applications can be fit in any SAP business scenario and are widely used on SAP Portal. These applications use standard download and upload functionality. In any scenario where forms are required one web dynpro download and one web dynpro application is required. The download application contains the actual interactive form required in business process. Using this application user can download the form. This form can be used as an offline tool to store data and later on this form can be uploaded to the SAP system. The important thing is that data captured in the form remains secured as well as it can be validated using coding scripts provided by form designer.
This is a general upload/download scenario in web dynpro but can be useful in many standard existing scenarios as only a small upload and download application is required to be developed and embedded in the process.
Below are some of the issues and limitations of SAP Interactive forms and print forms based on some of the areas:
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.
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. 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.
Cost based on licensing
The license for Adobe forms is needed, if the following three criteria apply to you. Then you must purchase an additional license from SAP for your SAP Interactive Forms:
This extra licensing need adds extra cost to the customer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
10 | |
9 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |