By Daniel Wood, 4 July 2014
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.
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).
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.
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 !
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:
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.
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:
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.
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.
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.
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:
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.