As y’all probably know by now, FileMaker 17 has been released, including the first production edition of FileMaker Server’s Data API. This API was originally released with FileMaker 16, but only as a “beta”, expiring September 2018. As you might expect, the FileMaker 17 Data API introduces significant changes. This means that any applications written against the FM 16 Data API need to be refactored for compatibility with FileMaker 17. And that’s the work we’re here to do!

With everything that we’ve learned with our last post, Communicating with a Web Viewer in FileMaker, it makes sense to wrap up the functionality into a FileMaker module and JavaScript library.

If you’ve been working with FileMaker, then I don’t have to sell you on the fact that it’s a great solution to help you manage your data. Whether you’re an in-house developer, a consultant, or just starting to explore what is possible with this powerful platform, you will at some point come across the need to build in some kind of dashboard. Maybe your group needs to see sales trends for the last year or perhaps you have a system that tracks projects and want to see the daily average of tasks completed. In either case, dashboards are a great way to synthesize large amounts of information and provide you with insight in a simple and informative visual design.

We recently built an application that included PDF document management. While it might seem as simple as a quick FileMaker container field, we wanted to impress our client with an integrated solution on par with a content management system (CMS). Here’s how we built a powerful PDF viewer directly into FileMaker.

Using a combination of AngularJS, HTML5, CSS, WKHTMLTOPDF, PDFtk, bBox and FileMaker scripting, we can create PDF reports from a FileMaker solution, taking advantage of the design and development flexibility afforded by using JavaScript and web tools to accomplish the task.

JSON doesn’t parse easily with FileMaker’s text handling functions. And using a Web Viewer has complications, the main one being getting data in and out. Some other solutions only parse JSON, but don’t encode it. Here's yet another way, using the bBox plugin with Python.

As y’all probably know by now, FileMaker 17 has been released, including the first production edition of FileMaker Server’s Data API. This API was originally released with FileMaker 16, but only as a “beta”, expiring September 2018. As you might expect, the FileMaker 17 Data API introduces significant changes. This means that any applications written against the FM 16 Data API need to be refactored for compatibility with FileMaker 17. And that’s the work we’re here to do!

I’m always excited each time the FileMaker Platform gets new capabilities. It isn’t just the new features on their own that make things interesting, but what happens to the platform as a whole which provides for some interesting and inspiring innovations. In this case, it is a new way to do transactional record editing in FileMaker. This is the first in a multi-part series on this topic.

In 2017, we released several new versions of bBox plugin. In the spirit of yearly retrospective, let’s highlight perhaps the most exciting new bBox feature: JavaScript for FileMaker. The new JavaScript for FileMaker functions in bBox are great for heavy duty JSON processing tasks, repurposing JavaScript code for use in FileMaker, or other computation intensive processing. Here’s a recap…

We recently built an application that included PDF document management. While it might seem as simple as a quick FileMaker container field, we wanted to impress our client with an integrated solution on par with a content management system (CMS). Here’s how we built a powerful PDF viewer directly into FileMaker.

There’s a new hero in the world of web applications, services, and microservices: Server-Side Swift is making serious waves across the industry. At Beezwax, it’s changing how we approach and solve many typical, long-standing coding challenges.

Using a combination of AngularJS, HTML5, CSS, WKHTMLTOPDF, PDFtk, bBox and FileMaker scripting, we can create PDF reports from a FileMaker solution, taking advantage of the design and development flexibility afforded by using JavaScript and web tools to accomplish the task.

I needed to set up some monitoring for FileMaker Server that made moderately heavy use of the XML interface for Custom Web Publishing (CWP). The server was mostly working well, but was due for a rebuild, or at the least, an upgrade, but the client wanted to squeeze out one more season before we did this.

Since FileMaker Server version 13, FMS has used its own Apache configuration files on macOS instead of just adding includes to the OS configuration files. Because of this, the technique I mentioned here no longer works for newer systems. This new arrangement has reduced issues for FileMaker Server’s web connectivity. But updates or other changes can still cause the httpd process to fail to start up, and all you’ll see is something like this in the system log:

Now more than ever we’re relying on Perform Script on Server (PSoS) to maximize FileMaker performance, so naturally a need arose for a way to proactively monitor how many concurrent scripts are being triggered. This type of logging helps us see if we’re reaching our maximum limit, or have a rogue script eating up processing power.

If you’ve been working with FileMaker, then I don’t have to sell you on the fact that it’s a great solution to help you manage your data. Whether you’re an in-house developer, a consultant, or just starting to explore what is possible with this powerful platform, you will at some point come across the need to build in some kind of dashboard. Maybe your group needs to see sales trends for the last year or perhaps you have a system that tracks projects and want to see the daily average of tasks completed. In either case, dashboards are a great way to synthesize large amounts of information and provide you with insight in a simple and informative visual design.

We recently built an application that included PDF document management. While it might seem as simple as a quick FileMaker container field, we wanted to impress our client with an integrated solution on par with a content management system (CMS). Here’s how we built a powerful PDF viewer directly into FileMaker.

FileMaker 17’s new master-detail layouts display the list of records in the user’s found set. As the user performs finds, constrains, omits, sorts, or creates or deletes records, the master-detail portal will update to stay in sync. Imagine a portal that a user can sort any way they like, filter any way they like, and click a row to see details for that row, all right out of the box. That’s the power of the master-detail portal.

A few years ago, I worked on a FileMaker project where the client told us that every week they need to import about 7,000 rows of data that represent some information that this company uses. And every week there might be some modified records, some records that don’t show up any longer, and some new records that hadn’t already existed. For this example, let’s just call it this data “Products”.
Over the years that weekly information grew to about 12,000 records per week. This PRODUCT table itself had 35 fields of data. So, without a way to manage the duplicates, every week lots of redundant data would need to be imported.

If you’ve developed solutions with FileMaker for any length of time, you’ve almost certainly created files using FileMaker’s native Excel exports. Although quite useful, this feature gives almost no control over the formatting, and definitely no way to set formulas, charts, or even text formatting.

Now that FileMaker 17 has officially been released and along with it the Data API is out of beta and is a version 1.0. There is so much to talk about what now becomes possible with FileMaker and other services/applications, starting with Tableau.

Now that the FileMaker Data API has been officially released (with FileMaker 17), it is time to share an update on Tableau-to-FileMaker integration. I originally wrote about integrating Tableau and FileMaker to create a match made in data heaven. I’ll also be speaking on “FileMaker + Tableau” at FileMaker DevCon 2018.

JSON doesn’t parse easily with FileMaker’s text handling functions. And using a Web Viewer has complications, the main one being getting data in and out. Some other solutions only parse JSON, but don’t encode it. Here's yet another way, using the bBox plugin with Python.

With everything that we’ve learned with our last post, Communicating with a Web Viewer in FileMaker, it makes sense to wrap up the functionality into a FileMaker module and JavaScript library.

When the Web Viewer was introduced in FileMaker, it was designed to display websites such as a Google Maps which included the address of the current record.  It accomplished this by inserting record data into the url as an HTTP GET request. However, it didn’t take long for developers to take advantage of html’s data URI syntax to insert html directly into the Web Address box.

You gotta love FileMaker Go. Go’s ability to effortlessly create data-driven mobile apps and extend existing desktop data applications to mobile users is transformative. But sooner or later, almost all of us run up against one of Go’s core limitations: its lack of native plugins.

If you are having difficulty getting your HTML, CSS, or JavaScript to render in a FileMaker Web Viewer, you may have a struggle ahead of you trying to find the problem, and no good way to debug it. In comparison, most web browsers have debug facilities that can help developers find problems in their code.

Using a combination of AngularJS, HTML5, CSS, WKHTMLTOPDF, PDFtk, bBox and FileMaker scripting, we can create PDF reports from a FileMaker solution, taking advantage of the design and development flexibility afforded by using JavaScript and web tools to accomplish the task.