Skip to main content

Sessions in SIM Dispatcher

Sessions are a core concept in SIM Dispatcher and the underlying ResQueServe® platform.

Updated over 2 months ago

Sessions form the working basis for every simulation and separate the actual dispatch center from its active use in the simulator.

A session is always a complete replica of an existing dispatch center. It cannot be created independently but is always based on an existing dispatch center configuration. When a session is created, the entire current dataset of the dispatch center is copied. This includes, among other things, dispatch areas, street directories, keywords, resources, and other static configurations.

This replica is provided in an isolated environment. All work within a session happens exclusively on this copy. Changes made to the dispatch center in the background, such as adding or editing data records via the dashboard, do not affect sessions that already exist. Each session remains exactly in the state that was valid at the time it was created.

Sessions run on what is called the Realm. Maintenance and management of the static dispatch center data is handled independently through the dashboard components.

The dashboard component of SIM Dispatcher is accessible at www.sim-dispatcher.com. The Realm component is provided at platform.sim-dispatcher.com.


Unmanaged sessions

Unmanaged sessions are the default type in SIM Dispatcher. They are mainly intended for short-term simulations, exercises, or getting to know the system.

These sessions act as a temporary working environment. They allow processes to be tested, simulations to be run, or new features to be tried without creating long-term effects. All incidents and states created within the session exist only inside that single instance.

A key characteristic of unmanaged sessions is their limitation. They do not react to changes in the background dispatch center data. For example, if new emergency units or keywords are added to the dispatch center, they will not be available in an existing session. To work with updated data, a new session must be created.

Unmanaged sessions are not intended for permanent or productive operation. They are also subject to automatic cleanup: if an unmanaged session is not used for 14 days, it is automatically deleted. In addition, only one unmanaged session can exist at a time per dispatch center.


Managed sessions

Managed sessions are also based on a replica of the dispatch center but extend this principle with additional features and permanent data storage.

A major difference is the ability to reinitialize. A managed session can be updated while it exists. During this process, the dispatch center replica is rebuilt and static data is brought up to date without having to create a completely new session.

All data generated within a managed session is stored persistently and redundantly. This includes incidents, status changes, log entries, and other session-related information. Even in the event of server failures, connection losses, or system updates, the session is preserved and can be resumed.

Managed sessions also provide advanced integration options. Access can be granted via a bearer token in the form of a JSON Web Token, allowing external systems to connect via an API. Managed sessions also support HTTPS webhooks, enabling real-time event delivery to external services.

Because of these properties, managed sessions are particularly suitable for productive scenarios, long-term simulations, and complex integrations.


Current status and differences

Managed sessions are currently considered an experimental feature. They are available but still under active development.

A key difference compared to unmanaged sessions is their lifespan. While unmanaged sessions are automatically deleted after 14 days of inactivity, managed sessions persist indefinitely.

Did this answer your question?