RPM Actions Portal

History

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

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

RPM has always tried to go 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 setup.

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 language, different vendor, etc. Let's call them printer A and printer B.

Our configuration:

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:

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:

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

Actions list