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

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

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

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

[quote] Куприян Влад Валерьевич Клиент писал/а: Что вам мешает весь обмен переделать через API, тут у вас появится и скорость и доступ ? [/quote] Отсутствие API у сервисов с которыми строится связка. Одна система без API, вторая работает по API но только на импорт в систему, а любые доработки выполняются только их разработчиками системы (появляется зависимость от скорости реализации задач). А Бокс со своим API. Своя инфраструктура более быстрее в реализации. + за логирование подключим в graylog.

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

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

Писать что-то в базу данных 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 авторизацию), которое будет делать только нужное добавление обновление юзера. Я понимаю, что задачка не простая. Дайте контакт технаря который пилит биллинг напрямую - и я ее решу. Только технаря напрямую, если там будет какой-то менеджер и он что-то будет согласовывать - ой все :)