Plugin SDK

Iotellect Server and Iotellect Client support several types of plugins for communicating with different Devices, adding new contexts to a server context tree, building custom reports, localizing and customizing textual and graphical resources, and more. General information is available in Plugins section while this part of documentation is covering development of new plugins.

Documentation provided in this section is applicable only to on-premise and edge Iotellect server instances. Cloud server users get Iotellect as a managed service, so custom plugin functionality is disabled to unsure server reliability and uptime.

Plugin architecture is based on Java Plugin Framework (JPF) library. JPF was selected in favor of frameworks like OSGi due to its extremely lightweight nature. It allows the server to operate in low-memory environments like single-board computers, IoT gateways, touch panels and Linux PLCs.

Most server modules are implemented as plugins and, thus, are optional.

All plugins except for a so-called root plugin extend some other plugins by connecting to an extension point. Extension point must be specified in a plugin descriptor.

There are several types of plugins available.

Iotellect Server plugin types are listed in the below table:

Iotellect Server plugin has two mandatory components:

• Plugin Java class that implements AggreGatePlugin interface. Most implementations extend children of BasePlugin class to avoid implementing irrelevant methods and preserve their default functionality.

• Plugin descriptor that defines plugin properties and its place in Iotellect Server's plugin hierarchy.

These components must be packed in the Java Archive (JAR). Plugin descriptor (plugin.properties) must be located in the root folder of the archive.

Each plugin has a unique ID, such as com.tibbo.linkserver.plugin.context.uniqueid. In a few places, this ID may be substituted by a short ID, which is the last segment of plugin's full ID, e.g. uniqueid.

To create new Iotellect Server plugin from scratch, create new Java class inherited from one of BasePlugin's children (such as AbstractDeviceDriver, AbstractContextPlugin or AbstractAuthPlugin). You will need to override at least some of the methods to provide plugin functionality.

Plugin development process includes the following main stages:

• Implementing plugin's configuration

• Preparing plugin descriptor

• Building and deploying plugin archive

Every Iotellect plugin has the following methods (declared in AggreGatePlugin interface):

• getId(), getShortId(), getDescription() and getSortIndex() are called by the core to collect basic information about the plugin. Normally, overriding this methods is not required since abstract plugin classes provide proper implementations.

• globalInit(), globalDeinit(), userInit() and userDeinit() should be overrided to perform basic plugin's initialization/deinitialization. Those methods are called at context tree loading/unloading stages of server startup and shutdown processes. Method implementations should call createGlobalConfigContext() and createUserConfigContext() to setup plugin's configuration.

• globalStart() and globalStop() should be overrided to implement plugin startup and shutdown logic. Those methods are called at context tree starting/stopping stages of server startup and shutdown processes.

Every plugin has its own class loader (java ClassLoader implementation) separated from server's primary class loader.

Accessing class loader of a particular plugin is possible by passing plugin's ID to getPluginClassLoader(String) method of PluginDirector that, in its turn, can be obtained via ContextManager's getPluginDirector() method.

Was this page helpful?

Tell us more

Send

Thank you!