- Регистрация
- 23 Август 2023
- Сообщения
- 2 971
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 51
Offline
Привет, Хабр! В прошлой статье мы говорили о применении языков разметки для описания графических артефактов, идее языка разметки для аналитиков и приложении для генерации макетов UI и BPMN схем.
В сегодняшней статье хочу рассказать об эволюции экспериментов с разметкой и поделиться опытом разработки генератора веб форм для 1С, который позволяет прототипировать и запускать автоматизацию бизнес процессов, эмулируя работу пользователя с ТСД.
История
В свое время, идея генерации макетов форм по текстовому описанию возникла из практики: на проекте мне нужно было сделать довольно много рисунков форм, а потом долго-долго их согласовывать и править, а потом снова долго-долго согласовывать и править.. Ну вы поняли.
Когда нужно делать такое, вы хотите иметь систему контроля версий, чтобы управлять правками, а значит вы хотите иметь текстовое представление, а значит вы знаете чем развлечься (ответ: делать рендеринг картинки по текстовому представлению).
После этого в вашу голову может придти вопрос: окей, могу ли я теперь как то упростить процесс производства реальных форм, имея их разметку? Так мы переходим от генерации макетов к генерации рабочих форм.
Зачем? Потому что это интересно.
Итак, задача: сгенерировать рабочее клиентское приложение по его текстовому описанию.
Идеи
Перед тем как проектировать решение, нужно как то сформулировать идеи, на которых мы будем основываться.
Первая идея (бизнес логика остается в мастер-системе)
У нас, по всей видимости, будет чисто декларативное описание, что мы хотим контролировать с помощью этого описания?
Главную проблему здесь, на мой взгляд, представляет декларативное описание бизнес логики, поэтому предлагаю такое ограничение: мы заимствуем всю бизнес логику из мастер системы. Как этого добиться?
Таким образом, наш клиент, в части действий, модифицирующих состояние системы-приемника, будет уметь только одну вещь: создавать в приемнике новый экземпляр указанного типа.
Это все очень хорошо ложится на функциональную архитектуру, которую предлагают нам любые системы на базе 1С: у нас есть объекты (мы говорим о "документах"), которые инкапсулируют в себя бизнес логику и при создании производят модификацию состояния системы, интерпретируя собственные данные.
Например, документ "пересчет товаров" предполагает, что введенные в него фактические остатки должны быть сверены с учетными остатками (тем, что числится на складах по данным учета), а разница должна быть списана или оприходована. Определение учетных остатков, вычисление разниц и логика списания/приходования уже реализованы в этом объекте, поэтому, чтобы пользователь мог выполнить эти действия, ему достаточно предоставить фактические данные об остатках, все остальное уже реализовано.
Дополнительный и важный плюс: если внедрено 1С решение, значит, скорее всего, внедрен и процесс и мы не будем вынуждены глубоко заниматься процессным консалтингом, а просто предоставим оптимизацию ввода данных над существующим процессом, что должно облегчить наше внедрение.
Таким образом, бизнес логику в разметку мы не заводим, определяем только свойства для разметки UX (внешний вид, поведение) и свойства для разметки метаданных.
Вторая идея (заимствуем UX от приложения под ТСД)
Причин несколько:
ТСД приложения, как правило, эксплуатируются на производственных и торговых предприятиях, где
Это довольно широкий целевой охват.
Третья идея (используем ручной сканер штрихкодов)
Чтобы сделать приложение для ТСД, необходимо иметь функционал считывания штрихкода. Мы не будем делать/заимствовать программное обеспечение, а ограничимся покупкой готового ручного сканера штрихкодов, который будет подключаться к нашему приложению в разрыв устройства ввода (клавиатуры) по Bluetooth или USB. Отдельно приятно, что ресурс, который нам здесь понадобится, равен 1-2 тыс. руб.
Четвертая идея (доставка приложения через телеграмм)
Мы будем делать веб клиент, его код должен как то доставляться и где то исполняться. С учетом того, что это эмулятор ТСД, логично предположить что в большинстве случаев будут использоваться мобильные приложения. Итак, нам нужна:
С учетом таких пожеланий, мне показалось, что будет хорошо сделать доставку приложения через телеграмм, потому что в нем есть встроенный браузер, сам телеграмм это довольно распространенное и понятное пользователю приложение, при взаимодей��твии с чат ботом мы получаем id пользователя и можем построить на этом авторизацию.
Пятая идея (веб-редактор формы)
Преимущества такого подхода:
Конфиг, сформированный в веб конструкторе, будем выгружать в виде JSON и импортировать в 1С.
Архитектура
Давайте соберем в кучку наши идеи и нарисуем картинку как будет работать наше решение.
Упорядочив идеи, описанные выше, пришел к такой архитектуре решения
И словами, по порядку.
Аналитик на своем личном ПК открывает конструктор форм и пишет разметку (самостоятельно либо вместе с заказчиком прямо на интервью или демо). Введенная разметка отображается на странице в реальном времени в виде кликабельного рендера. При желании, аналитик может прописать по конфигу заглушки на сервисы вроде beeceptor чтобы макет на лету работал как реальное приложение.
Для разметки будем использовать этот язык.
Затем аналитик выгружает готовый json конфиг формы из веб конструктора (введення разметка конвертируется в json в веб конструкторе) и загружает его в 1С. Также аналитик прописывает в 1С ключ для доступа к телеграмм боту и список ID пользователей, которые смогут получать формы из 1С через указанного бота.
Пользователь на своем телефоне открывает телеграмм, начинает диалог с ботом и запрашивает список доступных ему форм.
Сообщения от пользователя на сервер 1С доставляются сначала через MTProto c клиента телеграмм на сервер телеграмм (этот процесс не требует нашего участия), а затем с сервера телеграмм - на 1С сервер. Есть два варианта доставки из телеграмм в 1С: либо через Telegram bot API (1С сервер сам запрашивает сообщения в телеграмм), либо через вебхук (телеграмм самостоятельно отправляет сообщения на http ручку 1С сервера).
Далее сервер проверяет, какие формы доступны пользователю и высылает в ответ на запрос пользователя список веб ссылок на доступные формы. Сообщение от сервера 1С пользователю доставляется типовым способом телеграмм: с сервера 1С на сервер телеграмм по Telegram bot API и далее с сервера телеграмм на клиентское мобильное устройство - через MTProto.
Пользователь получает ссылки на формы и выбирает из них ту форму с которой будет работать. Выбранная форма открывается во встроенном в телеграмм браузере.
Пользователь заполняет поля формы (в том числе с использованием ручного сканера) и отправляет заполненную форму в 1С. Отправка формы происходит http запросом из браузера телеграмм непосредственно к 1С веб серверу.
Далее веб сервер передает данные серверу приложений 1С и данные записываются в объект-приемник (в 1С создаются документы в соответствии с целевым бизнес процессом).
Итого, нам понадобится разработать:
Перед тем, как перейти к разработке, нужно определиться с семантикой разметки. Ка�� писал выше, использовать решил этот формат разметки, но какие объекты, свойства и значения вообще понадобятся для описания простейшего клиентского приложения? Для этого нужно придумать UX нашей формы.
Прежде всего, какие данные пользователь будет передавать в 1С? Чтобы передать произвольный объект, нужно будет уметь заполнять на форме:
Для всех указанных примитивов в html есть элемент input и специфичные указания на типы данных для него (checkbox, tel, date и т.п.). Поэтому добавим в разметку объект "Поле" с указанием типа и имени. Этот объект нашей разметки мы будем конвертировать в html input + label.
поле формы в нашей разметке будет выглядеть так
Массивы (табличные части)
Что насчет массивов? Структурно, массивы на форме мы можем хранить в таблице, но возникает проблема: пользователю будет неудобно добавлять и заполнять новую строку непосредственно в таблице на мобильном устройстве.
Поэтому предлагаю ввести в разметку два элемента для поддержки ввода двумерных массивов:
Операция - это отдельная страница на форме, которую мы будем открывать с помощью специального переключателя в верхней части формы.
Давайте вернемся к примеру: допустим, для того чтобы провести инвентаризацию, нам нужно заполнить таблицу с наименованиями товаров и их фактическими количествами. Разбиваем действия пользователя на "ввести остаток" (добавить в таблицу строку с новым остатком) и "подтвердить остатки" (отправить таблицу на сервер) и получаем примерно такую разметку и рендер.
Так выглядит разметка для формы ввода таблицы остатков товаров
Так работает UX flow в рендере этой разметки
Таким образом, мы сможем добавлять строки в табличную часть с использованием полей нужных типов, нужно только создать таблицу (приемник) на одной из вкладок, присвоить ей идентификатор и указать этот идентификатор в качестве приемника для одного из действий нашей формы.
Работа с объектами и ссылками
Окей, теперь перейдем к следующему типу данных, объекту. Объект может быть передан в систему приемник как целиком, так и как часть другого объекта.
С первым кейсом все понятно, мы как раз занимаемся построением формы, задача которой создать представление экземпляра объекта и отправить его на сервер. Но что со вторым вариантом? Как будем отправлять вложенный объект?
Допустим, нам нужно передать в составе документа пересчета товаров данные о товарах и кладовщике, который проводит инвентаризацию, причем передать их не как текстовое наименование, а как объект, имеющий в системе-приемнике конкретный идентификатор.
Давайте подумаем, какие задачи здесь нужно решить:
Примем ограничения:
Проще, говоря, мы реализуем такой флоу: пользователь перемещает фокус на поле штрихкода, производит сканирование ручным сканером. После сканирования, сканер передает в поле символ перевода каретки (это стандартное поведение ручного сканера), поле с заполненным штрихкодом теряет фокус. На событие потери фокуса мы вешаем хук, который отсылает на сервер запрос в котом указывает считанный штрихкод, тип объекта который нужно найти и имя поля, в котором можно найти считанную со штрихкода информацию. Сервер получает такой запрос, ищет нужный экземпляр указанного типа и возвращает его идентификатор и текстовое представление. После получения ответа сервера, мы заполняем представление и идентификатор в поле и пользователь видит что заполнение произошло.
Тогда мы можем передать в систему некий текстовый идентификатор этого объекта (в нашем случа�� это будет штрихкод.
Итак, как это будет выглядеть:
Добавили все что нужно для интеграции с системой-приемником
Так работает получившаяся форма
Мы придумали как будет работать флоу нашей формы, осталось добавить атрибуты для стилизации управления внешним видом формы.
Добавим в разметку элементы и свойства для управления отображением
Теперь мы умеем в горизонтальные экраны и темную тему цвета
Реализация
В этом разделе расскажу / покажу что получилось по отдельным компонентам. Без кода и глубоких подробностей, только по верхам. Если тема окажется интересной, возможно, напишу что то в отдельной статье.
Конструктор форм
Логика конструктора подробно разобрана выше, результат можно потрогать здесь.
Реализовал:
На стороне 1С сделал расширение, зависимое от БСП и не зависимое от конкретной конфигурации, в расширении реализовал:
Хочу отметить что в GUI-арсенале 1С есть специальное поле для HTML документа и, по идее, можно было бы сделать весь флоу работы с конфигурированием формы внутри 1С, но все же вынес это в веб потому что:
Здесь все просто, идем в BotFather и следуем его инструкциям. Нам нужно создать нового бота. После создания, BotFather сообщает нам ID и токен бота. Эти токен и ID используем для интеграции 1С с телеграмм, в остальном бот готов к использованию. Если интеграция буде�� использоваться в режиме веб хука, нужно сделать запрос на установку адреса вебхука, это можно сделать руками из браузера методом setWebhook (описание см. в документации) .
Как то так выглядит диалог получения формы с 1С сервера
Сканер
Не заметил здесь никаких нюансов, просто идете на тот маркетплейс, который вы любите, и покупаете ручной сканер за несколько тысяч рублей. Единственное на что обращал внимание при выборе - поддержка подключения по bluetooth. Стандарты 2D кодов сейчас поддерживаются в очень широком спектре любыми устройствами.
Практика
Внедрения
В какой то момент мне показалось что все получилось, я (не без опаски) рассказал об этом коллегам по цеху. К счастью, коллеги были тоже немного с люфтом, и это привело к тому что мы сделали два игрушечных небольших внедрения: сеть магазинов одежды (там нашим решением теперь делают инвентаризации товаров) и проектное производство (удаленный монтаж изделий на территории заказчика, сборщики отчитываются о приемке и выработке).
Что получилось хорошо
Во-первых, решение эксплуатируется уже полгода, обращений мало, отзывы хорошие, были запросы на развитие, отработали и ничего не развалилось.
Во-вторых, по сравнению с классическим подходом к внедрению автоматизации, есть колоссальная экономия времени: во время демо на лету показываем заказчику форму, вносим изменения, демонстрируем рабочее решение вплоть до получения данных из демо базы. Это все происходит в режиме Live и, кажется, воспринимается заказчиком как магия, что способствует скорости движения проекта. На проект получается 10-20 часов в прыжке с учетом общения, консалтинга и доработок.
Что можно улучшить
Ожидаемо, в процессе родилось некоторое количество костылей. Расскажу о самом болезненном из них. Обычно, когда мы создаем объект из интеграции, не все поля явно заполняются пользователем. Часть полей заполняется либо предопределенными значениями, либо вычисляются из значений других полей по логике, специфичной конкретному объекту.
Что с этим делать? Мы же не хотим заставлять пользователя указывать все необходимые поля явно.
На практике, мы пошли несколькими путями:
По сути, получилось, что решение не универсально, но в реальности объем специфичных доработок под заказчика получился не большой, так что все не так уж плохо. Простые объекты могут создаваться без доработок из коробки, для сложных нужны небольшие доработки.
Второй момент: сложность контекста, который нужно держать в голове аналитику. Нужно понимать бизнес процесс, логику работы системы-приемника, имена типов, правила разметки, порядок настройки расширения и т.п. На выходе получается довольно высокая когнитивная нагрузка и сложность передачи бизнес-функционала в развитие.
Вывод
В целом, шалость удалась! Спасибо что дочитали, удачи на проектах!
Обратная связь в канале: https://t.me/analyst_writes_things
В сегодняшней статье хочу рассказать об эволюции экспериментов с разметкой и поделиться опытом разработки генератора веб форм для 1С, который позволяет прототипировать и запускать автоматизацию бизнес процессов, эмулируя работу пользователя с ТСД.
История
В свое время, идея генерации макетов форм по текстовому описанию возникла из практики: на проекте мне нужно было сделать довольно много рисунков форм, а потом долго-долго их согласовывать и править, а потом снова долго-долго согласовывать и править.. Ну вы поняли.
Когда нужно делать такое, вы хотите иметь систему контроля версий, чтобы управлять правками, а значит вы хотите иметь текстовое представление, а значит вы знаете чем развлечься (ответ: делать рендеринг картинки по текстовому представлению).
После этого в вашу голову может придти вопрос: окей, могу ли я теперь как то упростить процесс производства реальных форм, имея их разметку? Так мы переходим от генерации макетов к генерации рабочих форм.
Зачем? Потому что это интересно.
Итак, задача: сгенерировать рабочее клиентское приложение по его текстовому описанию.
Идеи
Перед тем как проектировать решение, нужно как то сформулировать идеи, на которых мы будем основываться.
Первая идея (бизнес логика остается в мастер-системе)
У нас, по всей видимости, будет чисто декларативное описание, что мы хотим контролировать с помощью этого описания?
Поэлементный состав и внешний вид GUI;
Данные, введенные на форму (структуру, типы и значения);
Поведение элементов формы при взаимодействии пользователя с формой (значения по умолчанию, автозаполнение, фокус элементов и т.п.);
Бизнес логику (что происходит на уровне абстракций системы-приемника, при взаимодействии пользователя с формой).
Главную проблему здесь, на мой взгляд, представляет декларативное описание бизнес логики, поэтому предлагаю такое ограничение: мы заимствуем всю бизнес логику из мастер системы. Как этого добиться?
Убедиться что в системе-приемнике реализован объект, уже решающий нашу бизнес-задачу;
Смэпить данные формы на данные объекта-приемника так, чтобы по данным формы можно было создать целостный объект в системе-приемнике;
Таким образом, наш клиент, в части действий, модифицирующих состояние системы-приемника, будет уметь только одну вещь: создавать в приемнике новый экземпляр указанного типа.
Это все очень хорошо ложится на функциональную архитектуру, которую предлагают нам любые системы на базе 1С: у нас есть объекты (мы говорим о "документах"), которые инкапсулируют в себя бизнес логику и при создании производят модификацию состояния системы, интерпретируя собственные данные.
Например, документ "пересчет товаров" предполагает, что введенные в него фактические остатки должны быть сверены с учетными остатками (тем, что числится на складах по данным учета), а разница должна быть списана или оприходована. Определение учетных остатков, вычисление разниц и логика списания/приходования уже реализованы в этом объекте, поэтому, чтобы пользователь мог выполнить эти действия, ему достаточно предоставить фактические данные об остатках, все остальное уже реализовано.
Дополнительный и важный плюс: если внедрено 1С решение, значит, скорее всего, внедрен и процесс и мы не будем вынуждены глубоко заниматься процессным консалтингом, а просто предоставим оптимизацию ввода данных над существующим процессом, что должно облегчить наше внедрение.
Таким образом, бизнес логику в разметку мы не заводим, определяем только свойства для разметки UX (внешний вид, поведение) и свойства для разметки метаданных.
Вторая идея (заимствуем UX от приложения под ТСД)
Причин несколько:
Мои личные предпочтения (люблю ТСД, мне кажется что они поставляют предприятиям колоссальный объем выгоды и порядка);
ТСД решают ту же самую проблему, до которой только что сузились мы: предоставляют пользователю простой клиентский интерфейс, помогающий собрать и отправить данные для последующей обработки на сервере.
ТСД приложения, как правило, эксплуатируются на производственных и торговых предприятиях, где
Внедрено штрихкодирование сущностей: товарно-материальных ценностей, документов, бланков, мест хранения, бэйджей сотрудников и т.п.;
Операции ввода данных занимают много времени в хронометраже производственных операций, от их автоматизации ожидается большая выгода;
Сложная структура нормативно-справочной информации (НСИ) => высокая вероятность совершить ошибку при ручном вводе;
Производственные условия не позволяют вводить данные с помощью традиционных интерфейсов (например, условия низкого холода, требования к стерильности помещений, использование средств индивидуальной защиты);
Персонал, занимающийся вводом данных, не заинтересован в высоком качестве ввода или по каким то причинам затруднено обучение (аутсорс сотрудники, внешние контрагенты, неуверенные пользователи ПК).
Это довольно широкий целевой охват.
Третья идея (используем ручной сканер штрихкодов)
Чтобы сделать приложение для ТСД, необходимо иметь функционал считывания штрихкода. Мы не будем делать/заимствовать программное обеспечение, а ограничимся покупкой готового ручного сканера штрихкодов, который будет подключаться к нашему приложению в разрыв устройства ввода (клавиатуры) по Bluetooth или USB. Отдельно приятно, что ресурс, который нам здесь понадобится, равен 1-2 тыс. руб.
Четвертая идея (доставка приложения через телеграмм)
Мы будем делать веб клиент, его код должен как то доставляться и где то исполняться. С учетом того, что это эмулятор ТСД, логично предположить что в большинстве случаев будут использоваться мобильные приложения. Итак, нам нужна:
кроссплатформенность
желательно, независимость от браузера (мы не хотим и не имеем ресурса тестировать все на нескольких браузерах)
понятная точка входа для пользователя (запуск приложения как можно более привычным способом)
желательно, чтобы не нужно было ничего устанавливать
авторизация, простая и для пользователя и для администратора
С учетом таких пожеланий, мне показалось, что будет хорошо сделать доставку приложения через телеграмм, потому что в нем есть встроенный браузер, сам телеграмм это довольно распространенное и понятное пользователю приложение, при взаимодей��твии с чат ботом мы получаем id пользователя и можем построить на этом авторизацию.
Пятая идея (веб-редактор формы)
Преимущества такого подхода:
облегчение процесса сбора требований и проведения демо аналитиком: конструктор форм доступен с любого устройства в любой точке земного шара, можно изменять форму "на лету", показывать заказчику, согласовывать и вносить правки;
на мой взгляд, конструктор проще разработать в веб чем внутри 1С из за некоторых особенностей встроенного в 1С движка рендеринга HTML+CSS+JS, а также из за особенностей платформенных средств работы со строками (нам же нужно будет где-то написать конвертор из нашей разметки в JSON).
Конфиг, сформированный в веб конструкторе, будем выгружать в виде JSON и импортировать в 1С.
Архитектура
Давайте соберем в кучку наши идеи и нарисуем картинку как будет работать наше решение.
Упорядочив идеи, описанные выше, пришел к такой архитектуре решения
И словами, по порядку.
Аналитик на своем личном ПК открывает конструктор форм и пишет разметку (самостоятельно либо вместе с заказчиком прямо на интервью или демо). Введенная разметка отображается на странице в реальном времени в виде кликабельного рендера. При желании, аналитик может прописать по конфигу заглушки на сервисы вроде beeceptor чтобы макет на лету работал как реальное приложение.
Для разметки будем использовать этот язык.
Затем аналитик выгружает готовый json конфиг формы из веб конструктора (введення разметка конвертируется в json в веб конструкторе) и загружает его в 1С. Также аналитик прописывает в 1С ключ для доступа к телеграмм боту и список ID пользователей, которые смогут получать формы из 1С через указанного бота.
Пользователь на своем телефоне открывает телеграмм, начинает диалог с ботом и запрашивает список доступных ему форм.
Сообщения от пользователя на сервер 1С доставляются сначала через MTProto c клиента телеграмм на сервер телеграмм (этот процесс не требует нашего участия), а затем с сервера телеграмм - на 1С сервер. Есть два варианта доставки из телеграмм в 1С: либо через Telegram bot API (1С сервер сам запрашивает сообщения в телеграмм), либо через вебхук (телеграмм самостоятельно отправляет сообщения на http ручку 1С сервера).
Далее сервер проверяет, какие формы доступны пользователю и высылает в ответ на запрос пользователя список веб ссылок на доступные формы. Сообщение от сервера 1С пользователю доставляется типовым способом телеграмм: с сервера 1С на сервер телеграмм по Telegram bot API и далее с сервера телеграмм на клиентское мобильное устройство - через MTProto.
Пользователь получает ссылки на формы и выбирает из них ту форму с которой будет работать. Выбранная форма открывается во встроенном в телеграмм браузере.
Пользователь заполняет поля формы (в том числе с использованием ручного сканера) и отправляет заполненную форму в 1С. Отправка формы происходит http запросом из браузера телеграмм непосредственно к 1С веб серверу.
Далее веб сервер передает данные серверу приложений 1С и данные записываются в объект-приемник (в 1С создаются документы в соответствии с целевым бизнес процессом).
Итого, нам понадобится разработать:
веб конструктор форм
http интерфейсы 1С и исполняемую логику за ними
код веб клиента, который будем высылать пользователю
Перед тем, как перейти к разработке, нужно определиться с семантикой разметки. Ка�� писал выше, использовать решил этот формат разметки, но какие объекты, свойства и значения вообще понадобятся для описания простейшего клиентского приложения? Для этого нужно придумать UX нашей формы.
Прежде всего, какие данные пользователь будет передавать в 1С? Чтобы передать произвольный объект, нужно будет уметь заполнять на форме:
примитивы (булево, число, строка) и примкнувшие к ним строки со специфичными требованиями к формату (дата, телефон, цвет)
массивы
объекты
Для всех указанных примитивов в html есть элемент input и специфичные указания на типы данных для него (checkbox, tel, date и т.п.). Поэтому добавим в разметку объект "Поле" с указанием типа и имени. Этот объект нашей разметки мы будем конвертировать в html input + label.
поле формы в нашей разметке будет выглядеть так
Массивы (табличные части)
Что насчет массивов? Структурно, массивы на форме мы можем хранить в таблице, но возникает проблема: пользователю будет неудобно добавлять и заполнять новую строку непосредственно в таблице на мобильном устройстве.
Поэтому предлагаю ввести в разметку два элемента для поддержки ввода двумерных массивов:
таблица
операция
Операция - это отдельная страница на форме, которую мы будем открывать с помощью специального переключателя в верхней части формы.
Давайте вернемся к примеру: допустим, для того чтобы провести инвентаризацию, нам нужно заполнить таблицу с наименованиями товаров и их фактическими количествами. Разбиваем действия пользователя на "ввести остаток" (добавить в таблицу строку с новым остатком) и "подтвердить остатки" (отправить таблицу на сервер) и получаем примерно такую разметку и рендер.
Так выглядит разметка для формы ввода таблицы остатков товаров
Так работает UX flow в рендере этой разметки
Таким образом, мы сможем добавлять строки в табличную часть с использованием полей нужных типов, нужно только создать таблицу (приемник) на одной из вкладок, присвоить ей идентификатор и указать этот идентификатор в качестве приемника для одного из действий нашей формы.
Работа с объектами и ссылками
Окей, теперь перейдем к следующему типу данных, объекту. Объект может быть передан в систему приемник как целиком, так и как часть другого объекта.
С первым кейсом все понятно, мы как раз занимаемся построением формы, задача которой создать представление экземпляра объекта и отправить его на сервер. Но что со вторым вариантом? Как будем отправлять вложенный объект?
Допустим, нам нужно передать в составе документа пересчета товаров данные о товарах и кладовщике, который проводит инвентаризацию, причем передать их не как текстовое наименование, а как объект, имеющий в системе-приемнике конкретный идентификатор.
Давайте подумаем, какие задачи здесь нужно решить:
система приемник должна каким то образом понять, экземпляр какого типа мы ей пытаемся передать в составе документа инвентаризации
пользователь должен иметь возможность выбрать экземпляр объекта и убедиться, что на форме он выбран правильно
Примем ограничения:
в качестве вложенных объектов всегда передаются только уже существующие в приемнике экземпляры
при передаче вложенного объекта, мы передаем в систему приемник идентификатор, являющийся ключем главной таблицы объекта
чтобы узнать ключ объекта, клиент делает запрос в систему приемник, в котором отправляет
тип объекта
имя поля в системе приемнике, по которому можно найти существующий объект
значение, по которому будем искать нужный экземпляр объекта указанного типа (поиском по указанному полю)
система приемник возвращает клиенту в результате
чтобы пользователь мог понимать, какой экземпляр объекта заполнен в поле, сервер должен отдать вместе с ключем найденного экземпляра объекта его текстовое представление, которое будет показано пользователю
Проще, говоря, мы реализуем такой флоу: пользователь перемещает фокус на поле штрихкода, производит сканирование ручным сканером. После сканирования, сканер передает в поле символ перевода каретки (это стандартное поведение ручного сканера), поле с заполненным штрихкодом теряет фокус. На событие потери фокуса мы вешаем хук, который отсылает на сервер запрос в котом указывает считанный штрихкод, тип объекта который нужно найти и имя поля, в котором можно найти считанную со штрихкода информацию. Сервер получает такой запрос, ищет нужный экземпляр указанного типа и возвращает его идентификатор и текстовое представление. После получения ответа сервера, мы заполняем представление и идентификатор в поле и пользователь видит что заполнение произошло.
Тогда мы можем передать в систему некий текстовый идентификатор этого объекта (в нашем случа�� это будет штрихкод.
Итак, как это будет выглядеть:
Добавили все что нужно для интеграции с системой-приемником
Так работает получившаяся форма
Мы придумали как будет работать флоу нашей формы, осталось добавить атрибуты для стилизации управления внешним видом формы.
Добавим в разметку элементы и свойства для управления отображением
Теперь мы умеем в горизонтальные экраны и темную тему цвета
Реализация
В этом разделе расскажу / покажу что получилось по отдельным компонентам. Без кода и глубоких подробностей, только по верхам. Если тема окажется интересной, возможно, напишу что то в отдельной статье.
Конструктор форм
Логика конструктора подробно разобрана выше, результат можно потрогать здесь.
Реализовал:
простой текстовый редактор с подсветкой, подсказками по семантике
рендер кликабельного макета (в принципе, если cors/csrf политика сервера позволяет обрабатывать опасные запросы, то запрос уйдет и будет обработан, по крайней мере работает с заглушками вроде beeceptor)
конвертацию разметки в JSON-конфиг
На стороне 1С сделал расширение, зависимое от БСП и не зависимое от конкретной конфигурации, в расширении реализовал:
HTTP методы:
на раздачу формы
на поиск и возврат объекта указанного ссылочного типа по идентификатору
на получение от нашего клиента представления (с описанием метаданных) и последующее создание нового документа в 1С базе
Функционал для чтения телеграмм (сделал только в режиме без вебхука). Указываем в настройках ID пользователя и токен телеграмм-бота. 1С начинает вычитывать и обрабатывать сообщения в этом боте от этого пользователя. Логика взаимодействия:
Пользователь запрашивает список доступных ему форм (храним формы в отдельном справочнике, назначаем доступность пользователям в отдельном регистре)
Высылаем пользователю список доступных форм
Пользователь выбирает нужную форму
Рендерим форму (об этом чуть ниже) и высылаем пользователю ссылку http метода на раздачу формы
Пользователь проходит по ссылке - возвращаем ему форму, она открывается во встроенном в телеграмм браузере
Справочник для конфигурирования форм. В справочнике сделал два основных поля: код клиента и конфигурацию клиента. Код клиента заполняется предопределенным в расширении значением. Функционально, это JS код, который рендерит форму в веб конструкторе, только без конкретного конфига. В поле "конфигурация клиента" администратор добавляет JSON конфиг, который выгрузил из веб конструктора. Когда от пользователя приходит запрос на рендеринг конкретной формы, мы применяем конфиг к коду и получаем рендер приложения, который и отдадим пользователю по ссылке.
Хочу отметить что в GUI-арсенале 1С есть специальное поле для HTML документа и, по идее, можно было бы сделать весь флоу работы с конфигурированием формы внутри 1С, но все же вынес это в веб потому что:
некоторые вещи в HTML поле работали неожиданно (в части рендеринга и внешнего вида некоторых типовых виджетов), хотя справедливости ради надо отметить, что в целом все работало хорошо, JS исполнялся в полном объеме вплоть до того что с формы уходили запросы прямо к 1С серверу на котором работал
держал в голове преимущество работы аналитика с веб конструктором с любого браузера любого устройства без регистрации и смс
Здесь все просто, идем в BotFather и следуем его инструкциям. Нам нужно создать нового бота. После создания, BotFather сообщает нам ID и токен бота. Эти токен и ID используем для интеграции 1С с телеграмм, в остальном бот готов к использованию. Если интеграция буде�� использоваться в режиме веб хука, нужно сделать запрос на установку адреса вебхука, это можно сделать руками из браузера методом setWebhook (описание см. в документации) .
Как то так выглядит диалог получения формы с 1С сервера
Сканер
Не заметил здесь никаких нюансов, просто идете на тот маркетплейс, который вы любите, и покупаете ручной сканер за несколько тысяч рублей. Единственное на что обращал внимание при выборе - поддержка подключения по bluetooth. Стандарты 2D кодов сейчас поддерживаются в очень широком спектре любыми устройствами.
Практика
Внедрения
В какой то момент мне показалось что все получилось, я (не без опаски) рассказал об этом коллегам по цеху. К счастью, коллеги были тоже немного с люфтом, и это привело к тому что мы сделали два игрушечных небольших внедрения: сеть магазинов одежды (там нашим решением теперь делают инвентаризации товаров) и проектное производство (удаленный монтаж изделий на территории заказчика, сборщики отчитываются о приемке и выработке).
Что получилось хорошо
Во-первых, решение эксплуатируется уже полгода, обращений мало, отзывы хорошие, были запросы на развитие, отработали и ничего не развалилось.
Во-вторых, по сравнению с классическим подходом к внедрению автоматизации, есть колоссальная экономия времени: во время демо на лету показываем заказчику форму, вносим изменения, демонстрируем рабочее решение вплоть до получения данных из демо базы. Это все происходит в режиме Live и, кажется, воспринимается заказчиком как магия, что способствует скорости движения проекта. На проект получается 10-20 часов в прыжке с учетом общения, консалтинга и доработок.
Что можно улучшить
Ожидаемо, в процессе родилось некоторое количество костылей. Расскажу о самом болезненном из них. Обычно, когда мы создаем объект из интеграции, не все поля явно заполняются пользователем. Часть полей заполняется либо предопределенными значениями, либо вычисляются из значений других полей по логике, специфичной конкретному объекту.
Что с этим делать? Мы же не хотим заставлять пользователя указывать все необходимые поля явно.
На практике, мы пошли несколькими путями:
добавлять на форму настроечный блок, в котором на этапе разметки формы прописывали константы (то что реально является константами)
для всего, что не является константой, но и не должно явно заполняться пользователем, начали делать на стороне 1С библиотеку процедур, расширяющих "универсальную" часть механизма
добавили в систему промежуточный объект "сообщение", чтобы дать пользователю возможность создать документ на клиенте по команде из сообщения, тем самым добавив переиспользование уже написанного кода 1С клиента
По сути, получилось, что решение не универсально, но в реальности объем специфичных доработок под заказчика получился не большой, так что все не так уж плохо. Простые объекты могут создаваться без доработок из коробки, для сложных нужны небольшие доработки.
Второй момент: сложность контекста, который нужно держать в голове аналитику. Нужно понимать бизнес процесс, логику работы системы-приемника, имена типов, правила разметки, порядок настройки расширения и т.п. На выходе получается довольно высокая когнитивная нагрузка и сложность передачи бизнес-функционала в развитие.
Вывод
В целом, шалость удалась! Спасибо что дочитали, удачи на проектах!
Обратная связь в канале: https://t.me/analyst_writes_things
