Context
FSAL is the recommended browser‑less runtime for Forms 12c/14c, but enterprise teams still need a reliable way to provision, configure, and keep client‑side artifacts (launchers, config, JRE) in sync at scale.
The approach below standardizes zero‑touch onboarding from an Nginx bundle and an application‑triggered, versioned self‑update that runs asynchronously at startup, without blocking users.
What this solution does
- Zero‑touch Windows onboarding: download a FSAL bundle from Nginx, extract, write the server configuration, add per‑user proxy exceptions, create desktop shortcuts for .bat launchers, and optionally install TTF fonts, all non‑interactively.
Async self‑update at launch: a startup component pulls an update ZIP using conditional requests (If‑None‑Match/If‑Modified‑Since), unzips securely to a staging folder, and atomically syncs only the required artifacts into C:\fsal, with a file lock to avoid races.
Install flow (install_fsal.bat)
- Flexible parameters: server URL, install path, which shortcuts to create, and a disk‑space check, then scripted downloads of 7za.exe and fsal‑install.zip from a /utils path on the content server for unattended extraction.
Environment preparation: generate server.conf from the host, update HKCU proxy exceptions additively, create desktop shortcuts for all or selected .bat launchers, and copy TTF fonts when allowed by policy, keeping everything under the chosen install directory.
Self‑update flow (BootBean)
- Safety and idempotence: exclusive file lock in .update, ETag/Last‑Modified caching, isolated staging under C:\fsal.update, path‑traversal‑safe unzip, and exclusion of internal folders from the final copy step.
Performance and resilience: background daemon thread so the UI never blocks, minimal logging, and a cleanup of stale local RDF reports to avoid noise during upgrades.
Optional “6i successor” path
- The installer can leverage the existing FMX 6i client update channel to deliver the FSAL client, ensuring a smooth succession while the legacy update mechanism remains active at some sites, easing the transition from client/server to FSAL.
Governance and compatibility notes
- FSAL launchers are version‑specific and must match the server’s Forms version and patch level; keeping frmsal.jar and the Java runtime pinned and updated together on the client is essential for supportability and security.
- Favor per‑user installs and per‑process Java proxy settings where possible, serve artifacts over TLS, verify checksums/ETags, and avoid logging secrets to align with FSAL security guidance and general desktop deployment best practices.
Questions for the community
- What scope of client updates have proven most reliable in practice (launchers, config, JRE), and how did endpoint security tools react to self‑updating FSAL clients ?