Showing posts with label Spool Database. Show all posts
Showing posts with label Spool Database. Show all posts

Authorizations for Output Devices

Definition

The authorizations for output devices define which users can generate spool and output requests for which output device.

Use

The system always checks the device authorizations before creating a spool or output request. Users can only create requests if they have an appropriate authorization for the relevant output device.

The system checks device authorizations using the authorization object S_SPO_DEV. You can also specify output quantity with the authorization object S_SPO_PAGE.

The authorization objects are shown with the corresponding field values in the figure below:

This graphic is explained in the accompanying text
Additional Information about the Authorization Objects

Authorization Object

Action

Additional Information

S_SPO_DEV

Allow access to named printers

· Example:

FI_PR* means:

Print on devices that begin with this character string

· Instead of authorizing output on individual devices, you can also use authorizations for groups

S_SPO_PAGE

Restrict print quantities for requests to a certain maximum number of pages

· The parameter rspo/auth/pagelimit must have the value 1 in the system profile.

· All users must have an authorization based on S_SPO_PAGE when the changed profile becomes active; otherwise no user will be able to print.

Integration

To be able to output with requests on output devices, the user must also have authorizations for the following authorization objects in addition to the authorizations for the object S_SPO_DEV:

· System administrators and end users: Authorizations for the Output Controller (authorization object S_SPO_ACT)

The authorizations for the output controller specify which operations a user can perform with spool and output requests in the Output Controller (transaction SP01).

· System administrators: System authorization (authorization object S_ADMI_FCD)

The system authorizations specify which spool administration operations (transaction SPAD) a user can perform in which clients.


To be able to use frontend printing, users must have authorization for the output device %LOC in addition to authorization for the frontend printer.

For more information about spool authorizations, see SAP Note 119147.

Logical Spool Servers

Definition

A logical server stands for one or more other logical and/or real SAP spool servers. Logical servers can be used in place of real SAP spool servers anywhere in the spool system. The logical server is a “placeholder“ for the spool server assigned to it, while a real server is an actual application server with a spool work process and can output print requests.

If, for example, a logical server is specified as the spool server for output in the device definition of an output device, you have the following options:

· The logical server is directly assigned to a real spool server.

Printing can be performed using this real spool server.

· The logical server is directly assigned to another logical spool server.

The system check in turn for the assignment of this second logical server.

A real spool server with which printing can be performed must be present somewhere in the series of assignments.

The following figure shows some possibilities for how an output device can be assigned to a spool server:

A: Output device assigned directly to the spool server

B: Two output devices that are assigned to the spool server using a logical server

B: Two output devices that are assigned to the spool server using two logical servers

This graphic is explained in the accompanying text

Use

You have the following options for printer administration through the use of logical spool servers:

· Grouping devices (local and remote printers): You can group the SAP output devices, for example, defining logical servers for devices connected over a network and for local devices. Both logical servers could point to the same real SAP spool server. However, you can manipulate the devices separately for such purposes as switching devices to another spool server.

· Switching Spool Servers: If you assign output devices to a logical spool server, you can then switch the devices from one server to another quickly and easily.

Example

For example, if a spool server is down for maintenance, you can switch all of its devices to another server simply by changing the Mapping field in the definition of the logical spool server. When the original server is active again, you can switch the devices just as easily back to it.

Switching spool servers can be performed automatically. To do this, an alternative server must be specified in the spool server definition.

· Balancing the Output Workload: You can distribute the output processing workload of a spool server between the server and its alternative server.

To do this, you must have specified an alternative server and selected the option Allow Load Balancing.

· Transporting the Print Landscape Between Systems: Unlike real servers, logical servers can have the same names in different SAP Systems. You can therefore define a uniform SAP print architecture using logical servers and then transport this to all of your systems.

An output landscape of this type – device definitions and server definitions – can be transported in its entirety to another SAP System. After transport, you only need to enter the real spool servers that exist in the respective systems.

Transporting the Print Architecture Using Logical Servers

You can easily transport a complete print architecture using logical servers.

Prerequisites

You are using logical spool servers as an “intermediate layer” in the print architecture.

Process Flow

The figure below shows the transport of a development system into a quality assurance system. All output devices and logical spool servers are transported. To activate printing in the target system, you only need to change the mapping in the definitions of the logical spool servers.

This graphic is explained in the accompanying text

Spool Server Selection Example

The following example shows a configuration of logical servers and how this configuration affects the system’s spool server selection.

Server for Local Printing

This server is defined for output devices that are connected with local access methods. As the server selection should be static, the server is not integrated into a hierarchy.

This graphic is explained in the accompanying text

Server for Remote Printing

There is a hierarchy of logical servers for remote printing.

This graphic is explained in the accompanying text

For information about the legend in the screenshot, see Interpreting the Spool Server Display. The individual servers are explained with their definition below.

The LocalProductionPrint Logical Server

The LocalProductionPrint server is defined for time-critical printers, such as production printers, that the SAP System accesses using the local access methods C and L.

The server definition of LocalProductionPrint looks like this:

This graphic is explained in the accompanying text

As the server does not have an alternative server and is load balancing is not enabled, only hs0311_BIN_53 can process output requests for devices that specify the spool server LocalProductionPrint in their device definition.

The ProductionPrint Logical Server

While the LocalProductionPrint server processes requests for time-critical production printers that are connected using local access methods, the ProductionPrint server handles requests for time-critical production printers that the SAP System accesses using the remote access methods U and S, or with the OMS access method E.

The server definition of ProductionPrint looks like this:

This graphic is explained in the accompanying text

This server allows load balancing. Due to this server’s position at the top of the hierarchy of logical servers, its load balancing can draw on all of the spool servers in the BIN SAP System. This strategy is in accordance with the high priority of the output requests. To ensure the fastest possible processing, these requests are allowed to draw on servers reserved for mass printing and desktop printing, as capacity permits.

In load balancing for this server, the spool system searches both the Mapping and Alt. server hierarchies. In the Alt server hierarchy, the spool system evaluates the spool system used for mass printing and desktop printing; the evaluation therefore includes all spool servers in the SAP System.

By contrast, output requests for the logical server VolumePrint cannot access the time-critical spool server, hs0311_BIN_53. This server is exclusively reserved for production printing, while all other servers are shared.

LocalProductionPrint and ProductionPrint separate output devices by their access methods, local or remote. This grouping allows you to distribute output requests for unproblematic remote printers, while keeping a static server assignment for local printers.

If all local printers were defined under the same names in the hosts of other spool servers, then these devices could use alternative servers and/or load balancing as successfully as remote printers can.

The VolumePrint Logical Server

This server is for high-volume line printers, such as those in some computing centers.

The server definition of VolumePrint looks like this:

This graphic is explained in the accompanying text

Load balancing is permitted; this means that output requests sent to it can be distributed among its own server (pcintel_BIN_53) and the DesktopPrint server. Its own server cannot be used for DesktopPrint requests.

If you should decide, for example, that desktop requests should have a higher priority than mass print requests, you only need to move DesktopPrint into VolumePrint’sposition in the hierarchy and change the load-balancing settings in the definitions.

The enabled load balancing also affects ProductionPrint output requests. The server selection procedure is recursive; it uses the same rules at each level of the hierarchy. As the server can distribute its load, load balancing of ProductionPrint requests can take both pcintel_BIN_53 (in the logical server hierarchy) and the DesktopPrint server into consideration as the least-busy server.

If load balancing were not allowed for VolumePrint , then only pcintel_BIN_53 could be considered for ProductionPrint requests. As long as pcintel_BIN_53 is a valid spool server (running, with a spool work process), then the load balancing search would not be allowed to search the Alt server hierarchy at this level.

The DesktopPrint Logical Server

This server is defined for desktop printers whose requests have a low priority. The printers do not have to print large quantities, nor are their requests time-critical.

As the overview at the start of the example shows, this server has a special characteristic:
its alternative server is VolumePrint. This alternative server specification points back upward in the hierarchy. This is necessary to give DesktopPrint a substitute server. The spool system is able to resolve such redundancy correctly; it will not endlessly loop through the DesktopPrint hierarchy if it looks for an alternate server.

The server definition for DesktopPrint looks like this:

This graphic is explained in the accompanying text

Because the server is exclusive, no load balancing is allowed for its output requests. If pn0202_BIN_53 is active, all DesktopPrint output requests are processed there. VolumePrint is checked for an available alternate server only if pn0202_BIN_53 is no longer active.

Static and Dynamic Server Selection

Static Spool Server Selection

With static server selection, the device definition in the spool system specifies the SAP spool server that is to process output requests for the device.

This static server selection is used in the following cases:

· You have not defined any special server definitions for the spool servers in transaction SPAD ( ® Spool Server ® Spool server ® Create/Create Using Template).

· You have defined and/or classified the server in SPAD, but have not filled out the fields Mapping and Alternative Server.

In this way, you can use the classification and identification attributes of spool servers without compromising the printing of requests in the sequence in which they are generated.

Dynamic Spool Server Selection

By default, the selection of a spool server is static, that is, defined by the spool server specification in the device definition.

You can select a Spool Server dynamically using the server definition in transaction SPAD ( ® Spool Servers ® Spool server ® Create/Create Using Template) using load balancing, the alternative server, or both. In this case, if the spool server fails or is overloaded, the system searches the hierarchy of servers that are specified in the Mapping and Alternative Server. The server with the lowest output workload is then used for printing.

Dynamic server selection can include load balancing or simply the use of logical or alternate servers. If you are allowing dynamic server selection, then the selection of the spool server to process an output request is not solely determined by the device definition. For the server selection to be performed dynamically, the server must be defined in transaciton SPAD ( ® Spool Servers ® Spool server ® Create/Create Using Template) and fulfill one of the following conditions:

· Load balancing is activated for the server specified in the device definition

· An alternative server is specified for the server in the device definition.

· A logical server is specified for the spool server in the device definition.

Process of Dynamic Server Selection

While with static server selection, the spool server specified in the device definition is simply used, with dynamic server selection, the system must find the spool server with the lowest output workload. The following figure shows how the system does this:

This graphic is explained in the accompanying text

As in static server selection, the spool system starts by looking in the definition of the target output device to find the primary spool server. If you have created a definition for this in transaction SPAD ( ® Spool Server ® Spool server ® Create/Create Using Template), the spool system uses the algorithm described below to determine the spool server to be used.

It is important to note that this server-selection algorithm is recursive. As the spool system traverses the server hierarchies defined in the logical server definition (transaction SPAD ® Spool Server ® Spool server ® Create/Create Using Template ® Mapping field) and in the alternate server definition (in the Alt. server field), it applies these rules at each new level of the hierarchy.

...

1. First check: Is there any relevant information in the spool server definition? If the spool server is not a logical server and does not have an alternative server, the server specified in the device definition is used. In this case, the server selection is static.

If this result occurs while searching a spool server hierarchy, then this server is returned (if it is running) by the search as a potential server to use for the output request. This is a terminal node in such a hierarchy.

2. Is load balancing activated for this server?

If yes, then the spool system searches both the logical server and alternate server definitions, as available, to find the spool server that has the shortest queue of spool requests waiting.

If both a logical server definition and an alternate server have been specified, then the spool system compares the best server found in each hierarchy. The server that has the least output load is returned by the search, regardless of which hierarchy it was found in.

3. If load balancing is not in effect, then the spool system checks whether the server is actually a logical server.

If yes, then the spool system searches the logical server hierarchy (in the Mapping field) for a spool server to use. If the spool system finds an active spool server, then this server is used. If none is found, then the spool system searches the alternate server hierarchy, if available. If an active spool server is found there, then it is used.

The spool system uses the first active spool server that it finds. There is no attempt to distribute the workload among available servers.

4. If the server is not a logical server, then the spool system checks that the server is running and has a spool work process. If these conditions are met, then the server is used for processing the output request.

If these conditions are not met, then the spool system checks to see if an alternate server has been defined for the server.

If there is an alternate server definition, then the spool system searches the alternate server hierarchy for a spool server to use.

5. If all of these possibilities for finding a spool server fail, then the spool system reports an error with the output request. No spool server could be found to process the request.

For a detailed example of server selection, see the Example: Spool Server Selection section.

Restrictions of Dynamic Server Selection with Local Printers

You can use dynamic server selection without restrictions only for output devices that are defined with remote access methods S and U or with the local OMS access method E. The reason for this is that the SAP System accesses remote printers using a network link. This network link is likely to be usable without adjustment by any spool server. Output requests for a remote printer can therefore be moved from one spool server to another without causing any problems.

Output Management System (OMS) printers are accessed by a print command that can be executed locally from any spool server. Requests for OMS printers can therefore also be moved from spool server to spool server without problems.

For local printers (access methods C and L), on the other hand, dynamic server selection requires some preparation at the operating system level. In a local connection, the SAP spool server passes an output request directly to the spooler or print manager in the host on which it is running.

Such an output request can be processed at another server only if the local spooler or print manager at the second spool server can identify the target output device. This means that the target output device must be defined under the same name in both local spoolers (in the host of the first spool server, and also in the second host). For all practical purposes, an output device with a local access method must be defined under the same name in all hosts on which an SAP spool server runs. Otherwise, switching an output request for such a device to another spool could generate the error Device unknown from the local spooler or print manager.

The graphic below gives an example.

This graphic is explained in the accompanying text

In the example, the SAP System is to access printer P330, through a local connection, at a Microsoft Windows NT system called NT1. The Print Manager of NT1 knows P330 under the name NT330. NT330 is entered as the host printer in the P330 device definition.

The local connection ­‑ using access method C ‑ means that the primary SAP R/3 spool server for printer P330 runs on NT1. The spool server is called NT1_C11_01.

However, server NT1_C11_01 is overloaded. NT1_C11_02 on NT2 is specified as the alternative server. Output requests for P330 can however be processed by the spool server on NT2 only if NT2’s print manager has a printer definition with the identical name NT330. This NT330 printer definition must also connect to the same printer as NT330 in NT1.

You can use dynamic server selection with local printers only if:

· You can define each affected local printer under an identical name in each host system on which an SAP spool server runs. The spool server can find the printer name NT330 on every host

· You ensure that local printers have names that are unique across all of your SAP host systems LPT1 on one host identifies the same printer as LPT1 on another host

· You can use problem-free dynamic server selection for OMS devices (SAP R/3 devices defined with access method E) as long as the commands used by the ROMS and LOMSs can be executed from each of your spool servers.

Assigning Output Devices to Other Spool Servers

Use

You want to change the server assignment for multiple output devices, because, for example, the previous spool server has failed and you have not specified an alternative server or activated load balancing.

Procedure

There are different methods to assign output devices to other spool servers, depending on whether you have defined logical servers or not:

· You have defined a logical server between the output devices and the real spool server, that is, a logical server is specified as the spool server in the device definitions of the output devices.

Somewhere in the hierarchy, this logical spool server points to a real spool server that performs the output formatting. If this real server fails, you only need to edit the definition of the logical spool server. You must enter a different real spool server in the Mapping field of the server definition. You do not need to change the device definitions of the individual output devices of the individual output devices, as they do not point to the real server that you are changing, but only to the logical server.

Example

You have assigned the production printers Prod1 and Prod2 to the logical spool server Log_Prod, which is classified as a production server. The logical production server Log_Prod points in turn to the real server twdf5001_DEV_00.

This graphic is explained in the accompanying text

If the real server twdf5001_DEV_00 fails and you want to assign the production printers Prod1 and Prod2 to the real spool server twdf5000_DEV_00, you only need to change the mapping information in the definition of the logical server. It must point to the current real spool server twdf5000_DEV_00. As the logical production server is specified in the device definitions of the individual output devices, you do not need to change anything in these definitions.

· You have not defined logical servers in your system. In this case, you can change the server assignment for all output devices whose names match a certain pattern (such as PRI*).

...

a. In Transaction SPAD, choose Utilities ® For Output Devices ® Assign Server.

b. On the next screen, enter the desired pattern for the output devices, as well as the name of the old spool server assigned and the name of the new spool server to which you want to assign the devices.

c. Choose Display List, then Convert to switch spool servers.

Result

You have changed the server assignment for some or all of your output devices. If output requests still exist for the affected devices, for which processing is not yet complete, processing of the requests is transferred to the new spool server.

Spool Server

The spool server is an SAP application server that provides spool processing. It therefore requires at least one spool work process.


SAP Note 108799 in the SAP Service Marketplace explains how many spool work processes you should configure for each server.

A spool server processes the data for transfer to the spool system of the operating system. You can set up a spool server by adding the profile parameter rdisp/wp_no_spo to the instance profile of the corresponding server (Administration ® CCMS ® Configuration ® Profile Maintenance) and entering the desired number of spool work processes.

Setting or Changing Properties of a Spool Server

You can enter additional attributes and administration information for spool servers.

To do this, call transaction SPAD (Tools ® CCMS ®Spool ® Spool Administration), and, on the Devices/Servers tab page, choose the Spool Servers pushbutton. The list of defined spool servers appears. If you double click the relevant spool server, a window showing the attributes of the spool server appears.

The following example shows the attributes for a mass printing server:

This graphic is explained in the accompanying text

You can enter or change the following attributes in this window:

· Server Name: You can enter a description of the spool server in the long field of the Server Name area.

· Server Class: Choose a suitable entry, depending on the intended use of the server, from the input options for the server class field, such as production printing, mass printing, and so on. The classification of the spool server helps you to realize your planned printing architecture, that is, to assign newly defined output devices to the corresponding spool server. If you specify the spool server in a device definition, the spool system compares the classification of the output device to the classification of the server. If they do not match, then the spool system warns you.

Example

If you are preparing to assign a mass printer to a time-critical production server, then the spool system warns you of this disparity.

· Alternative server: You can specify a “replacement printer”, the alternative server, for a spool server. The alternate server takes over the processing of output requests if the original server is down or unavailable. For more information, see Alternative Server.

· Allow Load Balancing: You can define whether the output processing workload of a server may be distributed among its alternate servers. By default, load balancing is deactivated. Instead, the spool system ensures that output requests are printed in the order that they are generated.

· Logical server: You can define spool servers as logical servers. A logical server is a name that can, in turn, stand for one or more logical or real servers (a real spool server is a server that actually has spool work processes and can run in the SAP System).

Using logical servers, you can transport a complete printing architecture to another system with only minimal changes. To activate printing in the target system, you only need to edit the assignment of the logical server. You can do this using the Mapping field. For more information, see Logical Spool Servers.

Deleting Multiple Spool Requests Simultaneously

Use

You want to delete multiple spool requests simultaneously. You can perform the deletion in the output controller or, with appropriate authorization, in Spool Administration.

Prerequisites

Every user can delete his or her own spool requests in the Output Controller (SP01).

For Spool Administration (SPAD), you require administrator authorization.

Procedure

Deleting in the Output Controller (SP01):

...

1. Choose Tools ® CCMS ® Spool ® Output Controller (transaction SP01).

2. Display the overview of the spool requests.

3. Select the requests to be deleted.

4. Choose This graphic is explained in the accompanying text Delete.

Deleting in Spool Administration (SPAD):

...

1. Choose Tools ® CCMS ® Spool ® Spool Administration (transaction SPAD).

2. On the tab page Admin. choose Settings.

You can delete spool requests by the following criteria:

¡ Spool requests whose expiration date has been reached

¡ Spool requests that have been successfully output

¡ All requests

¡ Requests with a certain minimum age

When deleting a spool request, you delete the following files or entries in addition to the request itself:

- The spool request itself; the record of the spool request in the spool database

- The print file; the data is stored separately from the spool request, in the temporary sequential object database (TemSe).

- Administration data for all output requests generated for the spool request.

- Any error logs that exist; these are stored separately from the spool request, in the temporary sequential object database (TemSe).


We recommend that you regularly delete old print requests in the background with report RSPO1041.

You can also delete inconsistent spool requests in the background during the spool consistency check with report RSPO1043.

Maintaining the Spool Database

Maintain the spool database regularly to ensure optimal performance and size. You should perform the following tasks to maintain the spool database regularly:

· Check the consistency of the spool database

· Delete old spool requests

Process Flow

The figure below shows the most important methods of maintaining the spool database:

This graphic is explained in the accompanying text

Scheduling both deletion and the consistency check in the background is preferable to performing these tasks in dialog. Scheduling these tasks in the background ensures the regularity of deletion and of consistency checks. It also eases the workload both of the administrator and of the systems.