FileMaker 12 and SuperContainer: A comparison

Of all of the new features in the recently released FileMaker 12, one of the most significant is the inclusion of enhanced container fields with managed storage. These enhanced container fields offer users a simple solution to store container assets outside of the database file in order to avoid increasing the size of the database file itself.

Solving this issue was the driving force behind the development of 360Works' SuperContainer, a server application that leverages FileMaker's Web Viewer to manage digital assets from your FileMaker interface.

In this article we'll compare the unique features of both FileMaker Enhanced Container Fields and SuperContainer so that you can make an informed decision for your solution.

FileMaker and SuperContainer BOTH offer

Small files sizes- Both FM 12 and SuperContainer allow you to manage assets without increasing the size of your FileMaker file. This ensures that your file is still fast, clean, and portable.

Thumbnail generation- Both FileMaker 12 and SuperContainer can generate network-efficient thumbnails. This means that for image files, the container fields will generate a thumbnail of the image, while interactive files, like .mp3 or .mov, have the option of immediate streaming playback. This can help to optimize database speed as the images and files are progressively streamed to users from the server, rather than waiting for the entire file to download. Note that when using SSL encryption, only SuperContainer supports streaming - FileMaker Server does not. Also note that for thumbnail generation of PDF files, SuperContainer must be deployed on a Mac OS X sever.

Interactive content- Both FileMaker 12 and SuperContainer can store static and interactive media, allowing you to read through the pages of a PDF document, playback audio or video files, or view thumbnails of image files - all from within the container field.

Easily move, copy, or upload existing files- Both FileMaker 12 and SuperContainer allow users to easily manage their assets, giving the ability to move files to new directories, copy files to new locations, and easily upload existing container field contents.

User interface control- FileMaker 12 and SuperContainer both give you control over the look and feel of your layout objects, including displaying titles, metadata, playback functions, upload, download, or delete functions, and thumbnail size.

SuperContainer is available for purchase at

About 360Works

Located in metro Atlanta, 360Works, a FileMaker Platinum Business Alliance member, has been providing FileMaker-based solutions for 15 years. The company is a leading developer of both shrink-wrapped and custom database design solutions for clients such as NASA, Pixar, US Marines, Make-A-Wish foundation and others. The company is credited for its forward-thinking solutions, dedication and unparalleled client service.

The Staff, 360Works

plugins@360Works.com

(866) 662-9185

This tutorial video describes how to run credit card transactions from FileMaker Go using the 360Works Plastic plugin. The transcript is attached below, and the video can be watched on YouTube at

Hi, I’m Sarah Mulligan from 360Works, and this video is going to demonstrate how to run credit cards from FileMaker Go. We’ll be using a combination of FileMaker Server, FileMaker Go, and a plugin called

To start, we’ll load the solution file on FileMaker Server. FMS will include all our scripts, including the payment script. FileMaker Server will also be loaded with the Plastic Plugin. We will then access this file from FileMaker Go, but all the scripts and plugins will be located on FMS. We’ll let the user enter payment information remotely, and then save that information to the database as a transaction. We’ll also attach another field called Statusand set it to PENDING. The server will run a script every minute to find all transactions marked with PENDING and then process the transaction from FileMaker Server. The FileMaker Go user could then refresh his interface to see the payment was successful, or be presented with a descriptive error.

Let’s take a close look at how this works in an example. We’ll be working with the solution file found with the Plastic demo download. You can find this file and a demo plugin free on our website,

On this layout, we set a number of fields. In this example, first select the gateway. Currently we support Authorize.net and PayPal. We also enter our Merchant Account and Password. You may want to set these fields yourself in a different layout, and only expose the relevant fields to an end user. The end user will enter an amount, a card number, and an expiration date in the form MMYY. We also have a field called Status, which should default to “PENDING” with a new record. I’ve done this by auto entering “PENDING” in the options for the field Status. Make sure the fields are committed in FileMaker Go.

This should be all the information you collect from FileMaker Go.

From FileMaker Server, let’s open our solution and take a look at the server-side script that actually processes this payment.

It performs a find, looking for all status fields marked pending. It sets the processing gateway using the function CCSetGateway from the plugin Plastic.

From the found set, it performs a Set field step on those transaction IDs. It uses the function CCProcesssPayment from the Plastic plugin. Set the following:

CCProcessPayment(

Settings::merchantAccount ;

Settings::transactionKey ;

Simple example::Amount ;

Simple example::Card number ;

Simple example::Expiration date

)

Finally, we check if the CCProcessPayment returned an error, in which case we set the status to CCLastError. CCLastError will provide more information if the transaction was not successful. These errors would be descriptive and end-user friendly; for example: card declined, or loss of connection. If there were no errors, we set the Status field to SUCCESS.

This makes the script that the server will run. To set the script up on FileMaker Server, we’ll create a new schedule that runs that FileMaker scripts every minute. This one minute interval will reduce the time a client will have to wait.

Since this solution includes credit card information, FileMaker Server should use encryption when passing this information. To enable this, open FileMaker Server Admin Console, choose Database Server, click the security tab, and choose “Secure connections to Database Server.” Restart FMS to being using the encryption.

Taking a look at this altogether again, we use FileMaker Go to enter our payment information, we mark the status as PENDING, and the FileMaker Server runs a script that looks for those PENDING transactions and runs them using Plastic.

This concludes the tutorial on running credit card transactions using Plastic and FileMaker Go. If you have any questions, please feel free to email us at plugins@360works.com, ask a question on one of our

This tutorial video describes an example of using

The transcript of the video is provided below.

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

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.

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