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.

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.

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.

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.

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…

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.

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.

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:

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.

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.

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.