1b.app
Скопирована ссылка -

Вынести базу бокса на отдельный сервер

Есть идея вынести БД бокса на отдельный сервер (нужно для интеграции с другими системами) чтобы не делать двух сторонние интеграции, так как они работают с задержкой в минуту или 5 минут, а то больше. Это не удобно. + как показала практика, какие-то наши внедрения у вас могут синхронизировать с боксом год. ((
Вообщем нужно разделить бокс на разные сервера БД отдельно, медиа отдельно.

Есть ли у вас описание структуры с описанием БД бокса для программера? И можно ли вообще это реализовать?

Ответы:

Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan)
Мне кажется это плохая затея, так как последствия не работы одного сервера могут быть плачевными, ну а также задержки передачи между серверами.
Вы бы лучше решали проблемы с интеграциями, то что вы описываете "внедрения у вас могут синхронизировать с боксом год" не есть нормой
30.09.2020, 22:46


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


Для нас не проблема поддерживать связанность двух серверов. Они находятся в своей гермозоне. Решение задачи позволит подключатся всем системам биллинг/ERP/etc. к одной БД и вносить актуальные изменения онлайн.
Хуже тот, костыль которых построили сейчас, как оказалось это более сложная затея, которую пытаются решить уже более года. А именно построить синхронный импорт/экспорт для биллинг<->CRM
30.09.2020, 23:47

Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan)

Кушнир Александр Клиент писал/а:
Куприян Влад Валерьевич Клиент писал/а:Мне кажется это плохая затея, так как последствия не работы одного сервера могут быть плачевными, ну а также задержки передачи между серверами.Вы бы лучше решали проблемы с интеграциями, то что вы описываете "внедрения у вас могут синхронизировать с боксом год" не есть нормойДля нас не проблема поддерживать связанность двух серверов. Они находятся в своей гермозоне. Решение задачи позволит подключатся всем системам биллинг/ERP/etc. к одной БД и вносить актуальные изменения онлайн.Хуже тот, костыль которых построили сейчас, как оказалось это более сложная затея, которую пытаются решить уже более года. А именно построить синхронный импорт/экспорт для биллинг<->CRM

Что вам мешает весь обмен переделать через API, тут у вас появится и скорость и доступ ?
Просто понимаете если вы пустите в БД другого разработчика то там начнется "срачь" за которым нужно следить (логгировать), а это еще один "головнять" для ПМ-ма проекта
01.10.2020, 00:02


Куприян Влад Валерьевич Клиент писал/а:
Что вам мешает весь обмен переделать через API, тут у вас появится и скорость и доступ ?


Отсутствие API у сервисов с которыми строится связка. Одна система без API, вторая работает по API но только на импорт в систему, а любые доработки выполняются только их разработчиками системы (появляется зависимость от скорости реализации задач). А Бокс со своим API.
Своя инфраструктура более быстрее в реализации. + за логирование подключим в graylog.
01.10.2020, 00:32

Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan)
Понятно только что у вас много переменных в вашей задаче :)

Ну давайте подождем ответа Устименко или Мирошниченко, мне кажется за такую задачу браться не будут, так как тут много подводных камней в том числе которые отвечают за поддержку продукта, это все нужно где-то прописывать
01.10.2020, 00:41


Куприян Влад Валерьевич Клиент писал/а:
Понятно только что у вас много переменных в вашей задаче :)Ну давайте подождем ответа Устименко или Мирошниченко, мне кажется за такую задачу браться не будут, так как тут много подводных камней в том числе которые отвечают за поддержку продукта, это все нужно где-то прописывать

Реальная боль работы в CRM сейчас только увеличивается, вот только представьте весь путь оформления клиента в CRM сейчас.
Из телефонии завели контакт в бокс, создали ему карточку с фио и тел и др. Далее чтобы предоставлять клиенту услугу (тв/интернет и др.) его нужно передать в биллинг (биллинг следит за оплатами и разрешает Radius серверу авторизовать клиента)
Так как нет двухстороннего импорта/экспорта в бокс-биллинг, то приходится создавать учетную запись отдельно в биллинге.
Но работает импорт в бокс из биллинга. Сейчас Бокс создает дубль заявки и получается задвоение клиентов в боксе. (клиенты заведенные в боксе и клиенты импортированные из биллинга)
Остановить бокс на импорт нежелательно, так как в нем используются бизнес-процессы и считается по ним ЗП менеджера)
А экспорт из бокса полноценно еще не работает в биллинг, чтобы в одной системе создавать учетку.
И есть еще третья система ERP с которой планировали построить интеграцию, но теперь задумался сколько еще на это нужно времени :)
Надеюсь понятно объяснил про все переменные.

Я с Мирошниченко общался по этому поводу. Давайте подождем его возвращения, понимаю что он пока не доступен, пусть поправляется.
01.10.2020, 01:04

Писать что-то в базу данных OneBox'a напрямую - не стоит (даже "нельзя").
OneBox - это не софт, который пишется "от базы данных". Не все так просто.

Сама БД OneBox'a - не нормализированна согласно всем канонам ANSI SQL. Это цена производительности, чтобы OneBox мог переваривать десятки миллионы контактов и десятки миллионов ордеров.
Простыми словами (для тех кто не в теме SQL'a) - одни и те же данные могут дублироваться в разные ячейки разных таблиц. Для производительности выборок.

Базу данных OneBox'a контроллирует так называемый ORM SQLObject. Это важная история:
когда OneBox обновляется, SQLObject смотрит какие колонки куда добавить, какие убрать, для каких поменять тип данных. Если вы добавите колонку в базу данных - ничего страшного, ее SQLObject не тронет. Но, если вы руками поменяете колонку - SQLObject через 1 минуту вернет тип данных на место согласно конфигурации ORM.

Никому не стоит привязываться к базе данных OneBox'a - потому что мы ее меняем.
Мы без проблем можем переименовать таблицу, создать новую структуру таблиц и сконвертить данные между ними даже в пределах одной версии, а клиент этого даже не заметит.

---

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

Вариант 1, самый правильный
OneBox стукается в API billing'a и меняем там что нужно.
Если API нету - можно сделать вполне конкретные скрипты на php/perl/python/cgi которые будут принимать GET/POST параметры и запускать нужный SQL.

Вариант 2
Есть некий скрипт на стороне биллинга (или близко к нему), который стукается в API OneBox'a, получает данные, затем SQL-ом меняется то надо в биллинге.

Вариант 3
Перевести биллинг на сторону OneBox'a.
Я понимаю что вы на это сейчас не согласитесь, но по сути даже первая версия OneBox'a https://crm-onebox.com/ru/version/ начиналась с биллинга для интернет-провайдера и OneBox напрямую вел тарификацию и контроллировал raduis-сервера. Эх, хорошие времена были :)

---

Самый классный вариант 1 - сделайте на своей стороне мега-простое API, без авторизации (ну или IP restricted авторизацию), которое будет делать только нужное добавление обновление юзера.
Я понимаю, что задачка не простая.
Дайте контакт технаря который пилит биллинг напрямую - и я ее решу. Только технаря напрямую, если там будет какой-то менеджер и он что-то будет согласовывать - ой все :)
21.10.2020, 22:27
Как со мной связаться - никак :)
Задавайте вопросы на форуме публично - и я отвечу.
Подробнее - https://1b.app/ru/user/11/

Связался с Сергей Изотовым

обсудили вариант решения всех вопросов

вопрос решаем
29.10.2020, 15:33

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