Planning the SAP Print Architecture

You should plan your SAP print architecture especially carefully if you must deal with the following print tasks:

• Printing time-critical documents (such as delivery notes: if these are not added to the delivery, the product cannot be sent)

• Printing large print requests (for example, printing long monthly lists).

The following aspects are intended to support you in planning your optimal print architecture.

The print data of a spool request is stored in TemSe (a store for temporary sequential objects). You can define whether the objects are to be stored by TemSe in the SAP database or in the file system by setting the profile parameter rspo/store_location.

• When you use value db (the default value), the print data of a spool request is stored in the database table TST03. Advantage: The spool/TemSe data is saved using regular DB backups and then restored. The database keeps the various spool/TemSe tables consistent when restoring them. No additional memory is required in the file system for TemSe. Disadvantage: It takes longer to write to the database than to the file system (generally also longer than writing to NFS file systems). The temporary spool data is always saved too, which makes the backups longer.

• When you use value G, the print data of a spool request is stored at the operating system level in the (global) directory /usr/sap/<SID>/sys/global. Advantage: Usually much quicker than writing to the database. Disadvantage: The data is backed up outside of the database backups, which means that the administration tables TSP01 and TST01 might be inconsistent with the files in the file system and need to be made consistent again using consistency checks after restoring a backup in the case of disk crashes. If the SAP system consists of multiple instances on multiple machines, the 'global' directory must be mounted on all machines using NFS; if not, inconsistencies occur and spool operations cannot run without errors. Enough disk space must be available, since spool data can easily reach volumes of several GB in the file system.

• When you use value L, the print data of a spool request is stored at the operating system level in the (local) directory /usr/sap/<SID>/<Instance>/data. Advantage: Usually even quicker than option G, since the data is written to and read from a local disk. Caution: This value should only be used in special cases. If misused, it could cause inconsistencies in spool/TemSe and produce printing errors. L specifies that the creator of the spool data and the spool work process are part of the same instance and run on the same physical machine (to which the printer is also connected). The printer must also be assigned to this spool work process. The spool requests are created in this way so that they can only be edited on this instance. This type of configuration requires a lot of work and is therefore not recommended.

• When you use value T, the print data of a spool request is stored at the operating system level in the temp directory /tmp (Linux/UNIX default), C:\Temp (Windows default). This directory is used by the operating system independently of the SAP system and, more specifically, is deleted without the SAP system being informed. This can produce data loss, inconsistencies, and other errors when printing. This means it should never be activated in production environments.

For more information, see SAP Notes 20176 – Where is the spool request saved? and 11070 – Space requirements of TemSe and spooler.

The first task to plan a print architecture is to determine the most important print requirement. For this, you should identify which users print time-critical documents (for example, delivery notes), which users prints large documents (such as ABAP list reports) and what is the expected total quantity of output request in your SAP system.

Next you need to determine how important the respective printers are (important printers are for example printers whose output is time-critical).

Then you may think about classifying the printers. In case that you have set up three or more spool servers in your SAP system, you may then finally assign every print group to one or more spool servers.

To get an optimal printer throughput, you may distinguish (see the following figure):

• For production printing (time-critical printing), you should usually use local printing as it is probably faster than remote printing. Remote access methods should be taken account for production printers in case of high reliability (failure safety with the help of logical spool servers) in case that the network between the spool work process and the host spool system allow a high data throughput.
• Similar to production printing, for mass printing, local access methods also have the advantage of better performance – when you use remote access methods, you require a fast network and a reliable printer server. You may also think about setting up a separate spool server for mass printing so that processing of long lists does not affect the output of other output requests.
• For non-critical printers, you may also setup a separate spool server so that they do not affect and are not affected by print requests for other printers. You should never use a spool server for both time-critical and non-critical printers, as the non-critical output requests could block the processing of the time-critical output requests. For example, if a non-critical printer that uses access method U or S cannot be accessed, time-critical printing may be seriously delayed.

As you typically have multiple SAP systems in use that use the same printers, after defining the print architecture there comes the question of how to distribute the print landscape to the single SAP systems (and how to redistribute it after you have performed some changes.

The concept of logical servers supports you when defining a consistent, transportable print landscape. For example, unlike real spool servers, logical servers can have the same name in different SAP systems. Therefore, you can define a consistent SAP print architecture in the development system and then transport it to other systems. All output devices and logical spool servers are transported. After the transport, all you need to do is adjust the mapping of the logical servers to the (physical) spool servers of the new system, as shown in the left part of the figure Distributing the Print Architecture.

The Printing Assistant for Landscapes (transaction PAL) gives you another option for distributing output devices within an SAP system landscape (see the right part of the figure Distributing the Print Architecture).

You can use PAL to configure output devices in one system instead of configuring them separately in each system of your system landscape. After you have decided which system shall serve as the "Central System", you define all output devices of your system landscape as PAL Printers in this system. Afterwards you distribute the PAL Printer definitions from the "Central System" to other systems ("Target Systems") via RFC. When the distribution is successfully finished, all PAL Printers can be used immediately on the Target Systems for actual printing.

Printing Assistant for Landscapes (PAL) lets you maintain output devices in one (central) system and then distribute them to other (target) systems using RFC destinations.