RPM Overview

RPM Remote Print ManagerRPM Remote Print Manager® ("RPM") is a unique product in the marketplace. Even though RPM is a print server and a virtual printer, our primary goal is to provide a print workflow that you can set up yourself. Of course, we can help! When print jobs arrive, RPM will run unattended to produce the results you need.

For instance, let's say you have PCL files you want to convert to PDF, but you still want to print the files. With RPM, it's easy to set up a workflow to accomplish this. First, you would create a queue that receives the print job and sends it to the printer you specify. This queue would also copy the job to a second queue where you would convert the PCL to PDF, then archive to disk (or email or several other likely actions).

The reason we split it up this way is this. When RPM processes your print job, first, it runs through all the data changes or transformations you specified. Then it sends that result to each of the actions you have added to that queue. In this example, we printed the original data. Then we copied that data to a different queue where we changed it to PDF, and then we archived that PDF.

General overview

Following is an overview of the significant parts of RPM. In this article we'll talk about:

  1. Inputs to RPM, that is, the ways you can get jobs into the software
  2. Print spooler, which is the gateway to many of our features
  3. Queues, where much of the action takes place
  4. the Job scheduler, which controls the order in which jobs are processed
  5. Transforms and actions

Inputs to RPM

RPM is a listener, or server, for the following:

Print spooler

RPM includes a print spooler, which stores incoming print jobs on disk before the RPM scheduler runs to process the jobs.

The two primary reasons we spool print jobs to disk are reliability and flexibility.

Let's talk about reliability first. If we sent your print job directly to the printer as it arrived over the network, and we did not spool to disk, then you would inevitably run into two problems: if the network fails, you have only a partial job printed. In fact, with some print languages (e.g., PostScript), you would have no printed job at all.

Similarly, if the printer fails for any reason while printing, your job is lost, and you will have to send it again.

You don't have to have a computer science degree to appreciate that spooling print jobs is the more reliable solution.

Secondly, by spooling print jobs, we can offer customers the flexibility they would not otherwise have.

  • RPM will automatically retry a print job if it fails for any reason
  • we offer a reprint feature depending on how you configure the queue
  • you can manually hold jobs and release them to print later
  • RPM supports the copies command, so you don't have to resend the same job repeatedly

RPM also allows you to put a priority value on devices and queues so you can fine-tune the job processing order. Additionally, RPM Elite offers several job scheduling options for broader policy control.

None of this would be available without spooling your print jobs.

Queues

RPM follows the model of the LPD print server, where you send print jobs to a named queue. Queues in RPM function much like a print queue on a Linux system, although we have extra functionality.

Each queue has a unique set up so you can create utterly independent processing in each queue. RPM also features queues working together, which is a topic we can explore in a longer article about print workflow.

Queues also have settings that control whether jobs in the queue are immediately available to be scheduled or not.

The page How Queues Work in RPM has a comprehensive overview of queue setup and functions.

Job scheduler

Once RPM spools your print job, next on the agenda is scheduling. RPM Select offers one scheduling model, "fifo" or "first in, first out." RPM creates jobs when they have entirely arrived (or soon after).

RPM Elite offers four scheduling models:

  1. "fifo" as with RPM Select
  2. "fair" which tries to service all the eligible queues which have jobs
  3. "priority" where you can set a weight on queues, devices, and actions to receive preferred scheduling (or deferred)
  4. "ordered" which attempts to follow the job ID more strictly than "fifo"

The user interface with RPM Elite lets you select the scheduling model where RPM Select does not.

Transforms and actions

The way we achieve print workflow for you is by using transforms and actions.

Transforms make changes to your data, possibly converting it entirely. We have one exception, data extraction, which searches your data and extracts values.

Actions are outputs such as print, archive, email and a number of others.

As we talked about above, when we receive the print job, we spool it to disk in its original binary form. That way, we always deliver accurate data to your print output.

However, there are numerous occasions to convert your data one way or the other. If you are converting PCL to PDF, obviously, that's a significant conversion.

RPM features several dozen transforms, which can be useful for a variety of processing tasks. Most of the "how-to" articles use transforms, creatively, we hope.

When you configure a queue with multiple transforms, RPM processes those transforms in order. The first transform receives the print job data for this job. RPM, in turn, runs each transform using the results of the previous transform.

Finally, RPM hands the result of the transforms over to each action.

Print workflow gets more interesting when you copy the job to another queue. In the example above, where we printed an incoming job, then converted it to PDF, that's how we achieved that result. Once again, refer to the fact that all the actions in a queue receive the same input. In the first queue, the action is "print this file directly to the printer." For convenience, we assumed the printer would not accept PDF, although some do.

In the second queue, we want to write a PDF file to disk. The transform or transforms we add to this queue will create a PDF from the original print file. Then the action, "write a file to disk," writes our result to disk.