Multi Admin Billing System (MABill)

Система Multi Admin Billing System (MABill) — биллинговая системой для интернет-провайдеров. Система построена по модульной архитектуре, состоит из набора скриптов на языках PHP и PERL и поддерживает четыре модуля: Dial-up, VPN, Почта и Web.

Основная задача, которую ставит перед собой комманда разработчиков проекта — использование в системе активно-развивающихся некоммерческих проектов. За основу были взяты свободно-распространяемые языки (PHP и PERL) и продукты.

Основой для хранения данных для системы MABill является СУБД MySQL. Модуль почты предназначен для администрирования почтового сервера Postfix. Модули Dial-up и VPN используют некоммерческие продукты FreeRADIUS и FreeNIBS.Модуль Web-hosting может использоваться с любым веб-сервером, но ориентирован на использование.

принципы функционирования

Задача любой биллинговой системы — вести учет предоставленных (полученных) услуг, вести расчет и учет денежных средств за предоставленные (полученные) услуги и предоставлять всем категориям пользователей удобный и функциональный доступ к информации такого рода.
В MABill есть несколько основных понятий.

ПРОВАЙДЕР УСЛУГ (или первичный провайдер) — это организация, которая владеет самими ресурсами (сервером коммутируемых линий, почтовым или веб-сервером).
От этого провайдера в системе действует системный администраторо (root). Для него создан набор скриптов, позволяющий управлять всеми ресурсами системы. Система позволяет обеспечить доступ нескольким системным администраторам. Системный администратор определяет (регистрирует в системе) компании, (вторичные провайдеры или потребители) которым будут предоставляться услуги.
КОМПАНИЯ (потребитель услуг или вторичный провайдер) — это организация, которая может являться сама потребителем услуг, а может предоставлять услуги на более низкий уровень (конечным пользователям). В любом случае в MABill все компании рассматриваются как потребители услуг. Соответственно у этих компаний в биллинговой системе есть свой биллинговый счет. Если быть точнее, то счет состоит из депозита и кредита в определенной валюте. На счета этих компаний производятся начисления (обычно это предоплата). И с этих же счетов списываются деньги за предоставленные услуги. Компания, занесенная в систему, как и большинство объектов в ней, имеет свой уникальный порядковый номер. По этому номеру с компанией ассоциируются другие объекты системы (к примеру номера аккаунтов этой компании или ее операторы).

Компания обладает набором обязательных и необязательных параметров. К примеру у компании есть название, адреса, телефоны, банковские реквизиты. Необязательными являются те параметры, которые относятся непосредственно к услугам, которыми владеет компания (различные ограничения).

В системе от имени компаний действуют ОПЕРАТОРЫ (их может быть несколько с различными правами).
Операторов, так же как и компании, заводит системный администратор. Оператор может относиться к определенной компании, а может быть и самостоятельным действующим лицом. В первом случае все предоставленные услуги, за которые взимается плата, оплачиваются с биллингового счета той компании, к которой
относится оператор. Во втором случае услуги, которые заказывает оператор, вообще не оплачиваются, т.к. нет компании к которой он относится.

У оператора так же есть набор обязательных и необязательных параметров.
При его регистрации указывается логин и пароль для входа в систему, принадлежность к компании (или он сам по себе), ФИО, телефоны, e-mail и пр.

Теперь поясним как работает вся система.
В начале Администратор должен установить и настроить систему. Дальше необходимо настроить те сервисы, которые требуют предварительной настройки. К примеру в модуле Dial-up и VPN необходимо настроить тарифы, праздники, черный/белый списки. В модуле почты необходимо настроить домены, сети и relay-хосты. Эти настройки потом можно будет изменить, добавить или удалить.
Дальше надо зарегистрировать компании, которые будут пользоваться услугами, и операторов этих компаний. В каждой компании должен быть как минимум один оператор, иначе некому будет заводить аккаунты (услуги).
Операторов можно заводить и без компании, тогда для них никаких денежных расчетов производиться не будет. Дальше компаниям и операторам назначаются соответствуюшие разрешения и ограничения. Здесь надо уточнить, что в начале назначаются общие ограничения на компанию, а потом ограничения для конкретного оператора. При этом ограничения для компании действуют по умолчанию и для оператора. Обязательными для оператора ограничениями являются доступ к модулям (по умолчанию он закрыт ко всем модулям).

К примеру, оператору можно открыть доступ к модулю Dial-up и задать ему ограничение на количество аккаунтов, которые он может завести (это и есть необязательные параметры).
Оператору можно и не открывать доступ к определенному модулю, но ограничения для этого оператора все равно будут действовать. Это необходимо, например, в такой ситуации, когда администратор (root) сам управляет услугами для какой-то компании, а поскольку каждая услуга в системе (к примеру Dial-up аккаунт) имеет ссылку на конкретного оператора и компанию, то оператор обязательно должен быть определен. Если оператору не назначены персональные ограничения, то они берутся из ограничений компании. Если и у оператора и у компании ограничения отсутствуют или равны нулю, значит по данному параметру нет ограничений.
Теперь, когда настроены модули, зарегистрированы компании и операторы, определены ограничения компаниям и операторам, можно приступать к предоставлению услуг.
Администратор (root) может сам добавлять, редактировать и удалять услуги. Каждая предоставленная услуга обязательно относится к определенному оператору. Если у этого оператора определена компания, то в нужных случаях с биллингового счета компании снимаются деньги за услугу.
Оператор тоже имеет возможность заказывать услуги для своей компании (или для себя, если он без компании), но у оператора функции заказа услуг не такие широкие, некоторые настройки запрещены. К примеру Администратор (root) может управлять расширенными настройками Dial-up аккаунтов, а оператор не может. Тонкости тех или иных функций станут понятны при работе с ними.

Подготовлено группой разработчиков системы (README).
обсуждение статьи


Сетевые решения. Статья была опубликована в номере 11 за 2003 год в рубрике software

©1999-2024 Сетевые решения