1.

System Architecture (old)

TEAM
Tobias Sjögren @Tobias S

PROJECT NAME
“FM Duo” - a temporary name until finding the right one to use…

MANIFEST
I shall develop both general and complete products (as well as custom apps), with
FileMaker - with as much modular design and reduced redundancy as possible,
where the modules can be updated and distributed independently and easily -
resulting in increased quality, easier maintenance, lower prices and less support.

SYSTEM ARCHITECTURE
The goal and the basis for the text below, is to have one single root database for all
products. However it could be that one root database per product is used.

Product
A product is a general system consisting of one root database and one or more
modules - to be used by multiple customers through licensing and/or subscription. A
product is defined by what parts of the full root database and which modules it is
using.

Root database
The root database is the hub to which all modules are connected. It uses the
modules and its functionality in whatever way it wants. All layouts are in the
UI/Logic file of the root database.
File Content

Data file no user’s data

no functionality/logic/scripts, relationships, global fields
 product setup (choice of modules/functions) and
users/privileges.

UI & Logic user interface, layouts

file functionality, scripts
no persistent data - only temporary data (in global fields)
limited functionality, logic/scripts - only what is required for the
UI to work
provides default values through scripting, e.g. timestamps, 0/1

Modules
A module is a self-contained unit with some specific functionality, used by a root
database (modules cannot be used by other modules or in stand-alone mode).
Modules can be used by multiple products in parallel - unmodified. Modules should
be well defined, complete each other, with zero overlap.

Each module consists of two separate FileMaker files where user’s data is separated
from logic. There is no UI file since the Root UI file has all the UI.
File Content

Data file tables with user’s data

no scripts (with some exceptions…)
no custom functions (with some exceptions…)
no relationships
no global fields
no layouts
no calculations fields ?

Logic file tables with predefined system data

scripts, the ones
no layouts
no relationships

ID’s
Every module is associated with an ID:
ID Module

11 CONTACT
 12 EVENT

13 ECONOMY

14 STATUS

15 PROJECT

Core Logic
The Core Logic FileMaker file handles database transactions and contains generic
functions - and is used over all products, all root databases and all modules as a
shared repository of scripts and logic. As soon as a script could be used by more
than one module, the script should be in Core Logic instead of in a module.

More info: +CORE LOGIC - specification

Data categories
Category Storage location Note

System data ui/logic files both persistent and temporary

“local file” data

User data modules data files both persistent and temporary

data

Data classes
Class Location Note

Persistent data data files data stored on disk

logic/ui files that survives user
logout

Temporary data logic/ui files disappears at user

not in data files logout
often in global fields

Levels & Scope

The system in its entirety has four levels, each one with different scope. See also
HERE.
Level Scope Represented Description
by

1 overall Core Logic file every product and all its

installations and all its users

2 product/overall Root UI file list of defined products (selection of

? modules and functions)

3 installation Root data file selected product and its

configurations

4 user Root data file all users (table USER)

Principles
Reduce redundancy everywhere as much as possible
Code once and use everywhere
”Separation of concerns”
Separate components from each other
root database from modules
module from other modules
data from UI from logic
functionality from specification
Configuration over customization
Restrict calls to server to the greatest extent possible
Use soft coding - no hard coding
Use normalization
Use de-normalization when needed
Use database transactions
Use supertype and subtype structures with broad tables where field "type" is
used to separate different types of records
Reduce record locking time
Use Localization system
Use an audit log and undo/rollback system
REQUIREMENTS
Internet connection
FileMaker Server 17 or later or FileMaker Cloud
FileMaker Pro Advanced 17 or later
FileMaker Go 17 or later

DEVELOPMENT TOOLS
FileMaker
Why FileMaker?
because (pros):
Single tool for building both user interface front-end and data storage back-end
Minimal programming to create GUI
Integrated programming environment
Built-in support for
importing and exporting Excel
exporting PDFs
reporting and charting tools
accessing external datasources
Reduced development time
Mobile-friendly, FileMaker Go (iOS)
 can input from camera, microphone and multiple sensors
Can be used as stand-alone without server

despite (cons):
Commercial → Licensing costs
More closed system 
Not full web browser compatibility
Lack of scalability
Lack of centralized security module for multiple files

Version compatibility
FILEMAKER MINIMUM NOTE
PRODUCT VERSION

Server v16 ? use ?

 Cloud use ?

Pro v16 or 17 ? *

WebDirect adapt for ?

Go v16 or 17 ? *
* v17 is needed for Master Detail-portals, v16 is needed for Card windows

MySQL
Why MySQL?
because (pros):

despite (cons):