fmEcommerce Link (Shopify Edition) Now Runs Natively on FileMaker 16/17 Platform and supports Order Creation Webhooks

 

We’re pleased to announce that v1.3 of fmEcommerce Link (Shopify Edition) is now available and includes a number of new features, including native support for FileMaker Pro v16 and later. This is a free update to all existing customers (simply download using the same link that was on your original order email).

With the release of the FileMaker 16 platform we got a number of new functions and script steps, including support for working with JSON data and being able to specify supported cURL options with the Insert From URL script step. These new features meant that we were no longer dependent on plug-in functions and we could replace these with native FileMaker features.

We’ve updated all the requests for downloading and uploading to the Shopify API to use native FileMaker functions and script steps so you no longer need to use a FileMaker plug-in if you’re using FileMaker Pro v16 or higher. This means you can also use fmEcommerce Link on FileMaker Go natively (requires FileMaker Go 16 or higher).

Like our previous updates for native FileMaker functionality for our other products we’ve simply updated the scripts to check which version of FileMaker Pro, FileMaker Go or FileMaker Server is being used and if you’re using v15 or earlier we simply use the previous plug-in functionality, and if you’re using v16 or later we now use native functionality. Everything works exactly the same regardless of which version of FileMaker Pro you’re using, but we can now include support for FileMaker Go as well as having one less dependency to worry about.

This release also includes support for Shopify Webhooks – see our earlier post for a short video demonstrating how the Order Creation Webhook works. Instructions for setting up the Order Creation Webhook can be found here.

You can get all the details on our version history page – we’re continuing to work on adding native FileMaker 16 support to our other products, as well as some further updates to fmEcommerce Link (Shopify Edition) including support for processing Fulfilments in FileMaker and uploading to Shopify.

Automate Electronic Document Signing with FileMaker and DocuSign


For many years we’ve helped business both large and small with their workflow challenges, and one of the most common issues we see is managing the distribution and signing of standard business documents such as contracts, employee agreements, quotes and proposals. The solutions to these problems vary depending on a number of factors, including the type of document to be signed, the number of recipients, volume of documents and the location of recipients.

Over the past few years we’ve helped a number of customers integrate with DocuSign, one of the most popular electronic signature platforms. DocuSign helps organisations connect and automate how they prepare, sign, act-on, and manage agreements and allows users to sign electronically on practically any device, from almost anywhere, at any time.

With DocuSign you can create DocuSign Templates with merge fields that you sent to recipients for signing, or you can create a PDF on the fly and upload that at the time of sending the signing request. A common workflow solution integrating your custom FileMaker business app with DocuSign might look like this:

The process would typically work like this:

  • a FileMaker user is notified that a certain document needs to be sent to a customer for signing, such as a contract
  • the FileMaker user clicks a button that creates a custom PDF with any merged data for that customer with details on what actions the customer needs to take, such as signing on a particular page, entering their name or other details such as their date of birth
  • the FileMaker generated PDF is then sent to DocuSign with instructions to send this PDF to be signed to the specified customer, and DocuSign then sends a signing request email (you can customise the email subject and body)
  • the customer receives the email and electronically signs the document. DocuSign then notifies you that the document has been signed and you can then download the signed version of the document into a FileMaker container field

This type of tight integration between FileMaker and DocuSign has a number of benefits, including being able to manage the document signing process in one central place from start to finish. You don’t need to give your FileMaker users access to DocuSign as everything is managed from within FileMaker and you have access to the signed documents from FileMaker. You can even setup Webhooks to have FileMaker automatically notified by DocuSign when a document has been signed and have FileMaker download this automatically.

You will need to sign up for one of the DocuSign API Plans – (US, UK and Australian plans) which have a number of tiers depending on the number of documents you need to send each month and other additional features.

Here’s a short video demonstrating how a FileMaker DocuSign integration might work (YouTube link):

If you would like to discuss integrating DocuSign with your FileMaker solution please get in touch for a free initial consultation to discuss your requirements.

FileMaker, cURL and HTTP Response Codes

When FileMaker Inc. released the FileMaker 16 Platform last year they included a feature I had been requesting for over 15 years – native cURL support. cURL is a command line tool and library for transferring data with URLs – you’re probably familiar with the HTTP, HTTPS, FTP and SMTP protocols. cURL is important as it allows us to interact with external web services/APIs directly from FileMaker Pro, FileMaker Go, FileMaker WebDirect and FileMaker Server. For example we can use FileMaker to send an SMS, upload an Invoice to Xero or MYOB, or download Orders from eCommerce platforms like WooCommerce or Shopify.

Starting with the introduction of the Insert From URL script step in FileMaker Pro v12 we’ve been able to interact with URLs with some limitations:

  • FileMaker Pro v12 introduced the Insert From URL script step which supported http, https, ftp, ftps, and file protocols. A field was required to download the result/response into and it didn’t support performing an HTTP/S POST request – only GET requests were supported (most APIs require a POST request to create/update records via the API). There was also no ability to customise the HTTP request, e.g. to set HTTP Headers which are often required for many APIs
  • FileMaker Pro v13 extended the Insert From URL script step to both HTTP GET and HTTP POST requests using the httppost and httpspost custom schemes that you specified when constructing the URL (e.g. “httppost://www.filemaker.com/path?fname=Bob&lname=Smith”). You still couldn’t specify HTTP Headers and still required a field for the result

Given these limitations I rarely used the Insert from URL script step until FileMaker Pro 16 was released. Since the FileMaker Pro v6 days I have been using a number of different plug-ins to perform HTTP requests – initially I had a custom plug-in developed, then switched to the Troi URL plug-in and then to the BaseElements plug-in. Databuzz sponsored the development of some specific functions that we needed and the BaseElements plug-in provided us with cURL support and a number of other related functions, such as JSON encoding and parsing and XPath for parsing XML data. The BaseElements plug-in has provided us with the functionality we needed that was missing in the FileMaker platform, but as a plug-in was required it did have a number of disadvantages:

  • FileMaker Go does not support plug-ins (you can now use the iOS SDK). You could use FileMaker Server script schedules and Perform Script on Server as a workaround but this required the FileMaker solution to be hosted by FileMaker Server so wouldn’t work for solutions running locally on the iPad or iPhone
  • running scripts under FileMaker Server required the plug-in to be installed on the server, which can be done easily as long as the appropriate permissions have been granted in the FileMaker Server Admin Console. Some hosting providers also disabled the option to install plug-ins on shared servers.

With the release of the FileMaker 16 platform came the ability to specify one or more supported cURL options as a calculation when using the Insert From URL script step, as well as the ability to specify a variable as the target (no more fields required!). This was a game changer as far as working with APIs was concerned – now the entire FileMaker Platform could natively make HTTP requests, set HTTP Headers, and encode JSON data and parse JSON. All of our integration solutions were using the BaseElements plug-in, so we started to work on adding native support for FileMaker Pro v16 users by switching from the BaseElements plug-in functions to using the native Insert From URL script step, cURL options and JSON functions.

One function for which there was no native equivalent was the BE_HTTP_Response_Code function which returns the HTTP response code value from the last request. HTTP Response Codes are issued by the server in response to a request and can be used to determine whether the HTTP request was successfully completed or if there were issues associated with the request. For example 200 is the standard response for a successful request and 401 means there was an authentication issue and the request failed. It’s important when working with APIs to check the HTTP Response Code to confirm that the request was processed successfully – the documentation for each API will usually specify what response code indicates a successful request (typically 200 or 201).

The HTTP Response Code is contained with the HTTP Response Headers which are returned by the server processing the request. You need to specify the following cURL option to get the response headers returned into a FileMaker variable:

" --dump-header $responseHeaders"

The $responseHeaders variable will then contain something like this after the Insert From URL script step has been performed:

HTTP/1.1 200 OK
Date: Wed, 13 Jun 2018 04:45:17 GMT
Server: Apache/2.4.26 (Red Hat)
X-Powered-By: PHP/5.6.35
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8

In the above example you can see the first line of the response headers contains the response code: “HTTP/1.1 200 OK”. Other common response codes that you might encounter include:

HTTP/1.1 100 Continue
HTTP/1.1 403 Forbidden
HTTP/1.1 201 Created
HTTP/1.1 302 Found
HTTP/1.1 301 Moved Permanently

You can use standard FileMaker functions to get the actual numerical response code from the first line of the response headers, e.g.:

Let ( [
t1 = GetValue ( $responseHeaders ; 1 ) ;
t2 = Substitute ( t1 ; " " ; "¶" ) ;
n1 = GetValue ( t2 ; 2 )
] ;

n1

) // Let

This all works fine as long as the Response Headers only contain a single response code, but sometimes the server will return multiple response codes. For example the response might include a redirect or a continue and look like this:

HTTP/1.1 100 Continue

HTTP/1.1 403 Forbidden
Server: nginx/1.14.0
Date: Wed, 13 Jun 2018 07:41:16 GMT
Connection: keep-alive

The response code we are after is the “403” value and not the “100” value, so our above calculation would return the wrong response code in this situation. We started working on a custom function that would look for the last “HTTP/1.1” string and then get the code following this, but that failed pretty quickly when working with a server that included the string “HTTP/1.1” elsewhere in the response headers.

We’ve settled on using this custom function which so far is returning the correct result, at least with the APIs and servers that we have tested it on so far. We would much rather have a native function for this which does the equivalent of what the BaseElements BE_HTTP_Response_Code function does without having to try to locate and find the last response code from the response headers. From researching this it appears that there is already a cURL option for this:

-w "%{http_code}"

but unfortunately the -w option is not one of the FileMaker supported cURL options, so for now you’ll need to parse out the response code until FileMaker add support for the -w option. We’ve added this to the FileMaker Product Ideas discussion area – if you would also like to see this feature in a future version of FileMaker platform you can vote up the idea here.

fmEcommerce Link (WooCommerce Edition) Now Runs Natively on FileMaker 16 Platform

When we first released fmEcommerce Link (WooCommerce Edition) back in 2016 the functionality required to integrate with the WooCommerce REST API did not exist in the current version of FileMaker Pro, therefore we had to use a FileMaker Pro plug-in to handle the API requests, set HTTP Headers, encode JSON and parse the JSON response. This allowed fmEcommerce Link (WooCommerce Edition) to run under FileMaker Pro v12 and later, as well as under FileMaker Server with the plug-in installed, however it prevented it from running on FileMaker Go which does not currently support plug-ins (except via the iOS App SDK).

With the release of the FileMaker 16 platform we got a number of new functions and script steps, including support for working with JSON data and being able to specify supported cURL options with the Insert From URL script step. These new features meant that we were no longer dependent on plug-in functions and we could replace these with native FileMaker features. We’re pleased to announce that v1.5 of fmEcommerce Link (WooCommerce Edition) is now available and includes a number of new features, including native support for FileMaker Pro v16 and later. This is a free update to all existing customers (simply download using the same link that was on your original order email).

We’ve updated all the requests for downloading and uploading to the WooCommerce API to use native FileMaker functions and script steps so you no longer need to use a FileMaker plug-in if you’re using FileMaker Pro v16 or higher. This means you can also use fmEcommerce Link on FileMaker Go natively (requires FileMaker Go 16) – we’ve also included an example for using Perform Script on Server to have FileMaker Server handle uploading a Product to WooCommerce.

In working on this update (which was a much bigger update than we anticipated and took much longer than we planned!) we tried to avoid making too many unnecessary schema changes. We’ve simply updated the scripts to check which version of FileMaker Pro, FileMaker Go or FileMaker Server is being used and if you’re using v15 or earlier we simply use the previous plug-in functionality, and if you’re using v16 or later we now use native functionality. Everything works exactly the same regardless of which version of FileMaker Pro you’re using, but we can now include support for FileMaker Go as well as having one less dependency to worry about.

You can get all the details on our version history page – we’re busy working on adding native FileMaker 16 support to our other products, as well as some further updates to fmEcommerce Link (WooCommerce Edition) including support for uploading Orders from FileMaker to WooCommerce.

Gravity Forms Integration with FileMaker

Gravity Forms is a popular Form plugin for the WordPress platform, allowing you to create simple or advanced forms to capture data on your WordPress website. Over the years we’ve helped many customers with retrieving data from their Gravity Forms using a variety of methods, including:

  • simple CSV file download from Gravity Forms then import that CSV file into FileMaker
  • using the FileMaker PHP API to have Gravity Forms data automatically ‘pushed’ to their FileMaker solution each time an entry is submitted
  • using the External SQL Data Source feature to view the Gravity Forms data live from within FileMaker and create FileMaker scripts to download data

Each of these methods have their pros and cons: for some users the FileMaker PHP API integration is not an option, and for others they aren’t able to connect remotely to the SQL database as this is blocked by their web host. Downloading CSV files each day/week is also time consuming and cumbersome. Fortunately there is another method to use that has many advantages over these methods: the Gravity Forms Web API.

Using the Gravity Forms Web API we can dynamically query Gravity Forms from within FileMaker to check for new form entries and download those directly into our FileMaker solution, all within a few seconds. If you’re using FileMaker Pro v16 you can also use the new native JSON and cURL features to do this without requiring any FileMaker plug-ins – for older versions of FileMaker a plug-in is required to handle the API requests and cryptographic requirements. You can also setup schedules using FileMaker Server to have new form entries downloaded automatically (hourly, daily etc).

Here’s a short video demonstrating how we can download Gravity Forms entries directly into a FileMaker solution (you can also view it directly on YouTube):

If you would like to discuss integrating Gravity Forms with your FileMaker solution please get in touch for a free initial consultation to discuss your requirements.

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.

 

FileMaker 16 Certified Developer

Databuzz is pleased to announce that Andrew Duncan recently passed the Developer Essentials for FileMaker 16 Certification Exam and is now FileMaker Certified in v8, 9, 10, 11, 12, 13, 14, 15 and 16. FileMaker 16 Certification is the official credential offered by FileMaker, Inc.

FileMaker Certification is your validation that you are hiring an experienced FileMaker professional who has technical knowledge of the complete FileMaker product line and has passed the “Developer Essentials for FileMaker” certification exam. Being a certified developer demonstrates to clients, peers and management that you’ve achieved an essential level of knowledge, experience and skills in developing FileMaker solutions.

fmAccounting Link (MYOB AccountRight Edition) Updated for Purchase Orders

An updated version of fmAccounting Link (MYOB AccountRight Edition) has just been released which now includes examples for working with Purchase Orders, which has been a popular request from our customers. fmAccounting Link shows you how you can use FileMaker to:

  • download Purchase Orders from MYOB to FileMaker (all Purchase Orders or filtered by Purchase Order Date)
  • create Purchase Orders in FileMaker and upload them to MYOB
  • update a single Purchase Order from MYOB

This is a free update for all existing customers. You can view the full release notes on our version history page.

Our next update will include examples for working with Bills in MYOB and FileMaker. We’re also planning an update that will be ‘plug-in free’ for FileMaker v16 users, allowing you to use the fmAccounting Link (MYOB AccountRight Edition) solution natively under FileMaker Pro,  FileMaker Go and FileMaker WebDirect without having to install and manage plug-ins. The FileMaker v16 platform introduced some new cURL options and JSON functions which will allow us to perform the same functions as the plug-in provides when using FileMaker v16 – earlier versions of FileMaker will still need to use the plug-in functions.

If there are other features you would like to see in the core fmAccounting Link (MYOB AccountRight Edition) file please get in touch and let us know.

FileMaker Cloud Joins the FileMaker 16 Platform

FileMaker, Inc. today announced availability of the latest version of FileMaker Cloud, its cloud platform for managing and running custom apps that runs on the Amazon Web Services Cloud. With this release (1.16.0.55), FileMaker Cloud joins the FileMaker 16 Platform and it is available in the US, Canada, Europe, Japan and Australia.

This release of FileMaker Cloud requires FileMaker 16.0 clients at a minimum – if you’re using FileMaker v15 clients you will need to upgrade to v16 in order to access hosted solutions on FileMaker Cloud 1.16.0.55. You can read the full release notes here.

The new release includes a number of integration, security and development features:

  • FileMaker Data API trial: Use FileMaker data in other popular apps and services with the REST-based FileMaker Data API in FileMaker Cloud during the trial period.
  • Tableau Web Data Connector for FileMaker: Better visualize FileMaker data with the Tableau Web Data Connector for FileMaker. The connector uses the FileMaker Data API trial to provide integration with Tableau Desktop.
  • FileMaker Admin API trial: Help manage and administer custom apps with the REST-based FileMaker Admin API trial in FileMaker Cloud. Create messages and script schedules, open and close apps, and more.
  • OAuth 2.0 support for accounts: Simplify credential management with OAuth 2.0 using third-party authentication providers. Use existing Amazon, Google or Microsoft Azure account credentials to log in to FileMaker custom apps.
  • PDF support: Generate PDFs of layouts and data from FileMaker WebDirect. Save and print PDFs of invoices, labels, badges and more, just like with FileMaker Pro.

For more information on the differences between FileMaker Cloud and FileMaker Server check out our previous article on FileMaker Cloud as well as FileMaker Inc’s comparison between the two products. This release of FileMaker Cloud brings the ability to schedule scripts via the new FileMaker Admin API trial which was one of the missing gaps when compared to FileMaker Server. FileMaker Cloud does not support Custom Web Publishing with PHP and XML and FileMaker Inc. have stated that this will not be supported by FileMaker Cloud in the future – the FileMaker Data API will be the focus as far as API integrations are concerned so developers should focus their efforts here.

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.