Софт от ISPsystem

[Alex Keda]

разработка заказов сабжа вошла в активную фазу, уже формируются запросы к их АПИ.

собственно, возникают вопросы по фунциклированию.

описание правильной схемы работы

есть таблица лицензий, где собраны все лицензии.
1. лицензии делятся на внутренние - привязанные к каким-то собственным IP сетям, и внешние - не привязанные к сетям.
2. для внутренних лицензий - нельзя менять IP через интерфейс пользователя, заказ лицензий осуществляется всегда "вечных"
3. заказ пробных внутрь - вечная даётся, через неделю или две лочится - как настроить
4. при заказе новой лицензии (неважно куда) по таблице ищщется свободная лицензия такого типа, если есть - ей просто меняется IP, если нет - делается заказ
5. при заказе пробной лицензии наружу - заказываетс пробная, при продлении - смена тарифа на нормальную.

описание неправильной схемы работы.
1. выкидываем заказ пробных наружу - там тьма реализации и минимум два варианта - т.к. можно вместо пробных заказывать вечные и через две недели лочить - но, возможен вариант что какойнить придурок ночью закажет тыщщу и сожрёт все деньги на баллансе
2. ... хер знает, но ещё много чё покоцать можно =)
--

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

[serge]

Как видится реализация "таблицы лицензий"? Т.е. в которой как я понял будут сведена вся информация о лицензиях. Она будет отображаться в биллинге? Или это будет таблица в БД, а вывод в биллинге будет формироваться на основе нужных вьюх? Можно ли будет через биллинг контролировать/просматривать состояние "внутренних" и "внешних" лицензий?

[Alex Keda]

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

[serge]

В целом логика считаю что верная.
Как я представлял это себе:

(класс для ПО ИСПсистем)

(какое-то АПИ для регистрации лицензий)
- имеем "таблицу лицензий" в БД
- внутренние лицензии вешаем на владельца с ID 100 (системный акк биллинга)
- внешние лицензии на их владельцев

(какое-то АПИ для управления лицензиями, смена IP адреса в частности)
- юзер управляет только своей лицензией
- системый юзер (ID 100) упрвляет внутренними лицензиями

(какое-то АПИ для выдачи внутренних лицензий в аренду, выделение на внутренние сервера)
- только для лицензий с OwnerID//UserID = 100
- при заказе лицензии для ВПС и ДС делается проверка наличия свободных лицензий
- при наличии лицензии запрос к вышеописанному АПИ для смены ИП адреса
- при отсутствии лицензии запрос к вышеописанному АПИ для регистрации лицензии

[serge]

Если так как я написал, то вроде все достаточно просто получается. Просто не нужно делать разделение на внутренние и внешне лицензии. Все считаю правильней привязывать к ID владельца. И писать для каждого действия свое АПИ. В принципе АПИ должно получится универсальным. Т.е. ему будет похер какой UserID у лицензии для которой меняется IP, оно его просто сменит на нужный. А вот АПИ, которое примет решение о возможности смены IP для той или иной лицензии уже это обыграет.
Смотрелок тоже в таком случае не нужно. Будет общая таблица лицензий (что тоже идеологически верно), а к ней уже можно добавить фильтр типа "внутренние", который выберет лицензии с UserID = 100.

[Alex Keda]

я хотел обойтись одной функцией
типа GetFreeLicense - смотрит таблицу, если есть нужный тип лицензии, и по срокам уже можно - меняет IP у неё. (или, если залочена - разлочивает)
если вернула TRUE - задание выполнено, если FALSE - заказываем лицензию.

[serge]

Если придерживаться данной идеологии, то в принципе можно подумать над универсальным классом SoftWares (аналог Registrators). Который будет предоставлять абстрактные универсальные функции управления ПО, типа создать, заблокировать, удалить, сменить IP. А сами функции будут реализовываться в библиотеках типа ISPmanager.lib DNSnameger.lib, IPmanager.lib, abocms.lib и т.д.

[serge]

я хотел обойтись одной функцией
типа GetFreeLicense - смотрит таблицу, если есть нужный тип лицензии, и по срокам уже можно - меняет IP у неё. (или, если залочена - разлочивает)
если вернула TRUE - задание выполнено, если FALSE - заказываем лицензию.

Вот это наверное тут случай когда упрощение только все усложняет. Ну и в целом идеология биллинга интересная и как сам же и говорил правильная. Каждое действие должно делаться своим компонентом. В итоге нужная реализация получится "дерганием нужных веревочек" и обработкой результатов их работы.

[Alex Keda]

вот от этого я и ушёл в итоге, т.к. понял что какой-то универсальный класс с нуля нарисовать не потяну
проще реализовать под что-то одно.
--
я даже Server() выпилил из реализации, т.к. данные для подключения есть в конфиге, а занчит можно просто вызывать целевую функцию - она всегда называется одиаково.

[serge]

По классу... давай вместе подумаем над реализацией. Решим по тому какой будет функционал у него, определимся с интерфейсом (забыл как это прально называется))) и тогда уже можно будет поделить работу. Кто-то реализует API, вызывающие эти методы, кто-то пишет библиотеку для взаимодействия непосредственно с биллингом ispsystem.