BiTel

Думаю о том как можно прикрутить новую штуку к биллингу
Абонент получает gps трекер. Мы заводим абонента в биллинге. Каждый трекер это предположим сервис inet. Но тут спорный вопрос как лучше его вести. В доработанном личном кабинете абонент может получать различную аналитику по его трекерам. Главная проблема как используя максимально родные для биллинга средства забирать с датчиков информацию? С программированием проблем нет, вопрос в архитектуре - каким путем лучше пойти. Может какой модуль получится приладить для этого?

а по конкретнее можно?
что нужно считать, как управлять, какие тарифы?

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

С управлением тоже нет проблем. Если хранить трекер в договоре в виде сервиса inet, то там же можно хранить номер сим карты вставленной в трекер и написать обработчик который будет при определенных событиях отправлять на трекер команды в виде смс.

В общем пока я не понимаю как получать данные от трекера. При этом надо понимать что данные могут быть абсолютно разные как и трекеры.

что то я не понимаю какая связь между трекерами и биллингом?
вам просто нужна оболочка для хранения и отображения каких то "левых" данных?

Не нужно задаваться вопросом ЗАЧЕМ, в топике главный вопрос КАК. Представьте на минуту что вам надо это сделать на основе bgbilling и предложите решения которые приходят в голову. Биллинг мне нужен как оболочка для хранения данных об абонентах, их устройств, их баланса, привязки платежных систем, управления устройствами средствами модуля inet, личного кабинета (с доработкой). Я достаточно давно пользуюсь bgbilling для операторских нужд поэтому понимая его возможности сделал вывод что bgbilling подходит и для моей задачи с трекерами
Чтобы запустить это мне надо решить задачу:

Разные устройства определенных заранее типов присылают данные биллингу
Как с минимальным вмешательством в систему получать эти данные и хранить

Откуда я знаю может вы уже делали что то подобное или что то можно применить для этого

Вопрос "зачем" не стоит. Стоит вопрос "в чём вообще задача"? Ну напишите отдельный сервлет, который будет принимать данные. Создайте таблицу в БД куда он будет их складывать.
Но дальше то что?

_________________
I'm clever. I've got a computer.

не ответив на вопрос "зачем" не возможно ответить на вопрос "как".

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

если бы биллинг опрашивал, то можно было использовать тот, обработчик который snmp считывает. А если слушатель с нашей стороны , то только если свой класс-слушатель напишите и добавите его в accounting.xml по аналогии с radius или netflow слушателями . И пусть он грабит корованы

Ну наконец то ) Где же ты раньше был добрый человек. Копну в этом направлении.

Я это в качестве шутки, можно сказать, предложил. Вы например можете не биллинг встроить, а в какой-нибудь другое приложение-контейнер. В данном случае связь примерно как если в нашем sh-файле вы прописали дополнительно запуск своего демона слушающего ваш протокол. Т.е никакой связи с биллингом и нашим приложением.

Я просто не могу понять что именно вам не ясно. Зачем в каком смысле? Зачем использовать для этого bgbilling? Или вообще не понятно что я хочу?

Вы не поставили ни одного конкретного вопроса или задачи. "абонент получает gps трекер" можно заменить на "абонент варит борщи" и далее по тексту, и ничего не изменится. Чо за данные? Нафига они в биллинге? Что вы собираетесь с ними делать? В чём заключается их обработка, использование?
Вы же спрашиваете о том, какой модуль больше подходит.
Потому что, думаю, заведомо понятно, что всё это можно сделать костялями в биллинге, там даже слишком много путей для этого. Завести таблицу и там хранить. Но тогда причём бы тут был биллинг и вопросы?

_________________
I'm clever. I've got a computer.

Не понимаю вопросов "при чем тут биллинг?".
Человек хочет считать реальные бабки сертифицированной АСР.
БГБ является сертифицированной АСР. Поскольку БГБ зело гибкий, то человек может, в своей конторе, заменить понятие "байт" на "кол-во тарелок борща" и скормив БГБ эти "байты" посчитать тарелки борща.

Где-то тут есть человек, который через БГБ считает рендеринг 3D рендер фермой, а вы говорите "при чем тут биллинг?"

Насколько я могу судить, что то схожее с модулем phone/VoiceIP требуется идентификатор в виде номера сим карты, аккаунтинг по gps координатам и вывод всего этого в личный кабинет. Но не понятно если нет проблем почему бы не сделать как димон писал:

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

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

Я, возможно, могу пояснить. На вопрос "зачем" ответ "что бы отображать дополнительную информацию в личном кабинете". На вопрос "при чем тут биллинг" ответ "потому что клиент платит за трекер/устройство, следовательно в биллинге есть уже договор, услуга и объект, а еще потому что 10 различных ЛК для клиента это не удобно". Сами геоданные, естественно совершенно левые для биллинга (хотя я знаю платформы где оплачивается каждый запрос координат).

Написал тут просто потому что обдумывается схожая задача. И, если я правильно понимаю возможности и архитектуру, то если эти геоданные будут "приходить", то надо написать свой сервлет, а если данные "пулятся", то можно написать свою задачу планировщика. Так?
Хотел вот только спросить поделиться паттернами по работе с БД, есть в BGB свое API для работы с БД? Например, для организации сплитящихся таблиц по типу bgs_query_201601.