Snapshot

A snapshot is a ZIP file containing the configuration of business logic in Higson Studio. It can include the entire configuration or only selected parts. Its primary purpose is to facilitate the transfer of changes between environments — users can export a snapshot from one environment and import it into another. This makes data migration simple and eliminates the need for administrator intervention, database restores, system downtimes, or other complex operations. The download and upload of ZIP files are performed directly through the Higson Studio GUI.

Snapshot Structure

The folders within a snapshot correspond to the main modules of Higson Studio. A full snapshot contains:

  • Domain
  • Functions
  • Decision Tables (params)
  • Flows
  • Profiles
  • Tags
  • Tests
  • Test Packages

Additionally, snapshot includes a configuration file in JSON format.

Snapshot Content Control

Users have full control over what data is included in a snapshot. The built-in interface allows filtering of the content during both export and import. During export, selections can be made at two levels:

  • General – Users choose which modules to include in the snapshot (domain, profiles - including context, decision tables, functions, flows, tests, batch tests, tags).
  • Detailed – Additional filters can be applied to decision tables, functions, flows, tests and batch tests.

During import, users maintain full control over which elements are loaded into the environment. After a snapshot is imported, the system generates an import report, and the changes are placed in a session. Only when the session is published do the changes take effect in the environment, allowing users to either approve or discard them.

Snapshot Download#

To open the Download snapshot panel, select Snapshot in Tools from the Main Toolbar:

This opens the Snapshot view. Click the Download snapshot action in the top-right corner of the view.

On the Download snapshot panel you can select items you want to download in a snapshot:

  1. Profiles

  2. Domain

  3. Decision tables

  4. Functions

  5. Flows

  6. Tests

  7. Test packages

  8. Profile

  9. Tags

  1. Choosing the Profiles:

    The snapshot download will contain functions, decision tables, and flows assigned to the selected profiles, as well as global elements. You can choose one or more profiles. In this case, the snapshot download will contain functions, decision tables and flows from two selected profiles:

  2. Choosing the Domain:

    When you choose Domain snapshot download will contain the domain with published changes and the current user’s session changes by default.

  3. Choosing Decision tables:

    When you choose Decision tables snapshot download will contain decision tables:

    a) which are only from the current session if only from active session is checked (A)

    b) which are filtered by name if a value is entered and added in Name begins with (B)

    c) which use a specific tag if selected in Used tags (C)

  4. Choosing Functions:

    When you choose Functions snapshot download will contain functions - filtered the same way as Decision Tables.

  5. Choosing Flows:

    When you choose Flows snapshot download will contain flows - filtered the same way as Decision Tables.

  6. Choosing Tests:

    When you choose Tests snapshot download will contain Tests. Tests may be filtered by name.

  7. Choosing Test packages:

    When you choose Test packages snapshot download will contain Test packages. Tests packages may be filtered by name.

  8. Choosing Profile:

    If you choose Profile, the snapshot download will contain the configuration of the profile.

    The data contained in the snapshot may also contain elements from the context if the With context checkbox is marked. Context definition can only be downloaded together with the profile definition. If you do not mark the Profile checkbox, the snapshot download will contain only functions, decision tables, and tags.

  9. Choosing Tags:

    When you choose Tags snapshot download will contain tags.

    Finally, after applying the configuration - to download the snapshot, click the Download button at the top of the panel (A):

Snapshot Upload#

To open the Upload snapshot panel, go to the Snapshot view (Tools → Snapshot in the Main Toolbar) and click the Upload snapshot action in the top-right corner:

The Upload snapshot panel then slides in from the right:

Select a snapshot file by clicking the upload area or dragging a ZIP file onto it (A), then click the Upload button at the top of the panel (B). If you check the Publish session after import option (C), all changes from the snapshot are published immediately after the import.

When the snapshot file is selected additional upload options will appear:

No. Item Description
1 Profiles List of profiles included in the snapshot.
2 Export time Export time of the snapshot
3 Functions Options available for functions during snapshot import. You will find details below.
3a Function filters List of filters used for functions during snapshot export – the same criteria will also apply during the import. You will find details below.
4 Flows Options available for flows during snapshot import. You will find details below.
4a Flows filters List of filters used for flows during snapshot export – the same criteria will also apply during the import. You will find details below.
5 Decision tables Options available for decision tables during snapshot import. You will find details below.
5a Decision tables filters List of filters used for decision tables during snapshot export – the same criteria will also apply during the import. You will find details below.
6 Domain Removes domain configuration elements which do not exist in the snapshot.

Removing not in snapshot

  • Remove not in snapshot - removes objects that are on the environment and are not in the snapshot file. During the snapshot upload, the export parameters used during the snapshot creation are taken into account. This means that if filters were applied during the export — such as Name begins with, Used tag, etc. — the same criteria will also apply during the import.

Example:

The environment contains 10 decision tables (first column of the table below). We want to import a snapshot that was exported with the filter Name begins with = ‘demo’ (second column of the table below). During the import, we enable the Remove not in snapshot option for decision tables. In this case, only the decision tables whose names start with ‘demo’ will be considered during the import. As a result, if the decision table demo.motor.coverage.availability is not present in the snapshot, it will be removed from the target environment. However, tables with names starting with dictionary or pl will remain in the environment — even if they are not included in the snapshot — because they do not match the Name begins with = ‘demo’ condition.

If an element scheduled for deletion is referenced by another component — for example, a function used as the value source in the IN level of a decision table — the element will be retained. A warning indicating the dependency will be logged in the snapshot upload report (see screenshot below). This mechanism is designed to maintain referential integrity within the environment and prevent deletion of in-use objects.

  • Force Delete - The force delete flag allows you to force the deletion of items for which, for some reason, this deletion is not recommended. If the element is in use, removing it will cause errors.
  • Search Within Parameter Matrix - Selecting this option will ensure that if a decision table or function is not present in the snapshot, not only domain elements and source value of IN levels decision tables will be searched, but also the matrices of the decision tables. This mechanism is designed to maintain referential integrity within the environment and prevent deletion of in-use objects. In the basic version, Higson does not check the matrix for performance reasons. If it finds a conflict it returns a warning (see screenshot below).

After the snapshot uploads, summary results with detailed information will appear in a dropdown list form:

In summary, there is information on how many elements were in status:

No. Status Description
1. Imported Elements imported
2. Deleted Elements deleted
3. Errors Elements with errors occurred
4. Skipped Elements skipped
5. Not published Elements not published

Every status section can be expanded (A) for more detailed information with a description per element, e.g.:

Historical Snapshot Uploads#

The Snapshot view (Main Toolbar → Tools → Snapshot ) shows the history of snapshot uploads in the form of a table:

with column names:

No. Column name Description
1. Date Date of snapshot upload
2. File name The name of the file from which the snapshot was uploaded
3. User User name which performed the snapshot upload
4. Job status Status of the asynchronous import job: QUEUED, RUNNING, DONE, FAILED (see Async Import Configuration)
5. Snapshot status Summary status of the snapshot upload: Warning, Skip, Ok, Error
6. Actions Contains the expandable Details link, which opens the detailed upload report

After clicking Details you will see the detailed information as a dropdown list, like in the Upload snapshot summary view.

The Search field allows filtering the table data by the File name column.

Async Import Configuration#

Snapshot import in Higson is processed asynchronously. When a user submits an import, the request is placed in a queue and processed in the background — the user does not need to wait on screen for the import to finish.

The queue is checked by a poller — a mechanism that wakes up at regular intervals, looks at the queue, and picks up pending import jobs for processing. Each wake-up cycle is called a tick.

Each import job goes through the following statuses:

Status Description
QUEUED The job is waiting in the queue to be processed.
RUNNING The import is currently being processed.
DONE The import completed without interruption. Does not mean the import is free of warnings or errors — check the report.
FAILED The import ended with an error. The error message is available in the report.

Only one import per user can be in RUNNING status at a time. If the poller picks up a second job for the same user while their first import is still running, it returns that job to QUEUED and retries in the next tick.

Poller Properties#

Property Default Description
higson.studio.snapshot.async.poll.interval-ms 5000 How often (in milliseconds) the poller checks the queue for new jobs.
higson.studio.snapshot.async.poll.initial-delay-ms 10000 How long (in milliseconds) the poller waits after application startup before checking the queue for the first time.
higson.studio.snapshot.async.poll.batch-size 3 How many QUEUED jobs the poller picks up from the queue in a single tick.
higson.studio.snapshot.async.poll.max-concurrent-jobs 6 How many imports can run in parallel on a single instance.

When to adjust:

  • interval-ms — Decrease if imports are waiting too long to start. Increase if the server is under heavy load.
  • initial-delay-ms — Increase if the application needs more time to fully initialize before handling imports.
  • batch-size — Should not be greater than max-concurrent-jobs. In multi-instance deployments, dividing the value across instances allows each instance to pick up a portion of the load while leaving room for others.
  • max-concurrent-jobs — Decrease on low-resource machines. Increase on powerful machines. In multi-instance deployments, each instance has its own limit — the total throughput is the sum across all instances.

Multi-instance configuration examples:

Two equal instances, max-concurrent-jobs=4 each:

instance 1: max-concurrent-jobs=4, batch-size=2
instance 2: max-concurrent-jobs=4, batch-size=2

Each instance picks up 2 jobs per tick, distributing the load evenly. The optimal values depend on your specific usage patterns and deployment setup.

Orphan Watcher Properties#

If the server crashes or loses its database connection during an import, the job may become stuck in RUNNING status indefinitely. Note that a server crash also stops the watcher — it only resumes searching for orphaned jobs after the application restarts, once the initial-delay-ms delay has passed and the threshold-minutes threshold is exceeded. The orphan watcher detects such jobs and automatically returns them to the queue so they can be retried.

A job is considered orphaned when it has been in RUNNING status without a heartbeat signal for longer than the configured threshold.

Property Default Description
higson.studio.snapshot.async.orphan.threshold-minutes 5 How many minutes without a heartbeat before a RUNNING job is considered orphaned and reset to QUEUED.
higson.studio.snapshot.async.orphan.interval-ms 60000 How often (in milliseconds) the watcher checks for orphaned jobs.
higson.studio.snapshot.async.orphan.initial-delay-ms 60000 How long (in milliseconds) the watcher waits after application startup before running for the first time.

When to adjust:

  • threshold-minutes — The watcher considers a job orphaned when its heartbeat has not been updated for longer than this value. A running import updates its heartbeat every 30 seconds, so healthy imports are not interrupted. Increase this value only if you observe false positives — jobs being reset despite being actively processed.
  • interval-ms — Decrease for faster detection of stuck imports. Increase if the server is under heavy load.
  • initial-delay-ms — Increase if the application needs more time to stabilize after startup.

Note: In the event of a critical infrastructure failure (e.g., out-of-memory error), the lock held by the affected user may not be released automatically — even by the orphan watcher. In such cases, manual administrator intervention is required before the user can submit new imports.