RPM Workflow Portal

Purpose

RPM has several features designed to support print job workflows. Workflow is a process more than a formula, so we will discuss several strategies for workflow on this page.

If you find your problem represented only partially here, please contact our technical sales department to discuss your situation. It is impossible to plan one product that provides every feature expressed in a simple setting. However, there are enough tools built into RPM that, with some creativity, we may be able to find a solution for you.

Transforming the data

RPM provides around thirty transforms, which make some kind of change to the data. You could categorize the transforms this way:

• edit, for instance, the string search and replace function
• change from one form to another, such as EBCDIC to ASCII, other code pages, PCL to text, and vice versa
• eliminate ranges of data (leaving the original print job unchanged, of course)
• supplement the data by prepending to the beginning or appending

Important points to note:

1. The order in which you place the transforms usually makes a difference. For instance, you can do page range operations on text data before you convert to PDF but not after
2. It is a lot more time-effective to chain as many transforms together as possible before you process the actions. That is, it's a lot more expensive to run one transform, copy to a queue, run another transform, and copy to a third queue than it is to run two or three transforms.

Grouping transforms

The RPM actions portal shows examples of chaining several transforms together, running some actions, and then copying to another queue for more processing. We added the "copy to queue" action for just such an event.

Let's consider two common requests: first, print to multiple printers; and second, print, email a PDF, and archive a PDF.

Now, take a look at the inputs and outputs. The text print action requires text markup. The text markup transform reads plain text and provides text markup. So, it's easy to see those should work together.

Here is how we would set it up:

Transforms

convert the text-to-text-markup

Actions

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

(Copied from the Actions portal example)

In this case, the most straightforward approach is also the best approach. RPM is optimized for this kind of processing. If you were to print to printer A, and then copy to another queue where you printed to printer B, you would have one unnecessary copy of the print job, and the second print operation would be sent to the end of the job processing queue. There is no real savings in that.

For the second example, we convert to text markup, then to PDF. The PDF transform requires text markup as input, so the order is settled. The email and archive actions do not require PDF In general; however, we want to archive PDF and email PDF, so we'll make sure the PDF is provided to both.

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

Again, RPM is optimized for this kind of setup. In this case, RPM will process the print job through the two transforms, save the result in a temp file, and then pass it to each of the two actions. We have also eliminated all unnecessary copying.

Using the filter action for caching

Our PCL Caching utility is an example of using a filter action (external program) for processing. Here RPM receives the print jobs in pieces: PCL macros, fonts, and other resources may arrive as separate print jobs or be included inside the same part of another print job.

RPM calls our PCL Caching utility, passing the path to the print job as an argument. PCL Cache reviews the contents of the print job, and extracts and stores any macros or font definitions it has. If it doesn't have macros or fonts, but simply calls a previous macro or font, it adds the macro or font needed and sends it to the destination.

This is the sort of thing that can't be done natively in RPM.

Using the filter action to eliminate waste

We worked on another workflow scenario with a client who is constantly receiving print jobs from one of the major financial services. In this case, we developed a script according to their specifications which did the following:

1. If a certain text string was present on a certain line on the first page, the file was discarded (this accounts for 80% of the files)
2. If another text string was present in another location, the file was sent back to an RPM queue where it was converted to PDF and emailed
3. All other files were sent to a queue in RPM where they were held for further review

Before this was put in place, the printer was using at least one ream of paper per day. The savings in paper, toner, and printer maintenance should pay for the development costs in a few months.

Thinking outside the RPM box

We worked with another customer who reported to us how they fit RPM Elite into their process. As medical services providers, they are required to respond to patient information requests. Their HIPAA compliance system (which they didn't name) ultimately generates a PCL print job.

They have configured RPM to be in the place of their HP printer. RPM converts the file to PDF, then writes it to disk. They then use utilities from other vendors to write a collection of files to a ZIP archive, then burn to DVD.

In this case, the client saves both paper and shipping costs. The DVDs still have to be mailed at a much lower cost than the equivalent paper bundle.