Hi, my name is Sarah Mulligan from 360Works and I'm here today to discuss the scripts and functions behind the 360Works RemoteScripter plug-in. Today we'll be looking at an example where we create a PDF in Instant Web Publishing and save it to a container field. As you'll notice, I've started the Web Publishing Engine and then loaded the solution in my browser. What you're looking at here is Safari. We'll be working with the Bonsai solution file found in the FileMaker certification study materials.

Let's take a look at the appearance of the end product, so that you know what we're working towards. We have a button in our browser called print invoice that creates an invoice and saves it to a container field. This container field is then accessible in Instant Web Publishing. We can download it and view it all from our browser.

This graphic may help you understand how we just did that. The browser sends requests to the Web Publishing Engine, which runs the "Print Invoice" script from the button. The Web Publishing Engine can't generate PDFs, so to get around this limitation we have FileMaker Pro installed and running. This is done either on the same computer as the Web Publishing Engine or a different computer dedicated to PDF generation. We also installed the 360Works RemoteScripter plugin on both the Web Publishing Engine and FileMaker Pro, which allows them to communicate with each other. The Web Publishing Engine uses RemoteScripter to trigger the Create PDF script running in FileMaker Pro, which creates the PDF and then passes it back to the WPE and eventually the browser. In the video tutorial, you can see that this happens instantly from the user's standpoint.

Let's take a look at the backend and see how this all comes together. First, let's look in depth at our scripts. We need to modify our OnOpen script to use RemoteScripter register and listen functions. This is done so that FileMaker Pro will listen for requests from the Web Publishing Engine and ensures that RemoteScripter starts appropriately. This OnOpen script is going to be run when the database is accessed. I've created a field here called Order::Error that is used to save any errors we encounter and display them for the end user. We blank this field out to make sure all previous attempts are wiped- anything that we see is from this attempt. Next we're going to set our variable as "$register." This is going to use the RemoteScripterRegister function. Enter the license key and registered to name here. RemoteScripter is available as a free 2-hour demo. You can try out this example on your own without this step, but if you find RemoteScripter useful, please purchase from our website at 360works.com and we'll provide you a license key

We're also going to set a $listen variable and use the value RemoteScripterStart. Now we need to pass in three parameters to this variable.

We need a port number; I've picked 4,645. We pick a random number for our port. This can be anything from 1,024 to 65,535, but the best numbers to use start from 49,152 as these numbers are unlikely to be used by another application. Whatever number you use, make sure its not used by any other application. If your scripts are not triggering, try changing the port number here.

The $listen variable will also need the file name where the script is actually going to be run. For my example, the script I want to execute is in the same file as the startup script, so I just use Get(filename).

We're also going to define the script that we want to run when the port number is triggered. In my example, this is "Save Invoice as PDF to Container."

After that, we're going to go to our layout. Then, I've added that if the $listen variable is an error, we're going to set the field Order::Error to RemoteScripterLastError. This function will show anything that went wrong with the listening process. We're also going to look for register errors. The way we'll do this is adding if the $register variable's value is an error; we'll also set Order::Error to RemoteScripterLastError.

We're going to look at our second script now, called Print Invoice. This is the script that I've linked up with the "print invoice" button on the form and will run in the Web Publishing Engine. First, we'll set our field Order::Error and clear that out to make sure there are no errors from previous attempts. We're going to create a variable called $trigger, and we're going to set it to the RemoteScripterTrigger function. This function calls FileMaker Pro to run the script we defined earlier in the listening step. It then waits for FileMaker Pro to finish. IWP is essentially triggering FileMaker Pro's client to perform the scripts.

In our $trigger variable, we need to pass in three things. Our IP address, which is local host; our port number, 4645 (which we defined previously) and our parameter. In this example, it's my order number. Then we set a field to Get(CurrentTimeStamp). We put this field on the layout to force the record to refresh. Sometimes there's a little bit of lag between when IWP sees information after FileMaker Pro finishes. By setting a timestamp field, we can force it to refresh and make sure the client sees exactly what it needs to see. Finally, a little bit of error checking - if the trigger was an error it will display RemoteScripter LastError. This will show whatever the problem was with the last attempt. We'll end the if statement, save that script off, and take a look at the next script.

Finally, we have a "Save Invoice as PDF to Container" script. This is the script that runs when RemoteScripter is triggered by the port number. At this point scripts will begin to run in FileMaker Pro rather than Instant Web Publishing. By switching to running scripts on FileMaker Pro, we can use all the script steps that would normally be unavailable in the web publishing engine. We have here a simple "find and save as PDF" script. I set the variable as ID and use get script parameter. We open a new window, enter find mode, set the ID as order number, perform the find, go to related records, and then set the variable path. This grabs the desktop path and saves it there if you are using FileMaker Pro. We'll save these records as a PDF with no dialog using our path defined earlier with the records being browsed. We close the current window, and insert file into path, and commit with no dialog. In FileMaker Pro, I've enabled the option to show only those scripts steps that are safe for IWP. Saving records as a PDF is not one of those that are available browser side, which is exactly why RemoteScripter is such a good solution. We can simply call this script in FileMaker Pro from IWP using RemoteScripter.

Let's just look at this one more time, here in the browser. We click the Print Invoice button, and FileMaker Pro creates the PDF and saves it in the background. After that, in the browser, it's available for download as a PDF.

This concludes our short tutorial on the scripts and functions behind saving a PDF in IWP using RemoteScripter. You can download a demo or purchase a license from 360works.com/remotescripter. If you have any questions, please don't hesitate to contact us by emailing us at plugins@360works.com or visit our forums. Thank you and have a great day.