Connecting FileMaker Pro to FileMaker Server with the FileMaker Data API

FileMaker Server 16 (and FileMaker Cloud 1.16.0) included a new trial feature called the FileMaker Data API (application programming interface), which allows web services or applications to access data in hosted FileMaker solutions without needing any FileMaker client software to be installed. This is similar to the current XML and PHP APIs which have been around for over 10 years, however the Data API is a REST (Representational State Transfer) API which means you don’t need to use any particular programming language to work with the Data API.

In their Product Roadmaps over the past couple of years FileMaker Inc. have indicated that they will be investing in the Data API in future releases of FileMaker platform. Whilst they have not included the XML and PHP APIs in their list of deprecated features their focus will be on the Data API which opens up the FileMaker platform to an almost unlimited number of external apps and services.

We’ve been working with REST APIs for many years – sending SMS messages, integrating with Accounting platforms and eCommerce platforms – so we were pleased to see FileMaker Server (and now FileMaker Cloud) include a REST API as this now opens up many possibilities for integration by external web services and applications, as they don’t need to know “FileMaker” in order to make requests with the Data API. If you’re familiar with making HTTP requests (GET, POST, PUT, DELETE) and working with JSON data formats then you will have no issues working with the FileMaker Data API.

As the FileMaker Data API is a trial feature – the trial expires on September 27, 2018 and the Data API will cease to operate – we normally wouldn’t recommend our clients use this feature in any live systems as it is likely to change and you will have to upgrade to the latest version of the FileMaker platform before the trial expires in order to keep using it (after making any necessary changes to ensure compatibility with the final release of the Data API). There is also the issue of licensing – the Data API is currently free to use in the trial period, but FileMaker plan to have a licensing model in place before the end of the trial. Without knowing what the final licensing model will be makes it hard for clients to commit to using the Data API at this stage.

During a recent project we had encountered a challenging issue that turns out was perfect for the Data API. This project has a FileMaker Server v16 hosted solution with a Custom Web Publishing/PHP interface. All users access the solution using a web browser – for security reasons installing FileMaker Pro was not an option. One requirement of the project was to allow printing of labels with barcodes and picking lists – we solved this by generating PDF files via the new support for generating PDF files on FileMaker Server as well as Excel files (see our blog post from last year on how we did this). We still ended up using a local FileMaker file to import the Excel file containing the data for the shipping labels and to create the barcodes.

This process was working smoothly but was more suitable for doing large bulk shipments and involved a number of steps that you normally wouldn’t have to perform in a purely FileMaker Pro interface:

  • users would first have to find the records via the web interface that they wished to generate labels for
  • they would then click a button to call the server side script to create the PDF or Excel file
  • they would then have to download this Excel or PDF file to their local machine
  • for PDF files they would simply open them and print as needed, and for the Excel files they would open the local FileMaker file and click a button to import the Excel file which then generated the labels and barcodes

As you can see there’s a number of steps involved, whereas with a pure FileMaker Pro interface there would typically be only 2 steps:

  • find the records to print
  • click a button to print the shipping labels or picking lists

The process was also the same regardless of whether you wished to print a single shipping label or 100 labels. We had been discussing ways to streamline and improve this process, knowing that we couldn’t connect to the solution using a live FileMaker Pro connection. We were leaning towards building a integration using either the XML or PHP APIs, or using a product like RESTfm when we realised that the Data API might be another option worth considering, knowing that it was a trial feature and would stop working in September but would be a better long term investment. Now that FileMaker Pro v16 supports cURL and JSON natively it started to make even more sense, even though using FileMaker Pro to integrate with FileMaker Server via the Data API doesn’t make too much sense at first.

We built a basic prototype in a few hours to authenticate and make simple requests to get single and bulk shipping labels and picking lists and were impressed by the speed of the responses, so decided to press ahead and incorporate this functionality into the existing local FileMaker solution that users were already using to import the Excel files and print labels and barcodes. We were further able to link the web interface with this local FileMaker file through the use of FMP URLs by adding buttons on the web interface that called scripts in the local FileMaker file and passed in parameters, so the updated process to print labels and packing lists is now down to 2 steps:

  • find the records to print
  • click a button to print the shipping labels or picking lists

If you’re thinking about using FileMaker Pro as a client for the FileMaker Data API here’s some tips and tricks we learnt along the way:

  • the FileMaker Data API Reference can be found on your FileMaker Server at this URL – https://localhost/fmi/rest/apidoc/ – and contains examples for the requests and responses you can expect when authenticating, working with records and performing finds. The FileMaker 16 Data API Guide is the other main reference to working with the Data API. I recommend having both of these resources open in separate tabs when working with the Data API for the first time
  • we recommend using tools like Postman when working with the Data API to learn how to structure your requests. You can convert your working requests to cURL using the Generate Code Snippets feature which you can then copy and paste into your FileMaker Insert From URL script step and format for use with FileMaker Pro. See our previous article about about using Postman environments with the REST API.
  • the Data API is not currently a complete replacement for the XML or PHP APIs. For example you cannot insert container data or run FileMaker scripts with the Data API, or retrieve metadata about your FileMaker solution such as layout schema. The Data API does not currently return data such as the number of found records like the getFoundSetCount() method does in the PHP API, so you need to use workarounds for these.
  • date formats appear to work in a similar way to the PHP API in that you need to specify them in MM/DD/YYYY format regardless of your date formats on your server or FileMaker solution. Dates are also returned in the same MM/DD/YYYY format (e.g. 11/30/2017 for November 30th, 2017).
  • when performing a find query the fields you are searching for don’t need to be on the layout you specified in your URL, but only fields on the specified layout are returned in the response.
  • when performing a find query that results in no records found the use of the –show-error cURL option determines whether the Insert From URL script step returns an error (1631) or not. This is documented in the Supported cURL options page help page under the Handling errors heading.
  • one issue that caused us grief is an apparent bug with the use of the JSONSetElement function with spaces when used in a particular way the the cURL options. We have now standardised on specifying the JSON for each Data API request using the –data @$data syntax instead of the alternative methods
  • to help with debugging we recommend using the –trace and –dump-header options with every request

The final cURL options generally look like this for a typical request (assuming you have already authenticated and stored the access token somewhere):

"--request POST" & 
" --header " & Quote( "Content-type" & ": " & "application/json" ) & 
" --header " & Quote( "FM-data-token" & ": " & $$restAPIAccessToken ) & 
" --data @$json" & 
" --trace $$cURLTrace" & 
" --dump-header $responseHeaders"

Using FileMaker Pro as a client for the FileMaker Data API has us thinking about new ways we can leverage the Data API from an offline FileMaker Pro or FileMaker Go client, such as syncing records when using FileMaker Go on an iPhone or iPad and removing the overhead of having to have a live connection to your FileMaker Server. The Data API is perfect for uploading or downloading small changes from an offline file and once the shipping version of the Data API is available in the next version of the FileMaker platform (and the licensing model revealed) we expect to see more widespread use of the Data API, particularly for offline files running under FileMaker Go.

 

Using Postman Environments and Tests with the FileMaker Data API

One of the new features of FileMaker Server 16 and FileMaker Cloud 1.16.0 is the FileMaker Data API – currently in trial mode which expires on September 27, 2018. The FileMaker Data API is an application programming interface (API) that allows web services to access data in hosted FileMaker solutions and conforms to Representational State Transfer (REST) architecture, making the FileMaker Data API a REST API.

You can use the Data API to integrate your FileMaker solutions with other applications and services – REST APIs are the current standard for integration and the Data API will be the replacement for the current XML and PHP APIs.

Your web service or application calls the FileMaker Data API to obtain an authentication token for access to a hosted solution, then uses that token in subsequent calls to create records, update records, delete records, and perform find requests.The FileMaker Data API returns data in JavaScript Object Notation (JSON), another standard that is used with REST APIs for data formatting (and is also supported by FileMaker Pro v16).

A great tool to use when testing REST calls with the Data API is Postman, a free app for macOS, Windows and Linux (paid versions are also available). Postman allows you to make requests (GET, POST, PUT etc) to a REST API like the FileMaker Data API and inspect the response, including the headers. You can quickly make changes to the requests and headers that you send and compare the results – when working with REST APIs a tool like Postman is indispensable.

As mentioned above the FileMaker Data API requires you to obtain an authentication token when first accessing a FileMaker solution – the access token is valid until you log out of a solution or for 15 minutes after the last call that specified the token. While the token is valid, each call that specifies the token resets the session timeout counter to zero. To save you from having to manually copy and paste your token with each new request you can use some features of Postman to save your from having to manually update any variables in your requests manually, including the Data API access token.

Postman lets you setup multiple “environments” that can contain multiple variables fore each environment, such as the host address URL. For example you might have a development environment and a production environment, each with their own host address and other variables. In Postman I would simply have a POST request URL like this:

https://{{server}}/fmi/rest/api/auth/Tasks

and in each Postman environment I would specify the value for the {{server}} variable. When you make your request by hitting the Send button in Postman it will insert the appropriate value for each variable you’ve specified. You can read all about setting up Postman environments and variables in the Postman docs.

As you can’t specify the Data API access token in advance you can use another great feature of Postman to dynamically create the token variable which is then used in subsequent API requests. Your initial request to authenticate/login will look like this:

{ "user":"admin", "password":"admin", "layout":"Tasks" }

and if successful the response will look like this:

{ "errorCode": "0", "layout": "Tasks", "token": "fdde29fa175eb1cc8347512ca327b191619fc32ed65efaab26d8" }

Using the Tests feature when making a Postman request you can execute some JavaScript code after the request is sent to dynamically create a token variable that you can use with your subsequent API calls without having to copy and paste the token each time. Here’s a screenshot of how you would set this up in Postman for the Data API authentication request:

The JavaScript code you can copy/paste is:

var data = JSON.parse(responseBody);
postman.setEnvironmentVariable("token", data.token)

Using Postman environments and Tests to update the token variable makes working with the FileMaker Data API much easier and should save you a lot of time.

Easier PDF Creation using PHP with FileMaker Server 16

If you’ve been doing Custom Web Publishing with the FileMaker PHP API and needed to generate a PDF report you haven’t had many simple options. You can use one of the available PHP PDF classes such as TCPDF or FPDF which require specifying x and y coordinates, fonts and text to output in certain positions on the page, or setup a “robot” FileMaker Pro client that runs in a loop looking for new jobs to process.

Developers have been requesting the ability to generate PDF files server-side for many years, and from my conversations with FileMaker, Inc. engineers it was the number one feature request. FileMaker, Inc. were finally able to deliver on this with the release of the FileMaker 16 platform earlier this year, which included the following new features related to PDF and printing from FileMaker Server:

  • the Print script step now allows you to create PDFs in web browsers with FileMaker WebDirect
  • the Print Setup script step now allows you to specify PDF options for the Print script step and Save Records As PDF script step on FileMaker Server and FileMaker WebDirect
  • the Save Records as PDF script step now allows you to save PDFs with FileMaker Server and FileMaker WebDirect

If you look at the documentation for the Save Records as PDF script step you will see that is only compatible with FileMaker Server and FileMaker WebDirect  and not compatible with Custom Web Publishing (CWP), which is used by the PHP API when running FileMaker scripts. At this point you might be inclined to assume that there is nothing helpful in these changes for CWP/PHP developers, but there is a way to leverage the Save Records as PDF support under FileMaker Server from a PHP page.

The solution to this requires the Perform Script On Server script step (PSoS) which is CWP compatible. At this point it’s important to mention that PSoS does require the fmapp extended privilege to be enabled for your PHP/CWP users and their associated Privilege Sets. If your PHP users don’t normally access the database using a FileMaker Pro client then you may need to make some changes to your OnFirstWindowOpen script to limit their access (e.g. lock and hide the toolbar, navigate to a blank layout etc).

With some planning you can implement a solution that works like this:

  1. you have a PHP script – e.g. printReport.php – which includes a Print PDF Report button
  2. when a user clicks this button it performs a FileMaker script using the PHP API newPerformScriptCommand method. Let’s call this script Create PDF Report on Server
  3. the Create PDF Report on Server script is run as a CWP script (remember this script cannot create a PDF on its own). It includes a Perform Script On Server step which performs another script running under FileMaker Server which handles the Print Setup/Save Records as PDF steps and generates the PDF file and stores it in a container field (or passes the PDF back as Base64 encoded text using the Base64Encode function). Let’s call this script Save PDF
  4. the Create PDF Report on Server receives the script result from the Save PDF script – if you’re passing the PDF as Base64 encoded data you can set a container field using the Base64Decode function. Now that you have the PDF in a regular container field you can exit the FileMaker script and your printReport.php can use the getContainerData method to retrieve the PDF and either display this in the browser or download it

This might look complicated but I was able to implement this in a couple of hours for a client that needed to generate PDFs for a PHP/CWP solution. Before implementing this I would recommend you first become familiar with the server side printing/PDF changes in FileMaker Server 16 – a great place to start is the found in the App Innovations space of the FileMaker Community. Download the 05_Server side PDF support.fmp12.zip file which is part of DemoKit16 – a collection of tools aimed at helping demonstrate and explore new features of the FileMaker 16 Platform (brought to you by the World Wide Solutions Consulting team at FileMaker, Inc.). Upload this file to your FileMaker v16 Server and run through the examples and see how the Print Setup and Save Records as PDF script steps work under FileMaker Server 16. I ended up using these scripts:

  • [btn] How – Inventory Report – request report from server
  • [sbr] How – Inventory Report – get report as PDF (PSoS)

as the basis for my CWP scripts with only a few minor modifications, such as setting and retrieving various script parameters related to the records I was creating a PDF for.

The PHP code for this looks like this:

$scriptName = 'Request Invoice PDF'; 
$scriptParams = $orderID;  
$scriptObject = $fm->newPerformScriptCommand('WebOrders', $scriptName, $scriptParams); 
$scriptResult = $scriptObject->execute(); 
if(FileMaker::isError($scriptResult)) { $scriptError = 'Perform Script Error: '. $scriptResult->getMessage() . ' (' . $scriptResult->code . ')'; 
} else { 
$scriptError = ''; $record = $fm->getRecordById('WebOrders', $recid); 
$url = urlencode($record->getField('zv_Container_gr')); 
$fileName =  $orderID. ' Order Invoice.pdf'; 
$downloadLink = 'downloadFile.php?fileName='.$fileName.'&path='.$url; 
}

The downloadFile.php script simply retrieves the container data (PDF in this example) and does a force download of the PDF file to the user’s downloads folder. You could also change this to display the PDF in either the current tab or in a new tab as required.

Here’s a screenshot of the Request Invoice PDF script (have simplified this to show just the relevant steps for this technique):

and here’s the screenshot of the (simplified once again) Create Invoice PDF script that runs as the PSoS script:

I’m setting the generated PDF into a global container field in the Create Invoice PDF script as I don’t need to store the PDF file permanently in the database as this can be generated at any time, however you could also store the PDF in a regular container field in a new record etc as required and avoid having to Base64Decode/Encode the PDF data. It’s also worth remembering that you can’t use the PSoS script to set the PDF into a global field, as global fields are unique to each clients “session” so the CWP script and the PSoS script are each running in their own session, which is why you need to use the Base64Decode/Encode functions.

I’m looking forward to implementing this in existing CWP solutions which required complex FileMaker layouts to generate the PDF that weren’t easily created using the available PHP PDF classes. If you have any questions please leave a comment below.

Custom Web Publishing Changes in FileMaker Server v16

If you’re using Custom Web Publishing (CWP) with FileMaker Server v16 (PHP and XML) there are some changes in FileMaker Server v16 that you should be aware of that could break the functionality of your solution.

A client of ours recently upgraded their FileMaker Server to v16 which has a component that uses the FileMaker PHP API . One aspect of this involves a PHP page performing a FileMaker script which downloads files from an external service to the temp directory using the Get ( TemporaryPath ) function. Before I had a chance to troubleshoot this issue I noticed a post in the FileMaker Community titled “FMS 16 breaks CWP” – as a longtime PHP developer with many CWP client solutions this immediately caught my eye!

The post from David Jondreau mentioned that FileMaker Server v16 doesn’t support the Get ( TemporaryPath ) function – sure enough a quick check of the FileMaker v16 help confirms that under FileMaker v16 in “FileMaker WebDirect and Custom Web Publishing, this function is not supported and returns an empty string”. If you compare this to the FileMaker v15 help file it only states that in “In FileMaker WebDirect, this function is not supported and returns an empty string”.

I started troubleshooting my clients solution and after reviewing some server log table records that I had previously setup (always pays to have some kind of server side script logging setup that you can enable/disable on the fly as required) I could see that it was not generating a valid file path as the Get ( TemporaryPath ) function was returning an empty string. Our file paths to insert the image had gone from:

file://C:/Windows/Temp/S1494/IMG_4268.JPG

to:

file://IMG_4268.JPG

I was able to workaround this by splitting the single script into 2 scripts. The first script is called by the PHP page but it then utilises the Perform Script on Server (PSOS) script to run a script using FileMaker Server to download the file using the Get ( TemporaryPath ) function which is supported under FileMaker Server. The final sequence now looks like this:

  1. download.php file calls the newPerformScriptCommand to run a FileMaker script named ‘Start Image Download’ passing in a number of script parameters
  2. the ‘Start Image Download’ script runs under CWP and as part of this script it also includes a PSOS step to run another script named ‘Download Image’ in turn passing in a number of script parameters
  3. ‘Download Image’ runs as a PSOS successfully

I’ve since downloaded a copy of the FileMaker v16 help file and have been performing some searches to see if I can find any other changes for CWP compatibility. I couldn’t find any reference to these changes in the v16 Custom Web Publishing Guide or other release notes. David has started a new Product Idea in the FileMaker Community as well around this issue to see if some of the functionality can be restored. Hopefully someone from FileMaker Inc. can chime in with an update on why certain changes were made to CWP in v16 and provide a definitive list of what these changes were so we can put in place workarounds for solutions that will be deployed using FileMaker Server v16. If you know of any other CWP related changes in v16 please leave a comment below – I’ll update this post if I find out about any other changes as well.

Update 25 July, 2017: the FileMaker Community forum discussion has been updated with some feedback from FileMaker Inc. on why these changes were made: “Web clients (WebDirect, XML, & PHP) can no longer directly access files that are on the server (DBS) or worker (WPE) host file systems via scripting”. The solution is to use PSOS as described above.

 

FileMaker Cloud Now Available in Australia and Japan

FileMaker Inc. today announced that FileMaker Cloud, their cloud-based platform for managing and running custom apps, now supports the Japan and Australia Amazon Web Services (AWS) regions. With FileMaker Cloud you don’t have to spend time and resources deploying and maintaining a server – there are no up-front costs and you can be up and running in around 20 minutes.

FileMaker Cloud now supports 7 AWS regions including:

  • Sydney
  • Tokyo
  • Canada
  • US West
  • US East
  • Ireland
  • Frankfurt

Today’s update also includes the ability to renew the 90-day trial Comodo SSL certificates through the FileMaker Store for 1, 2 and 3-year terms, using the initial host name and the filemaker-cloud.com domain. We recently wrote about our experiences with FileMaker Cloud and some differences between FileMaker Cloud and the traditional FileMaker Server product that you should be aware of.

 

Reduce No-Shows with SMS Appointment Reminders

If you’re running an appointment based business you’re probably painfully aware of the cost of no-shows and missed appointments. Whether you’re taking bookings for an office based business (doctor, dentist, hairdresser etc) or for onsite appointments (building inspections, electricians, plumbers etc) it’s important to have a system in place to remind your customers about the upcoming appointment in advance.

Integrating reminders into the daily workflow of your appointment based business has a number of important benefits:

  • decreases appointment no-shows. We’re all human and sometimes we just forget to enter the appointment into our diary, but being reminded helps prevent no-shows or gives customers a chance to cancel or reschedule. It also allows you to fill your calendar if someone cancels with other waitlisted customers
  • maximises the convenience to the customer by allowing them to receive reminders on their mobile phone which they generally have with them at most times. They can also choose to respond if necessary from their phone at a time of their choosing
  • reduce the number of outbound and inbound calls and staff playing telephone tag

SMS messaging has emerged to be a preferred channel for customer communication including appointment reminders. I personally receive SMS reminders for the majority of my appointments (everything from car repairs/servicing to dental appointments). There are a number of advantages of SMS appointment reminders including:

  • SMS/TXT messaging is available on every mobile phone – there’s no need to download an app. It will work just as well on a Nokia from the 1990s as it will on the latest iPhone or Samsung Galaxy and doesn’t require an Internet/data connection
  • sending txt messages is immediate and asynchoronous – it doesn’t require you and your customer to be talking to each other at the same time. You can send an appointment reminder to a customer and they can read the message and reply if needed at a time that is convenient to them
  • 90% of SMS messages are read within 3 minutes of being received and have a a 5X higher open rate than email
  • Cost effective – compared to a physical mail out or phone calls SMS appointment reminders are very cost effective

We’ve helped many small businesses implement an SMS based appointment reminder system into their daily workflows, including:

  • a removal business sends appointment reminders to both customers and truck drivers 2 days in advance confirming the upcoming appointment
  • a hairdresser automatically sends out appointment reminders 3 days before each appointment using a FileMaker Server scheduled script
  • a physiotherapist sends out birthday congratulations to all their customers automatically on their birthday with special offers using a FileMaker Server scheduled script

Appointment reminders can be sent by a staff member each day (for example to remind everyone about appointments tomorrow) or scheduled to be sent automatically by FileMaker Server. You can also take advantage of 2 way messaging to allow your customers to send a reply via SMS which is routed directly back into your FileMaker solution. One customer was able to replace a process that took 2 staff members over 90 minutes to contact all customers to confirm their appointments for the next day with an automated SMS reminder system that sends out hundreds of appointment reminders in under 5 minutes.

If you would like to discuss integrating SMS appointment reminders into your FileMaker solution please contact us for a free initial consultation to discuss your requirements. Our fmSMS solution is also available if you would like to have your existing in-house/external FileMaker developer perform an integration using our ready made solution.

 

The Benefits of eCommerce Integration with your FileMaker CRM

 

In Australia and other parts of the world this week marks the start of a new financial year, which is a great time to review your business processes and eliminate any inefficiencies that is costing your business time and money.

One of the most common businesses processes we see in many small- medium sized businesses is the double data entry of orders from online eCommerce systems into the FileMaker custom business application (and sometimes once more into the Accounting software). We work with many small businesses that have an online presence, selling products and services using online platforms such as WooCommerce and Shopify. Many of them are unaware they it is possible to automate the exchange of data between eCommerce systems and FileMaker using APIs (an API is an Application Programming Interface that a company makes available to other software developers to allow you to get your software – FileMaker in this case – talking to their software).

If you’re using FileMaker as your CRM (Customer relationship management) application to track your customers, sales, invoices and payments there are a number of advantages of integrating it with your eCommerce software, including:

  • no more double data entry in FileMaker. The order and customer details have already been entered by the customer in the eCommerce system – with the click of a button the order details can be downloaded to your FileMaker custom application in a few seconds
  • no more double data entry of Product details in your eCommerce system. If you’re using your FileMaker application as the central repository of product data you can push/upload data from FileMaker to your eCommerce system (including images) at the click of a button
  • less errors between your eCommerce system and your FileMaker custom application. Being able to download and upload data between your eCommerce system and your FileMaker application means there is less likelihood of data entry errors between the 2 systems
  • free up staff time for more productive work. Rather than having staff spend countless hours each week doing double data entry they can be freed up for more productive (and enjoyable) work, such as following up on sales leads, customer service, marketing etc.
  • it also allows staff to upload and download data to the eCommerce software without giving them direct access to the eCommerce software

We’ve helped customers save between 1-2 hours of time each day for staff that were previously manually entering online orders into their FileMaker application. Now they download all the orders in the morning for the previous day and the whole process takes under a minute. We’ve even helped some customers use the power of Webhooks to have new orders pushed directly to their FileMaker Server so they don’t have to download any new orders – they instantly appear seconds after being placed online.

If you would like to discuss integrating your FileMaker solution with your eCommerce system please contact us for a free initial consultation to discuss your requirements. We also have a number of products which allow you or your in-house/external FileMaker developer to do the integration yourself with the WooCommerce and Shopify eCommerce platforms:

FileMaker Cloud Notes

FileMaker Cloud, FileMaker Inc’s cloud-based platform for managing and running custom apps, was officially launched in September, 2016. FileMaker Cloud gives you the the simplicity and performance of the FileMaker Platform without spending time and resources deploying and maintaining a server

FileMaker Cloud runs on the Amazon Web Services Cloud (AWS) and was originally only available for customers in the United States and Canada (AWS Regions of Oregon and N. Virginia). This was extended to Europe, the Middle East and Africa in March 2017 (AWS regions of Ireland and Frankfurt). According to FileMaker Inc’s product roadmap the next AWS Regions to be supported will be Japan, Australia, and Montreal.

There are a number of important differences between FileMaker Cloud and the traditional version of FileMaker Server for Mac/Windows – it’s worth remembering that FileMaker Cloud is not FileMaker Server as not all FileMaker Server features are available in FileMaker Cloud. FileMaker have a comparison between FileMaker Server and FileMaker Cloud that outlines the differences in various categories – some of the features of FileMaker Server not currently available in FileMaker Cloud include:

  • Custom Web Publishing with PHP and XML
  • Scheduled Scripts in the FileMaker Server Admin Console
  • External authentication via Active Directory/Open Directory

It’s also worth noting that FileMaker Cloud’s support for certain features may lag behind what is offered by FileMaker Server. For example the ESS Adapter that was introduced with the FileMaker 15 platform providing External SQL Data Source support for PostgreSQL, IBM DB2 and IBM iSeries is not currently supported in FileMaker Cloud, and some of the recent features of FileMaker Server v16 such as PDF support and the Data API are not currently supported in FileMaker Cloud. The FileMaker Server v16 features are currently “in development” according to the product roadmap so we can expect to see this released at some stage in the future.

If you use plug-ins with FileMaker Server (e.g. when called via the Perform Script on Server script step) you will need to check with the plug-in developer as they will need to compile a Linux version of the plug-in. You will also need to use the Install Plug-In File script step to install the plug-in from a container field in a file hosted on your FileMaker Cloud server.

Setting up a FileMaker Cloud instance is very quick – around 20 minutes or less in our tests so far. The FileMaker Cloud Getting Started Guide has all the steps required, including the AWS requirements, to get you up and running. As you don’t need to setup a physical server or operating system (FileMaker Cloud runs on CentOS Linux 7.2) everything is managed through the AWS and FileMaker Cloud consoles. You upload files to FileMaker Cloud the same way you do for FileMaker Server – using the FileMaker Pro/Pro Advanced client. There are some important differences with FileMaker Cloud, including the requirement for all files to be encrypted and that files that have the default account name of “Admin” with no password will be blocked from being uploaded until a valid password is configured for that account – this FileMaker Knowledge Base article has more details.

For FileMaker Developers there are some important differences in the results of certain FileMaker functions:

Get (HostApplicationVersion) returns Cloud Server 1.15.2.23 (the number corresponds to the FileMaker Cloud Version number from the FileMaker Cloud Admin Console)

Get (SystemPlatform) returns 5

Get (SystemVersion) returns 7.2.1511 (this is the version of CentOS)

Get (TemporaryPath) returns /FileMakerData/tmp/S177/

Get (DesktopPath) returns /home/fmserver/Desktop/

Get (DocumentsPath) /opt/FileMaker/FileMaker Server/Data/Documents/

Get (CurrentHostTimestamp) always returns timestamps in the UTC time zone. If you want to use the local time zone, you must include the calculation (the difference between UTC and your time zone) in your FileMaker Pro scripts/calculations. There’s a number of ways to do this such as this custom function.

FileMaker Inc have a number of online resources to help you with your FileMaker Cloud installation:

If you have any questions please leave a comment below or get in touch.

Voice Calling with FileMaker

Since we released v1 of fmSMS many years ago we’ve been approached by customers from all around the world to work on integrations between FileMaker and other APIs (Application Programming Interfaces). Customers love using FileMaker to send and receive SMS/TXT messages, but they have also asked us to help them send faxes, MMS/Picture messages and to make outgoing voice calls from their FileMaker solution.

We’ve done a number of voice call integrations with FileMaker over the years – having FileMaker initiate a series of outgoing voice calls can be useful in a number of situations, including:

  • Alerts: you might not have mobile phone numbers for all your contacts/customers, but if you have a phone number you can call that number to provide an update to important events (e.g. school closures due to snow days)
  • Election Campaigns: we’ve helped one customer initiate a series of campaign calls to voters about upcoming elections (you may well have been on the receiving end of one of these)
  • Appointment Reminders: we helped one customer move away from having administration staff manually phone each customer about their upcoming appointments and having FileMaker generate these calls, saving them 1-2 hours of staff time each day

The process for generating a voice calling campaign works as follows:

  1. you’ll need to sign up for an account with one of the voice calling providers such as Twilio that handle the voice calling
  2. if you wish to have a dynamically generated message that references data from your FileMaker solution (e.g. to have the voice call say “Hello Andrew” instead of just “Hello”) you’ll need a process on your FileMaker Server than can generate the dynamic message for each contact to be called. We use the FileMaker API for PHP to generate these. If you don’t need a dynamic message you could simply hard code the message so it is the same for all recipients of the voice call
  3. a FileMaker script that is initiated either by a user or FileMaker Server that finds a group of records, then loops through each record and makes a request to the voice calling provider to generate a new outgoing call to that contact
  4. if you wish to be notified of the result of each call you can setup a webhook on your server to be notified by the voice calling provider each time a call is made with the result (engaged, answered etc) and the duration of the call

We’ve put together a simple demonstration video showing this in action – you can watch the video inline below or directly on YouTube:

 

If you would like to discuss integrating voice calling into your FileMaker solution please get in touch.

FileMaker and Xero Integration Webinar Recording