Skip to content

Purpose of the Server API

Plugins developed with the ScaleTrade Server API serve four primary purposes:

  1. Access to Internal Server Data
    Plugins can read configurations, databases, and obtain information about the current state of clients and the platform as a whole.
    This enables the creation of custom reports and analytics based on real-time data.

  2. Management of Server Data
    Plugins can modify server settings, update databases, and create new records (such as emails, news, and more).

  3. Receiving Event Notifications
    Plugins can be notified about changes in databases or configuration and react to those events automatically.

  4. Changing Server Behavior
    Plugins can alter server logic, such as customizing commission calculation algorithms, quote filtering, and other core processes.

In summary, plugins created for the ScaleTrade Server API allow you to tailor the server for your needs, enhance its capabilities, and integrate ScaleTrade with external systems (such as CRM platforms or analytics tools).

System Requirements

To develop server plugins, your computer must meet the following requirements:

Hardware Requirements

  • At least 8 GB of RAM
  • CPU with at least 4 cores, 4 GHz
  • At least 100 GB of free disk space
  • Network transfer speed — at least 10 Mbit/s (may depend on server load)

Operating System

  • Minimum supported version — Ubuntu 24.04 build 145 or higher
    (otherwise, it will not be possible to run the debug version of the server)

Development Tools

  • Clion is required for plugin development
  • ScaleTrade platform is required for debugging

Plugin Requirements

When developing plugins, the following requirements must be met:

  • Plugin bitness must match the server bitness on which it is used.
    • 64-bit plugins do not work on 32-bit servers and vice versa.
  • The plugin operates in the server address space, therefore:
    • it must use memory efficiently;
    • it must minimize memory fragmentation;
    • it must not cause memory leaks.
  • The plugin must never cause unhandled exceptions.
  • The plugin must return control from event and hook handlers as quickly as possible.

It is recommended to specify the preprocessor directive _CRT_SECURE_NO_WARNINGS (Preprocessor section).

Warning

The plugin must not access server databases during optimization (ConCommon::liveupdate_mode == 1) on Sundays, when service operations are performed: database optimization, deletion and backup of old accounts, etc.
During this period, the server blocks access to databases, and attempts to access them from a plugin may cause a server failure.

Plugin Configuration

The server starts using a plugin after you enable it in the configuration via the back office.
Plugins are placed in the /plugins folder on the server. On each startup, the server scans this folder and generates a list of available plugins.

Enabling a Plugin

You can change the priority of plugins in the list using the "Up" and "Down" commands in the context menu.
The server accesses plugins in the order they are listed by priority. If multiple plugins use the same hook, the hook of the first plugin in the list is called first, then the second, and so on.

  • Adding a new plugin takes effect after the server is restarted.
  • Changes in plugin priority order (rearranging in the list) are also applied only after a server restart or reconfiguration activation.

Interaction with Servers

When the trading server starts, it scans the /plugins folder to generate a list of available plugins, and then loads those for which the "Load at server startup" option is enabled in the settings.

Plugin Loading Sequence

  1. The server calls the AboutPlugin entry point and compares the obtained information with the plugin configuration available on the platform.
  2. If no configuration is found, it is added to the platform.
  3. The server checks the plugin’s digital signature.
  4. If the plugin is enabled, the CreatePlugin entry point is called. After this, the plugin is considered running.

During plugin loading, the server performs several tests. If problems arise, corresponding messages are added to the log:

  • The server measures the number of threads in the system before and after loading. If the number increases by more than 50, a warning is added to the log.
  • A log entry is added if the plugin contains a debug module.
  • The plugin’s digital signature is verified. If no signature is found, a message is added. If a signature is found, the log displays the name of the signing organization.
  • If the plugin uses Java or .NET, a message recommends avoiding such plugins, as they increase server load.
  • After loading a DLL, the server checks for replacement of exception handlers (SetUnhandledExceptionFilter, _set_new_mode, _set_new_handler, _set_invalid_parameter_handler). If replacement is detected, the log notes: "It is recommended to remove handler replacements in the plugin, as this negatively affects the server self-testing system."
  • On plugin unload, the DestroyPlugin function is called, after which the library is completely unloaded from the server.

Entry Points

Any plugin must contain at least two hook functions: CreatePlugin and DestroyPlugin.
The server calls them when loading the plugin:

  • AboutPlugin — provides the server with basic information about the plugin.
  • CreatePlugin — used for global initialization of the plugin; receives the server interface as a parameter.
  • DestroyPlugin — used for global deinitialization of the plugin; receives the server interface as a parameter.

Server Interface

The server interface is a set of functions for managing the server’s operation and accessing its internal structures.
For example, the interface can be used to add ticks to the quotes stream or request a list of all traders.
The server interface description is located in the file PluginServerInterface.h.

Plugin Deinitialization

If a plugin requires deinitialization (e.g., closing threads or sockets), add the DestroyPlugin hook function, which is called when the server shuts down.
Important: after DestroyPlugin is called, the server interface must no longer be accessed.
If the plugin has separate threads, they must be properly terminated within DestroyPlugin, without waiting for the plugin to unload.

Recommendations

  • All actions related to resource and environment initialization should be performed in AboutPlugin.
  • All actions related to resource release and cleanup should be performed in DestroyPlugin.