Deployment

After local validation, move the same tested workflow scripts, properties, and semantic rules into the corresponding FireSonic runtime directories. Treat deployment as a controlled promotion of a known-good integration generation rather than as an ad-hoc file copy.

Deployment workflow

1. Run automated tests and representative HL7 messages locally with the SDK.
2. Verify generated FHIR Bundles and expected semantic-validation results.
3. Optionally verify the integration against an isolated development FHIR server.
4. Commit and tag the tested scripts and semantic rules in source control.
5. Copy workflow .groovy files and script.properties to the runtime scripts directory.
6. Copy semantic-rule .groovy files to the configured semantic-rules directory.
7. Activate the new generation by FireSonic restart, or by hot reload when enabled.
8. Verify the active generation through startup/hot-reload logs and the Administration Console.

Runtime file layout

A typical project can be promoted into FireSonic with a directory structure such as:

scripts/
├─ Main.groovy
├─ core/
│  ├─ merge/
│  │  └─ PatientMergeWorkflow.groovy
│  └─ transfer/
│     └─ PatientTransferWorkflow.groovy
└─ script.properties

rules/
└─ semantic/
   ├─ core/
   │  ├─ PatientRules.groovy
   │  └─ EncounterRules.groovy
   └─ scheduling/
      └─ AppointmentRules.groovy

The exact subdirectory structure is project-specific, but keep related workflows and rule families grouped consistently so source control, review, and production diagnostics remain easy to follow.

Versioning the integration

Keep the integration project in Git and expose a meaningful script generation through scriptVersion(). Versioning makes it easier to correlate a production issue with the exact source revision that produced it.

@Override
String scriptVersion() {
    return "custom-script-v1.4.0"
}

Use release tags or another immutable source-control reference for production deployments so a previous known-good version can be reconstructed exactly.

Hot reload Commercial

Automatic script and semantic-rule hot reload can activate validated changes without restarting the FireSonic runtime.

scripts.dir=./scripts
scripts.autoreload=true

semantic.rules.enabled=true
semantic.rules.dir=./rules/semantic
semantic.rules.autoreload=true

Verify activation

After deployment, confirm that FireSonic is actually running the expected generation:

• Check startup or hot-reload logs for successful compilation and activation.
• Verify the active script version and semantic-rule state in the Administration Console.
• Run a small representative HL7 smoke-test set and inspect the resulting message status and Bundle.
• Confirm downstream FHIR delivery and any project-specific external-service integrations.
• For commercial monitoring deployments, watch failure rates and operational metrics after activation.

Rollback

If a newly deployed integration behaves incorrectly, restore the previous known-good script and rule generation from source control. Activate the restored files by restarting FireSonic, or allow hot reload to activate the restored generation when that feature is enabled.

Deployment safety checklist

• Test normal, edge-case, and failure-path HL7 messages before deployment.
• Run automated unit, semantic-rule, and SDK integration tests where applicable.
• Keep production credentials and secrets outside source-controlled script.properties.
• Deploy reviewed source from version control rather than local uncommitted changes.
• Verify activation before considering the deployment complete.
• Keep the previous known-good release available for rollback.
• Do not point local SDK debugging or automated tests at production FHIR endpoints.

For local validation and automated testing guidance, see Testing & Debugging.