1b.app
Скопійоване посилання -

Винести базу боксу на окремий сервер

Є ідея винести БД боксу на окремий сервер (потрібно для інтеграції з іншими системами) щоб не робити двох сторонніх інтеграцій, тому що вони працюють із затримкою в хвилину або 5 хвилин, а то більше. Це не зручно. Як показала практика, якісь наші впровадження у вас можуть синхронізувати з боксом рік. ((
Взагалі необхідно розділити бокс на різні сервери БД окремо, медіа окремо.
Чи є у вас опис структури з описом БД боксу для програміста? І чи можна це взагалі реалізувати?
Оригінальне питання доступне на версії: ru

Відповіді:

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


Купріян Влад Валерійович Клієнт написав:
Мені здається це погана витівка, так як наслідки не роботи одного сервера можуть бути плачевними, ну а також затримки передачі між серверами.

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

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

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

Що вам заважає весь обмін переробити через API, тут у вас з'явиться швидкість і доступ?
Просто розумієте якщо ви пустите в БД іншого розробника, то там почнеться "срач" за яким потрібно стежити (логгувати), а це ще один "головлювати" для ПМ-му проекту
01.10.2020, 00:02
Оригінальний коментар доступний на версії: ru


Купріян Влад Валерійович Клієнт написав:
Що вам заважає весь обмін переробити через API, тут у вас з'явиться швидкість і доступ?

Відсутність API у сервісів, з якими будується зв'язка. Одна система без API, друга працює з API але тільки імпорт в систему, а будь-які доробки виконуються лише їх розробниками системи (з'являється залежність від швидкості реалізації завдань). А Бокс зі своїм API.
Своя інфраструктура швидше у реалізації. + за логування підключимо до graylog.
01.10.2020, 00:32
Оригінальний коментар доступний на версії: ru

Куприян Владислав Валерьевич
Baza.cn.ua / Integrator (FOP Kupriyan)
Зрозуміло тільки що у вас багато змінних у вашому завданні.
Ну давайте почекаємо відповіді Устименка чи Мірошниченка, мені здається за таке завдання братися не будуть, тому що тут багато підводних каменів у тому числі які відповідають за підтримку продукту, це все потрібно десь прописувати
01.10.2020, 00:41
Оригінальний коментар доступний на версії: ru


Купріян Влад Валерійович Клієнт написав:
Зрозуміло тільки що у вас багато змінних у вашому завданні :) Ну давайте почекаємо відповіді Устименка або Мірошниченка, мені здається за таке завдання братися не будуть, тому що тут багато підводних каменів, які відповідають за підтримку продукту, це все потрібно десь прописувати

Реальний біль роботи у CRM зараз тільки збільшується, ось тільки уявіть весь шлях оформлення клієнта у CRM зараз.
З телефонії завели контакт у бокс, створили йому картку з фіо та тіл та ін. Далі щоб надавати клієнту послугу (тв/інтернет та ін.) його потрібно передати в білінг (білінг стежить за оплатами і дозволяє Radius серверу авторизувати клієнта)
Оскільки немає двостороннього імпорту/експорту у бокс-білінг, то доводиться створювати обліковий запис окремо у білінгу.
Але працює імпорт у бокс із білінгу. Зараз Бокс створює дубль заявки та виходить задваювання клієнтів у боксі. (Клієнти заведені в боксі та клієнти імпортовані з білінгу)
Зупинити бокс на імпорт небажано, тому що в ньому використовуються бізнес-процеси і вважається за ними ЗП менеджера)
А експорт із боксу повноцінно ще не працює у білінг, щоб в одній системі створювати облік.
І є ще третя система ERP, з якої планували побудувати інтеграцію, але тепер задумався скільки ще на це потрібно часу :)
Сподіваюся, зрозуміло пояснив про всі змінні.
Я з Мірошниченком спілкувався з цього приводу. Давайте почекаємо його повернення, розумію що він поки не доступний, нехай видужує.
01.10.2020, 01:04
Оригінальний коментар доступний на версії: ru

Писати щось у базу даних 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 починалася з білінгу для інтернет-провайдера і OneBox безпосередньо вів тарифікацію і контролював raduis-сервера. . Ех, добрі часи були :)
---
Найкласніший варіант 1 - зробіть на своїй стороні мега-просте API, без авторизації (ну або IP restricted авторизацію), яке буде робити тільки необхідне додавання оновлення користувача.
Я розумію, що завдання не просте.
Дайте контакт технаря який пиляє білінг безпосередньо - і я її вирішу. Тільки технаря прямо, якщо там буде якийсь менеджер і він щось узгоджуватиме - ой все :)
21.10.2020, 22:27
Как со мной связаться - никак :)
Задавайте вопросы на форуме публично - и я отвечу.
Подробнее - https://1b.app/ru/user/11/
Оригінальний коментар доступний на версії: ru

Зв'язався із Сергій Ізотовим
обговорили варіант вирішення всіх питань
питання вирішуємо
29.10.2020, 15:33
Оригінальний коментар доступний на версії: ru

Будь ласка, приєднуйтесь до діалогу. Якщо вам є що сказати – будь ласка, напишіть коментар. Для входу потрібний мобільний телефон та смс-код для ідентифікації. Увійти та написати коментар