As Claris gets further into an Agile groove, there are product releases more often, always with new features and improvements. Claris FileMaker 19.5 is no exception. It includes many new features, expanded extensibility, performance enhancements, and reliability improvements. I want to bring attention to one simple thing that promises to change the world for many of us in the FileMaker developer community: Save a Copy as XML…and the performance improvements running this on FileMaker Server.
Use Advanced Tools
Before we review this feature, I want to make sure you can access Save a Copy as XML by enabling advanced tools in FileMaker. If FileMaker Pro is running and you see a menu called Tools, then you are all set.
If you don’t see the Tools menu, then you need to follow these steps:
- On a Mac choose File –> Preferences…
- Or, on Windows, choose Edit –> Preferences….
- With this dialog open, check the option “Use advanced tools”.
- Then click OK and restart FileMaker Pro.
“Use advanced tools” is just a checkbox away, accessible to all in FileMaker Pro 19.x.
Now if you navigate over to the Tools menu, you should see Save a Copy as XML….
In FileMaker 19.5, a newfound ability of Save a Copy as XML allows it to run on FileMaker Server (it is server-compatible), and this is a VERY BIG DEAL! It will lead to innovative uses of this output by the Claris developer community at large. Combining this feature with FileMaker Server automation, scripting and Admin tools will allow this data to be automated and scheduled at regular intervals.
Welcome To The Metadata-Verse
But I am getting ahead of myself. Some of you might be new to this realm of metadata, not realizing that FileMaker solutions could represent themselves as XML. This goes beyond being an easy-to-use database and low-code app builder.
There are actually 2 outputs, living side-by-side. The menu item just below the “Save a Copy as XML…” is called “Database Design Report,” or better referred to as the “DDR”. And it has been around for a very long time. What is it? Well the DDR is the representation, in XML, of the whole structure of metadata for your solution (or almost the whole structure, as there are a few spots the DDR still misses.).
Here is a sample snippet of the XML representing a field.
Again this is from Database Design Report output – maybe another way to describe it is the legacy “DDR 1.0”.
And you might be thinking “Why would I need or want to use this?”. Well, the DDR gives you a basic summary of your metadata. And there are tools out there like InspectorPro, FMPerception, FM Version, or BaseElements that can ingest this information, analyze it and give you insights about your solution:
- detecting problems in the code
- identifying dependencies and references
- comparing differences between versions
- searching through tables and fieldnames and scripts
- collaborating with development teams.
Once you have built a FileMaker solution of modest complexity, you’ll need something to help you see your code in augmented ways that are not realized directly within FileMaker Pro itself.
DDR 2.0
So, stepping forward into the world of “DDR 2.0”, or rather what Save a Copy as XML on FileMaker Server promises to deliver.
Note: This post isn’t meant as a comprehensive review of the differences between DDR 1.0 and DDR 2.0; that will be for another time. This post is to point out one small change that will have a dramatic impact on those of us who consume this data on a day to day basis.
FileMaker Server – Save A Copy as XML
The ability to have the XML generated on FileMaker Server allows for the automation and scheduling, and can save developers many, many hours of time.
Let’s look at a scenario…
Let’s say, you have a file hosted on your Development server, and you and your team are doing daily work on this solution. And you have gotten into the habit of generating an XML Database Design Report (DDR) regularly during the development each day.
We looked at a modest-sized solution that generates an XML file, approximately 73 MB in size. If you run this process via FileMaker Server it takes about 3.6 seconds to generate. However if you run it locally via FileMaker Pro (even if the file itself is hosted on FileMaker Server), then it takes around 9 minutes. That is a huge difference in time. To put things in perspective, imagine the little red square is the 3.6 seconds vs the full yellow circle, which is the 9 minutes.
Now if we can output a whole XML DDR in 3.6 seconds, we might be inclined to do this more frequently through our work day. So, let’s assume that we would do just that in both cases. Let’s say the development team outputs a DDR 3-5 times per day during their regular work week. Let’s say in a year they will have done this 1,000 times. For the 3.6 seconds it will have required one whole hour of waiting time… per year. Whereas at 9 minutes per DDR, it will have gobbled up 6.25 full days of time, just waiting for the XML / DDR to be generated.
Running this much faster, via FileMaker Server, is going to save so much time for so many developers. Now, what will you do with all that extra time? That is the question. Write better code and for sure find a way to automate the generation and processing of this XML.
The Future Looks Bright
Save a Copy as XML on FileMaker Server is all very exciting. However, perhaps like the metaverse, Save a Copy as XML itself is still a work in progress. There are still things needing to be worked out to enable an accurate and complete “DDR 2.0”. However, finally when those enhancements and fixes are done, it will only feel like a blip in time, and we’ll be transformed into developer superheroes.