Plugins and modules in BILLmanager

The following terms are used in the article

Before studying this section, it is recommended to familiarize yourself with the developer documentation for COREmanager, since BILLmanager inherits part of the mechanisms from the base platform.

The article describes methods for extending BILLmanager functionality: plugins and modules. Plugins allow changing platform behavior without modifying the source code, while modules implement integration with external systems, such as payment gateways, domain registrars, and service providers.

Definitions of plugins and modules

Plugin

A plugin is a mechanism for modifying existing and adding new behavior to the BILLmanager platform without modifying the source code. Plugins can be written in almost any programming language, however, using Python is preferred. ISPsystem provides an SDK (Software Development Kit) that simplifies working with:

XML data;
sessions and request parameters;
database;
error handling.

Some functionality is available only in C++. In such cases, C++ and header files from the directory /usr/local/mgr5/include should be used.

For more details, see the article Plugins. General principles.

Module

A module is an extension and automation mechanism that does not modify the behavior of the BILLmanager platform, but implements integration with external systems. Modules can also be written in almost any programming language. Using Python and SDK reduces development time. Unlike plugins, modules allow implementing any functionality.

For more details, see the article Modules. General principles.

Differences between plugins and modules

Plugins and modules have different entry points, invocation methods, and formats for interacting with the platform:

Criterion	Plugin	Module
Entry point	BILLmanager launches the script when an event occurs or a function is called. The function or event name is read via `session.get_query_param("func")`.	The script is launched with the argument `--command <command_name>`.
Who calls	BILLmanager automatically: when an event occurs. For example, opening a dedicated server or expiration of an action; when a user calls an interface function. For example, when a user navigates to virtual machine license settings or when checking a custom field value.	BILLmanager in the following cases: on schedule (scheduler); on user action (opening or closing a service); when parameters change.
I/O format	Input (`stdin`): XML file with request parameters; Output (`stdout`): XML response (`<doc/>` for events, form data for func, `<error>` on error).	Input (`stdin`): XML file with parameters (optional, if the command requires them); Output (`stdout`): XML response (`<doc>` with data) or nothing. Arguments: `--item`, `--module`, `--command`, etc.
Registration	XML file: `<handler name="script.py" type="xml">` with nested `<event>`, `<func>` or `<task>`.	XML file: `<plugin name="..."><group>processing_module</group>`.
Language	Python (SDK), C++ or any other. Part of the functionality is available only in C++.	Python (SDK) or any other. No restrictions on functionality.
What to use for	To modify existing platform behavior. For example: intercept an event; add a button; extend a form; validate a field when ordering.	To implement BILLmanager integration with an external system. For example, add: a new service type; a payment method; a message gateway.

May be useful