Today is the day everything changes for FileMaker developers. (Orchestra, play loud!)

Almost a year ago, soon after the release of FileMaker Pro 12, we already released FMSDIFM, and you might already have seen this video. The technique was widely discussed among the FileMaker community, but although it was incredibly efficient and stable, it was quite difficult to deploy, and this is why we didn’t give the source away. The principle was public, but the implementation was for our hosting service customers only.

Today, on the occasion of the Berlin Pause On Error conference, we release a free, fully functional, open source and downloadable version. From now, you can deploy FMSDIFM on your own FileMaker Server. Be ready, this is going to change your developer life, and your users’ experience.

What is FMSDIFM?

FMSDIFM stands for “FileMaker Server, Do It For Me”. Yes, we’re bad at finding names.

The principle is the following: by offloading the client and performing all CPU and Data-access intensive tasks to the server, you can improve performance by a huge factor, including on the LAN, a WAN connection, and even more if you’re using FileMaker Go. By huge, we mean something like several hundred times faster!

As you will soon discover, performance is only one of the many benefits of FMSDIFM.

How does it work?

First, the new FileMaker Server 12 architecture is of great importance for this technique. The fact that it’s 64 bits and can be allocated more memory, as well as the relative independence of the database engine which won’t slow down during backups or when a container field is requested by a user, make FMSDIFM secure and stable.

The idea is super-simple. FileMaker 12 new feature Insert From URL allows interacting with a web server. It also allows really hiding objects on the right side of a layout. FileMaker Server also comes with several web publishing methods, including XML. Web publishing can of course perform a script on a database.

So what if you’d call a script on the server from the client? This is what FMSDIFM is about. At any time, FileMaker Pro/Go can trigger a script on FileMaker Server. It will then be performed in no time, and can send a result so your client side script can use it and adapt its behaviour.

All it takes is check the XML checkbox on FileMaker Server!

Download FMSDIFM

The demo file

Please download the demo file and install it on your server (it won’t work if it’s not hosted by FileMaker Server). Ensure that the XML web publishing is enabled. If it’s not, you can do so from the FileMaker Server Admin console.

Note that the performance differences will be even more noticeable if the server is remote, typically on a WAN network.

Now, from your desktop or from your iOS device, you can try to click each of the 8 buttons on each layout (In Context and De-contexualized). You’ll be amazed.

Why does it look a little more complex than you said?

That’s true, this free downloadable version is a little more complex than the one we presented last year. Here is why:

A great part of the complexity is there to be able to create records in the FMSDIFM table without changing layout. It is not directly linked to the technique itself. With the ’old’ version (which is still available), you could simply insert a URL, as complex, long, full of special characters… the system was doing the job, but it was to complex to deploy. We hope that FileMaker will soon allow ExecuteSQL to create records using INSERT INTO, but for now we have to deal with this limitation.

OK, so now the communication with the server is easier (it doesn’t require an installation) but it requires a little more adaptation in your solution.

Here are the things you need to do in your solution.

• copy the FMSDIFM table to your file.
• if you’re using the separation model, add a table occurrence and a layout for this table in your interface file, and name both FMSDIFM.
• copy the ΩFMSDIFM global field in all tables. (by “all”, we mean all tables which have a layout from which you might want to trigger a script on server)
• on all layouts, paste the g_Insert field from the FMSDIFM table. IMPORTANT: from the position inspector, name the object FMSDIFM. We recommand pasting the object on the right side of the layout (in the “hidden part”, and locking it so you can’t delete it easily)
• for each table occurrence on the graph representing a layout from which you want to use FMSDIFM, create a new FMSDIFM table occurrence, and name it after your TO. If your TO is “Clients”, then the new TO should be “Clients_FMDIFM” (append _FMSDIFM)
• create a relationship between the two TOs, from ΩFMSDIFM in your original TO to UID in FMSDIFM. Enable record creation on the FMSDIFM TO side.
• copy the FMSDIFM script folder.
• choose Manage/Security from the File menu. Create 2 users with 2 Privilege Sets. Note that this is only a proposal for securiy implementation. FMSDIFM_connect privilege set is very restrictive. It allows FMSDIFM to connect and retrieve a record in the FMSDIFM table only. FMSDIFM_full is much more permissive. Both passwords are set to “TopSecret” in our examples. You can of course change them, and adapt the FMSDIFM | RELOGIN scripts. This step must be reproduced in all you solution files.
• while in Security settings, ensure all users can write to FMSDIFM table. Ensure FMSDIFM | SETTINGS script is not modifiable for it contains passwords (you can store these passwords more securely using custom functions, but we chose to keep things simple in this demo file)
• if your solution has multiple files, the script FMSDFM | RELOGIN must be copied to all files of your solution. You should also adapt the script FMSDIFM | EXECUTE in your main file. Where the relogin script is performed, add other Perform Script actions to relogin in every file.

That’s it. FMSDIFM is installed.

How to use FMSDIFM in my solution?

Now that your solution is ready, you must reorganize your scripts a little. Remember: you don’t need to do everything using FMSDIFM. Try to start with the heavy scripts with loops.

• in your script make distinction between what’s data modification and what’s user feed back (layout/record navigation, messages, mode changes…). You will be surprised to see how much code is simply there because you need to navigate through layouts to modify data. You will soon be able to simplify all this for it will be performed on server. Typically, we try to identify 3 parts in the script:
  — the header, where we control if the script should be performed or not (is the parameter valid? is the user allowed to run this script? should this record really be deleted?…)
  — the body, where things are done (data creation/modification/deletion). This is what we want to be performed on server.
  — the footer, where the user is taken to a layout/tab panel/field/record, given a message or a feed-back, or where something is pdf/printed…
• copy the steps from the body, and paste them to a new script (for example myscript.server)
• cut these steps from the old script (your ’client side script’), and replace them with Perform Script [ FMSDIFM | CLIENT ]
• pass a parameter that identifies which script the server should perform, as well as your real parameter. In the demo file, we have somthing like SCRIPT IDENTIFIED¶Get ( ScriptParameter ), you’re of course free to structure your parameter just as you usually do (we use XML parameters in our solutions)
• in the script FMSDIFM | DISPATCHER, adapt the two first lines to your way of passing parameters, and add a new Else If clause for your new action.

This is it. Your client side script will now call server scripts and receive a result.

What are the benefits of using FMSDIFM?

As you will soon discover, benefits are simply huge.

Of course, by offloading the client and having CPU/data intensive tasks performed on the server, the performance is increased dramatically, as this demo file illustrates. But there are number of other benefits, among which:

• context free scripting. We’ve been using FMSDIFM for more than a year now. You wouldn’t believe how simple our scripts have become, now that any action can be triggered from any layout, without wondering if we should freeze the window, refresh it, change layout, store/restore selected tab panels, open new hidden windows to preserve the foundset… Working in a real client/server environment is so much cleaner.
• diminish the risk of interrupted script. Especially on FileMaker Go, where any incoming phone call, flat battery, 3G connection failure… can cause a script to stop in the middle of a process.
• use plugins without deploying them. If you’re using a server compatible plug-in, you can use it in FileMaker Go! And… all you need is a single server licence!

What should I know before I start?

There are still limitations that you should be aware of:

• because the script is performed by the web publishing engine, some script steps are not compatible (set the bottom left compatibility menu in your script editor to Custom Web Publishing)
• because the server session is different than the user’s, server side scripts can’t use user defined global fields or variables. Those need to be passed using script parameter. (to FMSDIFM | CLIENT)
• for the same reason, the server side script does not know which account is active. You therefore can’t use the Get ( AccountName ) or other user specific Get functions. This is why we added the creator’s account name to the FMSDIFM table, so you can use it in your scripts ($$account.name). You might want to add other information such as IP address, Persistent ID…
• FileMaker 12 Insert From URL feature has weaknesses. Namely, there is no timeout. It means that unfortunately, if there was a web connection failure, you’d see a ’Transfer from HTTP’ progress bar forever. You must then force quit your FileMaker Pro/Go client. We can only hope that future releases of FileMaker will solve this. Please note that this is a very hypothetical test case. Because the calls are so short (scripts are performed so fast), the risk of a http connection failure is much lower than a plain FileMaker failure on port 5003.
• debugging a server side script is not so easy. That is why you have a debug mode built-in. To access it, simply hold the shift key down while performing the script. What the debug mode does is simply perform the server side part in a client new window. Still, it’s not a perfect solution because the client has a different privilege set, and has access to all client side global fields and variable. Well, it still helps…

We hope that you will enjoy using FMSDIFM. We’ve worked hard to make it available for you and free of charge. Please help us improve it, and feel free to mention us somewhere in your interface.