RPM Actions Portal

Purpose

The purpose of RPM Remote Print Manager® ("RPM") "actions" is to give you the most functionality, the most output options, for your print jobs.

Most print servers do one thing, and do it very well: they send every print job they receive to the same printer, and no changes to the data stream sent to the printer. This works much of the time for many people.

A smaller set of print servers support multiple queues. These queues typically have some settings for data tweaking.

RPM has always gone far beyond that. For years we supported three types of print actions:

1. Windows printing, which we referred to as "text printing"
2. Direct to the printer, which we referred to as "raw printing" based on comments in some Windows documentation (that's more or less what typical print servers do)
3. Run a program on your data, which we called "filter processing", derived from our Unix heritage

We executed this approach by assigning a "type" to each queue. That queue performed one of these actions based on its type and other setups.

We also had some general processing steps independent of the 3 print actions, which we called "transforms" hidden behind the term "Print data options". This is how you specified a code page, SCS, insert a file, etc. 

A new approach 

However, the weakness of that approach became evident every time someone asked us, "How do I print this job, then archive it?" or, "How do I send this to two different printers?" Those are the simplest versions of the same type of question we heard over and over.

What we decided to do was break out the print actions. Rather than a queue having one action based on a "type" we came up with this approach:

• run the job through all the transforms the user specifies
• take that result and feed it to one or more actions

Now we can print, archive, email, as many places and times as we want. We have it set up so that the actions are independent from each other. It doesn't matter which goes first, or next. We use multiple threads so the actions are usually done in parallel.

The one caveat is that the actions need to use the same data.

While the multiple action approach is an improvement, it still doesn't answer the question of what to do when the data is not in the form you need for the action. For instance, let's say you convert to PDF, and your actions archive to disk and email a copy. These are well suited to PDF input.

Now, what happens if you want to do a Windows print action, and archive to PDF, and email? The Windows print needs an intermediate form, text markup. It won't work with PDF data. On the other hand, we convert to PDF from text markup.

We decided to address by adding a "copy to queue" action. Doing this, we expanded the workflow capabilities of RPM considerably.

Multiple actions for a multifunction software print server 

Let's use some examples to illustrate.

First, let's send text reports to completely different Windows printers; different printer languages, different vendors, etc. Let's call them printer A and printer B.

Our configuration:

Transforms

convert the text to text markup

Actions

• Text print to printer A
• Text print to printer B

We have now demonstrated broadcast print with two completely distinct printers.

Next, let's try this: convert to PDF, archive, and email. To do that:

Transforms

1. text markup (in this case, plain text is converted to text markup)
2. text markup to PDF

Actions

• archive; this gets the PDF file and places it in a folder
• email; in this case, the PDF file is an attachment

Note that the two transforms are run back to back, then the PDF is handed off to each of the actions.

Now, let's do something a little more challenging. We receive Simplified Chinese and Traditional Chinese jobs. They are not identical. We want to print them to a Windows printer (our text print action), and convert to PDF, archive, and email.

Here is how we do it:

Queue A, send Simplified Chinese here

Transforms

text markup transform that reads Simplified Chinese and writes UTF-8

Actions

copy to Queue C 

Queue B, send Traditional Chinese here

Transforms

text markup transform that reads Traditional Chines and writes UTF-8

Actions

copy to Queue C 

Queue C, send text markup here

Transforms

None

Actions

• text print
• copy to Queue D 

Queue D Transforms text markup to PDF

Actions

• email with PDF as an attachment
• archive the PDF to the specified folder, as above 

With this setup, we have handled multiple languages and hit 3 distinct outputs, the archive, email, and print.

Actions list 

Text print

1. input = text markup
2. Windows printing which supports any Windows printer including shared

Raw print

• input = printer language
• Print directly to any Windows printer, including shared

Email

• input = anything
• Anything can be attached. Plain text and HTML can optionally be used as the message body.

Archive to Folder

• input = anything
• Write the results of transforms to disk, job metadata is available for file naming, supports shared drives

Filter

• input = anything
• Run any program available, job metadata is available for command-line options

Copy to queue

• input = anything
• Copies print job using the final output of any transforms to another queue

LPR printing

• input = anything
• Sends print jobs to an LPD server remotely, locally or loopback

IP printing

• input = anything
• Sends print jobs to any IP addressable printer, defaulting to port 9100

Archive to FTP

• input = anything
• Use File Transfer Protocol (FTP) and file naming options to upload print jobs to an FTP server