Understanding how Adobe Document Services (ADS) fits into the SAP system and the role it plays in printing are the keys for understanding how printing with the SAP Interactive Forms software by Adobe (SAP Interactive Forms) differs from legacy printing in the SAP system. Find out how SAP Interactive Forms are integrated into the print job status view in SAP transaction SP01. In addition, I introduce some new development that allows printing of SAP Interactive Forms on any Windows printer without worrying about the printer’s device driver.

The article is for system and print administrators. You should be familiar with the Basis architecture of the SAP system and the basics of SAP printing terminology. I focus on the special requirements of SAP Interactive Forms printing compared to SAPscript and Smart Forms. This is not an introduction on setting up a print environment in the SAP system.

Printing Architecture of the SAP System

The general architecture of the SAP system is three tiered: a single database, several application servers, and multiple front ends. The application servers consist of the kernel written in the C and C++ programming language and the ABAP application layer on top of the kernel. Users write their applications in the ABAP programming language. The kernel consists of several work processes with different modes. There are batch work processes without a user interface for large background tasks. Dialog work processes have a connection to the front end component process user interactions with the SAP system. Update and enqueue work processes coordinate the database access of all other work processes. Spool work processes generate the print output in a printer understandable language. Figure 1 shows the process view of an SAP application server with several work processes.

Figure 1

Process view of an SAP application server

Spool and Output Requests

A spool request is a collection of form and application data that is intended to be printed at some time. There are different types of spool requests in the SAP system — ABAP lists, SAPscript, Smart Forms, SAP Interactive Forms, and binary spool data. I focus on the difference between the spool requests created from form tools SAPscript, Smart Forms, and SAP Interactive Forms. These spool requests are created from ABAP print programs generated from the form processing tools. For SAP Interactive Forms, this tool is the Adobe LiveCycle Designer.

The print programs make calls to several ABAP APIs. The most basic ones are three ABAP function modules to create a new spool request, to write data to a specified spool request, and to close it after writing has finished. These function modules contain several parameters. The most important ones for this article are the printer name that specifies an SAP-defined printer on which you want to print the spool request and a logical flag that determines whether the spool request should be printed immediately after closing or not.

The Print immediately parameter controls the printing workflow of applications. Spool requests are only printed after they are closed if it is set to the value 1. Otherwise they stay in the system for further use.

Let me show you an example using an accounting workflow that creates the accounts for letters A to M on Thursday and N to Z on Friday. All accounts should be collected in a huge single spool request and printed on Friday after the second run has finished. The first run on Thursday creates a new spool request and writes the data for letters A to M into it. After it has finished, the first run closes the spool request. The second run on Friday appends the data for letters N to Z to the same spool request and closes it again after finishing. Finally it triggers the printout. Triggering the printout creates an output request from the spool request. This means the spool request’s data is translated into a printer definition language (PDL), depending on the printer’s device type.

This translation happens in the spool work process of the SAP system within the SAP kernel. The output request’s PDL data is sent to the printer for output. After an output request is created from a spool request no further appending is possible. Each time a printout is triggered, a new output request is created. The spool request can be printed as often as you like, as long as it stays in the system. Spool requests also can be finished without printing. Then also no appending is possible. Appending to a spool request requires strict conditions. For a document to be appended to a spool request, the following preconditions must be fulfilled:

• The parameter Create new spool request must not be set for the document
• The spool request that is intended to be appended to must not be already completed
• The spool request may not be processed from another work process  

The system checks all spool requests that fulfill these preconditions to determine if there is a suitable spool request to which the document can be appended. If there is no suitable spool request, the system creates a new one automatically. The following attributes are checked and must match:

• Client
• Owner
• Format
• Printer name
• Number of copies to print
• Deletion date
• External mode (an internal parameter set when the work process is created)

Some other weak attributes such as department info, title, name, or title pages are only compared if the creator sets them via the user interface or the application via function module parameters. All these attributes are either explicitly or implicitly set during the creation of a new spool request.

Printers and Device Types

A printer in a SAP system consists of several attributes that describe how and where a spool request is prepared for printing, how the prepared data stream is sent to the printer, and on which physical device it should be printed. How a spool request is prepared is determined by the device type of the printer. A device type specifies settings of the PDL the physical printer is able to understand. The spool request must be converted from the internal format to the PDL. This is done from a spool work process. The spool server attribute within an SAP printer specifies the application server on which the spool request is prepared. The access method specifies how the print data is send to the physical printer by the spool work process after finishing preparation. This can be done via network or via operation system command, for example.

There are a lot of printers with different PDLs on the market. It is a prerequisite for printing on a certain printer that an appropriate device type exist within the SAP system. This is comparable to a home PC: You only can use a printer if a Windows device driver exists for it. However, nearly all printer models on the market have a Windows printer driver. But not all printer models have an SAP device type.

You can use the generic device type SAPWIN for those models as with either SAPSprint or front-end printing. The SAPWIN interpreter in the SAPSprint service translates the generic SAPWIN device type information. The translated data stream uses the Windows device driver for printing, so it can be used for all printers. However, it only can be used on the Windows platform.

All non-SAPWIN device types are called native device types. As long as not mentioned explicitly, I am referring to native device types in this article. Some of the native device types can be used for different printers, because they belong to the same PDL family. This means certain printer models understand the same basic PDL. They are only different in some printer features. For SAPscript and Smart Forms a lot of device types exist. For SAP Interactive Forms, the number of available device types is much smaller. The four following Basis device types are available for SAP Interactive Forms printing:

• POSTSCRIPT: The Postscript PDL is a common PDL that is understood by numerous printers from different vendors.
• PCL: This PDL is from Hewlett-Packard and understood especially by HP printers. However, some printers from other vendors are able to understand PCL.
• ZPL: This PDL is for barcode printing on Zebra barcode printers only.
• PDF: Correctly spoken PDF is not a PDL but a document format. However, some printers can print PDFs directly so PDF also could be treated as a PDL. PDF plays a role as a generic device type similar to SAPWIN with a new product PDFPRINT, as I explain later in this article. Finally, PDF is used for print preview.

 ADS

In summary, the printing workflow for SAPscript and Smart Forms is as follows: Forms and application data is collected in a spool request until the spool request is finalized or printed. You carry out the collection by appending data. The PDL is generated as an output request from the spool request within a spool work process of the SAP system and sent to the printer. For SAP Interactive Forms, the final PDL for the printer is the same, but the workflow to it is completely different.

First of all, the creation of the PDL is not performed within a spool work process. Instead, the ADS is used. This component does not run within the SAP kernel, but within the Java Stack of the SAP system. This stack consists of numerous Java services running on the SAP JEE server. This architecture is shown in Figure 2.

Figure 2

SAP system with ADS

The input to the ADS is a set of three XML files: The first one consists of the form data generated from the Adobe LiveCycle Designer. The second one consists of the application data that fills the form and is generated from the ABAP print program similar to Smart Forms. The third one consists of the printer description on which the form finally should be printed.

The file extension of this XML file is XDC. The XDC is comparable to the SAP device type definition. XDC files are not being generated but must be installed on the file system together with the ADS. The output of the ADS is a file containing the generated PDL according the specified XDC. The ADS output is stored in a subdirectory of the global directory of the SAP system (usr/sap/<SID>/SYS/global). This is the second difference compared to legacy printing: The PDL is not generated as an output request at the time of printing. It is generated at the time of processing the form and stored as a file for later printing. In other words, finalizing and printing a SAP Interactive Forms spool request means the spool work process is sending the formerly ADS-generated PDL to the printer. The SAP spool work process does not generate any PDL for SAP Interactive Forms printing. Figure 2 illustrates this.

Device Types and XDC Files

As mentioned earlier, SAP device types and Adobe XDC files are comparable. Both consist of the necessary definitions to generate the appropriate PDL. However, since the generation for SAP Interactive Forms, SAPscript, and Smart Forms is carried out from completely different components, there is one further overlap.

Remember, a printer in the SAP system consists of a device type. The device type specifies which PDL must be generated. Now what about SAP Interactive Forms? Instead of SAP device types, XDC files are necessary for the generation. How is the correct XDC file determined during processing time of the form? The application using SAP Interactive Forms does not know anything about XDC files. It only uses a printer name on which to print the form as well as for SAPscript and Smart Forms processing. The mapping that the XDC file uses for a certain printer is carried out via SAP database table TSP0B. The mapping shown in Table 1 is delivered with an SAP system according to the supported PDLs.

Table 1

Delivered mapping

This means SAP Interactive Forms can be printed on all printers that consist of the specified device type. Because of the large number of SAP device types belonging to the same family, you can use printers that do not have exactly the same device type. If no entry is found for a certain device type, the PDL family is checked. If it matches with one of the basic device types the system uses the corresponding XDC file for printing. 

For example, HPLJIID is also a PCL device type, so the hppcl5e.xdc is used for printing. If no basic match is found in TSP0B and no matching via the PDL family is detected during processing, the error message Cannot find PDL type for output device <device name> is shown. Entries in table TSP0B can be created, deleted, and changed via report RSPO0020. The basic XDC files are installed during the installation of the ADS.

Navigation in Spool Requests

With transaction SP01, you can look at the generated spool requests of your SAP system. Figure 3 shows the various types of spool requests: SAP Interactive Forms, SAPscript, and ABAP lists.

Figure 3

Types of spool requests

As mentioned, you can append data to spool requests as long as they are not finalized. Spool requests for SAPscript and Smart Forms consist of a single block of data in an SAP internal format. Since SAP Interactive Forms consist of PDL files stored on the file system, each append to a spool request generates a new file. Therefore, SAP Interactive Forms spool requests can consist of a large number of single files independent from each other. These single files are called parts. For SAP Basis releases 6.40, 7.00, and 7.10 the part list is shown first after you click an SAP Interactive Forms spool request in transaction SP01. Figure 4 shows the part list of a SAP Interactive Forms spool request.

Figure 4

Part list of PDF-based forms spool request

After you select a certain part and click the view icon, the content of this file is shown (Figure 5).

Figure 5

Content of a part of a PDF-based forms spool request

You can navigate forward and backward with the arrow buttons at the top of the window through the single parts of the whole spool request. The preview of the single parts is always shown as a PDF, regardless of the device type of the spool request. Before the PDF is shown, the system automatically makes an additional call to the ADS to generate the PDF file. 

This is the first reason for the PDF XDC file mentioned before. The PDF XDC generates a PDF file for print preview. The other two files containing the form and application data were stored together with the generated PDL output with the spool request. Because of performance reasons the generation of the PDL and the PDF print preview are separated into these two steps. Not all parts of a spool request will be used for print preview; therefore, the PDF is only generated if required.

Because the part list is not very informative, the navigation through SAP Interactive Forms spool requests has changed with SAP Basis releases 7.01 and greater (except for 7.10). The part list is omitted. After clicking an SAP Interactive Forms spool request in transaction SP01, you immediately jump into the first part of the spool request. More navigation buttons are at the top of the window. You can navigate forward and backward in steps by 1, 10, 100, and 1,000 parts (Figure 6).

Figure 6

New navigation for PDF-based forms

If the part list is needed, you can enable it in the mentioned releases through activation of the SHOW_PART_LIST option using report RSPO0021 (Figure 7). RSPO0021 is a general report to activate or deactivate different spool options.

Figure 7

Report RSPO0021

Printing PDF-Based Forms with SAPSprint

SAPscript and Smart Forms enable the use of the generic device type family SAPWIN. With all SAPWIN-like device types, you don’t have to care about the PDL your printer can understand. You can print on each printer as long as there is a Windows device driver for it.

SAPWIN cannot be used for SAP Interactive Forms. The SAPWIN data stream is generated from the spool work process in the SAP kernel. SAPSprint consist of a SAPWIN interpreter which transfers the SAPWIN data stream into the printer’s PDL via the Windows programming interface using the Windows device driver. The PDL for SAP Interactive Forms is generated from ADS. ADS is not able to generate a SAPWIN data stream. Therefore the printers that you can use for SAP Interactive Forms are limited to the ones understanding the PDLs.

Starting with SAPSprint release 7.20, which was shipped in March 2010, SAPSprint can use a brand new development from Adobe and SAP: PDFPRINT. PDFPRINT is a library that you must install separately on the same server as SAPSprint. During runtime SAPSprint automatically detects the existence of PDFPRINT.

PDFPRINT works in a similar way to the SAPWIN interpreter. It uses the Windows device driver to print on each printer. However, the input for PDFPRINT is not a SAPWIN data stream, but a PDF instead. If you define a printer with device type PDF1 in the SAP system, ADS generates PDF as the output. As long as PDFPRINT is not installed, this usually is only printable on a very limited number of printers. With PDFPRINT it is printable on each printer with a Windows device driver. It is the same as when you use Adobe Reader to view a PDF and print it from the reader. However, with Adobe Reader you have to open a single document, view it, and click the print button to print it. You can use PDFPRINT and SAPSprint for mass printing SAP Interactive Forms generated from ADS without any user intervention.

Michael Szardenings

Michael Szardenings is a senior developer in the SAP IMS organization. Working in the Systems Management Group within IMS, Michael is responsible for all kinds of Windows printing from SAP systems. He started his career in 1989 in the IBM Research and Development Lab in Germany, with the development of various user interface components for IBM mainframe computers. As SAP IBM came together on several joint venture projects in the systems management area, which includes job scheduling and printing, Michael’s focuses switched to SAP. He joined SAP in 2001.

You may contact the author at editor@sappro.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.