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, tags).
  • Detailed – Additional filters can be applied to decision tables and functions.

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 see the Download snapshot view select Download snapshot in Tools from Main Toolbar:

After that, you will see a screen allowing you to choose the elements that you want to be 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, which are versioned inside the selected profiles. 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 will be from the current session if marked (A)

    b) which will be filtered by name if filled and added in (B)

    c) which will be marked by a specific tag if selected in (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 contain elements also from the context (A). Context definition can only be downloaded together with the profile definition. If you do not mark the checkbox Profile, 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 configuration to snapshot download - to download the snapshot, you need to click the Download button (A):

Snapshot Upload#

In order to see Upload snapshot view select Upload snapshot in Tools from Main Toolbar:

Then Upload snapshot view will appear:

When you choose a file in (A) and click the Upload button (B), the upload will take place. When you choose the upload option (C) all changes from the snapshot will be published right away.

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#

There is also a historical Snapshot uploads view available. After clicking on (A) from the Upload snapshot view:

you will see the Snapshot uploads view with historical uploads in the form of a table:

with column names (C):

No. Column name Description
1. Date Date of snapshot upload
2. File name The file name of the file from which the snapshot was uploaded
3. User User name which performed snapshot upload
4. Status Summary status of snapshot upload: Warning, Skip, Ok, Error
5. Actions Contains expandable Details (D) if any message upload exists

After clicking on (D) you will be redirected to view with detailed information as a dropdown list like in the Upload Snapshot summary view.

Insertable field (B) allows filtering table data by Date and 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.