Licensing

Licensing of plugins is mandatory. Before starting the development of a plugin, it is necessary to obtain a developer license, which will allow you to run a test instance of the SyrveFront application for the development, debugging, and testing of the plugin. Users installing an already finished plugin will need to purchase a license for it. This mechanism protects plugin developers from unauthorized use and allows Syrve to control the use of certain features.

Licensing Schemes

From a technical point of view, there are two licensing schemes:

• Pay per instance of the plugin: limits the number of simultaneously running instances of the plugin.
• Pay per external connection to the plugin: limits the number of devices simultaneously working with the plugin.

Pay per Instance of the Plugin

This option can be applied to plugins that provide complete functionality and have standalone value. For example, a plugin that duplicates the contents of the current order on the customer’s screen could be licensed under this scheme. License control is automatically handled by the SyrveFront application; the plugin will only be loaded if a license for it is available. To use the plugin simultaneously on multiple terminals, a license for the corresponding number of plugins is required. Thus, if the plugin needs to be installed on 10 terminals, a license for 10 instances of the plugin will be required.

To protect the plugin under this scheme, it is necessary to:

• Register with Syrve to obtain an identifier for the licensed module.
• Mark the plugin class with the attribute PluginLicenseModuleId, specifying the identifier obtained during registration.

Pay per External Connection to the Plugin

This scheme is applicable for plugins that act as intermediaries between SyrveFront and external devices. In this case, the plugin is responsible for license control. In addition to the fact of including the module in the license, additional restrictions may be imposed, the main one being the number of slots. A module slot is a kind of cell that can be occupied temporarily by a plugin or a connected device. By connecting alternately, two devices can share one slot, taking turns occupying and freeing it, but for simultaneous operation, they will need two slots. For example, if the plugin enables mobile terminals in an establishment consisting of two groups of departments, each with one instance of the plugin installed, and both groups use 5 mobile terminals, the user will need a license for 10 slots. The number of running instances of the plugin is not taken into account in this case.

To implement this protection scheme, it is necessary to:

• Register with Syrve to obtain identifiers for two licensed modules:
  • a module for the plugin itself, as in the previous case, but here it is a formality, needed only to link the plugin using the attribute PluginLicenseModuleId, so that the plugin starts; in practice, this can be a free module without a limit on the number,
  • a module for external connections, which will be used further.
• Implement the ability to identify connecting devices in such a way that one device always corresponds to the same identifier.
• When establishing an external connection, call the method AcquireSlot of the ILicensingService, specifying the identifier of the module obtained during registration and the identifier of the connecting device. Remember the reference to the object returned by the method.
• When terminating the external connection, call the Dispose method on the object returned by the AcquireSlot method when establishing the connection.

When calling AcquireSlot, one of the slots of the plugin module is marked as occupied by the specified device. If there are no free slots, the method generates an exception InsufficientLicenseException, meaning that the maximum allowed number of devices is already connected, and the next device in the connection should be denied.

It should be noted that the ability to free a slot is not always available: the operation of the plugin or the SyrveFront application may be interrupted by a sudden power outage, network issues may occur (license manipulations may require network interaction), and so on. To avoid “leaking” slots when they are occupied but not freed, it is important to ensure consistent identification of devices. For example, if a certain device connects to the plugin, occupying one slot, and after a sudden reboot, this device connects again, then, having the same identifier, it will occupy its slot again; if it had a new identifier, it would need another slot, and the first slot would remain permanently occupied.

Registration

The developer must register their plugin as a licensed module in Syrve, and the user must obtain a license to use this module. When registering, the plugin is assigned a certain identifier, an integer, which will be the module identifier. This can be either a new module created specifically for this plugin or a universal one used for small private modifications. The developer links the plugin to the module by specifying its identifier using the attribute PluginLicenseModuleId. The user will need to obtain a license that includes the corresponding module.

To register, obtain a developer license, get the identifier of the licensed module, and conclude a contract, you need to send a request to github@syrve.com.

Uniqueness of ModuleId

Rule

ModuleId (LicenseModuleId) must be unique for each plugin. If several plugins use the same ModuleId, they start to conflict with each other.

ModuleId must match in two places:

• Manifest.xml (LicenseModuleId)
• the attribute PluginLicenseModuleId in the plugin class

❗Why This Is Important

ModuleId is used as a key for:

• licensing and identifying the plugin
• inter-plugin routing (calling external operations by ModuleId)
• isolating plugin data (e.g., CustomData)
• diagnosing and analyzing problems (logs/reporting)

With duplicate ModuleIds, the following effects may occur:

• one plugin “consumes” the license of another or prevents it from starting
• calls to external operations go to the “wrong” plugin or conflict during registration
• CustomData is mixed up or overwritten
• it becomes more difficult to diagnose problems from logs

Signs of a Problem

• the plugin disappears or is replaced after an update
• registration of an external operation fails with an error like “already registered”
• the plugin reads or receives CustomData events that clearly belong to another plugin
• unstable licensing behavior when starting multiple plugins

Quick Checks

1. Compare LicenseModuleId in all Manifest.xml of installed plugins.
2. Check the correspondence between Manifest.xml and the attribute PluginLicenseModuleId.
3. When using inter-plugin operations, ensure that the target ModuleId belongs to the correct plugin.

Recommendations

• Do not borrow ModuleId from other plugins or examples.
• A fork of a plugin is considered a new product: use a new ModuleId.
• Different versions of the same plugin should maintain the same ModuleId (for correct updates).
• Use different ModuleIds for dev/stage/prod if builds may coexist on the same installation.

Migration (Changing ModuleId)

Changing the ModuleId makes the plugin “new” from the perspective of SyrveFront. This may affect:

• licensing (a different license may be required)
• previously saved plugin data (e.g., CustomData)
• integrations that access the plugin by ModuleId

It is recommended to first test the change of ModuleId on a test environment.

Links

• General API licensing help for all Syrve products