A Proper Printing Framework for WebDirect

Introduction

For those not familiar with WebDirect, think of it as Instant Web Publishing enhanced. Whereas IWP was fairly static,  the goal for WebDirect is to be more dynamic and responsive to the user. Most FileMaker Pro functionality is there in WebDirect and the overall experience can be made to feel very similar to FileMaker Pro.  One of the key features it lacks though is printing, and this is quite an important feature if it is a larger solution to be widely deployed to a number of users.

The implications of no printing in WebDirect

Because the Print script step is unsupported in WebDirect, the only other way to print is through the browsers print function. This however is a very poor substitute, as the browser will only print the visible window contents. This means any lists of records, or any layout that cannot fit entirely in the window will not properly print.  Without Preview mode, we also have no ability for producing complex sub-summary reports or sliding of records. Basically, it just dun work!

As a note, when we say printing in this article what we really mean is preview mode and all that goes along with that (such as printing).

Okay so it doesn't print, so what can it do?

One thing WebDirect does do quite well is displaying interactive container data. What has that got to do with anything you ask? Well, it means displaying a PDF within WebDirect is pretty nice, so if we could generate a report as a PDF and display that to the WebDirect user instead, then this should allow them to scroll through it, preview it, and subsequently print it via printing of the PDF.

So how will we generate a PDF?

This is at the heart of the entire framework.  Unfortunately FileMaker Server is unable to generate a PDF. The only two FileMaker platforms capable of generating a PDF is FileMaker Pro, and FileMaker Go. Go is obviously not an option so lets use FileMaker Pro! What we need to do is have a copy of FileMaker Pro responsible for the PDF generation of WebDirect user initiated reports. 

This is not an uncommon technique. This is something that sometimes is done when reports need to be e-mailed to users on a nightly basis. Because FileMaker Server cannot produce the PDF, we call on the help of a Robot copy of FileMaker Pro to do the effort of PDF generation. FileMaker Server could then attach and send the reports via a scheduled script, or the copy of FileMaker Pro could just do this itself.

We shall call this copy of FileMaker Pro from this point on RoboPrint !  

What is the basic framework outline?

In the framework we refer to the WebDirect user as RoboUser and the robot copy of FileMaker Pro tasked with producing report PDFs as RoboPrint. The basic process of events is as such:

1. RoboUser initiates a print request
2. RoboPrint is polling for new print requests and detects the request from RoboUser
3. RoboPrint then runs the report on behalf of RoboUser.
4. The resulting report is saved as a PDF document onto the print request and marked as done.
5. RoboUser now sees their report has been generated and is able to view the PDF.

That is it in a nutshell. Now how this all actually works is a little more in-depth so we'll cover the process in a little more detail below and how this relates to the example framework file.

... For those who just want to get stuck in and see how it works...

Technical jargon and explanations are below, but if you want to just fire up the demo file and see what it's all about, you'll need to do a few things first:

• Demo file hosted on FileMaker Server (because WebDirect is FMS only).
• A copy of FileMaker Pro must be running the database logged in with username RoboPrint (no password), and the RoboPrint function must be running by clicking the launch button.
• Fire up WebDirect and open the database with username RoboUser. You can then click on any of the 3 report buttons.

You should see the RoboUser wait for the PDF to be generated. In FileMaker Pro you should see RoboPrint retrieve the print job, process it and mark it as done.  Then back in WebDirect you'll see the resulting PDF displayed to the user.

You can also run as RoboUser in either FileMaker Pro or FileMaker Go - this does not necessarily require WebDirect to test with.  If you do not have access to WebDirect, then so long as you can access the database (shared) in 2 copies of FileMaker Pro you will be able to test the demo.

Still a work in progress

This framework at this stage is by no means perfect. It was built out of necessity for a WebDirect deployment, and has so far stood up to the test and been a reliable means of generating reports via WebDirect, which is why we have turned it into an article :)  There will always be improvements that can be made to the framework and the intention is that others in the community will take the general method and build upon it for others.

The idea of a print request

In the framework is the idea of a print request. Because RoboPrint and RoboUser are run on different platforms, there needs to be a method of communication between them.  We do this by way of a table, funnily enough also called RoboPrint (just to confuse you!).

Each record in this table is an individual print request that is generated by a WebDirect user. The record contains a number of fields that will tell RoboPrint all the information it needs to run the report. Most fields are self explanatory (you can check the comments on the fields for more info).

When a user wishes to run a report, they will generate one of these records, populate it with the required information, and sit back and wait until the record is marked as either complete, or in the event something went wrong it will be marked with an error.

The Initiation script

When a WebDirect user wishes to run a report, the generic script they run is called "Robouser - Initiate Print Job". 

We pass 3 key parameters:

• Type is a keyword that will tell RoboPrint what type of report the user wishes to run
• Parameters is a text string of parameters that may be required to produce the correct report output.
• Timeout - this is a period - in seconds - which will be used for how long the WebDirect user will wait for the report output to be delivered. Default is 30 seconds.

The rest of the script will launch a new virtual web window and go to the RoboUser PDF layout. It creates a print request and then simply sits and waits until the process if finished, or expires.