Server-based printing from SAP systems on Microsoft Windows can occur via the Windows standard TCP/IP print service or the SAPlpd implementation. Both options, however, have some drawbacks. The TCP/IP print service only understands the old Berkeley communication protocol, which is not extendable for future requirements. Furthermore, it only is suitable for SAP device types with a native printer language (e.g., PostScript). The TCP/IP print service does not support SAPWIN device types that use the Windows printer drivers via the Windows Graphics Device Interface (GDI). The SAPlpd service has, on the other hand, a limited internal job queue, which is problematic when handling high print output; plus no multi-threaded job processing is possible.

For these reasons, SAP prepared an entirely new implementation of the print server as a Windows service in SAPSprint, replacing SAPlpd. You can print using SAPSprint and the TCP/IP print service from every SAP system, just as before. No changes are necessary in the SAP system itself. All you have to do is to replace SAPlpd with SAPSprint on the print server and configure it accordingly.

I describe the internal implementation of the SAPSprint service and provide all necessary information on how to install and configure SAPSprint. I begin with installing and configuring SAPSprint, which is the easy part. I then describe how SAPSprint processes a print job with the defaults options and then all possible configuration options that might change the processing, so you can take advantage of this robust program.

Finally, I discuss SAPSprint and front-end printing. SAPlpd was used for both printing methods, front end and server based. SAPSprint, on the other hand, is only for server-based printing. SAPSprint uses the same sapwin.dll, which is used also for front-end printing. Customers have been known to install SAPSprint on the front-end systems because that’s what they did with SAPlpd. I explain why you shouldn’t do this.

Install and Configure SAPSprint

Before you install SAPSprint, you need to delete SAPlpd manually. Usually you only have to delete the installation directory of SAPlpd. If you have installed SAPlpd as a Windows service using the SRVANY tool from Microsoft, you can remove the service from the Windows Service Control Manager by calling Instsrv SAPlpd remove. Make sure that no active print job is in the system at this time. The SRVANY tool is described in the Microsoft Knowledge Base article 137890 (https://support.microsoft.com/kb/137890 ).

Next, download SAPSprint as a self-extracting executable file from SAP Service Marketplace at https://service.sap.com/patches (logon credentials are required) and follow menu path Entry by Application Group > SAP Frontend Components > SAPSPRINT > SAPSPRINT > SAPSPRINT > Win32. You can also download the newest patch level from the download section of SAP Note 927074.

Launch the installation program, and then enter the installation path (for example, C:Program FilesSAPSAPSprint). Next, enter the LPD port to communicate with the SAP system (Figure 1). Normally, the default setting of 515 is suitable for the port. You should only change this setting if the Windows TCP/IP print service is also running on the same computer. If you change the port number, you also have to specify the new number in the printer configuration in the SAP system. The SAPSprint Windows service starts as soon as the installation has finished.

Figure 1

Enter the port during installation

Furthermore, the SAPSprint Windows service must run under a Windows user who has the relevant authorizations for the required printers. After the installation is complete, the service runs under the local system account. This user can access locally defined printers only. You specify the user using the options on the Log On tab in the SAPSprint Properties window (Figure 2). To navigate to the Properties window, click the Start button and then follow menu path Control Panel > Administrative Tools > Services. Right-click SAPSprint and click Properties in the context menu.

Figure 2

Specify the authorized Windows user after installation

Click the OK button to accept the values. You must restart the SAPSprint service if you change the user. After the restart, the configuration of the Windows print server is finished. The next step is to define a printer in the SAP system.

Configure a Printer on an SAP System

To define a suitable SAPSprint printer in the SAP system, call transaction SPAD. Enter the SAP printer name in the Output device field (e.g., ZTEST) and click the display button. You see the settings of the printer ZTEST. Press F8 to switch into change mode.

Next, switch to the Device Attributes tab, select a device type, for example, POST2, and then select a spool server. To display a list of active spool servers in your system, click the Spool Server field and then press the F4 button to open the Spool Administration: List of Active SAP Servers window (Figure 3). Double-click the name of the server name (shaded in green) you want to use (e.g., ALEXTEST).

Figure 3

Choose an active print server from the list

You need to ensure that the printer understands the chosen printer language of the device type. Search SAP Notes, contact your printer manual, or select an SAPWIN device type if you are unsure about what language your printer understands.

Jobs printed from printers with a native device type are called RAW jobs. All SAPWIN-like device types use the Windows printer driver on the print server. The print data is generated in the sapwin.dll as part of SAPSprint. POST2 is an example of a native device type, in which the print data is completely generated in the SAP system.

On the Access Method tab (Figure 4), choose S or U for the host spool access method. The access method describes how the print data is transferred from the SAP system to the print server. U is the Berkeley communication protocol, which is only implemented for legacy reasons. There is no need to use the U protocol with SAPSprint. S is the advanced SAP protocol and the preferred one, because of several advantages that I explain in more detail in the next section.

Figure 4

Enter printer details

In the Destination host field, enter the IP address or the server name of the server where you installed SAPSprint (e.g., 10.20.72.70). If you have changed the port number during SAPSprint installation, you must enter the same port number in the Port Number field, which will be visible after you click the connection options icon on the Access Method tab. In the Host printer field, enter the name of the Windows printer to which you want to print. You can find the Windows printer name in the Printers folder on the print server. Be sure to enter the name exactly as defined there. Blanks in the printer name are not supported. Save the printer. You can leave the default values for all other parameters.

To test the printer you have configured, call transaction SP02 and follow menu path System > List > Print. Enter the SAP name of the printer you defined, choose Print out immediately as time of printing in the properties section of the print pop-up window, and confirm the setting. If the SAPSprint service is running, the list should print.

Implementation of the SAPSprint Service

SAPSprint provides several features that meet a wide range of printing requirements. You need, however, to know what kind of requests the SAP system can submit to the SAPSprint service and how they will be handled. You also need to know when and why you might initiate an SAPSprint restart. Finally, you need to know how to distinguish SAPSprint from front-end print and how to configure SAPSprint for printing barcodes.

There are two modules of SAPSprint that work together to facilitate the print process:

• The main module that receives the print jobs, implemented in the sapsprint.exe file
• The processing module that processes the print jobs, implemented in the sapwin.dll

Both modules reside in the SAPSprint installation directory. SAPSprint is implemented as Windows service — i.e., if the process ends unexpectedly or during a controlled shutdown because of an error, the Windows Service Control Manager detects the problem and restarts it automatically. You will learn more about these modules later in the article.

SAPSprint Requests

The main thread of the sapsprint.exe module listens on a TCP/IP socket on port 515 (or the port entered during the installation). As soon as the socket receives a request from an SAP system, the request is handed over to a new thread, which handles the request. The main thread is available again for another request.

A request can be a print job submission or a print job status request for both access methods U and S. (More types of requests might be possible with the S protocol in the future.) Both protocols are handshake protocols — i.e., several TCP/IP data packets are sent forth and back for a single request. One data packet consists of a key and the corresponding data.

The exact protocol syntax of the U protocol is described in the RFC1179 (line printer daemon protocol), which is documented by the Network Printing Working Group The S protocol is SAP’s proprietary protocol, which is subject to change; therefore, it is not documented for public use. S and U protocols are also called access methods. This term is used for a special kind of method to transfer print data from the SAP system to a printer.

The U protocol is implemented for compatibility reasons. You will want to use the S protocol with SAPSprint, because of the following advantages:

• Better job and trace file identification (see the section “Job Submission Requests”)
• Better job status feedback (see the section “Job Status Requests”)
• Extendable for further requirements

Job Submission Requests

A job submission request consists of the data to print, the printer name, and the number of copies for this job. After the SAPSprint service receives this data, the print data is stored in a temporary file. All temporary files are located in the Logs directory, which is a sub directory of the SAPSprint installation directory. You can change this location using the LogPath option. The name of the temporary file depends on the protocol:

• _ — e.g., ABC0000012345_1 for the S protocol
• dfA<3 Digits> — e.g., dfA001lambik01 for the U protocol

The name of the temporary file is also used as the job ID to identify a certain job in a later job status request. For each printer a working thread is started with the first print job. Also a job queue is created together with the thread. The first and all subsequent jobs for this printer are entered in the job queue. The working thread is processing the jobs sequentially in accordance with the First In, First Out (FIFO) principle. You can change this behavior with the ProcessingMode option. All printer working threads keep running as long as the service is running. Job processing is implemented in the sapwin.dll. The following types of jobs can be processed:

• SAPWIN. SAPWIN is a generic data stream that is generated in the SAP system and interpreted by the sapwin.dll. The interpretation maps generic format commands from the SAPWIN data stream to the Windows GDI interface. With this interface, all printers with a Windows device driver can print SAP jobs. There are several language-dependent SAP device types of the SAPWIN type.
• RAW. All other print jobs are RAW jobs — i.e., the print data is already in a specific printer language. Examples of printer-specific languages include PostScript and Printer Command Language (PCL). The SAP system creates the print data by a spool work process of the application server, which you need to specify as part of the printer configuration (as described before in the configuration section). For RAW jobs, you must select a printer-specific device type in the SAP system.

Figure 5 provides an overview of how a job is transferred from an SAP system to a printer. The spool job is generated in a spool work process on an application server in the SAP system. The job is then transferred together with some metadata (printer name, number of copies) via TCP/IP port 515 to the SAPSprint executable running on the Windows print server. SAPSprint stores the print data in a temporary file on disk and enters the job in a printer specific job queue. Depending on the type of job, the temporary file either contains SAPWIN data or data in the language of the printer. The printer-specific working thread processes on job after the other. It either transforms the SAPWIN data to a printer language via the Windows device driver, or just sends the RAW data to the printer. Transforming and sending is implemented in the sapwin.dll.

Finger 5

An overview of how a job is submitted to a printer

Job Status Requests

An SAP system frequently submits job status requests to a print server for each print job until the job has reached a final status (i.e., Printed or Error).

Job Status Requests with the U Protocol

For a job status request with the U protocol, SAPSprint performs a one-step query. With a single request, SAPSprint looks for the number of jobs in the Windows printer queue, for the queue status, and for the number of jobs in the SAPSprint job queue. The job status is shown in transaction SP01 in the SAP system.

If no problem is detected in the Windows printer queue, SAPSprint returns a list of jobs in the queue to the SAP system. The following job statuses are set:

• Waiting for output formatter. The first status of a job before it even has been submitted to the SAPSprint service or processed from a spool work process in the SAP system
• Processing. The status of a job that has been processed by a spool work process, but has not yet been submitted to SAPSprint
• Completed. The status of a job that was submitted and is no longer in the Windows printer queue (SAPSprint assumes that the job was printed successfully.)
• Printing. The status of the first job in the Windows printer queue
• Waiting in host spooler. The status of a job that is at any other position (not first) in the Windows queue
• Waiting. The status of the SAPSprint service when it is not running

If the Windows queue status check detects a problem or an error, the job status is set to Problem and then to Error or Completed depending on whether or not the intermediate problem can be solved. A job status, Error respectively Completed, is a final state — SAPSprint stops querying the queue for that job. You may find additional information in the status text field of transaction SP01 (list of output requests) in the SAP system. The status text depends on the information returned by the Windows GDI. To display the list of corresponding output requests of a given spool request, double-click the Status text field of the spool request (Figure 6). You can print the same job again from transaction SP01. A new output request is generated for each new printout.

Figure 6

Display information relating to a job status

There’s no guarantee that all problems will be detected correctly by the Windows interface that SAPSprint is using to record a job status. With the U protocol, SAPSprint checks only the printer queue. This check is very limited according to the definition of the protocol, because if the U protocol is used for the communication between the SAP system and SAPSprint, most of the problems are not detected.

Job Status Request with the S Protocol

Generally the job statuses are the same as those with the U protocol. However, with the S protocol, SAPSprint performs an additional step if the job query does not find a job in the Windows printer queue. When the S protocol is used, SAPSprint creates a separate job status list. If no problem is detected during the processing of a job, the job status is set to Printed. If a problem is detected, then the job status is set to Problem. If something unexpected happens during processing, then the job status is set to Error. These statuses are stored in a SAPSprint internal job status list, which is updated after each processed job. These processing errors are only logged with the S protocol, so more problems are detected with the S protocol. Therefore it is the protocol recommended for use with the SAPSprint service. (The U protocol is supported only for compatibility reasons.)

The following are typical examples of problems that might have been detected correctly by the Windows interface used by SAPSprint, especially when using the U protocol. The job status will probably to set Problem in transaction SP01; however, the source of the problem will not be apparent.

• Printer is paused
• Printer has no paper
• Printer tray is not closed
• Printer has no toner
• Printer is switched off
• Printer share is not available

These problems usually will not cause troubles immediately. The SAP system still can submit jobs to the corresponding Windows printer queue. However, if the problem lasts very long, the queue and the internal SAPSprint job lists will grow and grow for a long time. Status requests will always get the same result again and again. The system load will also grow unnecessarily. In case of service restart, huge job lists must be kept and will slow down the restart process.

SAPSprint Restart

SAPSprint provides a restart mechanism that saves and restores the printer-specific job queues and the SAPSprint global status queue during a restart. This mechanism minimizes the potential loss of print jobs during a restart. SAPSprint stores the necessary information in the following files in the LogPath:

• stal.dbd. — Consists of jobs with a not-yet performed status (e.g., Processing, Waiting) from the SAP system, or with a non-final state
• prnl<5 digit number>.dbd — Consists of information for jobs that have been successfully received, but not yet processed; only one file per job queue

These files are automatically deleted after restore. You can, however, change the default by enabling the KeepRestoreFile option. You should only consider making this change if you think you will need access to the files for problem analysis after the restart. During the restore, the working threads for all printers with a job queue file are started before any new job is received from the SAP system. For the SAP system, SAPSprint is not available during the restart.

SAPSprint and Barcodes

SAPSprint cannot generate any barcodes on its own. With a native device type generating RAW print jobs, barcodes can be integrated into the print data stream from the SAP system. They can be printed if the printer is able to print barcodes. This printing feature often is only possible with additional barcode modules. Contact your printer vendor to determine if and how your printer is able to print barcodes.

The Windows GDI used by SAPWIN device types has no interface for using the printer to print barcodes, even if the printer is able to print barcodes. This option is simply not available in the Windows specification. However, SAPSprint can access the services of an external DLL that must be available on the PC as a third-party vendor product.

You can purchase a suitable barcode DLL from an external vendor, which corresponds to the interface specification SAPSprint/BARCODE.DLL (for details see SAP Note 25344). Once you install this product, your printer will be able to print barcodes when using a SAPWIN device type. If the system detects a barcode within the SAPWIN data stream, an appropriate call into the BARCODE.DLL is made during job processing.

Install the product according to the installation package of the supplier. Usually, you can find an initialization message from the BARCODE.DLL in sapsprint.dbg. SAPSprint looks in the following directories for the BARCODE.DLL:

• The WINDOWS directory, typically c:Windows
• The system directory, typically c:Windowssystem32
• The SAPSprint installation directory, typically c:Program FilesSAPSAPSprint

SAPSprint and Front-End Printing

Front-end printing describes a printing method in which the printer specification in the SAP system consists of a device type and a printer name, typically the string “__default.” This means that the default printer of the user’s PC automatically is used for printing. This is useful if you often change your working PC. No further configuration is necessary.

Why is this mentioned in the context of SAPSprint? The SAPSprint predecessor SAPlpd was used for front-end printing also. SAPlpd was installed on front-end PCs together with SAPGUI, and the front-end print access method with SAPlpd was called F. The connection from the SAP system to the local SAPlpd was as follows: A Remote Function Call (RFC) to a DLL (i.e., lprintg.dll) was made from the SAP system. The DLL, which is part of SAPGUI, worked as a RFC server. The DLL sent the print data through the local port 515 to the running SAPlpd, which included an old SAPWIN interpreter. This mechanism had several drawbacks:

• Inter-process communication between the SAPGUI process and SAPlpd was often point of failure
• Front-end printer selection in the SAP system required another RFC call to get the list of printers installed on the front-end PC
• Problems with the mapping of print jobs and users on terminal server environments arose because the SAPlpd process had to be shared between different users

Similar to the replacement of SAPlpd with SAPSprint for server-based printing with S or U protocol, the front-end printing method F has been replaced by the new access method G. I mention this because you should not install SAPSprint on a PC for front-end printing. SAPSprint is for server-based printing on a separate print server. The SAPWIN interpreter used by SAPSprint is implemented in the sapwin.dll. This DLL is installed with SAPGUI, which you can then use for front-end printing with access method G. Assuming that the correct patches for the SAP system according to SAP Note 821519 are installed, just switch F to G in the printer configuration transaction SPAD. Do not install SAPSprint on each PC.

SAPlpd should not be used anymore. SAP will not be developing or supporting it anymore. Some customers will, however, continue to use it.

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.