RPM Actions Portal

Portals

Purpose

The purpose of 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:

Windows printing, which we referred to as "text printing"

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)

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.

Transforms

Actions

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

text markup (in this case, plain text is converted to text markup)

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 attachment

archive the PDF to specified folder, as above

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