Основные изменения

Информация, приведенная ниже, прежде всего предназначена, для пользователей, знакомых с версией АСР LANBilling предыдущего поколения. Текст показывает основные отличия концепции, которая легла в основу разработки версии АСР LANBilling 2.0 OSS, от ее предшественницы - 1.9. Статья имеет технический уклон и, вероятнее всего, будет полезна для сотрудников IT служб, эксплуатирующих биллинговую систему.

Что планируется внедрить в версии 2.0?

1. Поддержка нескольких типов СУБД (Mysql,Oracle)
2. Выделение логики общения с БД в промежуточный (Mediation) слой (LBserver)
3. Вынесение всего SQL-кода в процедуры
4. Транзакционная модель списаний, при которой любое движение средств по расчетным счетам возможно только в том случае, когда успехом закончились комплиментарные операции списания и зачисления (см. раздел 2.1) на расчетные счета объектов в АСР. Модель нулевого системного баланса.
5. Разделение логики списания и блокирования в три этапа:
   - вычисление нужной суммы списания
   - списание
   - блокировка при необходимости
6. Реализация механизма блокировок и списаний через систему нотификаций
7. Safe режим работы всех агентов

1. Схема работы

2. Архитектура БД

Коренным образом меняться структура БД в версии 2.0 не будет. Последняя версия БД располагается по адресу https://client.lanbilling.ru/table_fields. Предполагается провести следующие изменения:

2.1. Списания и начисления

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

Ситуация 1: Начисление средств на счет абонента посредством платежной системы (ПС) (менеджера).
- списание суммы со счета менеджера
- начисление суммы на счет пользователя
- фиксация платежа в таблице payments

Ситуация 2: Списание средств за услугу
- списание средств со счета пользователя
- начисление средств на счет агента, производящего списание
- фиксация списания в таблице day, usbox_charge, rentcharge или penalties

Таким образом в случае корректной работы системы конечная сумма средств в системе всегда будет одинаковой. Основная цель такого нововведения - детальный контроль списаний по каждому из агентов, а также контроль начислений по каждому из менеджеров.

2.2. Структура таблиц

Структура таблиц в целом остается неизменной, поскольку у каждого агента или менеджера есть свои особенности проведения платежа или начисления списания. Для реализации вышеописанного механизма к каждой из указанных таблиц добавлен договор-источник (инициатор), с которого произошло списание средств (в случае, если речь идет о платежной системе) или договор-получатель, если речь идет о списании средств со счета абонента.

Основная идея модели заключается в сохранении замкнутости денежного оборота в системе. Это позволит эффективным образом определять место возникновения ошибки в случае конфликтов. Кроме того, предполагается вести простой журнал по всем денежным операциям в системе, по которому в случае необходимости будут проводится сверки.

2.3. Система настраиваемых блокировок

Все текущие виды блокировок будут сохранены. Новая логика позволяет дополнять существующие типы блокировок пользовательскими при необходимости. Указанное нововведение позволит расширить функционал тарификации и состояний блокировки.

2.4. Скидки по услугам

В версии 2.0 предполагается внедрить как индивидуальные скидки по услугам, привязанные к конкретной учетной записи с указанием периода действия, так и индивидуальные скидки, привязанные к тарифам. Скидки по тарифам реализованы с помощью дополнительных механизмов тарификации таким образом, чтобы при определенных условиях пользователям предоставлялись индивидуальные скидки в зависимости от режима использования услуг или наличия дополнительных модификаторов тарификации таких, как, например, пакетные предложения.

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

Предполагается, что указанное изменение позволит более четко отслеживать систему действующих скидок, а так же не позволит сильно увеличится в размере таблице действующих скидок, обращение к которой будет довольно частым.

2.5. Кредиты

В предыдущих версиях системы было добавлено понятие кредита, при выставлении которого абоненты могли пользоваться услугами при отрицательном балансе. Для более тщательной детализации предоставляемых кредитов в версии 2.0 реализована схема назначения и смены значения кредита, аналогично системе назначения тарифных планов.

Таблица credit_rasp содержит будущие изменения кредита, credit_history - прошлые значения. Поле agreements.credit, как и ранее, содержит текущее значение кредита.

2.6. Система очередных списаний

Для каждого из агентов добавлена уникальная опция, указывающая очередность списания денежных средств. Указанное нововведение позволит клиентам самостоятельно определять приоритетность предоставляемых услуг в случае недостаточности денежных средств на счете абонента, пользующегося несколькими видами услуг.

2.7. Улучшенная тарификация

В версии 2.0. предполагается значительно расширить возможности тарификации за счет увеличения всевозможных тарифных опций.
- расширение возможных периодов тарификации (на какой период рассчитана АП): день, N-дней, месяц, N-месяцев, год;
- сколько должно быть списаний в указанном периоде (равномерность): N-раз, ежедневно, ежемесячно;
- увеличение количества возможных схем списаний;
- возможность изменения начала отчетного периода по дате подключения УЗ;
- установление кредита по умолчанию для всех пользователей тарифа;
- возможность использовать собственный скрипт тарификации, удовлетворяющий установленным требованиям.

2.8. Механизм списаний

Выше были описаны нововведения в механизмах, имеющих непосредственное отношение к системе тарификации. В версии 2.0. предполагается четкое выделение трех различных действий:

- начисление суммы списания (тарификатор)
- списание денежных средств со счета абонента (кассир)
- блокирование УЗ по балансу (блокировщик)

Такое разделение позволит разграничить и упростить работу агентов, а также легче отслеживать указанные изменения.

Помимо этого, списания и блокировки будут производится по событийной схеме, что существенно позволит снизить количество запросов к БД.

2.9. "Safe" режим работы агентов

В режим «Safe» в версии OSS могут функционировать все агенты системы. Основным, но не единственным его достоинством является возможность построения распределенной биллинговой схемы при которой в непосредственной близости от оборудования при помощи которого оказывается услуга устанавливается только агент, без центрального хранилища, серверной части LBserver и API LBCore. Все основные компоненты могут находиться на удалении от агента и узла связи. При этом гарантируется, что услуга продолжает оказываться на уровне узла и управление ее не страдает при пропадении сетевой связности между агентом и центральной частью системы.

Применение такой конфигурации оправдано в случаях когда услуги оказываются в рамках одной компании, необходим централизованный учет и контроль, единая отчетность, при этом узлы связи территориально распределены и объеденены каналами, надежность которых не гарантирована. В реализации версии 2.0 OSS данный режим предусматривает такие аварийные ситуации, при которых в период отсутствия связности компонентов биллинговой системы происходят перезагрузки агента, отключение с последующим восстановлением данных из локального временного хранилища. В конфигурации при наличии Safe режима все централизованные операции, такие как прием платежей, работа абонентского отдела, сервисных служб производится в едином центре управления. В ряде случаев отсутствует необходимость иметь на местах оказания услуг квалифицированный персонал.

Так, в качестве примера, можно привести конфигурацию при которой центральная часть АСР LANBilling 2.0 OSS может быть установлена в Екатеринбурге, а в узлах «саттелитах», таких как Миасс, Челябинск и Магнитогорск устанавливаются лишь агенты.

В момент потери связности с центральными компонентами АСР LANBilling 2.0 OSS агенты начинают работать в автономном режиме и актуальность данных разделяется между локальным хранилищем и центральной СУБД. В момент восстановления происходит синхронизация актуальных данных. Чем дольше агент проработает в автономном режиме тем, дольше займет времени процесс синхронизации. Этот фактор необходимо учитывать при проектировании IT инфраструктуры.

2.10. Незначительные изменения

3. Принцип работы

LBserver - новый компонент биллинговой системы, который является единой точкой входа для всех остальных агентов, одной из основных задач которого является предоставление по запросам от агентов доступа к данным в БД с целью их выборки, изменения или удаления. Работа компонента LBserver с другими агентами построена по принципу выборки определенных данных из БД или же запроса на их модификацию. Указанное действие реализуется через передачу сообщений с указанием вызываемой функции и параметров, с коими она должна быть вызвана.

Клиенты могут по желанию переопределять написанные функции посредством собственных (язык разработки - python), размещая их в специальной директории. Система при обнаружении таких файлов будет использовать их, вместо встроенной в код реализации.

Ниже описаны примеры использования переопределяющих функций и схема работы компонента LBserver с другими агентами.

3.1. Схема взаимодействия компонентов LANBilling v. 2.0.

3.2. Переопределяемые функции

Скрипт, приведенный ниже, определяет выполнение переопределенной функции find_user по логину.

def find_user( input, con ):
q = 'SELECT vg_id, login, password FROM vgroups '
q += 'WHERE login = "' + input[ "login" ] + '"'
res = con.query( q )
if len( res ) == 0:
raise Exception( "user '" + input[ "login" ] + "' not found" )
ret = {}
ret[ 'vg_id' ] = int( res[0][0] )
ret[ 'login' ] = res[0][1]
ret[ 'pass' ] = res[0][2]
return ret