Feature requests для Ubilling

[Phsm 19]

Пользуюсь Ubilling, функционалом доволен, однако есть неприятные моменты:

1. Как правильно из своего скрипта вносить оплату клиенту в убиллинге? Очевидно что такая опция должна быть в Remote API. Сейчас пришлось заинклудить в свой PHP-скрипт кишки убиллинга и вызывать соотвeтствующие функции.

 

2. Такая же проблема с аккаунтингом трафика. У меня есть Freeradius с rlm_perl, в который раз в 5 минут accel-ppp складывает Interim-Update-ы с количеством трафика у юзеров. Как зачислять юзеру трафик в Ubilling-е? В Remote API такого функционала нет, а снова инклудить кусок биллинга в свой скрипт не хочется.

[l1ght 377]

 

 

1. Как правильно из своего скрипта вносить оплату клиенту в убиллинге? Очевидно что такая опция должна быть в Remote API. Сейчас пришлось заинклудить в свой PHP-скрипт кишки убиллинга и вызывать соотвeтствующие функции.

Прием интернет платежей - для этого опенпейз есть. Скидки тоже реализованы. В чём сакральный смысл из вне заносить оплату? 

 

 

 

Такая же проблема с аккаунтингом трафика. У меня есть Freeradius с rlm_perl, в который раз в 5 минут accel-ppp складывает Interim-Update-ы с количеством трафика у юзеров. Как зачислять юзеру трафик в Ubilling-е? В Remote API такого функционала нет, а снова инклудить кусок биллинга в свой скрипт не хочется.

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

[Phsm 19]

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

 

К тому же я смотрел код убиллинга: добавление нового вызова в Remote Api сводится к добавлению вызова функции биллинга в switch, который разбирает api-вызовы

Відредаговано 2015-03-18 22:52:06 Phsm

[l1ght 377]

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

 

К тому же я смотрел код убиллинга: добавление нового вызова в Remote Api сводится к добавлению вызова функции биллинга в switch, который разбирает api-вызовы

Да вы правы, обработка remoteapi достаточно легкая. Но кхм, это как бы не "феншуйно", и что значит занести оплату скриптом, у вас там на кассе нету компьютера у кассирши, или вы все выписки из банков и пополнение через платежные системы вручную разгребаете?

Я как не пытаюсь - не могу понять смысла таких действий...

Честно - абсолютно нет смысла давать денег на счет абоненту через remoteapi, лично вы второй человек который этим "промышляет"

 

Кстати по опенпейзу, вы уверенны что понимаете о чём говорите? Во первых нужные фронтенды\бекенды если их нет - их пишут сами, не понимаю что вызывает сложность.

Во вторых - 

 

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

Это уже готовое api для провода оплат. Ну хочется вам извращатся - ваше дело

[nightfly 1 221]

2 ТС

1. L1ght вполне логично расписал, почему сейчас вещи которые работают, работают именно так.

2. По поводу аккаунтинга радиусом - вопрос точно не к нам, поскольку писать такое на похапе, еще и в обход архитектуры старгейзера - заведомое мудацтво. С одной стороны можно конечно попытаться спросить у madf-a, не хочет ли он часом написать модуль захвата трафика типа cap_radiusacct, но подозреваю, что он скажет то же, что и я - сейчас сложно найти хрень, с которой нельзя снять netflow.

[nightfly 1 221]

2 L1ght

 

Хочет человек стремных извращений - это его право. Чеж ты злой такой

 

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

[Phsm 19]

Дискуссия напоминает типичный линукс-форум: на вопрос тебе отвечают сотнями причин, почему тебе это не нужно, при этом не предлагая альтернатив

 

По поводу оплат: да, возможно с помощью openpayz можно прикрутить собственные оплаты, возможно нет. Не могу на этот счёт дискутировать в полной мере, т.к. код его читал между строк.

Но с другой стороны, почему бы не оставить альтернативу в виде api-вызова, который зачисляет абоненту деньги на счет? мне, к примеру, было гораздо быстрее написать свой скрипт, разобраться в ваших пхп-шниках и заинклудить нужный, чем вникать в openpayz (ко-ко-ко, велосипед, нет чтобы разобраться с openpayz - да, я в курсе). Работает замечательно, нареканий нет, но не радует перспектива того, что в следующей версии кому-то понадобится, к примеру, переименовать функцию CashAdd во что-нибудь другое. Причина, почему я не стал использовать openpayz ,в том, что написать скрипт приема оплат для меня было попросту быстрее.

В случае наличия сабжа я бы просто посмотрел док по API, и закончил работу над скриптом оплат еще быстрее.

 

По поводу аккаунтинга через радиус:

Аккаунтить по netflow заведомо дороже по ресурсам для пробы (да и коллектора - разобрать и сагрегировать потоки-то надо), по сравнению с простейшими Interim-Update-ами с количеством переданных/принятых конкретной сессией байт, разве нет? Зачем усложнять, когда можно использовать простое во всех смыслах решение? Я понимаю, что вопрос не к вам, просто воздух сотрясаю.

 

Просто вопрос к разработчикам. Очевидно, что со старгейзером в качестве бэкенда вы упёрлись в потолок его возможностей:

* скидки, которые начисляют деньги абону вместо удешевления конкретно для него тарифа,

* отсутствие тарифов с посуточной оплатой. Имеется в виду, когда пользователь подключается к инету, с него списывается N денег в день, пока он инетом пользуется.

* отсутствие контролируемых движком биллинга доп.услуг.

* больше не вспомнил.

Вы не думали начать разрабатывать свой движок биллинга? Понимаю что старгейзер крут в плане производительности, но мне кажется что можно достичь приемлемой производительности на perl/python/java вместо с++ с многопоточностью, как в старгейзере.

Відредаговано 2015-03-19 00:17:30 Phsm

[l1ght 377]

Дискуссия напоминает типичный линукс-форум: на вопрос тебе отвечают сотнями причин, почему тебе это не нужно, при этом не предлагая альтернатив

Я очень даже понятно расписал альтернативы.

 

 

Но с другой стороны, почему бы не оставить альтернативу в виде api-вызова, который зачисляет абоненту деньги на счет?

 

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

 

 

По поводу аккаунтинга через радиус:

Это к madf - он злой гений радиусов и прочего

Теперь читаем FAQ http://wiki.ubilling.net.ua/doku.php?id=faq

 

 

Q: Мы тут чего-то как-то тык… ааа… как это случилось!?

A: Да - Ubilling вполне позволяет выстрелить себе в ногу, если вы этого хотели и всецело стремились.

 

 

* отсутствие тарифов с посуточной оплатой. Имеется в виду, когда пользователь подключается к инету, с него списывается N денег в день, пока он инетом пользуется.

 

 

Q: Абонент «не пользуется» интернетом, можно чтобы ему не начислялась АП?

A: Вы это серьезно? И что вы понимаете под «не пользуется»? Абонент умер? А как об этом должен узнать биллинг? У абонента умерла кошка? Чур мы ни причем. У абонента не было трафика? А широковещательный? А ваши же пинги к нему? А попытки банально получать по DHCP адреса от сервера? А синхронизация времени ОС, роутера, и еще черт знает чего по NTP? А если у абонента обновилась ОС либо скажем антивирус - это он тоже «не пользовался»? У него было «мало» трафика? А мало это сколько? Одна киношка? Две? А она обязательно должна быть интересной? А разрешение киношки играет роль? Будем считать, что интернетом «не пользовались» если смотрели камрипы?

Q: Нет, ну есть же способы не начислять АП?

A: Мы умеем начислять только «абонплату». По определению «абонплата - это некий платеж, начисляемый абоненту исходя из какой-то определенной тарифной политики, каждый учетный период, вне зависимости от внешних факторов». Если этот платеж не происходит по причинам типа «у абонента прыщи», «затмение солнца», «пошел дождь», «полнолуние», «настала неделя кентавра, все юниты получили +15 к глупости» или «абонент не выучил уроки», «внезапно наступил апокалипсис» это уже не абонплата, это что-то другое.

 

 

 

отсутствие контролируемых движком биллинга доп.услуг.

Вы об этих?

http://wiki.ubilling.net.ua/doku.php?id=ukv

http://wiki.ubilling.net.ua/doku.php?id=uhw

Или у вас конкретные предложения? 

Відредаговано 2015-03-19 00:17:02 L1ght

[l1ght 377]

Кстати по поводу openpayz - пишите себе фроненд (а может ещё и бекенд, я ж не знаю зачем вам такой извратизм), принимаете параметры как вам угодно POST,GET,xml в принципе не важно, на что фантазии хватит.

И получаете тоже самое, что вы хотите сделать через remoteapi только в красивом и правильном виде.

[nightfly 1 221]

Дискуссия напоминает типичный линукс-форум: на вопрос тебе отвечают сотнями причин, почему тебе это не нужно, при этом не предлагая альтернатив

Вы по чисто каким-то физиологическим причинам читаете строго наискосок? (к слову L1ght таки не спалил тему с перехватом событий в engine)

 

 

По поводу оплат: да, возможно с помощью openpayz можно прикрутить собственные оплаты, возможно нет.

И опять же документация для лохов да...

http://wiki.ubilling.net.ua/doku.php?id=openpayz#%D0%BF%D0%B8%D1%88%D0%B5%D0%BC_%D1%81%D0%B2%D0%BE%D0%B9_%D1%84%D1%80%D0%BE%D0%BD%D1%82%D0%B5%D0%BD%D0%B4

 

 

(ко-ко-ко, велосипед, нет чтобы разобраться с openpayz - да, я в курсе).

и с табуреткой можно сексом заниматься... да... мы ж вам не мешаем же (фотки пжалста выложите, ок?)

 

 

но не радует перспектива того, что в следующей версии кому-то понадобится, к примеру, переименовать функцию CashAdd во что-нибудь другое.

Мы понимаем, что означают слова "backward compatibility" а также слегка беспокоимся о работающих сотнях сетей. Вы судя по замашкам - нет.

 

 

Аккаунтить по netflow заведомо дороже по ресурсам для пробы (да и коллектора - разобрать и сагрегировать потоки-то надо), по сравнению с простейшими Interim-Update-ами с количеством переданных/принятых конкретной сессией байт, разве нет? Зачем усложнять, когда можно использовать простое во всех смыслах решение? Я понимаю, что вопрос не к вам, просто воздух сотрясаю.

Давайте, расскажите нам пожалуйста о хайлоаде

 

 

Просто вопрос к разработчикам. Очевидно, что со старгейзером в качестве бэкенда вы упёрлись в потолок его возможностей:

Нет, очевидно вы просто не понимаете архитектуры решения, как собственно и не знакомы с существующим функционалом в принципе.

 

 

 

* отсутствие тарифов с посуточной оплатой. Имеется в виду, когда пользователь подключается к инету, с него списывается N денег в день, пока он инетом пользуется.

документация для лохов... да...

 

http://stargazer.dp.ua/download/server/2.408/stargazer_help_v2.17.pdf

http://wiki.ubilling.net.ua/doku.php?id=stargazerdailyfee

 

 

* отсутствие контролируемых движком биллинга доп.услуг.

Ага, есть только возможность тарифицировать кофе в постель и начислять дополнительно за шлюх которые его приносят, но вы ж хотите стремные велосипеды, да?

 

 

 

Вы не думали начать разрабатывать свой движок биллинга? Понимаю что старгейзер крут в плане производительности, но мне кажется что можно достичь приемлемой производительности на perl/python/java вместо с++ с многопоточностью, как в старгейзере.

Давайте, пишите, позволяю. Мы с удовольствием понаблюдаем за этим увлекательным процессом.

А пока вам "кажется" мы - точно знаем для кого и что мы делаем. К слову именно об этом говорится в последнем пункте FAQ. Но вы же слишком круты, чтобы читать документацию, это же для лохов, да?

Відредаговано 2015-03-19 00:42:13 nightfly

[sanyadnepr 305]

Просто вопрос к разработчикам. Очевидно, что со старгейзером в качестве бэкенда вы упёрлись в потолок его возможностей:

* скидки, которые начисляют деньги абону вместо удешевления конкретно для него тарифа,

* отсутствие тарифов с посуточной оплатой. Имеется в виду, когда пользователь подключается к инету, с него списывается N денег в день, пока он инетом пользуется.

* отсутствие контролируемых движком биллинга доп.услуг.

* больше не вспомнил. Вы не думали начать разрабатывать свой движок биллинга?

Очевидно что вы не потрудились почитать документацию и форум хоть по диагонали.

Понимаю что старгейзер крут в плане производительности, но мне кажется что можно достичь приемлемой производительности на perl/python/java вместо с++ с многопоточностью, как в старгейзере.

Когда кажется креститься надо а когда крестишься еще больше кажется  

 

[SoulRoot 0]

 

 

... вместо с++ ...

 

Ох, не почитав я бы тему всю, начал бы что-то говорить против. Но так, я прочитал и понял что человек просто извращенец...