Биллинг для хостинга

В том то и дело что есть желание + вопрос уже не терпит отлагательств. Я и хотел предложить чтобы ты на себя АПИ взял, а я бы либу сделал.

ну, по функциям я и так могу сказать что будет - два массива на вход - с настройками и данными заказа, на выхлопе TRUE/FALSE

т.е. либу можно уже писать - Create я уже даже написал.
плюс таск в жире висит по проверке балланса в ISPsystem - тоже можно - в ту же либу функции пойдут.
кучу всего можно делать.
было бы желание.

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

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

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

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

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

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

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

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

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

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

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

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

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