Розробка white-label рішення на 1С-Бітрікс

Розробка white-label рішення на 1С-Бітрікс

Компанія-розробник створює продукт, який клієнти продають під своїм брендом — це white-label. Агрегатор турів, платіжний шлюз, CRM-система або маркетплейс: все це можна побудувати як white-label на 1С-Бітрікс. Один код, десятки інсталяцій з різним брендингом — або одна інсталяція з мультитенантністю. Ми спеціалізуємося на таких рішеннях і гарантуємо архітектуру, яка масштабується від 5 до 500 клієнтів без переписування ядра.

Ключове технічне питання при старті — вибір між однією кодовою базою на всіх клієнтів або окремим інстансом на кожного. Цей вибір визначає подальшу архітектуру, вартість підтримки та швидкість впровадження. Нижче розберемо обидві моделі.

Дві архітектурні моделі

Мультисайтовість Бітрікс (один інстанс, кілька сайтів). Бітрікс підтримує кілька сайтів в рамках однієї установки. Кожен сайт — запис у b_lang, окремий шаблон у /local/templates/{SITE_ID}/, свої налаштування в b_option. Дані (товари, користувачі, замовлення) можуть бути спільними або розділеними по сайтах. Підходить коли клієнтів мало (до 20–30 сайтів), дані частково спільні, одна команда адмініструє всі сайти. Економія на ліцензіях досягає 30%.

Окремі інсталяції. Кожен клієнт отримує незалежну установку Бітрікс. Спільна кодова база поставляється як модуль або через Git. Оновлення розгортаються окремо на кожен інстанс. Підходить коли клієнти хочуть незалежність (свої дані, свої бекапи), потрібна різна конфігурація, або суворі вимоги до ізоляції даних (GDPR, медицина).

Як працює мультитенантність в одній інсталяції?

Для агрегаторів і SaaS-продуктів на Бітрікс будується мультитенантна архітектура:

• Таблиця b_lang — кожен сайт (тенант) з унікальним LID
• Шаблони — спільний базовий шаблон (/local/templates/base/) + перевизначення в /local/templates/{TENANT_ID}/
• Налаштування тенанта — кастомна таблиця b_tenant_settings з парами TENANT_ID / KEY / VALUE
• Користувачі — спільна таблиця b_user, розділення за групами та за SITE_ID

Брендування кожного тенанта:

// В init.php або в header шаблону $tenantId = SITE_ID; $tenantConf = TenantSettingsTable::getByTenantId($tenantId); define('TENANT_PRIMARY_COLOR', $tenantConf['PRIMARY_COLOR'] ?? '#0052cc'); define('TENANT_LOGO_URL', $tenantConf['LOGO_URL'] ?? '/logo.svg'); define('TENANT_DOMAIN', $tenantConf['DOMAIN']); 

CSS-змінні генеруються динамічно через PHP, кешуються на рівні сторінки:

$css = ":root { --primary: " . TENANT_PRIMARY_COLOR . "; --brand-font: " . $tenantConf['FONT'] . "; }"; 

Розробка ядра продукту як Бітрікс-модуля

Якщо код продукту поставляється кільком клієнтам, його краще оформити як модуль Бітрікс. Модуль встановлюється через /bitrix/admin/partner_modules.php, реєструється в b_module:

/local/modules/vendor.whitelabel/ ├── install/ │ ├── index.php │ └── db/install.sql ├── lib/ │ ├── TenantManager.php │ ├── BrandingService.php │ └── ... ├── options.php └── include.php 

Перевага: модуль оновлюється через стандартний механізм Бітрікс (ModuleManager::isModuleInstalled(), ModuleManager::install()), аналогічно стандартним модулям. На практиці це скорочує час деплою оновлень на 50%.

Розмежування функціональності за тарифами

White-label часто передбачає тарифні плани: базовий, стандарт, преміум. Кожен тарифний план відкриває/закриває частину функціоналу.

Перевірка доступності функції:

public static function hasFeature(string $feature, string $tenantId = SITE_ID): bool { $plan = self::getTenantPlan($tenantId); $features = self::PLAN_FEATURES[$plan] ?? []; return in_array($feature, $features, true); } if (!TenantLicenseManager::hasFeature('advanced_analytics')) { // Заглушка або редирект на сторінку апгрейду } 

Матриця функцій зберігається в коді або в БД. Зміни тарифу застосовуються без деплою.

Адміністративний інтерфейс для клієнтів

Клієнт white-label продукту повинен керувати своїм екземпляром. Це не стандартна адмінка Бітрікс — вона надлишкова та небезпечна. Будується окремий «особистий кабінет партнера»:

• Керування брендингом (завантаження логотипу, вибір кольорів)
• Керування користувачами свого тенанта
• Перегляд статистики та аналітики
• Налаштування сповіщень та інтеграцій

Реалізація — окремий розділ сайту з авторизацією за групою TENANT_ADMIN. Компоненти в /local/components/vendor.whitelabel/tenant.admin.*.

Чому важлива ізоляція даних між тенантами?

Критичне питання безпеки: дані тенанта A не повинні бути видні тенанту B. У всіх запитах до інфоблоків додається обов'язковий фільтр по SITE_ID або по кастомному полю TENANT_ID:

$filter = array_merge($userFilter, ['=PROPERTY.TENANT_ID' => CURRENT_TENANT_ID]); $res = CIBlockElement::GetList([], $filter, ...); 

Для критичних даних (платіжна інформація, персональні дані) рекомендується розділення баз даних між тенантами — кожен тенант працює зі своєю схемою PostgreSQL. Бітрікс не підтримує це з коробки, але через перемикання $DB об'єкта на початку кожного запиту це реалізовано.

Як оновлювати кодову базу при множині клієнтів?

Підтримка кількох інсталяцій — найскладніша операційна задача. При окремих інстансах потрібна система автоматичного деплою оновлень:

• Git-репозиторій з кодом модуля/шаблонів
• CI/CD (GitLab CI, GitHub Actions) з розгортанням на кожен сервер через SSH або Ansible
• Версіонування: модуль має VERSION в install/index.php, перед оновленням перевіряється сумісність з версією Бітрікс на сервері клієнта

При єдиній інсталяції оновлення простіше — один деплой.

Що входить в нашу роботу?

Ми надаємо повний комплект: документація по архітектурі, налаштування CI/CD, навчання команди клієнта, технічна підтримка на етапі запуску та супровід оновлень. Конкретний склад робіт уточнюється при постановці задачі.

Строки орієнтовно

Порівняння архітектур

White-label на Бітрікс — нестандартне застосування платформи, що вимагає глибокого розуміння її архітектури. При правильному проектуванні система масштабується від 5 до 500 клієнтів без переписування ядра. Наш досвід більше 10 років та сертифіковані спеціалісти гарантують надійність рішення. Замовте прототип вже сьогодні. Зв'яжіться з нами для консультації по архітектурі вашого продукту.