ISPmanager module at work

This article describes how the ISPmanager integration module works, including the step-by-step service provisioning workflow, resource synchronization mechanisms, and interaction logging.

Service provisioning workflow

After a client orders and pays for a service, BILLmanager executes the following steps sequentially:

Domain name validation.
IP address assignment.
User creation.
Processing the user creation result.
Service data collection.
Service activation.
Free domain name creation.
PTR record configuration.

Domain name validation

The system checks whether a domain name was specified in the order:

if the field is filled — the client’s value is used;
if the field is blank — BILLmanager generates a domain based on the template defined in the tariff settings. When a domain is auto-generated, the system will later create it on the name server for free domain names.

IP address assignment

If the service requires a dedicated IP address, BILLmanager:

Sends an API request to IPmanager to obtain a free IP address.
Receives the free address and reserves it for the service.

User creation

BILLmanager calls the user.add.finish method and passes the following parameters:

username and password;
resource values from the account template defined in the BILLmanager tariff plan contents;
domain name (either provided by the client or auto-generated).

Based on this data, ispmanager automatically creates:

WWW domain;
DNS zone;
mail domain.

If the user is created with a WWW domain limit of 0, then:

no WWW domain will be created during user provisioning;
a mail domain and DNS zone will still be created.

This rule applies independently to each domain type.

Processing user creation results

User creation in ispmanager may return one of the following responses:

Ok — user was created successfully;
error ERROR Error: Type: 'exists' Object: 'user' Value: '<username>' — the username already exists. In this case, BILLmanager retries creation with a numeric suffix appended (e.g., user_665 becomes user_6651, then user_6652, etc.) until successful;
error ERROR Error: Type: 'exists' Object: 'name' Value: '<domain name>' — the user is being created with a WWW domain that already exists. In this case, BILLmanager retries creation without the domain name.

If no response is received within the timeout period, BILLmanager performs up to 10 polling requests (1 second apart) to check if the user exists. If found, the operation is considered successful. Otherwise, it fails and appears in "Current operations" section with an error message.

Service data collection

When the user is created sucessfully, BILLmanager collects data about the new service. It sends an API request (domain.record) to ispmanager to retrieve the domain’s name servers— information is needed for the service activation notification. If this request fails, the error is ignored.

If the ispmanager user account was created without a dedicated IP address, BILLmanager sends an API request (ipaddr for business/host editions, ipaddr.list for Lite) to determine the list of IP addresses available to the user — also required for the activation notification. If this request fails, the entire service provisioning operation is marked with an error message.

Service activation

Once data collection succeeds:

the service status in BILLmanager changes to "Active";
an activation email is sent to the client.

Free domain name creation

To create a subdomain record, an API request (domain.record.edit) is sent to the free domain name server.

PTR record configuration

If the service uses a dedicated IP address:

BILLmanager sends an ip.edit request to IPmanager;
the service’s domain name is set as the PTR record for the IP address.

Synchronization

The ISPmanager processing module periodically compares the service state in BILLmanager with the corresponding user state in ispmanager. The value of Username in the Products/Services → Shared hosting field must match the username in ispmanager.

Status synchronization

During status synchronization:

all services linked to the ISPmanager processing module are selected;
the service status in BILLmanager is compared with the user state in ispmanager:
- if BILLmanager shows "Active" but the ispmanager user is disabled, the platform re-enables the user;
- if BILLmanager shows "Suspended" but the ispmanager user is enabled, a disable request is sent.

Status synchronization runs daily.

Resource synchronization

Account template synchronization occurs every three days. BILLmanager compares account templates between itself and ispmanager:

if templates match, resource values are checked. Any discrepancy triggers an API request (user.edit) to ispmanager to align the resource value with BILLmanager’s setting;
if templates differ, BILLmanager:
- sends an API request (user.edit) to apply the template defined in BILLmanager;
- adjusts resource values accordingly.

For ispmanager business, the resource sync task retrieves the cluster node name where the user resides and stores this information in BILLmanager.

Status and resource synchronization are handled by the cron job processing.syncserver.cron.

Logging

Interaction logs between BILLmanager and ISPmanager are written to /usr/local/mgr5/var/pmispmgr5.log.

You can identify operations in the log by these entries:

'processing/pmispmgr5 --runningoperation <current_operation_id> -- command open' — service provisioning;
'processing/pmispmgr5 --runningoperation <current_operation_id> --command close' — service termination;
'processing/pmispmgr5 --command sync_server --module <processing _module_id>' — data synchronization;
'processing/pmispmgr5 --command stat --module <processing_module_id>' — statistics collection.

Statistics collection

The ISPmanager processing module supports collecting usage statistics for the resources described in the article Tariff resources. ISPmanager. Statistics are gathered for the previous day.

Statistics collection is performed by the cron job statdaily.cron.

Useful tips