TonyWhite

What is the best architecture for FileMaker system files?

Discussion created by TonyWhite on Feb 6, 2019
Latest reply on Feb 6, 2019 by dfmorgan

What is the best architecture for FileMaker system files?

FileMaker system files are often used for features that include:

  1. Storing global resources
  2. Tracking session logins and running OnFirstWindowOpen routines
  3. Deploying plug-ins
  4. Providing a central navigation hub
  5. Providing a dashboard that displays Key Primary Indicators (KPIs)
  6. Serving as a repository of script functions and REST’ful integrations


First some background...

Over the years we have developed a number of multi-file solutions.
Prior to FileMaker 7 we used one File per BaseTable (because that was the only option).
When FileMaker 7 shipped, we starting building solution with FileMaker Files that sometime had more then 1 BaseTable in them. 

There were lots of reasons to have more than one BaseTable per file:

  • Share hosting cost less...as it was usually billed at a per file basis (and permitted under the FileMaker Server End User License agreement).
  • Single file solution are often faster to develop...for a variety of reasons


On the other hand, there are reasons to use multiple Files:

  • Large tables, for example, image tables with embedded thumbnails are often best kept in a dedicated file (to optimize backups).
  • Managing FileMaker Windowing seems to often be easier in a multi-file solution
  • Privilege sets are sometimes easier to manage with more FileMaker Files (assuming you have a good multi-file password management system in place)


How many FileMaker files should we have in systems that we work on today? Here are 2 things to consider...

  • The FileMaker Server 15 End User License Agreement (EULA) does NOT allow shared hosting.
  • A FileMaker server can host as many as 125 files, enough for the majority of customers.


In recent years, we have been splitting code into more files than we used to.

In the pre FileMaker Server 15 days we would tend towards a monolithic MainMenu/Home/Dashboard file that would serve multiple functions (repeated from above):

  1. Store global resources
  2. Track session logins
  3. Deploy plugins
  4. Provide central navigation
  5. Serve as a repository of script functions and REST’ful integrations


This all works reasonably well in a multi-file solution...the other files in the solution only require a single External Data Sources and a single table occurrence on the Relationship Graph to access all this functionality.

On the other hand, there are advantage to splitting these functions out:
1) A dedicated file containing global fields (build from scratch) would be:

  • Easier to optimize (as you more easily could dehost it so that the globals are “set before hosting”)
  • Easier to drop into a new or existing solution as it would have consistent sequential field IDs...a good thing if you are deplying to multiple solutions
  • If the file is 100% globals...record locking should not be a concern


2) Tracking session logins might be done better in a dedicated file with customized security

3) A separate file for deploying plug-ins would be useful as it would be:

  • Easier to drop in for those that need it
  • Easier to exclude for those customer that manage there deployments through ARD, JAMF, or other similar tools


4) Central navigation is a feature that could fit into almost any FileMaker system file (as it does not require much more than scripts and buttons that call them)

5) There are a few cases where it would be useful to have script functions in a separate file 

  • for better windowing


Here are some other possible types of dedicated FileMaker files that a system might include 

  • Image/Container
  • DataChangeLog
  • Picker
  • Mobile Light user interface
  • Help Request
  • Account and password management (kept separate for security reason)
  • Logic (to handle actions that are best done without a user interface)
  • Transactions (to manage transactions)


This is all in addition to files that are kept separate because:

  • They are utility files
  • Files that are part of large systems that are intentional split by functional area


Sounds great. I think that I want more files than ever before...

Wait, what is the cost of more External Data Sources and more Table Occurrences?
Is is more efficient or less efficient?

One of the questions at the engineering panel at DevCon 2018 was about the factors that affect the performance of the FileMaker Relationship Graph in a file as well as accross a multi-file solution.

The decision of how many files to have in a FileMaker system brings up many of the same questions.

Thoughts?

 

Tony White

[edit 1 - removed trailing white space]

Outcomes