In an earlier post, I cautioned against using FileMaker's ESS feature to bypass application logic in order to write to external SQL databases. This sort of begs the question: If you can't write to it directly, how are we doing any sort of interoperability between FileMaker, Drupal or other systems out there?

In general, if an API exists, that's the logical first choice. Updating a 'student' row directly is not always the same thing as updating the Student over a well understood API. In the case of web applications, we look for REST, SOAP or other kinds of services that let us play nice with the applications security model while practicing safe data-exchange.

In Drupal's case, there are a number of options, notably the Services module and a REST API module that, unfortunately, seems to be lagging in development.

That said, we've been succesful with a different method altogether to get FileMaker to speak Drupalese.

Instead of relying on another module, we bootstrap Drupal inside of FileMaker, effectively running a copy of Drupal locally that connects to a remote Drupal database. The great thing about this is that you instantly have access to the entire Drupal environment. Instead of writing additional XML or JSON files, you can write code that will work as if it were run remotely!

For this, you'll need a the help of a FileMaker PHP plugin. I highly recommend Scodigo's SmartPill plugin. Great stuff. Micah Woods and his team do some amazing work. Cheers!