Smartforms Architecture
While creating Smartform, the following things are described:
- The layout of the form to set the element positions on a page
- The elements to be displayed (i.e text, graphics, addresses, tables etc)
- The form logic for example is used to read application data from internal tables, to introduce conditions, and to control process flows
- Form interface to transfer application data to the form definition
On activating the Smart Form, the system generates a function module that encapsulates all attributes of the Smart Form. As soon as the application program calls the function module, it calls the smart form for printing. The Smart Form uses the module's interface (which corresponds to the form interface) to transfer any table data previously selected and to print the form according to the form description.
The application data can be merged with the form. Independent of the amount of data, you can print data as tables on the form. Thus, one Smart Form describes a set of forms that are created through calls with different application data. One call of a Smart Form always corresponds to printing one form.
The form logic can also contain statements that further select data during form processing.
Adobe Forms Architecture
The SAP Adobe Interactive Forms technology allows creation of interactive Adobe Forms where the user can enter data. The data entered is directly pushed into SAP. Along with SAP Workflow, the SAP Adobe Interactive forms is a powerful mechanism for providing a high quality user interface.
With Adobe Interactiveforms :
- The user can email the Adobe Interactive form as an email attachmnet, or click buttons on the Adobe Form
- SAP system would automatically take further action such as creation of document sets, start of approvals workflow etc.
· Reduces operational costs and improves business process via automation
- Easy to customize and change organizational forms and put additional data
- Increased efficiency and accuracy
- Faster process due to automation
- User can fill the form and send it via email by automatically pushing the data into SAP
Architecture of Print Scenario
The 2 scenarios how PDF based forms are used in SAP system:
- Integration into classical ABAP programs.
- Integration into browser-based, interactive scenarios.
The integration into classical ABAP program processes data retrieval, user communication, result processing with the logic of ABAP screens, whereas in Interactive forms, individual forms are processed and displayed in a web browser, where the user is allowed to enter data into the form and trigger further processing.
Adobe Form Output
The function module created for the form inherits the parameters of the form interface, which includes all the form properties (like name, data type, optional, pass by value etc), logic to communicate with the form routine environment.
The form is simply a function module at runtime to which all required data of the form interface are transferred. The formatting of data and call to Adobe Document Services (ADS) runs automatically.
The function module created for the form is provided by FP_FUNCTION_MODULE_NAME, to get the generated function module for the required system.
Note: The name of the generated function module is different in every system because it is not transported. If you transport your form from the development system to the test / quality / production system, it has a different name in each system. Therefore, never address the form via a generated name directly, instead use the function module |
- Get Function Module name: FP_FUNCTION_MODULE_NAME
Where v_form is the form name and the generated Function module is returned to the variable g_funcname.
- Open a Print Job
The ABAP function module, FP_JOB_OPEN, must be called at the beginning of the form output and determines the following settings. The below mentioned function module includes a CHANGING parameter with the name IE_OUTPUTPARAMS.
The changing parameter SFPOUTPUTPARAMS contains the following parameters:
Field Name | Meaning |
NODIALOG | Suppresses the dialog box for the output |
PREVIEW | Initially selects a print preview |
GETPDF | Requests the return of a PDF document |
GETPDL | Requests the return of a print data stream |
GETXML | Requests the return of application data |
CONNECTION | Connection to ADS |
ADSTRLEVEL | Trace level of ADS |
BUMODE | Bundling mode |
DEST | Defines the output device (printer) |
REQNEW | Creates a new spool request |
REQIMM | Immediate output of the spool request |
REGDEL | Deletes the spool request after the output has been implemented NODIALOG |
REGFINAL | Completes the spool request |
SPOOLID | Adds the output to this spool ID |
COPIES | Number of copies |
PDLTYPE | Printer language for the return of the print data stream |
XDCNAME | XDC file for the return of the print data stream |
ARCMODE | Archiving mode |
NOARMCH | No modification of the archiving mode |
NOPREVIEW | No preview possible from the print dialog |
NOPRINT | No print possible from the print dialog |
NOARCHIVE | No archiving possible from the print dialog |
XFP | Activates the XFP output |
XFPTYPE | Type of the XFP output |
XFPOUTDEV | Device of the XFP output |
- Calling the generated Function Module
- Close the print job.
The form output is closed using the function module FP_JOB_CLOSE.
The return parameter E_RESULT(optional) which is of type SFPJOBOUTPUT, maintains the following details:
· Output Completed
· Archiving Completed
· Table with spool ids
· No: of forms
· No of generated pages
· User action after print view
- Ie. The following points summarize the Structure of Print Program
· Data selection
· Determining the generated function module
· Opening the print jobs
· Calling the generated function module
· Closing the print job
Bluesky
