Налаштування старих клієнтів
HandyCafe працює поряд зі старими інсталяціями клієнтів V3 і V4 без перешкод. Сторінка налаштувань для старих клієнтів керує двома окремими функціями:
- Режим виконання протоколу. Увімкнює мережеві listener-и, які дозволяють клієнтам V3 і V4 підключатися до цього сервера на своїх оригінальних портах.
- Міграція бази даних. За бажанням імпортує учасників, тарифи, товари, замовлення, транзакції та журнали зі старої локальної інсталяції в нову базу даних HandyCafe. Це працює лише на Windows.
Обидві функції незалежні. Ви можете увімкнути підтримку виконання без міграції даних, мігрувати дані без увімкнення виконання, або зробити обидва кроки.
Розділ режиму виконання протоколу
Увімкнути підтримку старих клієнтів
Головний перемикач у верхній частині розділу. Коли він увімкнений, сервер запускає три мережеві listener-и:
- UDP listener на налаштованій multicast-групі.
- TCP listener команд на
UDP port + 2. - TCP listener передачі файлів на
UDP port + 7.
Вимкнення перемикача зупиняє всі три listener-и атомарно. Ви можете змінити номери портів або кодування, поки перемикач вимкнений, а потім увімкнути його знову, щоб застосувати зміни.
Поля конфігурації
| Поле | Типове значення | Опис |
|---|---|---|
| Auth Key | HANDYCAFE | Спільний ключ довжиною 10 символів. Кожен вхідний і вихідний кадр містить цей рядок. Кадри, що не збігаються, відкидаються. Усі ваші старі клієнти мають використовувати той самий ключ. |
| UDP Multicast IP | 230.4.4.46 | Multicast-група, яка використовується для beacon-повідомлень виявлення клієнтів і для UDP-доставки команд. У більшості збірок старих клієнтів це значення зашите. |
| Server UDP Port | 710 | UDP-порт, на якому сервер слухає beacon-повідомлення та команди клієнтів. Старі клієнти надсилають трафік саме на цей порт. |
| Client UDP Port | 711 | UDP-порт, на якому слухають старі клієнти. Сервер надсилає унікальні адміністративні команди на цей порт за виявленою IP-адресою клієнта. |
| Encoding | cp1254 | Кодування символів для строкових полів у wire-форматі. Використовуйте cp1254 для турецьких інсталяцій, cp1252 для західноєвропейських. Невідомі значення повертаються до cp1254 з попередженням у журналі сервера. |
| Server Version | 3.4.01 | Рядок версії, який розсилається в кожному UDP beacon. Деякі старі клієнти відкидають кадри від версій, яких не розпізнають. Поставте тут значення, яке відповідає версії вашого старого сервера. |
| Protocol Variant | STE | Вибір wire-формату. Дивіться порівняння варіантів нижче. |
| Inactivity Timeout | 10 | Секунди. Watchdog для кожного MAC. Якщо від клієнта не надходить трафік у межах цього вікна, клієнт позначається як офлайн. Інтервал 10 секунд підходить для старих клієнтів, які надсилають beacon кожні 2 або 3 секунди. |
Похідні порти
Під формою сторінка показує лише для читання рядок із похідними TCP-портами:
TCP Command Port: 712 File Transfer Port: 717
Ці порти обчислюються з UDP-порту сервера. Окремо їх не налаштовують. Якщо змінити Server UDP Port на інше значення, похідні порти змістяться разом із ним.
Варіант протоколу
Поле Protocol Variant вибирає wire-формат, який використовує сервер. Оберіть той варіант, який відповідає тому, як збирався ваш старий сервер.
| Варіант | Коли використовувати |
|---|---|
| STE (Smart/Turbo Edition) | Сучасна база старого коду. Додає 70-байтовий префікс license-info до структури кадру. Розмір кадру - 1337 байтів. Обирайте, якщо ваша стара інсталяція була Smart або Turbo edition. |
| Standard | Звичайна базова стара збірка. Розмір кадру - 1267 байтів без префікса license-info. Обирайте лише якщо ваша стара інсталяція була Standard edition без реєстрації ліцензії. |
Неправильний варіант призводить до втрати кадрів або неправильного їхнього читання. Симптоми - клієнти показуються онлайн, але ігнорують усі команди, або дані команд зміщені на 70 байтів.
Співіснування із сучасними клієнтами
Старі порти (710, 711, 712, 717) повністю окремі від сучасних портів протоколу HandyCafe (TCP 5001, 5002, 5003, UDP 5004). Обидва стекі протоколів працюють одночасно без конфліктів. Ви можете змішувати старі та нові клієнти в тій самій LAN і керувати ними з тієї самої Панелі адміністратора.
Застосування змін
Кожне поле в розділі Режим виконання протоколу зберігається глобальною кнопкою Зберегти внизу сторінки. Під час збереження сервер:
- Зупиняє три старі listener-и, якщо вони були запущені.
- Перевіряє auth key (він не може бути порожнім).
- Будує нові конфігурації listener-ів на основі оновлених полів.
- Перезапускає listener-и паралельно.
- Відправляє сповіщення, коли всі три знову онлайн.
Якщо порт уже використовується іншим процесом, сервер показує помилку, а перемикач повертається в стан вимкнено. Перевірте фаєрвол та інші служби через netstat і виберіть вільний діапазон портів.
Розділ міграції бази даних (лише Windows)
Ця функція доступна лише тоді, коли HandyCafe працює на Windows. На macOS і Linux у цьому розділі показується повідомлення: "Database migration is supported on Windows only."
Виявлення
Після відкриття сервер сканує систему на наявність старої інсталяції. Пошук виконується в:
- Реєстрі та типових шляхах інсталяції, таких як
Program Files\HandyCafeіC:\HandyCafe. - Файлі бази даних поруч із інсталяцією.
- Конфігураційних INI-файлах у каталозі інсталяції.
Коли виявлення успішне, сторінка показує:
| Мітка | Значення |
|---|---|
| Install Path | Де на диску розташована стара інсталяція. |
| Database Path | Повний шлях до старого файлу бази даних. |
| Server Version | Версія, зчитана зі старої конфігурації. |
| INI File Count | Кількість виявлених конфігураційних файлів. Корисно для перевірки, що інсталяція повна. |
Якщо інсталяцію не знайдено, сторінка показує "No legacy installation detected." Ви все одно можете увімкнути підтримку виконання - просто імпортувати буде нічого.
Статус міграції
Сторінка відстежує історію міграції:
| Статус | Значення |
|---|---|
| never | Ви ще не запускали міграцію. |
| in_progress | Міграція зараз виконується. Не закривайте сервер у цьому стані. |
| completed | Остання міграція завершилася без попереджень. |
| completed_with_warnings | Остання міграція завершилася, але деякі записи було пропущено (наприклад, через помилки кодування або некоректні дати). Перед продовженням перегляньте попередження. |
| undone | Останню міграцію було відкотено. |
Після першого успішного запуску кнопка Start Migration перейменовується на Re-run Migration.
Що мігрується
| Таблиця | Опис |
|---|---|
| Members | Записи клієнтів з іменами, контактами та балансами. |
| Pricing | Таблиці цін і погодинні ставки. |
| Products | Записи каталогу товарів. |
| Orders | Історія замовлень із прив'язками до сеансів. |
| Transactions | Записи в журналі з часовими мітками, сумами та способами оплати. |
| Logs | Аудитні записи та попередження зі старої бази. |
Гарантія "файли в безпеці"
Сторінка показує синє повідомлення: "The original database files are not deleted. You can safely delete them once migration is confirmed." Міграція працює лише для читання джерела. Навіть якщо ви запускаєте міграцію кілька разів, оригінальна стара база залишається недоторканою. Це дає змогу експериментувати з імпортом, перевіряти кількість записів і безпечно відкотитися.
Запуск, повторний запуск і відкат
- Start Migration. Відкриває модальне вікно прогресу. Воно показує поточну фазу та кількість уже оброблених записів. Не закривайте HandyCafe під час цього процесу.
- Re-run Migration. Доступно після успішного запуску. Повторно виконує імпорт з нуля. Новий імпорт замінює попередні дані в HandyCafe.
- Undo Migration. Доступно після успішного запуску. Відкриває діалог підтвердження. Після підтвердження кожен перенесений рядок видаляється з HandyCafe. Стара база не змінюється. Після відкату статус повертається в
never.
Completed with Warnings
Якщо міграція завершується зі статусом completed_with_warnings, з'являється жовтий банер із посиланням Details. Натисніть його, щоб розгорнути список пропущених записів і причину пропуску. Типові причини:
- Несумісність кодування. У вихідному рядку є символи, які не декодуються чисто в налаштованому кодуванні. Змініть поле кодування (cp1254 або cp1252) і запустіть міграцію ще раз.
- Некоректні дати. Деякі старі записи мають недійсні часові мітки. Їх пропускають, щоб валідні рядки все одно імпортувалися.
- Дублікати ключів. Запис із тим самим ідентифікатором уже існує в HandyCafe. Міграція зберігає наявний запис і пропускає дублікат.
Поради
- Зупиніть старий сервер перед міграцією. Якщо стара система все ще пише до своєї бази, імпорт може побачити застарілі або неповні дані.
- Перед першою міграцією підберіть значення Encoding відповідно до локалі вашої старої системи. Зміна після імпорту не виправить уже пошкоджені імена.
- Завжди запускайте тестову міграцію спочатку. Перевірте кількість записів у "Last Counts" і вручну перегляньте кілька рядків учасників та транзакцій, перш ніж переводити персонал на нову систему.
- Увімкніть підтримку виконання та тримайте старих клієнтів підключеними деякий перехідний період. Це дає змогу переконатися, що новий сервер обслуговує їх так само, перш ніж ви вимкнете старий сервер.
- Якщо змінюєте Server UDP Port, пам'ятайте, що похідні порти команд і передачі файлів змінюються разом із ним. Правила фаєрволу потрібно оновити відповідно.