Як я розробляю власний продукт для автоматизації діяльності бізнесу на заміну 1С

Усім привіт, мене звати Віктор, і у цій статті я розповідаю, як прийшов до розробки власної системи застосунків для бізнесу, на заміну сумнозвісній 1С, а також прошу спільноту оцінити мій продукт та конструктивно прокоментувати. Але про все своєю чергою.

1. Суть проблематики

Про необхідність заміни російського програмного забезпечення сказано й написано багато. В сегменті автоматизації діяльності бізнесу в Україні безумовним лідером є лінійка продуктів 1С (в тому числі з новим брендом BAS).

Статей та обговорень можливості заміни даного програмного забезпечення теж чимало (ось деякі приклади: Що таке 1С і чому її важко (але потрібно) замінити в Україні. Думка, Чи існує заміна 1С в Україні, або Варіант докорінного рішення проблеми).

Сам 20 років займався автоматизацією різних видів бізнесу за допомогою 1С. З 24.02.22 вирішив спробувати знайти альтернативну систему розробки застосунків для автоматизації управління та обліку бізнесу.

Так як основна моя спеціалізація — розробка ПЗ під індивідуальні вимоги конкретного бізнесу, при пошуку керувався наступними основними критеріями:

• можливість вносити зміни в існуючі продукти та можливість розробляти продукти «з нуля» (обов’язково);
• умовно допустима собівартість розробки (щоб не виходило набагато дорожче чим на 1С);
• враховувались технологічні можливості та обмеження побудови продуктів на платформі (що є «в коробці» платформи, з чим буде важко в розробці) — знову ж таки, в порівнянні з платформою 1С;
• відносно невисокий поріг перекваліфікації для програмістів 1С, які окрім 1С не володіють технологіями розробки на інших мовах програмування (один в полі не воїн — послідовників в основному надіюсь знайти з програмістів 1С).

Пів року активно шукав і знайомився з різними системами, які могли б стати заміною 1С. Розглядав як вітчизняні продукти (A2V10, A5 (Unity Base), IT-Interprise, відносно недавно познайомився з Вправно), так і іноземні (Oddo, SAP, Microsoft Dynamics).

В результаті аналізу та практичних спроб освоїти деякі з цих технологій за майже 6 місяців так і не зміг знайти для себе продукту, в який би вірив як перспективного серйозного конкурента 1С. Свої висновки та порівняння сильних та слабких сторін цих систем наводити не буду — це не мета цієї статті.

В результаті прийняв рішення спробувати написати новий продукт для розробки бізнес-застосунків. Доволі великий вплив на прийняття такого рішення та концепції розробки нового продукту мало моє знайомство з платформою A2V10, яку розробив Олександр Кухтін (даному продукту найбільше виділив уваги на знайомство при пошуках). В основному все, що планувалось та розроблялось порівнювалось з 1С (швидкість та зручність розробки) та A2V10 (взяв для себе як за еталон майбутніх WEB-застосунків).

На початок розробки даного продукту в мене практично не було ні досвіду, ні знань технологій, які планував використовувати (20 років майже тільки 1С, навіть SQL не вмів користуватись). Розробку вів частково своїми силами (паралельно вивчаючи технології), а частково наймав спеціалістів (деякі технології виявилось освоїти важко).

Протягом перших двох місяців взагалі у всіх, кого можна питав, на яких технологіях краще будувати свої ідеї — рекомендації були досить різні. Деколи мені говорили, що «це працювати не буде», «так ніхто не робить».

Але пройшло 8 місяців розробки, і я готовий показати проміжні результати. Буду вдячний за об’єктивну критику та рекомендації — саме їх хочу почути в першу чергу.

2. Про ідею та на кого орієнтований продукт (програмісти/ кінцеві клієнти)

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

Кінцевим клієнтам як правило відносно все рівно, як і на чому написане для нього програмне забезпечення — головне щоб якісно, за допустиму ціну і надійно. Окрім того, кінцевим клієнтам не цікава сама платформа для розробки, а цікаві тільки готові продукти, які на ній написані (або можуть бути написані). Тому теоретично обмежень по використанню платформи для кінцевих клієнтів немає — все визначається функціоналом розробленого бізнес-застосунку.

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

3. Загальна структура платформи та готового бізнес-застосунку та які технології використовуються

Готовий бізнес-застосунок на даній платформі — це фактично WEB-сайт в форматі SPA-застосунку (односторінковий WEB-сайт). Архітектура готового бізнес-застосунку, можна сказати, стандартна — трирівнева:

• клієнт (браузер);
• сервер (застосунок ASP.NET Core на IIS);
• СКБД (система керування базами даних).

Рис. 1. Загальна архітектура системи

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

Технічно бізнес-застосунок (готове для використання програмне забезпечення для кінцевого клієнта) — це конфігурація плюс база СКБД (або декілька баз СКБД).

Конфігурація — це папка з певною структурою підлеглих папок, в якій містяться файли з правилами та кодом для роботи даного бізнес-застосунку (правила обміну даними між клієнтом та СКБД за допомогою сервера). Як правило, це файли в текстовому форматі: json, html+js, sql.

Одне з ключових питань кінцевих клієнтів, коли приймається рішення, чи підходить технологія для заміни 1С: де будуть знаходитись дані? Тому уточню можливі варіанти щодо розміщення бізнес-застосунків (СКБД з даними, сервер платформи та конфігурації) по серверам:

• все розміщується на серверах клієнта (класичний варіант розміщення баз 1С);
• на серверах клієнта зберігається СКБД з даними, а сервер з конфігурацією — на серверах компанії, яка надає IT-послуги (може бути актуально при розробці додаткового WEB-інтерфейсу для баз 1С);
• все розміщується на серверах компанії, яка надає IT-послуги (класичні online-сервіси).

4. З чого складаються платформа та конфігурація та які технології використовуються

Платформа складається з:

• сервер (на C# ASP.NET Core);
• клієнтська частина (JavaScript + в деякій мірі фреймворк Vue).

В перспективі до складових платформи варто було б додати умовний «Конфігуратор» (як в 1С, але зі значно меншим функціоналом). На початку проєкту навіть запустив процес розробки конфігуратора, але потім заморозив (трудоємко, дорого і малоефективно). Тому вирішив до питання розробки конфігуратора повернутись пізніше.

Функціонал платформи (серверна та клієнтська частини) реалізований відносно на базовому рівні. Далі коротко перерахую реалізований функціонал на момент написання статті.

4.1. По роботі з СКБД

• Як основну СКБД можна використовувати або MS SQL, або базу 1С 8 (в останньому випадку бізнес-застосунок фактично буде альтернативним інтерфейсом роботи з базою 1С, для 1С 7.7 підключення не розробляли, але при потребі можна доробити);
• при роботі з MS SQL рекомендується використовувати певну конфігурацію базових таблиць (спрощується в деякій мірі розробка).

Використання postgree поки не реалізовано (планується реалізувати в майбутньому).

4.2. По роботі сервера

• Можливість одного сервера паралельно обслуговувати декілька бізнес-застосунків (за аналогією з сервером/службою 1С, яка обслуговує різні бази);
• можливість запускати декілька «серверів платформи» на одному WEB-сервері — кожен сервер обробляє свій список баз (декілька сайтів ASP.NET на одному WEB-сервері IIS).
• «гаряче» (без зупинки сервера і бази) перезавантаження конфігурації конкретної бази (дана можливість вмикається для кожної бази окремо);
• можливість для декількох баз використовувати одну конфігурацію — кожна база використовує одну й ту ж саму конфігурацію, але СКБД у кожної бази своя (в логіці 1С — це коли б декілька баз використовували б один *.cf — відпадає потреба переносити зміни конфігурацій з однієї бази на іншу, доволі зручно при розробці і тестуванню);
• можливість працювати з різними СКБД (поки тільки MS SQL та 1С);
• можливість в одній базі підключатись до додаткових СКБД: додатково до основної СКБД можна підключати довільну кількість інших баз СКБД в різних форматах (поки тільки MS SQL та 1С);
• при використанні 1С як основної СКБД для доступу користувачів (логіни/ паролі) може використовуватись один конкретний обліковий запис 1С, або персональні (в останньому випадку будуть автоматично використовуватись доступні в 1С логіни/ паролі, на рівні бізнес-застосунку логіни/ паролі доступу до 1С не зберігаються, на рівні 1С використовується повноцінний механізм прав по ролям та RLS);
• реалізовано декілька варіантів підключення до 1С:
  — http-запити;
  — підключення через COM-об’єкт;
  — підключення напряму до MS SQL (не рекомендується, відповідальність за цілісність бази залишається за розробником бізнес-застосунку);
• сервер приймає запити від клієнта (браузера), і в залежності від параметрів запиту відправляє відповідні запити до потрібної СКБД в потрібному форматі.
  При використанні MS SQL — це повноцінний код на T-SQL з можливими параметрами.
  При використанні 1С — це назва методу з можливими параметрами, а сам код повинен бути написаний вже в 1С (загальний модуль з певною назвою та однією точкою входу).

Окремої своєї «серверної мови» поки немає (по даному питанню поки рішення не прийнято і навіть серйозно не займався цим питанням).

4.3. По роботі клієнта

• Базовий каркас інтерфейсу складається з меню (+можливість перемикатись між різними варіантами меню, в логіці 1С — між «інтерфейсами») та робочої області.
• робоча область використовується для розміщення «вікон» (вікно — форма/ інтерфейс відображення об’єкту довідника/документа, форма списку, форма звіту, довільна форма тощо);
• для зручної навігації реалізована технологія «панелі вікон»;
• вікна працюють на розробленій технології «локального url» — аналог рядка url в браузерах (відповідно є можливість обмінюватись між користувачами локальними url в текстовому форматі для швидкого відкриття конкретних вікон);
• розробка самих «вікон» полягає в написанні html-коду вікна з прив’язкою до даних, які отримані з серверу (або будуть отримані пізніше) та, при необхідності, написанні допоміжного коду на JavaScript;
• як правило форми вікон будуються з використанням фреймворка Vue.js (на стороні серверу реалізований механізм підключення даного фреймворка до кожного окремого вікна);
• для спрощення розробки конфігурацій розроблений список методів на JavaScript. Це умовна стандартна бібліотека методів «високого рівня», щоб розробнику бізнес-застосунку максимально не потрібно було опускатись в низькорівневе програмування (в логіці 1С — це методи з синтаксис-помічника). Розширення даного стандартного списку методів являється одним з пріоритетних напрямків в розвитку платформи. Це важливо для прискорення розробки готових бізнес-застосунків та зменшення порогу входу для розробників, які не знайомі з JavaScript/html/css;
• частково реалізовані базові класи css для елементів діалогу (таблиці, поля вводу/вибору тощо).

Дизайном (CSS) серйозно не займались — так що виглядає не дуже красиво (зараз не варто витрачати енергію на критику кольорів, розмірів тощо). Для приведення дизайну в порядок планую знайти окрему людину, яка вміє цим займатись.

5. Вигляд бізнес-застосунку (приклади)

Рис. 2. Вигляд бізнес-застосунку

Рис. 3. Вигляд ієрархічного довідника

Рис. 4.1. Вигляд простої таблиці

Рис. 4.2. Вигляд коду html+js для вікна на рис. 4.1.

6. Які вимоги до програмістів для написання бізнес-застосунків

Потрібні як мінімум базові знання наступних технологій:

• HTML (хоча б базовий рівень);
• СSS (бажано хоча б базовий рівень);
• JavaScript (хоча б базовий рівень);
• T-SQL та Microsoft SQL Server Management Studio (або якийсь аналог) — якщо в якості СКБД буде використовуватись MS SQL;
• Розробка в 1С­ — якщо в якості СКБД буде використовуватись 1С.

При всьому бажанні зробити розробку бізнес-застосунків простою, швидкою та зручною — поки не можу сказати, що розробку по даним параметрам можна порівнювати з розробкою в конфігураторі 1С. Поки в цьому напрямку потрібно ще багато працювати.

Є багато ідей, але їх розробка (аналіз, дослідження та реалізація) потребує чималих ресурсів. Але «все життя спереду ж» )

7. Доступ до демо

Окрім скрінів в статті можна спробувати глянути на інтерфейс на демо-базі (логін: Test1, пароль: 123). Доступ до демо пізніше відключу, так що посилання може не працювати.

8. Переваги та недоліки системи (в порівнянні з 1С)

Переваги:

• швидша робота готового бізнес-застосунку (в першу чергу порівняно з роботою 1С через браузери);
• повноцінний WEB-сайт, з меншими обмеженнями побудови інтерфейсу (в 1С свій обов’язковий каркас інтерфейсу);
• можливість використовувати всю силу JavaScript та CSS для побудови інтерфейсу (в тому числі розподіл процесу розробки на програміста та верстальника/дизайнера, що в 1С не звично).

Недоліки:

• швидкість розробки значно нижча;
• використання JavaScript та CSS (навіть в базовому варіанті) окрім гнучкості та широких можливостей вимагає відповідних знань (JavaSript ще так собі, а от CSS — магічна технологія, від якої я постійно втікаю);
• набагато складніший процес відладки (точки зупину тільки в браузері — не звично й відповідно не комфортно, відладка часто через повідомлення);
• поки немає звичного конфігуратора з деревом метаданих (я за рік так і не звик до розробки в файлах);
• платформа в розробці, тому часто буде змінюватись (перероблятись) існуючий функціонал;
• на даний момент відсутня інформаційна підтримка (навчальні матеріали, в гуглі нічого не знайдеш, немає можливості поставити питання й отримати відповідь).

9. Деякі плани на майбутнє щодо технологічного розвитку платформи

Як вже раніше писав — ідей по модернізації системи багато. Коротко озвучу основні:

• інтерфейс під планшети/смартфони;
• конфігуратор;
• робота з postgree;
• серверна мова (розробити технологію, або відмовитись зовсім);
• розробка готових бізнес-застосунків (типових рішень).

10. Стан проєкту на зараз та можливі організаційні плани розвитку проєкту

На даному етапі система знаходиться в стані постійних експериментів, доробок та переробок. Зараз активно проєктом займаюсь я та допомагає ще один програміст — Олександр (окрема подяка йому за його вклад як програміста і особливо за консультації — без нього набагато довше блукав би в невідомих мені технологіях).

Я переважно займаюсь ідеологією системи, розробкою серверу, всіма питаннями по роботі з СКБД, частково розробкою клієнтської частини, розробкою бізнес-застосунків. Олександр займається розробкою клієнтської частини (як правило базові низькорівневі технології на JavaScript, базовий CSS, консультує мене по WEB-технологіям).

Не дивлячись на те, що продукт дуже «сирий» — вже розробляється перший робочий проєкт для клієнта (зараз цей проєкт на стадії впровадження та робочого тестування). Планую десь за місяць-другий запустити базовий функціонал й перейти до постійного вдосконалення бізнес-застосунку (цим займався 20 років і мені це подобається).

При старті проєкту ставив собі ціль отримати перший робочий запуск через 6 місяців, але вийшло через 8 місяців. Розглядаю варіанти розробки та запуску нових бізнес-застосунків для деяких інших своїх клієнтів (в найближчі місяці планую визначитись, куди витрачатиму свій час).

Окрім використання платформи у власних розробках, в процесі обов’язково враховував те, щоб дану платформу змогли б використовувати інші розробники. Якщо робити доступною платформу для широкого кола розробників — потрібно додатково чимало зробити для того, щоб освоєння розробки на ній було реальним для пересічного 1С-програміста.

Для популяризації системи потрібні:

• технічна документація;
• детально описаний процес створення та запуску мінімального бізнес-застосунку;
• сайт з прикладами вирішення елементарних задач;
• організувати підтримку розробників (відповіді на питання в чаті, а краще в форматі форума);
• приймання інформації про помилки та побажань з розвитку платформи.

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

Також поки немає прийнятого рішення щодо фінансової моделі використання системи — поки продукт (платформа) розглядається як комерційний.

11. Подяка та зворотній зв’язок

Всім, хто осилив прочитати все до кінця — дякую. Окремо буду вдячний за оцінку ідеї/ реалізації, побажання та рекомендації. Все це краще писати знизу в коментарях.

Щодо якихось суто технічних питань — краще в групі телеграму їх ставити: Група в Telegram для обговорення технічних питань. Намагатимусь відповідати оперативно.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті