Are you still processing credit card payments manually?

american-express-89024_640

Do you process credit card transactions manually and wonder if there is a better way? The good news is that there is a better more automated way that can integrate with your custom FileMaker solution and save your staff time and your business money.

Chances are if you’re a small business that sells goods or services your customers are going to want to pay by credit card, and having options and making it easy for customers to pay your invoices is a good thing for your business. Once you start accepting credit card payments however you need to comply with the PCI DSS (Payment Card Industry Data Security Standard) to help protect card data and prevent payment data theft. Small businesses are increasingly at risk for payment data theft – nearly half of cyberattacks worldwide in 2015 were against businesses with less than 250 workers according to cybersecurity firm Symantec.

The easiest way to protect against data breaches is to not store card data at all, however that isn’t always practical, especially if you’re selling an ongoing service that requires ongoing payments (e.g. a monthly subscription service). Whilst you definitely should not be storing unencrypted credit card data in your FileMaker solution that any employee can access, you can take advantage of encryption and tokenisation technologies that allow you to store an “alias” or token in your FileMaker solution and use that to processes future charges. Here’s how it works:

  1. customer provides credit card details to pay an Invoice
  2. you send an encrypted HTTPS request to a PCI DSS compliant credit card gateway who store the credit card details (as they are PCI DSS compliant) and send you back a token and a masked version of the credit card number (e.g. 512345…346)
  3. you store this token in your FileMaker transaction record. As this is a token and not a real credit card number it’s completely useless if stolen. You can also store the masked version of the card number in case you need to confirm with the customer which card number you are charging
  4. when you need to process a payment in the future you make another HTTPS request to the credit card gateway requesting a payment and referencing the token
  5. the credit card gateway returns a response indicating whether the transaction was processed successfully or if there was an error (e.g. declined, insufficient funds etc)

This can all be automated in a FileMaker solution allowing staff to process a payment or tokenise a card at the click of a button. We’ve worked with many PCI DSS compliant credit card gateways such as Stripe, eWay, BPOINT and Authorize.Net to help customers automate the process of processing credit card payments securely in their FileMaker solutions. If you’re currently storing credit card numbers in your FileMaker solution and would like to tokenise these we can also help you batch process these.

If you would like to discuss implementing a secure credit card processing system for your FileMaker solution plesae get in touch for a free initial consultation. For more information on how you can protect card data the Payment Card Industry has a number of guides for small businesses, including:

Update: we’ve published a short video demonstrating how you can use FileMaker to tokenise a credit card and then process a transaction by referencing that token.

FileMaker and eCommerce Integration – Part 3

puzzle-1152793_1280

In Part 1 of our series on FileMaker and eCommerce Integration we outlined the challenges many small businesses face when they go live with an online store and the new workflow challenges that can create, leading to the prospect of having to do double data entry in multiple places. In Part 2 we showed how you eliminate any double data entry by making your online store visible to your FileMaker solution by using the ESS (External SQL Data Sources) feature of FileMaker Pro/Server, allowing users to see online orders on a normal FileMaker layout.

Not all FileMaker Pro solutions will be able to take advantage of the ESS feature however for a variety of reasons, including:

  • your online store doesn’t use a supported ESS data source
  • your online store hosting provider doesn’t allow remote SQL access
  • your company firewall won’t allow ESS access to the hosting provider
  • you wish to avoid the expense of purchasing ODBC drivers

There are a number of alternatives to having a “live” view of your online orders using ESS which can be broadly defined as either a push or pull approach, whereby data is either pushed from the online store to your FileMaker solution or pulled/downloaded from your online store by your FileMaker solution. Like all solutions there are pros and cons to each approach and the particulars of how your FileMaker solution is hosted will determine which options are available to you.

In the following examples we’re going to be using the WooCommerce plugin for WordPress as it offers both a push and pull API and is a popular eCommerce store, powering over 37% of all online stores at the time of writing.

Push Online Orders to FileMaker – the push approach is usually considered the most optimal solution as it is only invoked when there is new data to transfer, thus reducing the number of unnecessary requests to the online store to check for new orders. In WooCommerce you implement a push solution through the use of Webhooks – Webhooks are are very common form of server event notifications which trigger an action by sending a request to a URL that you specify. WooCommerce has a number of Webhooks that you can activate, for example each time a new order is created.

We’ve helped many customers over the years implement a Webhook solution that works as follows:

  • a new order is created on the customer’s online store
  • a Webhook is triggered which sends the details of the new order as JSON encoded data to a URL (a PHP page) on the customer’s FileMaker Server
  • the PHP file uses the FileMaker PHP API to convert the JSON encoded data into a new customer record, order record and order line items

The customer also receives an email for each new order, which prompts them to open their FileMaker database and review the order details and ship any required products then push the invoice to their accounting software (Xero, MYOB etc). The customer hasn’t had to do any double data entry or query the online store for new orders – everything is pushed through as it happens. It does require the customer to have FileMaker Server with Custom Web Publishing enabled and allow external access to the PHP file hosted on their server.

Pull Online Orders to FileMaker – if the push approach is not a viable option WooCommerce also offers a REST API that you can also use with FileMaker Pro. The WooCommerce REST API allows you to query your WooCommerce online store and retrieve details about customers, orders, products etc, as well as being able to push data from FileMaker to WooCommerce if necessary. A typical solution using the WooCommerce REST API works as follows:

  • customer receives an email notification from the WooCommerce store about a new order
  • customer then clicks a button in their FileMaker solution to query the online store for any new orders since a timestamp (typically the last time they checked for new orders)
  • FileMaker sends a REST API request for any new order details and receives a JSON encoded response from the WooCommerce REST API with details about each order
  • the response is parsed out to create new customer, order and order item records

Once again the customer has been able to eliminate any double data entry and simply has to click a button in FileMaker to get all the new order details.

As we have illustrated in this series there are typically a number of options available when it comes to integrating your online store with your FileMaker CRM, whether that’s a direct live view using ESS or having new orders pushed or pulled into your FileMaker solution. With an integration into your accounting software such as Xero, MYOB AccountRight or MYOB Essentials you can completely eliminate any double data entry for the entire order and sit back and watch as the data flows from your online store to FileMaker and then to your accounting software.

If you would like to discuss integrating your online store with your FileMaker CRM please get in touch for a free initial consultation.


FileMaker and eCommerce Integration – Part 1

FileMaker and eCommerce Integration – Part 2

FileMaker and eCommerce Integration – Part 3

FileMaker and eCommerce Integration – Part 2

shopping-cart-3-1546160-1280x960

In Part 1 of our series on FileMaker and eCommerce integration we outlined the challenges many small businesses face when they go live with an online store and the new workflow challenges that can create, leading to the prospect of having to do double data entry in multiple places.

As a small business ourselves we also experienced this pain when we went live with our own online stores. Our first online store was for our oldest product fmSMS which allows you to send/receive SMS messages from the FileMaker platform – this has always had it’s own dedicated website/domain so it made sense for the store to live on the same site:

http://www.fmsms.com/shop/

A few years ago we also started selling the first of our fmAccounting Link products for the Xero accounting platform and it made sense to sell this via a store on our main Databuzz website:

http://www.databuzz.com.au/shop

So we now currently have 2 online stores located at different domains, but we will eventually merge these together to simplify things. As both stores were built using the WooCommerce plugin for WordPress and hosted with the same web hosting provider, we knew that any integration solution for one of the stores would work for both stores.

For each order that came through the store we need to perform the following actions:

  • check for an existing customer in our company FileMaker CRM and if no match is found create a new Contact record
  • create a new Invoice and associated Invoice Items
  • create a Payment record against the Invoice
  • push a copy of the Invoice to our accounting software (Xero in our case)
  • add the purchaser to a mailing list in MailChimp for future email newsletters/updates

The process starts with an email from the online store letting us know a new order has arrived:

New Customer Order

We would then have to copy and paste all the details into our FileMaker CRM, push the Invoice to Xero using our fmAccounting Link (Xero Edition) integration, then add the customer to the appropriate mailing list in in our MailChimp account. When you’re only dealing with a couple of orders a month you can probably cope with doing things manually, but once you start to get several orders a day you are then impacted by the time it takes to do all of these takes which are also prone to data entry errors. Like us you probably start wondering if there is a better way and can this process be automated.

The good new is that it can and having helped tens of customers in the past overcome similar FileMaker/eCommerce integration challenges so we knew where to start – ESS. ESS is the External SQL Data Sources feature that was first introduced way back with FileMaker Pro v9 and allows you to establish a live two-way connection between FileMaker Pro and the top SQL data sources. ESS originally supported these SQL data sources:

  • Microsoft  SQL Server
  • MySQL
  • Oracle

FileMaker Pro v15 introduced 2 new data sources:

  • IBM DB2
  • PostgreSQL

Most of the popular eCommerce stores are using one of the following backend databases to drive the store:

  • MySQL (used by WordPress/WooCommerce)
  • SQL Server
  • PostgreSQL

These are also supported ESS data sources so you can use the ESS feature to  get your FileMaker CRM talking to your online store. ESS allows you to view your SQL data from within FileMaker – it appears just like normal FileMaker tables. You can create new layouts to view the data, create relationships from your FileMaker tables to your ESS tables, access the SQL data from FileMaker scripts and more (there are some limitations and it does require setting up ODBC drivers – see the Accessing External SQL Data Sources (ESS) Overview and Troubleshooting for more details.

Once you have installed the appropriate ODBC driver and setup the System DSN you can then add an ESS table occurrence to your FileMaker relationships graph, just like you would for your normal FileMaker tables:

ESS Table Occurrences

You will need to have a basic understanding of your external SQL data source structure so you know which tables to add to your FileMaker graph and how they relate – details about WooCommerce can be found here. Once you’ve added your ESS table occurrences you can create new layouts based on each of these and start to view your online store data live in your FileMaker CRM. Here’s some examples showing some of the WooCommerce/WordPress tables that store online order details:

ESS Orders

ESS Orders Meta

ESS Order Items

ESS Order Item Meta

The above screenshots are showing data from 4 of the main tables that are used by WooCommerce to store order details:

  1. posts: this creates a record for each online order. This table is also used to store Product details
  2. postmeta: this stores a number of records related to each order, such as the billing/shipping and currency/tax details
  3. woocommerce_order_items: this stores line item details for each order
  4. woocommerce_order_itemmeta: this stores meta data about each order line item

As you can see by looking at these ESS tables in FileMaker we can see all the data about each order but it is located in at least 4 different tables, making aggregating the details each order so we can easily view the complete order challenging. We could create a number of FileMaker calculation fields to extra details about each order based on the meta_key for Orders and Order Line Items, but that would end up adding a lot of table occurrences and relationships to the graph and create another layout of unnecessary complexity.

There is a better way however that avoids all that unnecessary clutter on the graph – we can use SQL Views to create a more structured view of the SQL data we require. ESS fortunately also supports SQL Views which allow us to create a predefined SQL query that we then add to the relationship graph. We created 2 SQL views for Orders and Order Line Items to gather all the related meta data about each order and order item. When we add these to the graph and view them from a FileMaker layout here’s what we see for Orders:

ESS Orders View

and this for Order Items:

ESS Order Items View

Much better! For each Order we now get 1 record showing all the Order/Customer details, and for each Order Line Item we now get 1 record showing all the details about the Order Line Item, including the Product Price and SKU (the SKU is the same one used in Xero so it’s important that we can pass that through to Xero). We can then create a relationship between these 2 ESS table occurrences to relate an Order to its Order Items by the order_id value:

ESS Relationship

and be able to view a complete WooCommerce online order in FileMaker:

WC ESS Order

We now have a FileMaker layout showing all the details for a single WooCommerce/online order, including Customer Details, Line Item Details and related Product Details. From here’s a simple case of FileMaker scripting to move the data from the ESS tables to the native FileMaker tables (first checking for any existing Customers with the same name) and from there into Xero. We add a button to the Online Order layout to push the online order into out FileMaker CRM which handles all of these tasks, saving us around 15 minutes per online order (we have customers that are getting tens of orders every day so they time savings really start to add up).

If you’re not familiar with ESS it’s important to be aware of the following:

  • you will need to install ODBC drivers
  • if you’re hosting your file with FileMaker Server you can install the ODBC driver once on the FileMaker Server machine for all FileMaker Pro clients to use, which makes deployment a breeze
  • depending on your ESS data source and whether you are on Mac or Windows you may need to purchase the ODBC driver. There’s a full list of compatible ODBC drivers in the FileMaker Knowledge Base
  • you will need to get some documentation that explains how your SQL data source tables are structured so you know which tables to add to the relationship graph
  • when working with ESS tables it’s best to use a “read only” account that won’t let you edit any of the SQL data in case you accidentally edit/delete any of the online order records
  • your company firewall will need to allow access to the ODBC data source port
  • if you’re accessing a MySQL data source you will typically have to setup Remote Access to the MySQL database via your web hosting company (e.g. via cPanel).

In Part 3 of this series we’ll look into the options when you can’t use ESS and how you can still go about integrating your online shop with your FileMaker CRM. In the meantime if you would like to discuss integrating your online store with your FileMaker CRM please contact us.


FileMaker and eCommerce Integration – Part 1

FileMaker and eCommerce Integration – Part 3

Databuzz releases fmAccounting Link (MYOB AccountRight Edition) – Integrate FileMaker Pro and MYOB AccountRight Accounting Software

Sydney, Australia – April 12, 2016 – Databuzz today announced fmAccounting Link (MYOB AccountRight Edition), a FileMaker solution that integrates with the MYOB AccountRight Accounting Software.

fmAccounting Link (MYOB AccountRight Edition) allows you to upload and download data between your FileMaker solution and MYOB AccountRight, the powerful accounting software with business management capabilities that allows you to work off or online. fmAccounting Link (MYOB AccountRight Edition) removes double data entry and human errors saving your company significant time, money and hassle by automating the exchange of data between FileMaker and MYOB AccountRight.

fmAccounting Link (MYOB AccountRight Edition) is completely unlocked allowing you to integrate it into your FileMaker solution. You can copy and paste examples showing you how to authenticate with the MYOB AccountRight API and upload Contacts, Invoices, Payments and more at the click of a button.

fmAccounting Link (MYOB AccountRight Edition) features include:

  • works with FileMaker Pro v12, v13 and v14
  • completely unlocked
  • can be hosted by FileMaker Pro or FileMaker Server
  • works with Macintosh and Windows
  • works with MYOB AccountRight running in the Cloud or on the Desktop (online and offline)
  • works with MYOB AccountRight Live 2013, 2014, 2015 and 2016

“Previous integrations between FileMaker and MYOB AccountRight have involved manual exports and imports of multiple text files or a Windows only ODBC connection,” said Andrew Duncan, Director of Databuzz. “These are now a thing of the past – with fmAccounting Link (MYOB AccountRight Edition) you can push and pull data between FileMaker and MYOB AccountRight at the click of a button.”

fmAccounting Link (MYOB AccountRight Edition) includes examples for the following MYOB AccountRight API endpoints:

  • Company Files: select from all available MYOB AccountRight Company Files that you have access to
  • Contacts: download and upload Contacts (Customers and Suppliers)
  • Invoices: download and upload Invoices (including Invoice line items)
  • Items (Products): download and upload Items (Products price list)
  • Payments: download and upload Payments against an Invoice
  • Employees: download and upload Employees
  • Account Codes: download Account Codes from MYOB AccountRight
  • Tax Codes: download Tax Codes from MYOB AccountRight
  • Categories: download Categories from MYOB AccountRight

Availability, Pricing, and Compatibility

fmAccounting Link is available in a number of licenses: Company, Vertical Solution and Developer. It is available now from the Databuzz website at http://www.databuzz.com.au/fmaccounting-link-myob-accountright-edition/. Company Licenses start at AUD $495.00. fmAccounting Link (MYOB AccountRight Edition) requires FileMaker Pro v12, v13 or v14 and MYOB AccountRight Live 2013, 2014, 2015 or 2016.

Media/Customer Contact:

Andrew Duncan

Phone: +61 418 468 103

sales@databuzz.com.au

http://www.databuzz.com.au

About Databuzz: Databuzz is a long standing member of the FileMaker Business Alliance. We have been developing and deploying FileMaker solutions for clients in Australia and internationally since 1999. Our clients are individuals, small-medium businesses, government agencies and multi-national corporations. Databuzz was founded by Andrew Duncan, a Certified FileMaker 14 Developer. For more information please visit our website at http://www.databuzz.com.au.

###

FileMaker is a trademark of FileMaker, Inc., registered in the U.S. and other countries. All other trademarks are the property of their respective owners.

FileMaker PHP API Layout Tips

Over the past few months we’ve been working on a large FileMaker PHP Project for a client that required a web based interface to their FileMaker solution that worked on smartphones and tablets (both iOS and Android),  as well as the traditional desktops (Mac and Windows). The web interface was for users who were out of the office for large amounts of the week but needed to access the office solution from their car, client meetings or at home.

We’ve done many FileMaker PHP projects since the PHP API was first released in 2007 but this was by far our largest. Having worked closely with the PHP API for many months we’ve picked up a few tips and tricks along the way that we wanted to share, starting with Layouts.

If you’re not familiar with FileMaker’s PHP API the way the API interacts with your database is via FileMaker layouts – if you wish to find, edit, create or delete a record you need to specify the layout to use. Specifying the layout establishes the context for the query. It’s also important to note that everything on the layout is returned when performing a API command such as finding a record – this is why best practise has always been to only included the fields required by the PHP pages. The XML data that is returned by the API is quite verbose so you want to keep this to an absolute minimum as it can have significant performance implications if you don’t optimise your layouts for the API.

The following are some tips that you should be aware of when working with FileMaker Layouts and the PHP API:

Watch out for hidden fields not visible on the layout

In the screenshot below you can see there are only 5 fields on the ‘ContactsDetailsWeb’ layout: Title, First, Last, Initial and Name:

ContactsDetailsWeb

If we use the PHP API to request all the fields on that layout and echo this back to the browser:

$layout = $fm->getLayout('ContactsDetailsWeb');
// Get an associative array with the names of all fields as keys and FileMaker_Field objects as the array values
$layoutFields = $layout->getFields();
echo '<p><pre>'.print_r ($layoutFields).'</pre></p>';

we get the following:

Array(
 [Title] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Title[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [First] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => First[_autoEntered] => 1[_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [Last] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Last[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [Initial] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Initial[_autoEntered] => 1[_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => calculation[_valueList] => [_styleType] => [_maxCharacters] => 0)) [Name] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Name[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => calculation[_valueList] => [_styleType] => [_maxCharacters] => 0)) [Mobile] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Mobile[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [OfficeEmail] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => OfficeEmail[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [OfficePhone] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => OfficePhone[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [Fax] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => Fax[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [PersonalEmail] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => PersonalEmail[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0)) [PersonalPhone] => FileMaker_FieldObject([_impl] => FileMaker_Field_ImplementationObject([_layout] => FileMaker_LayoutObject([_impl] => FileMaker_Layout_ImplementationObject([_fm] => FileMaker_ImplementationObject([V73ee434e] => Array(
 [charset] => UTF - 8[locale] => en[logLevel] => 3[hostspec] => 127.0.0.1[recordClass] => FileMaker_Record[prevalidate] => [database] => ContactsStarterSolution[username] => Admin[password] =>
 ) [Vea4b3413] => [V9a3dcbce] =>) [_name] => ContactsDetailsWeb[_fields] => Array * RECURSION * [_relatedSets] => Array() [_valueLists] => Array() [Vab234ad8] => Array() [_database] => ContactsStarterSolution[_extended] =>)) [_name] => PersonalPhone[_autoEntered] => [_global] => [_maxRepeat] => 1[_validationMask] => 0[_validationRules] => Array() [_result] => text[_type] => normal[_valueList] => [_styleType] => [_maxCharacters] => 0))
 )

As you can see the result is quite verbose and includes some additional fields that you can’t see on the layout: Mobile, OfficeEmail, OfficePhone, Fax, PersonalEmail and PersonalPhone. So how does the PHP API see these fields? Let’s have a look at the same layout in Layout mode:

ContactsDetailsWeb Layout Mode

You can see these fields are hidden off to the right of the layout’s visible boundary and don’t appear in Browse mode using the FileMaker Pro client, but the PHP API sees all fields on the layout including the hidden fields. It’s advisable to not only have PHP specific layouts that contain just the fields you need for the PHP pages but don’t park/hide other fields off the edge of the layout. The PHP API will retrieve them as well and add additional overhead to your queries causing pages to take longer to load.

This only applies to those using FileMaker Pro/Server v12 or above – the ability to set a layout width was introduced in FileMaker Pro v12.

Beware of Layout Folder Names

We encountered an issue that caused quite a few hours of troubleshooting to resolve but seems obvious in hindsight. Here’s a screenshot showing a list of layouts in a FileMaker database:

List of Layouts

We had a PHP page that interacted with the ‘ContactsPHP’ layout – it would find records, edit records, create records etc and had been working fine for weeks without any issues when all of a sudden it stopped working one day. We ran multiple tests, double checked the spelling of the layout names, checked privileges etc but couldn’t understand what had happened.

We used the API to list out all the layouts in the database and echo this back to the browser:

$layout = $fm->getLayout('ContactsDetailsWeb');
$layouts = $fm->listLayouts();
echo '<p><pre>'.print_r ($layouts).'</pre></p>';

This returned the following array showing the ‘ContactsPHP’ layout:

Array(
 [0] => StartupScreen[1] => - [2] => Contacts[3] => ContactDetails[4] => Contacts | iPad[5] => ContactDetails | iPad[6] => Contacts | iPhone[7] => ContactDetails | iPhone[8] => Contacts | Web[9] => ContactDetails | Web[10] => ContactsDetailsWeb[11] => - [12] => Labels[13] => ContactList[14] => - [15] => ContactsPHP[16] => [17] => [18] => [19] => [20] => [21] => [22] => [23] => [24] => [25] =>
 )

Once again we couldn’t spot any issues with the layouts – the ‘ContactsPHP’ layout was amongst the list of layouts returned.

We then decided to rename the layout, update the PHP page and run some tests and it started working again. We renamed it back to ‘ContactsPHP’ and it failed immediately. Finally the penny dropped – we had a layout folder with exactly the same name that appear above the layout in the list of layouts. We tried renaming the layout folder and voila it started working again. It seems that for certain commands having a layout folder with the same name as the layout works fine, but there are times when it will cause the API to fail. We haven’t been able to isolate the specific circumstances yet but the safest approach is to simply avoid having layout folders with the same names as actual layouts entirely – remember that layout folders are special layout types and it appears that the PHP API can still interact with them when they share the same name as actual layouts.

We’ve run a number of tests and have been able to reproduce this many times on a sample file. We’ve found that if you’re checking for a 401 ‘no records found’ error with a find command like this:

if (FileMaker::isError($result)) {
    if ($result->code = 401) {
    $findError = $result->getMessage(). ' (' . $result->code . ')</p>';
    } else {
    $findError = $result->getMessage(). ' (' . $result->code . ')</p>';
    }
}

you will be mislead into thinking there was a real 401 ‘no records found’. If you examine the FileMaker_Error Object you should see it’s returning a 102 error:

[code] => 102

which is “Field is missing” and makes more sense if it’s using the Layout Folder instead of the actual Layout with the same name (we’ve also seen other instances where the API returns a misleading 401 error, such as when the XML returned is too large for the PHP XML  parser to handle – another reason to carefully optimise your PHP layouts). We first noticed this when we had a Layout Folder named ‘Websites’ and another layout used for a PHP find command called ‘WebSites’, but we have been able to reproduce this with other names as well.

Find Commands and the setResultLayout method

As we’ve discussed it’s ideal to optimise your FileMaker layouts used for the PHP API to only have the required fields on the layout necessary for the particular command, such as creating a new record or performing a find. It’s also possible to further optimise your queries to use separate layouts for the find command and the find results. For example you might have a form on your website that allows users to search for contact records by first name and last name only, however the PHP page is using a layout that has 25 fields from the Contacts table as you using the one Contacts layout for all PHP requests. For smaller record sets you can probably get away with this, but if you would like to optimise this further you can create a layout just for the find command with the 2 fields that you can search on and then have a separate layout that is used to display the find results, which might only require 6 fields for first name, last name, company, email, phone and mobile.

A typical PHP API find command that uses the one layout for both the find request and the find results looks like this:

$request = $fm->newFindCommand('ContactsDetailsWeb');
$request->addFindCriterion('FirstName', 'John');
$result = $request->execute();
if (FileMaker::isError($result)) {
    if ($result->code = 401) {
    $findError = 'There are no Records that match that request: '. ' (' . $result->code . ')';
    } else {
    $findError = 'Find Error: '. $result->getMessage(). ' (' . $result->code . ')';
    }
} else {
$records = $result->getRecords();
}

Here we are performing a find command on the ContactsDetailsWeb layout for any records that have a FirstName that equals ‘John’. We are then checking for any errors with the find command – if there are no matching records it will return a 401 error code, otherwise it will return another find error. If there is no error we are then retrieving all the found records.

To modify the find request to also use a different layout for the find results (to reduce the amount of XML data returned by the API by specifying a layout with just the fields required to show the search results) would look like this:

$request = $fm->newFindCommand('ContactsDetailsWeb');
$request->addFindCriterion('FirstName', 'John');
$request->setResultLayout( 'ContactsSearchResults' );
$result = $request->execute();
if (FileMaker::isError($result)) {
    if ($result->code = 401) {
    $findError = 'There are no Records that match that request: '. ' (' . $result->code . ')';
    } else {
    $findError = 'Find Error: '. $result->getMessage(). ' (' . $result->code . ')';
    }
} else {
$records = $result->getRecords();
}

The only difference between the 2 examples is the addition of this line that uses the setResultLayout method :

$request->setResultLayout( 'ContactsSearchResults' );

The setResultLayout method requests that the command’s result be returned in a layout different from the current layout. This certainly helps speed up the display of search results, however it does have one side effect. When you use the setResultLayout method as part of your find command and there are find errors (such as no records found) the API no longer returns a FileMaker_Error Object but instead returns a FileMaker_Result Object. This is a subtle but important difference – it means you can no longer simply trap for any find errors by calling:

if (FileMaker::isError($result)) {

as you will not get a FileMaker_Error Object. You can check for the number of matching records found, e.g.:

$found = $result->getFoundSetCount();

but it is certainly not as neat as simply checking for a FileMaker_Error Object.

I had trouble finding out more information about the setResultLayout method and ended up submitting a bug report with FileMaker Inc. The response they came back with suggests this is a known limitation when using the setResultLayout method. It would be great if this could be addressed in a future release of the PHP API.

(N.B. all references are to FileMaker Pro/FileMaker Server v14 which was the current shipping version at the time this article was written)

Simple FileMaker Server Monitoring

If you’re deploying mission critical FileMaker solutions hosted by FileMaker Server then monitoring the state of your databases and servers is an important part of ensuring everything is running smoothly. Server monitoring is something that’s normally managed by the IT department using dedicated monitoring tools and services to keep an eye on everything, however if you don’t have a dedicated IT department but still need to monitor the uptime of your FileMaker Server databases you will need to implement your own custom monitoring solution.

FileMaker Server has the ability to send email notifications to a nominated email address when errors are logged or when either warnings or errors are logged. However if you’re using web publishing it’s important to note that FileMaker Server sends no email notifications for web publishing errors or warnings. If you need to monitor your web publishing service or would like to do some custom monitoring to check that a particular database is currently hosted then you will need to implement your own monitoring solution.

There’s a number of commercial monitoring services – I’ve used Pingdom and Monitis – which will check for a response from a particular URL and notify you via email/SMS when it encounters an error. You can also tell it what content to expect for a successful result, rather than just relying on a generic HTTP 200 server response. With a bit of PHP code and FileMaker’s PHP API you can quickly setup a custom PHP page to check that the web publishing service is running or that a particular database is currently being hosted, and output a success or error message. You will need to deploy and enable Custom Web Publishing with PHP on your FileMaker Server first, and know where to find the web server root folder on your FileMaker Server machine:

  • on Mac OS X you can find this at /Library/FileMaker Server/HTTPServer/htdocs (or /Library/FileMaker Server/HTTPServer/htdocs/httpsRoot  if you have enabled HTTPS/SSL)
  • on Windows you can find this at [drive]:\Program Files\FileMaker\FileMaker Server\HTTPServer\Conf where [drive] is the drive on which the Web Publishing Engine component of your FileMaker server deployment resides.

Creating the PHP Page:

Using your favourite text editor create a file with the .php extension as follows:

<?php

// Include FileMaker API
require_once ('FileMaker.php');

$fm = new FileMaker();

$fm->setProperty('hostspec', '127.0.0.1'); 

$listDatabases = $fm->listDatabases();

if(FileMaker::isError($listDatabases)) {
 $connectionError = 'Server Error: '. $listDatabases->getMessage(). ' (' . $listDatabases->code . ')';
 echo $connectionError;
} else {
 $connectionError = '';
 echo 'Server Connection Successful';
}

?>

This simply makes a connection to the FileMaker Server (you can change the 127.0.0.1 hostspec address if required) and calls the PHP API listDatabases method – this returns an array of databases that are available with the current server settings and the current user name and password credentials. You will notice that I have not included a FileMaker database Account Name and Password – this will only work when the setting in the FileMaker Server Admin Console List only the databases each user is authorized to access is NOT selected (found under Database Server > Security > File Display Filter).

File Display Filter

We would generally recommend that this is enabled – however this will break our PHP code which will now return an error (401 Unauthorized). We now need to include some account credentials for the database you wish to monitor – I would recommend creating a new Privilege Set/Account in your FileMaker Database just for this purpose with very limited privileges as we won’t be using it to view or create records, but simply to check that the file is being hosted (don’t forget to enable the PHP extended privileges for this Privilege Set).

The PHP code would then look like this (using an Account Name of PHPWeb and Password W3bOnly):

<?php

// Include FileMaker API
require_once ('FileMaker.php');

$fm = new FileMaker();

$fm->setProperty('hostspec', '127.0.0.1'); 
$fm->setProperty('username', 'PHPWeb'); 
$fm->setProperty('password', 'W3bOnly');

$listDatabases = $fm->listDatabases();

if(FileMaker::isError($listDatabases)) {
 $connectionError = 'Server Error: '. $listDatabases->getMessage(). ' (' . $listDatabases->code . ')';
 echo $connectionError;
} else {
 $connectionError = '';
 echo 'Server Connection Successful';
}

?>

If you would like to extend this to check whether a particular database is currently being hosted you can search the array of database names that is returned by the listDatabases method for the presence of a particular file. You can see what the listDatabases array looks like by adding the following line:

echo '<p><pre>'.print_r ($listDatabases).'</pre></p>';

We use the PHP in_array function which checks if a value exists in an array like this:

if (in_array('Contacts', $listDatabases)) {
 echo 'Contacts Database is Live';
} else {
 echo 'Contacts Database is NOT Live';
}

Here I am checking for a database named Contacts – if it is part of the array of databases it will return the string Contacts Database is Live, otherwise it will return Contacts Database is NOT Live.

Here’s the complete PHP code which checks for the individual database name:

<?php

// Include FileMaker API
require_once ('FileMaker.php');

$fm = new FileMaker();

$fm->setProperty('hostspec', '127.0.0.1'); 
$fm->setProperty('username', 'PHPWeb'); 
$fm->setProperty('password', 'W3bOnly');

$listDatabases = $fm->listDatabases();

if(FileMaker::isError($listDatabases)) {
 $connectionError = 'Server Error: '. $listDatabases->getMessage(). ' (' . $listDatabases->code . ')';
 echo $connectionError;
} else {
 $connectionError = '';
 //echo '<p><pre>'.print_r ($listDatabases).'</pre></p>';
 //echo 'Server Connection Successful';
 
 if (in_array('Contacts', $listDatabases)) {
 echo 'Contacts Database is Live';
 } else {
 echo 'Contacts Database is NOT Live';
 }
 
}

?>

N.F. If the Web Publishing Engine is not running on your FileMaker Server deployment you will get a 503 Service Unavailable error.

You can get more information about Custom Web Publishing with PHP from the FileMaker Server 14 Custom Web Publishing Guide.

FileMaker Commercial Hosting Changes

FileMaker Inc. have recently released an updated version of the FileMaker Commercial Hosting FAQ. FileMaker Commercial Hosting involves the provision of FileMaker Server from a data centre via the Internet, typically on a rental or subscription basis. There are many FileMaker Commercial Hosting providers around the world that provide an alternative to deploying FileMaker Server within your organisation. FileMaker Commercial Hosting is currently supported with the current version of FileMaker Server – v14 – on the Volume License Agreement (VLA) and Annual Volume License Agreement (AVLA) license programs (as well as the Solution Bundle Agreement (SBA) for vertical solutions).

FileMaker Inc. have announced that they will be changing the FileMaker Server End User License Agreement (EULA) to require commercial hosting providers to acquire a dedicated license for each customer. This means that commercial hosting providers will no longer be able to offer a “shared server” hosting option where multiple customers database files are stored on the same FileMaker Server for future versions of FileMaker Server.

The can read the full FileMaker Commercial Hosting FAQ here. For further details on performance management best practices on the FileMaker platform click here.

Working with FileMaker Server and plug-ins

At Databuzz we use plug-ins in many solutions that we develop – the BaseElements Plug-in plug-in has become a standard feature of most solutions we deploy (if you also use the BaseElements plug-in you should sponsor the plug-in). One of my favourite features of FileMaker Server 12 was the ability to be able to have a server side script schedule install and/or update a plug-in.

If you login to your FileMaker Server using the FileMaker Server Admin Console application and navigate to the Database Server > Server Plug-Ins tab (for FileMaker Server v12 you’ll find this under FileMaker Server Overview>Configuration>Database Server) you will see 2 options which are disabled by default:

  • Enable FileMaker Script Engine (FMSE) to use plug-ins
  • Allow Install Plug-In File script step to update Server plug-ins

If you’re going to be working with server side script schedules that use plug-ins you will need to enable both of these. If you attempted to install/update a plug-in using a server side script schedule and the Allow Install Plug-In File script step to update Server plug-ins was disabled you would get this error:

This plug-in could not be updated automatically. Error 3 (Command is unavailable (for example, wrong operating system, wrong mode, etc.))

Once you enable the Allow Install Plug-In File script step to update Server plug-ins option you will be able to install plug-ins successfully via a server side script schedule, however you might not think it is working at first. Plug-ins get saved to the following directories:

  • Windows: [drive]:\Program Files\FileMaker\FileMaker Server\Database Server\Extensions\
  • Mac OS: /Library/FileMaker Server/Database Server/Extensions/

Here’s a screenshot showing the contents of my Extensions folder:

Screen Shot 2015-06-10 at 9.10.43 am

You’ll notice there are 2 plug-ins installed: the BaseElements plug-in and the SMTPit Pro plug-in. However looking at the list of installed plug-ins in the Admin Console only shows the SMTPit Pro plug-in:

Screen Shot 2015-06-10 at 9.10.02 am

 

Even though the BaseElements plug-in does not appear in the list it is installed and loaded, as I can perform server side script schedules that use the plug-in successfully. The only way I’ve found to update the list is to restart the server machine – logging out and back in to the Admin Console and restarting the Database Server do not appear to update the list of plug-ins in my experience.

If you look at the Log Viewer after restarting the Database Server you will only see log entries for the plug-ins that are visible in the Admin Console as well:

Jun 10, 2015 8:59:25 AM Server Events Information 476 Plug-in enabled: SMTPit Pro SE

I’ve experienced this on both Mac and Windows servers with Server v12, 13 and 14. Once you restart the server machine the list of plug-ins will then be updated, but this can be a bit disconcerting the first time you use server side schedules to install/update plug-ins and don’t see any evidence of them in the Admin Console.

 

Installing 32-bit and 64-bit plug-ins in FileMaker Pro v14

The recently released FileMaker Pro v14 is the first version of FileMaker Pro that can be installed and run as either a 32-bit application or a 64-bit application – on Windows you have to choose which version to install, and on OS X FileMaker Pro is installed as a single application bundle containing both 64- and 32-bit versions (you can choose which version to run via the Get Info window).

When using the 64-bit FileMaker Pro application you will need to ensure that any plug-ins you install are the 64-bit versions – 32-bit plug-ins won’t load with the 64-bit FileMaker Pro application. The same applies to the 32-bit FileMaker Pro application – it will only load 32-bit plug-ins.

How do you check which version of FileMaker Pro v14 is installed in order to install the appropriate version of the plug-in? FileMaker have added a new function to v14 for just this purpose – Get ( ApplicationArchitecture ). This function will return the following depending on the platform:

  • i386 for the 32-bit version of FileMaker Pro
  • x86_64 for the 64-bit version of FileMaker Pro, FileMaker Server, FileMaker WebDirect, and Custom Web Publishing
  • arm7 for FileMaker Go running on an ARMv7-based device
  • arm7s for FileMaker Go running on an ARMv7s-based device
  • arm64 for FileMaker Go running on a 64-bit ARM-based device

As plug-ins are only supported by FileMaker Pro and FileMaker Server you can ignore the FileMaker Go options. To install a plug-in for the appropriate version/architecture/platform you can write a script that incorporates the following:

  1. use the Get (ApplicationVersion) function to determine whether you are running under FileMaker Pro/Pro Advanced, FileMaker Server or the Web Publishing Engine
  2. also use the the Get (ApplicationVersion) function to determine the version of the FileMaker client you are running
  3. if the client is FileMaker Pro/Pro Advanced and the version is less than 14 you can simply install the 32-bit version of the plug-in using the Install Plug-In File script step – you can check the installed version using the Get(InstalledFMPlugins) function
  4. if the client is FileMaker Pro/Pro Advanced and the version 14 or higher you can use the Get ( ApplicationArchitecture ) function to determine is it is a 32-bit or 64-bit installation and then use the Install Plug-In File script step to install the appropriate version
  5. if the client is FileMaker Server and the version is 13 or higher you will need to install the 64-bit version of the plug-in. For FileMaker Server v12 you need to install the 32-bit version of the plug-in. Remember to check the options in the FileMaker Server Admin Console under the Database Server > Server Plug-Ins tab to enable FileMaker Server to use plug-ins and update them via the Install Plug-In File script step.

Plug-in vendors will typically supply 3 versions of each plug-in:

  1. the Mac OS X version of the plug-in – this is a single binary plug-in (file extension .fmplugin) containing both the 32-bit and 64-bit versions of the plug-in
  2. a Windows 32-bit plug-in (file extension .fmx)
  3. a Windows 64-bit plug-in (file extension .fmx64)

You can store each of these plug-in files in separate container fields to be referenced by the Install Plug-In File script step, once you have branched for your FileMaker client, version and architecture.

If you’re using plug-ins with FileMaker Server’s Web Publishing Engine you’ll need to install these manually on your server – see the FileMaker Server Help guide for details on where to install these (the Custom Web Publishing Engine has been a 64-bit process since FileMaker Server v12.0v2).

This FileMake Knowledge Base article has more information about FileMaker Pro v14 and 64-bit operating systems – FileMaker Pro/Advanced and Windows 64 bit operating systems.

Creating Panic Status Boards using FileMaker Server

As long time users of Panic applications we were very interested when they released Status Board earlier this year. Status Board is an iPad app designed to help you display your data. You can view the data on the iPad using the app, but where it gets interesting is the in-app purchase that lets you connect it a giant display screen/TV with HDMI out.

The app has some great standard display panels:

  • Clock — Analog or digital, anywhere in the world.
  • Weather — Temperature and four-day forecast.
  • Calendar — Pick a calendar and see your appointments at a glance.
  • Mail — Get messages counts, or see the latest Subject lines.
  • Twitter — See the latest Tweets or the volume of tweets.
  • Feeds — The latest headlines from your favorite sites

and also 3 Pro panels that let you customise your own content to display:

  • Graph — You provide the JSON or CSV data source, we make it beautiful.
  • Table — Toss us some HTML or CSV data and we’ll make a nice looking table.
  • Do-It-Yourself — Design your own panels using HTML

It’s these 3 Pro panels that let you display data directly from your FileMaker Pro databases hosted on FileMaker Server. We’ve used the FileMaker API for PHP to query hosted databases, return the result and then format the data into the required format. Here’s an example we did for a real estate client:

FileMaker Status Board

FileMaker Status Board

This Status Board is displayed on a TV in their office that all staff can and is updated every 5 minutes automatically. It allows sales staff to quickly see how they are tracking in terms of number of property listings for the month and sales for the month. They can also view historical data for the last 6 months. It includes a table of their current properties for sale – we’re only showing 4 at any one time but the table scrolls automatically on the external display. We even included some green/red icons for the admin staff to quickly see the status of their FileMaker Server and Web Servers so they can tell if there’s any issues.

If you have any questions about integrating your FileMaker data into a custom Status Board please contact us.