Connecting FileMaker Pro to FileMaker Server with the FileMaker Data API

/2 Comments/in , , , , , , , /by

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

/4 Comments/in , , , , , , /by

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.

Webhooks are coming to Xero

/1 Comment/in , , , , , , /by

Earlier this year Xero announced that Webhooks would be coming to the Xero API, which was exciting news for Xero developers who have been asking for webhooks support for a long time (there is a request from 2010 in the Xero API Customer Feedback site!). Webhooks allow you to subscribe to certain events that happen in Xero: the Contacts endpoint was the first to receive webhooks support and Xero have said they will quickly move to Invoices and other high-use endpoints (hopefully including Payments which our customers would love).

The events that are currently support for the Contacts endpoint are:

  1. Create: A new contact has been created
  2. Update: An existing contact has been updated (including when contacts are archived)

When one of these events are triggered the Xero API sends a HTTPS POST to the webhook’s configured URL – you can then perform the appropriate actions based on the contents of the webhook payload, such as creating a new contact or updating an existing contact in FileMaker.

Xero started a closed beta for the Contacts webhooks which Databuzz was lucky enough to be invited to join and we’ve been working on ways to implement webhooks with our fmAccounting Link (Xero Edition) solution, initially using the FileMaker PHP API. Databuzz has been working with webhooks for many years, for example adding webhooks support to our fmEcommerce Link (WooCommerce Edition) solution to allow new orders to be pushed automatically, and to fmSMS to allow incoming messages to be pushed to FileMaker without requiring users to download these manually. Adding webhooks support to our fmEcommerce Link solution was fairly straightforward – we created a PHP file that uses the FileMaker PHP API and processes the webhook payload to update the existing contact or create a new Contact as required.

We still need to polish these off but we wanted to demonstrate how you could use Contacts webhooks (and Invoices and other endpoints that are supported in the future) with our fmAccounting Link (Xero Edition) solution. If Contacts are created or updated directly in Xero and you need to make the same updates in your FileMaker solution web hooks will save you having to either re-enter these manually or downloads these from Xero via the Xero API.

Check out our video below (or on YouTube) that shows how you can use webhooks to have updates from Xero pushed automatically to fmAccounting Link (Xero Edition) (or your FileMaker solution that you have integrated this into). If you have any questions about webhooks and Xero please post them in the comments below or contact us directly.

Update November 30, 2017: webhooks for Invoices are now available.

fmAccounting Link (MYOB AccountRight Edition) Updated for Purchase Orders

/0 Comments/in , , , , , /by

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.

fmAccounting Link (Xero Edition) and Public Application Integrations

/0 Comments/in , , , , , , /by

When we released fmAccounting Link (Xero Edition) back in 2014 we developed it to be used with a Xero API Private Application – this made the most sense at the time and still does for most customers who are only concerned with connecting their custom FileMaker business app with their own Xero organisation. Private Applications are just one of the three different types of API Applications available for the Xero API:

  • Private – connected to a single Xero organisation, doesn’t require user authentication
  • Public -connect to multiple Xero organisations, requires user authentication, 30 minute access limit
  • Partner– connect to multiple Xero organisations, requires user authentication, long term access

One of the main advantages of a Private Application is that your FileMaker users do not need to have a Xero account, so you can allow them to perform specific functions (e.g. uploading Contacts, Invoices, Payments etc from FileMaker to Xero) without having to get them access to Xero itself – the Private Application handles the authentication with Xero for them. This means you don’t have to worry about giving access to confidential business information contained in Xero to all FileMaker users.

There may be times however when you wish to only allow Xero users to upload data from FileMaker to Xero – this would require the use of a Public or Partner application. Databuzz recently took part in Xero’s XD HAX Developer Challenge 2017 and we decided to use this opportunity to explore how a Public Application integration could work. We were focussed on integrating with FileMaker Cloud which runs on AWS and wanted to have a native solution that ran on all the FileMaker clients that FileMaker Cloud supports, including FileMaker Pro for Mac/Windows, FileMaker Go for the iPhone and iPad, and FileMaker WebDirect.

As FileMaker doesn’t have the native functions to perform the OAuth 1.0a authentication that a Private Application type uses we have used a FileMaker plug-in to handle the authentication with the Xero API. FileMaker plug-ins are only supported by the Mac/Windows FileMaker Pro client applications which means they cannot be used by FileMaker Go for iOS (though you can use the iOS SDK to create an iOS application based on FileMaker Go that can include the plug-in).

Using a Public Application type integration means we could remove the dependency on the plug-in as Public applications use the standard 3 legged OAuth process where a user can authorise your application – in Xero’s case this is for 30 minutes, at which point the access token expires.

For our XD HAX Developer Challenge entry we changed the authentication method to use a Public Application integration and took advantage of a number of native FileMaker features, such as using a Card Window to handle the Xero authentication window, and the new cURL and JSON functions to handle the encoding/decoding of data and uploading/download with the Xero API. Here’s a brief video demonstrating how a Public Application integration could work with our fmAccounting Link (Xero Edition) solution:

We would love to hear if this is something that you would be interested in seeing in a future version of fmAccounting Link. We love that we can provide a native solution that runs on all FileMaker clients without a plug-in but are not sure whether customers would prefer the long term access that a private application provides and the benefit of not having to use a Xero login to authenticate.

Xero User Magazine Custom Integration Article

/0 Comments/in , , , , , , , /by

Issue 12 of the Xero User Magazine was released today in time for Xerocon London where Xero announced they have now surpassed a quarter of a million subscribers in the UK, contributing to the more one million subscribers in over 180 countries.

We’re pleased to report that this latest issue of XU Magazine includes an article by Andrew Duncan of Databuzz on ‘The Benefits of a Custom Xero Integration’. You can find the article on page 110 of Issue 12 – you can subscribe for free to the print and digital editions here. The article discusses the benefits of a custom Xero integration, particularly when there is no add-on in the Xero App Marketplace that meets you needs. We also mention examples of integrations we’ve done for customers over the past four years that have helped them eliminate double data entry, for both FileMaker solutions and other applications.

Earlier this year we were approached by an Australian Government agency that was using three different software applications to handle online sales, point of sale merchandise and ticket sales and needed to get the consolidated data into their internal financial accounting software. Xero was used to reconcile all financial data which was uploaded by Vend each night and we developed a custom web application which ran every 24 hours to download the Invoices from Xero and generate a custom XML file which was sent to the internal financial application. This has been running smoothly for many months now and the customer is very happy about the time saved from not having to do any manual re-entry of financial data.

If you would like to discuss a custom integration with Xero please get in touch.

 

fmSMS Updated for Telstra Messaging API v2

/0 Comments/in , , , , , /by

Back in 2015 Telstra, Australia’s biggest mobile phone operator, launched a beta of their SMS Messaging API and fmSMS was one of the first commercial solutions to support the Telstra API. Telstra have recently released v2 of their Messaging API which includes a number of new features including:

  • dedicated number: you can provision an Australian mobile number for your account via the API
  • send SMS and MMS messages
  • receive messages to your dedicated number
  • delivery status: query the delivery status of your messages
  • callbacks: automatic notifications of message delivery status to a callback URL
  • alphanumeric sender ID support
  • concatenation: send messages up to 1900 characters long and Telstra will automatically segment and reassemble them
  • scheduled delivery: delay the delivery of submitted messages

Now that the Messaging API is out of beta there are a number of plans to choose from. You can start with a free trial which includes 1000 free messages and a dedicated mobile number. They also have a PAYG plan with no fixed term contract and messages are 6c per message, as well as an Enterprise plan.

You can download a trial version of fmSMS from the fmSMS website to test the Telstra SMS API using their Free Trial. When you purchase fmSMS you get the PHP files to use for automatic delivery status updates and automatic replies into fmSMS. Please contact us if you have any questions about fmSMS and the Telstra Messaging API.

fmEcommerce Link (WooCommerce Edition) Update August 2017

/0 Comments/in , , , , , , /by

We’ve just updated fmEcommerce Link (WooCommerce Edition) – our solution for integrating FileMaker with WooCommerce – with a number of new features and bug fixes. We love getting requests from our existing customer base in many different countries and have included a few feature requests in the latest update, including:

  • Products: we added support for Grouped Products so you can now create and update these from FileMaker
  • Products: we added the ability to Delete a Product in WooCommerce from FileMaker
  • Products:  you can now view Product Images using a Webviewer (you no longer need to download Images into Container field to View them)

We’ve had a number of requests for the ability to create an Order in FileMaker and upload that to WooCommerce so it is available for customers to view when they login. We had been planning to add this in already so this will now be included in the next release – there’s quite a bit of work involved in ensuring the Order data is valid and gathering the correct line items, shipping lines, taxes etc, but we’re hoping to have this released in the next 4-6 weeks.

We’re also working on an update for FileMaker Pro v16 users to take advantage of the new JSON functions and cURL options in the FileMaker v16 platform – this will allow you to no longer need a plugin to communicate with the WooCommerce API, making it easier if you’re using FileMaker Go and FileMaker WebDirect and not having to use server side scripts.

This is a free update to all our existing customers – you can get the full details of the changes in the release notes for fmEcommerce Link (WooCommerce Edition). If you have any additional feature requests please get in touch.

fmAccounting Link (Xero Edition) Update August 2017

/0 Comments/in , , , , , , /by

We’ve been busy over the last couple of months working on some updates to fmAccounting Link (Xero Edition) that fill in some missing gaps with the examples that we include in the fmAccounting Link (Xero Edition) file. For example we’ve always had examples for downloading:

  • Chart of Accounts
  • Tax Rates

from Xero into FileMaker, but some customers have asked for the ability to create and update these from FileMaker to Xero. We’re pleased to report that our latest update – v1.932 – now includes examples for creating Account Codes and Tax Rates in FileMaker and pushing these to Xero. You would typically apply some kind of access privileges around these features so that only authorised accounts users can perform these functions, but the functionality for this is now included in the core fmAccounting Link (Xero Edition) files.

We’ve also updated the Bank Transactions endpoint examples to support creating and updating Bank Transactions (spend or receive money) in FileMaker and pushing these to Xero. This update also includes some minor bug fixes – you can view all the changes in the version history notes.

Last month Andrew Duncan from Databuzz attended #XD17 – the Xero Developer Roadshow – in Melbourne, Australia. There were some great presentations on upcoming features for the Xero API as well as some cool demos showcasing some cutting edge Amazon Web Services integrations with Xero. Xero have also announced that Webhooks are coming to the Xero API, starting with the Contacts endpoint first then followed by Invoices (the two most popular Xero API endpoints). Databuzz have been invited into the closed beta of this and we’ve started work on a PHP solution using the FileMaker PHP API that will accept the incoming Xero Webhooks notifications and trigger an update in the fmAccounting Link (Xero Edition) file. We will post an article with further details about this when Webhooks becomes publicly available.

Xero have also just announced support for JSON when uploading data to Xero via the API – they have previously only supported JSON for downloads (GET requests). Now that FileMaker Pro v16 supports JSON natively this will allow us to add native support for uploading and downloading data between FileMaker and the Xero API.

We also get a number of questions about Invoice Numbers when pushing Invoices from FileMaker to Xero, so we’ve updated our list of Frequently Asked Questions with some details about the options you can use when pushing an Invoice from FileMaker to Xero and whether to allow Xero to generate an Invoice Number to have FileMaker push the Invoice Number across to Xero to use. We’ve also updated our FAQ to include a note about FileMaker Cloud support.

fmEcommerce Link (WooCommerce Edition) Now Supports WooCommerce 3.0

/0 Comments/in , , , , , /by

Earlier this year we wrote about the upcoming release of WooCommerce 2.7 and how it would be introducing a new version of the REST API (v2) with a number of new API endpoints, particularly for Product Variations. Shortly after our post WooCommerce decided to re-version 2.7 to 3.0 to better reflect the significance of this update and push the release date to the 4th of April, 2017.

Since the release of WooCommerce 3.0 we’ve been busy working on an update to fmEcommerce Link (WooCommerce Edition) to support the new v2 of the REST API and associated changes. We’re pleased to announce that v1.3 of fmEcommerce Link is now available as a free update for all existing customers (details have been sent via email about how to download this update). As v1 of the REST API has now been deprecated by WooCommerce we’ve decided to create 2 versions of the fmEcommerce Link file, one for each version of the REST API:

  • fmEcommerce Link (WooCommerce Edition) REST API v1.fmp12
  • fmEcommerce Link (WooCommerce Edition) REST API v2.fmp12

WooCommerce 3.0 is a major update and WooCommerce recommend that you ensure your store extensions and themes are compatible before upgrading, test on a staging site if you can, and make a backup for peace of mind. Since the 3.0 release on April 4th there have been 7 updates already fixing bugs with both WooCommerce and the REST API.

The major changes in fmEcommerce Link (WooCommerce Edition) 1.3 include:

  • now supports the WooCommerce REST API v2 only
  • Product Variations are now stored in their own table to match the new Variations endpoint (you can now update Variations independently of their parent Product)
  • added support for additional fields exposed by the v2 API for existing endpoints
  • added new Meta Data tables which are included with most of the API endpoints (Customers, Orders, Products etc)
  • added support for new Payment Gateways endpoint
  • added support for new Shipping Methods endpoint
  • added support for new Shipping Zone Locations endpoint
  • added support for new Shipping Zone Methods endpoint
  • fixed issue when uploading a Product with no Images when Product previously contained images

WooCommerce 3.0 supports both v1 and v2 of the REST API so you can upgrade to WooCommerce 3.0 and continue to use your existing version or integration of fmEcommerce Link and everything will continue to work as it did with WooCommerce 2.6. If you wish to take advantage of the new API endpoints (e.g. the ability to upload Product Variations separately to the parent Product) you will need to switch to the new v2 API and make some changes to your existing scripts etc using the examples from the fmEcommerce Link (WooCommerce Edition) REST API v2 file. If you are not planning to upgrade to WooCommerce 3.0 in the near future you do not need to make any changes.

All future development we now be focussed on the v2 REST API as that is the version that WooCommerce will continue to develop – we’ll certainly fix any bugs that arise with the v1 REST API. You can get the full details of all the change on the version history page.