Клієнт-серверний режим BAS

Клієнт-серверний режим BAS — це спосіб роботи інформаційної бази BAS, при якому користувачі підключаються до системи через клієнтські застосунки, а основна обробка даних виконується на сервері BAS / 1С і в системі керування базами даних. Такий режим використовується для більших баз, багатьох користувачів, складних облікових процесів, регламентних завдань, інтеграцій, web-доступу, підвищеної продуктивності й централізованого адміністрування.

На відміну від файлового режиму, де база зберігається у файлі, клієнт-серверний режим розділяє систему на кілька рівнів: клієнт, сервер застосунків і СУБД. Це дозволяє краще масштабувати роботу, контролювати доступ, виконувати фонові завдання, адмініструвати підключення користувачів і організовувати резервне копіювання на рівні бази даних.

Головне. Клієнт-серверний режим BAS — це архітектура, у якій користувач працює через клієнт, бізнес-логіка виконується на сервері BAS/1С, а дані зберігаються в СУБД. Такий режим потрібен для багатокористувацької роботи, великих баз, інтеграцій і стабільнішого адміністрування.

Важливо про BAS і 1С. BAS та 1С мають санкційні, юридичні й кібербезпекові ризики в Україні. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. Тому аналіз клієнт-серверної інфраструктури BAS варто розглядати як частину підготовки до контрольованого переходу на українську ERP-платформу.

Підхід K2 ERP. Під час переходу з BAS потрібно аналізувати не тільки довідники й документи, а й серверну архітектуру: де розміщена база, яка СУБД використовується, які є регламентні завдання, інтеграції, web-сервіси, користувачі, ролі, резервні копії, журнали й технічні обмеження.

Вступ

Клієнт-серверний режим використовується тоді, коли звичайної файлової бази вже недостатньо.

Типові причини переходу на клієнт-сервер:

багато одночасних користувачів;
велика база даних;
складні документи;
багато регламентних завдань;
активні інтеграції;
обмін із сайтом;
обмін із CRM;
обмін із WMS;
web-сервіси;
потреба в централізованому адмініструванні;
потреба в кращому контролі доступу;
потреба в резервному копіюванні на рівні СУБД;
потреба в стабільнішій роботі.

Наприклад, якщо в компанії одночасно працюють бухгалтерія, склад, продажі, закупівлі, каса, керівники, інтеграції із сайтом і регламентні завдання, файлова база може стати вузьким місцем. У такому випадку використовують клієнт-серверний режим.

Що таке клієнт-серверний режим BAS

Клієнт-серверний режим BAS — це архітектура, у якій система працює не як один файл на спільному диску, а як набір взаємопов’язаних компонентів.

Основні компоненти:

клієнтський застосунок;
сервер BAS / 1С;
кластер серверів;
СУБД;
інформаційна база;
регламентні завдання;
web-сервер, якщо використовується web-доступ;
інтеграційні сервіси;
адміністрування;
резервне копіювання.

Спрощена схема:

Користувач → Клієнт BAS → Сервер BAS/1С → СУБД → Дані інформаційної бази

Простими словами. У клієнт-серверному режимі користувач не працює напряму з файлом бази. Він підключається до сервера, а сервер уже звертається до бази даних.

Файловий і клієнт-серверний режим

У BAS зазвичай розрізняють файловий і клієнт-серверний режим.

Ознака	Файловий режим	Клієнт-серверний режим
Зберігання даних	Файл бази	СУБД
Підключення користувачів	До файлової бази	Через сервер BAS/1С
Масштабування	Обмежене	Краще для багатьох користувачів
Адміністрування	Просте, але менш контрольоване	Складніше, але гнучкіше
Резервне копіювання	Копія файлу або вивантаження	SQL-бекап, засоби СУБД, серверні процедури
Інтеграції	Можливі, але обмежені	Зручніше для web-сервісів і фонового обміну

Основні елементи архітектури

Клієнт-серверна архітектура BAS може включати:

робочі місця користувачів;
тонкий клієнт;
товстий клієнт;
веб-клієнт;
сервер BAS/1С;
кластер серверів;
сервер СУБД;
web-сервер;
файлові каталоги обміну;
сервер резервного копіювання;
інтеграційні шлюзи;
моніторинг;
журнал реєстрації.

Клієнт BAS

Клієнт — це програма або web-інтерфейс, через який користувач працює з базою.

Клієнт може бути:

тонкий клієнт;
товстий клієнт;
веб-клієнт;
мобільний або спеціальний клієнт, якщо він реалізований у конкретному рішенні.

Користувач через клієнт:

відкриває довідники;
створює документи;
проводить документи;
формує звіти;
запускає обробки;
працює з журналами;
виконує свої бізнес-задачі.

Тонкий клієнт BAS

Тонкий клієнт — це клієнтський застосунок, який виконує частину роботи на робочому місці користувача, але значна частина обробки відбувається на сервері.

Тонкий клієнт часто використовують для:

щоденної роботи користувачів;
підключення до серверної бази;
роботи через локальну мережу;
роботи через віддалене підключення;
зменшення навантаження на робоче місце.

Переваги:

легший за товстий клієнт;
краще підходить для серверного режиму;
простіше централізовано підтримувати;
може працювати з web-архітектурою.

Веб-клієнт BAS

Веб-клієнт дозволяє працювати через браузер.

Для цього зазвичай потрібні:

сервер BAS/1С;
web-сервер;
опублікована інформаційна база;
налаштований доступ;
HTTPS;
права користувачів;
контроль безпеки.

Веб-клієнт може бути корисним для:

віддалених користувачів;
філій;
керівників;
користувачів без встановленого клієнта;
окремих сценаріїв доступу.

Ризик безпеки. Публікація BAS у web без належного HTTPS, авторизації, обмеження доступу, журналювання й захисту може створити серйозні кібербезпекові ризики.

Сервер BAS / 1С

Сервер BAS/1С — це проміжний рівень між клієнтами й СУБД.

Він відповідає за:

виконання бізнес-логіки;
обробку запитів користувачів;
роботу сеансів;
виконання регламентних завдань;
роботу фонових завдань;
взаємодію із СУБД;
кешування;
контроль підключень;
адміністрування кластера;
виконання частини коду конфігурації.

Саме сервер дозволяє не підключати всіх користувачів напряму до бази даних.

Кластер серверів BAS

Кластер серверів — це група серверних процесів і служб, які обслуговують інформаційні бази.

У кластері можуть бути:

робочі сервери;
робочі процеси;
інформаційні бази;
сеанси користувачів;
фонова обробка;
регламентні завдання;
налаштування адміністрування.

Кластер допомагає централізовано керувати серверною роботою BAS.

Робочі процеси

Робочі процеси обробляють запити користувачів і фонових завдань.

На них впливають:

кількість користувачів;
складність конфігурації;
кількість звітів;
кількість документів;
запити до СУБД;
обробки;
інтеграції;
регламентні завдання.

Якщо робочих процесів недостатньо або сервер слабкий, користувачі можуть відчувати повільну роботу.

СУБД

СУБД — це система керування базами даних, у якій зберігаються дані інформаційної бази.

У СУБД зберігаються:

довідники;
документи;
регістри;
проводки;
користувачі;
налаштування;
службові таблиці;
історичні дані;
рухи;
журналові дані, залежно від налаштувань.

СУБД є критичною частиною клієнт-серверної архітектури.

Інформаційна база

Інформаційна база в клієнт-серверному режимі — це не просто файл, а база в СУБД плюс конфігурація та дані.

Вона містить:

конфігурацію;
дані користувачів;
довідники;
документи;
регістри;
налаштування;
права;
звіти;
службові дані.

Для користувача база виглядає так само, як звичайна BAS, але технічно вона працює через сервер і СУБД.

Підключення користувачів

У клієнт-серверному режимі користувач підключається до інформаційної бази через клієнт.

Приклад:

Користувач → Тонкий клієнт → Сервер BAS → Інформаційна база в СУБД

Підключення може бути:

локальне;
через корпоративну мережу;
через VPN;
через web-клієнт;
через віддалений робочий стіл;
через інтеграційний сервіс.

Сеанси користувачів

Сеанс — це активне підключення користувача або сервісу до бази.

Сеанс може належати:

звичайному користувачу;
адміністратору;
сервісному користувачу інтеграції;
регламентному завданню;
web-клієнту;
фоновому процесу.

Адміністратор може контролювати:

хто підключений;
з якого комп’ютера;
коли почав роботу;
які сеанси зависли;
кого потрібно відключити;
які завдання виконуються.

Регламентні завдання

Клієнт-серверний режим зручний для регламентних завдань.

Приклади:

нічний обмін із сайтом;
завантаження банківських виписок;
формування звітів;
оновлення курсів валют;
обробка замовлень;
вивантаження залишків;
синхронізація з CRM;
обмін із WMS;
очищення тимчасових даних;
службові перевірки.

Регламентні завдання можуть виконуватися на сервері без участі користувача.

Фонові завдання

Фонові завдання — це процеси, які виконуються паралельно з роботою користувачів.

Наприклад:

проведення великого пакета документів;
формування важкого звіту;
обмін даними;
імпорт;
експорт;
розрахунок собівартості;
оновлення залишків;
інтеграційна обробка.

Якщо фонові завдання налаштовані неправильно, вони можуть сповільнювати роботу всієї бази.

Продуктивність клієнт-серверного режиму

На продуктивність впливають:

потужність сервера BAS;
потужність сервера СУБД;
швидкість дисків;
обсяг оперативної пам’яті;
кількість користувачів;
складність конфігурації;
якість запитів;
індекси в СУБД;
регламентні завдання;
інтеграції;
мережа;
резервне копіювання;
антивірус;
застаріле обладнання.

Типові причини повільної роботи

Найчастіші причини:

слабкий сервер;
недостатньо оперативної пам’яті;
повільні диски;
перевантажена СУБД;
багато фонових завдань;
важкі звіти;
неоптимальні запити;
велика кількість старих документів;
нетипова конфігурація з поганим кодом;
інтеграції запускаються в робочий час;
немає регламентного обслуговування СУБД.

Приклад навантаження

Сценарій	Можливе навантаження	Що перевірити
10 користувачів	Невелике	Сервер, мережа, базові налаштування
50 користувачів	Середнє	СУБД, пам’ять, фонові завдання
100+ користувачів	Високе	Архітектуру, кластер, СУБД, індекси, інтеграції
Багато web-сервісів	Нерівномірне	API, черги, логи, таймаути

Резервне копіювання

У клієнт-серверному режимі резервне копіювання потрібно організовувати уважно.

Можливі варіанти:

резервна копія засобами СУБД;
вивантаження інформаційної бази;
знімок сервера;
копія віртуальної машини;
копія файлових каталогів обміну;
копія зовнішніх обробок;
копія web-публікацій;
копія налаштувань інтеграцій.

Важливо. Резервна копія клієнт-серверної BAS має включати не тільки дані в СУБД, а й пов’язані файли, обробки, інтеграційні каталоги, налаштування сервера і документацію відновлення.

Відновлення з резервної копії

Резервна копія має сенс тільки тоді, коли її можна відновити.

Потрібно перевіряти:

чи створюється бекап;
чи немає помилок;
чи можна відновити базу;
чи відкривається база після відновлення;
чи працюють користувачі;
чи працюють регламентні завдання;
чи працюють інтеграції;
чи збережені зовнішні файли;
чи збережені права;
чи є інструкція відновлення.

Адміністрування клієнт-серверної BAS

Адміністрування включає:

створення інформаційних баз;
налаштування кластера;
керування сеансами;
керування користувачами;
контроль регламентних завдань;
моніторинг продуктивності;
резервне копіювання;
оновлення конфігурації;
оновлення платформи;
обслуговування СУБД;
аналіз журналу реєстрації;
контроль інтеграцій;
контроль прав доступу.

Користувачі і ролі

У клієнт-серверному режимі важливо правильно налаштувати користувачів.

Потрібно контролювати:

активних користувачів;
адміністраторів;
сервісних користувачів;
користувачів інтеграцій;
ролі;
групи доступу;
права на документи;
права на звіти;
права на обробки;
заборону зміни закритих періодів.

Сервісні користувачі

Сервісні користувачі часто використовуються для інтеграцій.

Наприклад:

Користувач	Призначення	Ризик
api_site	Обмін із сайтом	Може мати надмірні права
api_crm	Обмін із CRM	Може бачити персональні дані
exchange_wms	Обмін зі складом	Може змінювати складські документи
bi_export	Вивантаження в BI	Може читати фінансові дані

Під час міграції в K2 ERP потрібно знайти всі сервісні облікові записи.

Безпека клієнт-серверного режиму

Безпека має включати:

контроль користувачів;
складні паролі;
обмеження адміністраторів;
обмеження доступу до сервера;
захист СУБД;
захист резервних копій;
HTTPS для web-доступу;
VPN для віддаленої роботи;
журналювання;
антивірусний контроль;
оновлення серверів;
контроль інтеграцій;
аудит сервісних користувачів.

Доступ до СУБД

Прямий доступ до СУБД має бути обмежений.

Ризики прямого доступу:

випадкове пошкодження даних;
обхід прав BAS;
витік даних;
неконтрольовані SQL-запити;
зміна таблиць напряму;
проблеми з підтримкою;
складність аудиту.

Користувачі мають працювати через систему, а не напряму з таблицями СУБД.

Журнал реєстрації

Журнал реєстрації допомагає аналізувати:

входи користувачів;
помилки;
відмови доступу;
запуск обробок;
проведення документів;
роботу регламентних завдань;
інтеграційні події;
критичні зміни;
технічні проблеми.

Перед міграцією журнал може допомогти знайти активні процеси, які не описані в документації.

Web-сервер і публікація бази

Якщо використовується web-клієнт або HTTP-сервіси, потрібна публікація бази на web-сервері.

Потрібно перевірити:

які бази опубліковані;
які URL використовуються;
чи є HTTPS;
хто має доступ;
які HTTP-сервіси активні;
які web-сервіси активні;
чи є зовнішні інтеграції;
чи не відкрито зайвий доступ в інтернет.

Інтеграції в клієнт-серверному режимі

Клієнт-серверна BAS часто є центром інтеграцій.

Інтеграції можуть бути з:

сайтом;
CRM;
WMS;
банком;
касами;
РРО / ПРРО;
мобільними застосунками;
BI;
електронним документообігом;
GPS;
сервісами доставки;
маркетплейсами;
зовнішніми API.

Перед переходом у K2 ERP потрібно знайти всі інтеграції.

Файлові каталоги обміну

Навіть у клієнт-серверному режимі можуть використовуватися файлові обміни.

Наприклад:

XML;
JSON;
CSV;
Excel;
DBF;
ZIP-архіви;
банківські файли;
файли сайту;
файли складу;
файли податкових документів.

Такі каталоги потрібно включити в інвентаризацію і резервне копіювання.

Клієнт-серверний режим і оновлення BAS

Оновлення клієнт-серверної BAS потребує плану.

Перед оновленням потрібно:

зробити резервну копію;
перевірити версію платформи;
перевірити версію конфігурації;
перевірити розширення;
перевірити доробки;
перевірити зовнішні обробки;
перевірити регламентні завдання;
перевірити інтеграції;
виконати оновлення на тестовій базі;
провести контрольні звірки.

Тестова база

Тестова база в клієнт-серверному режимі потрібна для:

перевірки оновлень;
тестування доробок;
перевірки інтеграцій;
навчання користувачів;
тестової міграції;
перевірки продуктивності;
аналізу помилок.

Тестова база має бути чітко відокремлена від робочої, щоб користувачі не ввели туди реальні документи.

Клієнт-серверний режим і міграція в K2 ERP

Під час переходу з BAS у K2 ERP клієнт-серверну інфраструктуру потрібно аналізувати окремо.

Потрібно зібрати:

список інформаційних баз;
сервери BAS/1С;
сервери СУБД;
web-публікації;
регламентні завдання;
фонові завдання;
інтеграції;
користувачів;
ролі;
сервісні облікові записи;
резервні копії;
зовнішні обробки;
файлові каталоги;
журнали;
документацію.

Інвентаризація серверної інфраструктури

Приклад таблиці:

Об’єкт	Приклад	Що зробити при міграції
Сервер BAS	srv-bas-01	Зафіксувати роль і бази
СУБД	sql-bas-01	Зробити бекап і описати бази
Web-публікація	/bas/erp	Перевірити доступ і інтеграції
Регламентне завдання	Обмін із сайтом	Перенести сценарій у K2 ERP
Сервісний користувач	api_site	Замінити API-доступом K2 ERP

Що переносити в K2 ERP

З клієнт-серверної BAS не переносять сам сервер як є.

Потрібно перенести або переосмислити:

довідники;
документи;
залишки;
відкриті операції;
права доступу;
ролі;
інтеграції;
регламентні завдання;
API-сценарії;
BI-показники;
журнали, якщо вони потрібні для аудиту;
архівні дані;
резервну стратегію;
бізнес-процеси.

Що залишити в архіві

Після запуску K2 ERP стара клієнт-серверна BAS може залишитися як архів.

В архіві можуть бути:

історичні документи;
проводки;
звіти;
друковані форми;
журнал реєстрації;
старі інтеграційні логи;
старі обробки;
стара конфігурація;
дані для аудиту.

Але архів не повинен бути активним джерелом нових операцій.

Типові помилки клієнт-серверного режиму BAS

Найчастіші проблеми:

немає резервних копій СУБД;
резервні копії не перевіряються;
сервер перевантажений;
СУБД не обслуговується;
фонові завдання запускаються в піковий час;
web-публікації відкриті без належного захисту;
сервісні користувачі мають надмірні права;
інтеграції не документовані;
журнал реєстрації занадто великий або не аналізується;
тестова база не відокремлена від робочої;
старі користувачі не заблоковані;
немає плану аварійного відновлення.

Помилка: не перевіряти резервне відновлення

Наявність SQL-бекапу не гарантує, що база відновиться.

Потрібно періодично перевіряти:

відновлення на тестовому сервері;
запуск клієнта;
доступ користувачів;
роботу регламентних завдань;
інтеграції;
звіти;
цілісність даних.

Помилка: залишити старі інтеграції активними

Після переходу в K2 ERP стара BAS може продовжувати приймати або відправляти дані.

Ризики:

сайт бере залишки зі старої BAS;
CRM створює замовлення в старій BAS;
BI читає старі дані;
WMS синхронізується не з тією системою;
користувачі бачать різні цифри;
джерело істини зникає.

Після запуску K2 ERP старі інтеграції потрібно вимкнути або перевести в архівний режим.

Помилка: не врахувати регламентні завдання

Регламентні завдання можуть виконувати критичні процеси.

Наприклад:

оновлення курсів валют;
обмін із сайтом;
завантаження замовлень;
вивантаження залишків;
синхронізація з CRM;
формування звітів;
очищення даних.

Якщо їх не перенести або не замінити, частина бізнес-процесів зупиниться.

Помилка: не перевірити сервісних користувачів

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

Після міграції потрібно:

знайти всі такі облікові записи;
зрозуміти, для чого вони потрібні;
вимкнути зайві;
замінити доступ на API K2 ERP;
змінити токени й паролі;
перевірити журнали доступу.

Як не треба робити

Погані підходи:

не робити резервну копію перед змінами;
не перевіряти відновлення;
не документувати сервери;
не знати, де розміщена СУБД;
не контролювати web-публікації;
не знати всі інтеграції;
не перевіряти регламентні завдання;
не аналізувати сервісних користувачів;
залишати BAS активною після запуску K2 ERP;
ігнорувати санкційні й кібербезпекові ризики.

Найгірший сценарій. Компанія переходить у K2 ERP, але залишає клієнт-серверну BAS активною: web-сервіси працюють, регламентні завдання обмінюються даними, BI читає стару базу, а користувачі продовжують вводити документи у дві системи.

Як правильно аналізувати клієнт-серверну BAS перед міграцією

Правильний порядок:

Зробити резервну копію.
Зафіксувати список інформаційних баз.
Визначити сервер BAS/1С.
Визначити сервер СУБД.
Перевірити web-публікації.
Перевірити користувачів.
Перевірити сервісні облікові записи.
Перевірити ролі й права.
Перевірити регламентні завдання.
Перевірити фонові завдання.
Перевірити інтеграції.
Перевірити файлові каталоги обміну.
Перевірити зовнішні обробки.
Перевірити журнал реєстрації.
Перевірити резервне відновлення.
Описати критичні процеси.
Перенести потрібні сценарії в K2 ERP.
Вимкнути старі інтеграції після запуску.
Перевести BAS в архівний режим.

Клієнт-серверний режим і цифрова незалежність

Аналіз клієнт-серверної BAS — це частина виходу зі старої ризикової системи.

Компанія повинна:

знати, де розміщені її дані;
контролювати сервери;
контролювати доступи;
контролювати резервні копії;
знайти всі інтеграції;
знайти всі web-публікації;
перенести потрібні процеси в K2 ERP;
вимкнути старі канали обміну;
не залишити BAS прихованим центром обліку;
зменшити залежність від BAS і 1С.

Цифрова незалежність. Клієнт-серверна BAS часто є центральним вузлом старої ІТ-архітектури. Завдання міграції — не просто перенести дані, а забрати контроль над серверами, доступами, інтеграціями, резервними копіями й бізнес-процесами в K2 ERP.

Коротко

Питання	Відповідь
Що таке клієнт-серверний режим BAS?	Це режим, у якому користувачі працюють через клієнт, бізнес-логіка виконується на сервері BAS/1С, а дані зберігаються в СУБД.
Чим він відрізняється від файлового режиму?	У файловому режимі база зберігається у файлі, а в клієнт-серверному — у СУБД і обслуговується сервером.
Коли потрібен клієнт-сервер?	Коли багато користувачів, велика база, складні звіти, інтеграції, web-доступ, регламентні завдання або високі вимоги до адміністрування.
Що важливо для безпеки?	Контроль користувачів, HTTPS, VPN, обмеження доступу до СУБД, захист резервних копій, аудит сервісних облікових записів.
Що перевірити перед міграцією?	Сервери, СУБД, бази, користувачів, ролі, регламентні завдання, інтеграції, web-публікації, резервні копії й журнали.
Чи потрібно переносити сервер BAS у K2 ERP?	Ні. Потрібно перенести дані, процеси, інтеграції, права, API-сценарії, BI-показники й правила роботи.
Яка головна помилка?	Залишити стару клієнт-серверну BAS активним центром інтеграцій після запуску K2 ERP.
Чи є санкційні ризики у BAS і 1С?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

Клієнт-серверний режим BAS — це важлива архітектура для великих і середніх інформаційних баз. Він дозволяє працювати багатьом користувачам, виконувати регламентні завдання, обслуговувати інтеграції, використовувати СУБД, web-клієнт, фонові процеси й централізоване адміністрування.

Але під час переходу на K2 ERP клієнт-серверну BAS потрібно аналізувати дуже уважно.

Потрібно:

зробити резервну копію;
описати сервери;
описати СУБД;
описати інформаційні бази;
перевірити користувачів і ролі;
знайти всі інтеграції;
перевірити web-публікації;
перевірити регламентні завдання;
перевірити резервне відновлення;
перенести потрібні процеси в K2 ERP;
вимкнути старі інтеграції;
залишити BAS тільки як архів, якщо це потрібно.

Правильний підхід. Клієнт-серверний режим BAS потрібно розглядати не лише як технічну інфраструктуру, а як карту старих бізнес-процесів, інтеграцій, доступів, регламентних завдань і ризиків, які потрібно контрольовано перенести або замінити в K2 ERP.

З урахуванням санкційних, юридичних і кібербезпекових ризиків BAS та 1С, аналіз клієнт-серверної інфраструктури має бути частиною ширшої стратегії переходу на українське програмне забезпечення, цифрову незалежність і сучасну ERP-архітектуру.

K2 ERP у цьому процесі може стати новою платформою для контрольованих довідників, документів, інтеграцій, API, BI-аналітики, журналювання, прав доступу, резервного копіювання, web-доступу й подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С.

Див. також

Зовнішні посилання