Я расскажу о проекте, клиентом которого выступала компания Пив&ко – на текущий момент это сеть, насчитывающая более 450 магазинов.
В 2014 году компания взяла курс на масштабирование за счет франшизной сети.
На тот момент учет всей розничной сети велся в «1С:Управление торговлей 10» – к этой же базе было решено подключать открывающиеся франшизные магазины.
Так как все отчеты для покупателей франшизы формировались вручную и отправлялись по почте, это занимало длительное время.
Такой уровень сервиса не соответствовал возможностям быстрого роста, поэтому с этим в 2016 году для франчайзинговой сети было принято решение создать отдельную базу.
В качестве конфигурации для учета франшизных магазинов было выбрано решение «1С:Розница» из-за того, что:
-
было легко найти исполнителя;
-
был обещан web-клиент из коробки.
Исполнителем на проекте выступала компания, которая на тот момент обслуживала для Пив&ко 1С и инфраструктуру в целом. Своего ИТ у них тогда не было, все на аутсорсинге.
Летом были переведены первые клиенты, но что-то пошло не так – система показывала большие расхождения по проливу (в несколько тонн), из-за которых приходилось проводить постоянную инвентаризацию.
Вторая и третья попытка по переводу тоже не увенчались успехом.
Тогда решили создать свое ИТ и уходить с аутсорса.
В феврале 2017 года мне было предложено заняться данным проектом. И уже в мае все проблемы были устранены, а учет по всем магазинам франчайзинговой сети перевели из «1С:Управления торговлей» в «1С:Розницу».
Доступ к базе предоставлялся через Web-клиент.
С этого момента работа закипела.
Особенности интерфейса базы для партнеров
Рассмотрим, как менялся интерфейс.
Первоначально для франчайзи не было создано никакого специального интерфейса – был стандартный интерфейс, зайдя в который клиенты очень сильно пугались, так как для них он был неудобен, непонятен, недружелюбен.
Было принято решение в кратчайшие сроки запустить красивый интерфейс.
За неделю его запустили, но он прослужил три месяца.
Его цель была – собрать всю статистику по отчетам и по необходимой клиентам функциональности. В результате был запущен онлайн-заказ, рекомендованный заказ, разные отчеты.
К сентябрю того же года был запущен финальный интерфейс. Он был красивый, удобный и дружелюбный.
Основной его плюс – его можно было настраивать на клиенте.
Можно было менять видимость элементов:
-
для одного сотрудника;
-
для списка сотрудников;
-
вообще убирать какой-то элемент из интерфейса.
На слайде показано, как настраивается элемент интерфейса «Пиво разливное» – это кнопка, которая выводит отчет:
-
тип элемента «Форма»;
-
можно выбрать изображение;
-
указать путь к отчету – к форме, которая открывается;
-
настроить параметры, которые передаются в форму.
Аналогичная форма используется и в других отчетах – отличается только передачей других параметров.
На слайде показан результат формирования отчета «Пиво разливное».
Обратите внимание, здесь есть «Тренд сети» – это средняя скользящая сумма по всем франшизным магазинам с учетом предыдущего периода. По сути, этот отчет сравнивает ваш магазин с остальными, показывает, в тренде вы или нет, нормально ли развиваетесь, в ногу со всеми идете или где-то проседаете.
Доработки
Что пришлось сделать? При работе клиентов с интерфейсом в браузере, все длительные вычисления результатов нужно реализовывать через функции модуля БСП «ДлительныеОперации» либо через фоновые задания. Эту функциональность приходится использовать почти всегда, иначе браузер будет говорить, что у вас сеанс не отвечает, возможно, сервер умер – поинтересуется, будем дожидаться или нет. Некоторые браузеры просто зарубают сеанс на корню и закрывают окно.
Были созданы «Срезы данных» для ускорения вывода данных в интерфейсе и в отчетах.
На слайде показано, как в интерфейсе выводится выручка за месяц и формируется рейтинг франшизы по выручке – это все сделано на «срезах».
Есть возможность создать несколько видов срезов – например, виды среза «Выручка» и «Пиво за месяц».
Все срезы настраиваются тоже в клиентской части.
В виде среза задается алгоритм для получения информации в разрезе некоторых параметров (например, магазин или магазин + номенклатура), с возможностью получения итогов в разрезе выбранных измерений.
Указывается выражение для вычисления значения измерения среза.
И таким образом читается «Тренд сети» по данному срезу.
Также была продумана функциональность автозаказов – клиент может ввести настройки автозаказа, и в определенное время по регламенту формируется рекомендованный заказ.
Как вы видите, для запуска по регламенту используются возможности подсистемы «Дополнительных отчетов и обработок» – это также дало возможность дорабатывать функциональность на лету.
Часть типовой функциональности пришлось переписывать с клиента на сервер – например, выгрузку-загрузку касс. Это позволило реализовать многопоточную обработку данных и дать возможность клиентам вручную загружать или выгружать кассы своих магазинов.
Была проделана работа по улучшению стандартного интерфейса. Для этого использовали расширения конфигурации.
Слева мы видим, как выглядит стандартная конфигурация, справа – как красиво мы сделали для клиентов. В стандартной конфигурации, чтобы ввести каждую настройку, надо сделать 4-5 кликов. У нас все это гораздо проще.
Еще один пример по улучшению стандартного интерфейса. Обычно, чтобы напечатать ценники, нужно сделать четыре клика – у нас это происходит по одному клику.
Плюсы и минусы от запуска web-клиента
Что заказчик получил от запуска web-клиента?
-
Во-первых, заказчик получил быстрый запуск.
-
Во-вторых, так как у нас любят использовать гибкие методики, заказчик получил обратную связь. И на основании обратной связи был создан сервис непосредственно для клиентов.
-
Была уменьшена нагрузка на собственных сотрудников, которые формировали раньше все вручную. Теперь клиенты сами формируют то, что им надо.
-
И была получена среда для быстрых доработок и улучшения возможностей, которые хотят клиенты.
Из минусов можно перечислить:
-
Расход сеансов. Поскольку web-клиент – это сеанс, любое серьезное обновление конфигурации уже нужно согласовывать с клиентами, искать технологическое окно.
-
Не все клиенты могут использовать web-интерфейс – не у всех есть ноутбуки, компьютеры и планшеты, а в мобильном приложении это выглядит ужасно.
Основной плюс, который получила группа компаний Пив&ко от внедрения – это удобный сервис, дающий преимущество перед конкурентами.
Как зарождалась идея универсального HTTP-сервиса
Немного истории – как зарождалась идея универсального HTTP-сервиса.
Когда я работал с HTTP-сервисами, я часто замечал, что они обрастают шаблонами и методами, и становятся монстрообразными – их становится сложно поддерживать.
Меня такой подход не очень устраивал. Тогда я нарисовал вот такую схему:
На схеме видно, как обрабатывается запрос:
-
у нас есть некий запрос;
-
происходит проверка параметров;
-
потом выполняется некий метод;
-
и возвращается ответ.
Все это можно сделать универсальным, кроме выполнения действий.
Тогда я пошел таким путем: я создал некий легко разворачиваемый HTTP-сервис, использующий методы GET и POST, обработчики действий которых размещались в отдельном общем модуле.
Такой подход просуществовал довольно долго. Он описан на Инфостарте в статьях из цикла «HTTP Сервисы: Путь к своему сервису».
Но рано или поздно всему приходит конец, мне понадобилось выйти из конфигуратора.
Тогда я пошел не совсем хорошим, ошибочным путем. Я часто вижу, что предлагаются такие решения, но прежде чем вы захотите наступить на эти грабли, я рекомендую все-таки ознакомиться со статьей «Выполнятор – как я породил монстра и лишился сна!» и не повторять чужих ошибок.
В итоге я понял, что к универсальному сервису можно прийти, используя метод ANY. Придумал даже шуточное название – PAPI от Pretty API, но реализацию отложил на неопределенное время.
Проект по разработке мобильного кабинета
В 2018 году в группе компаний Пив&ко решили разработать мобильное приложение, и тогда я понял, что появилась возможность убить двух зайцев:
-
во-первых, реализовывать универсальный сервис;
-
во-вторых, подтянуть знания по мобильной платформе.
Проект я разбил на четыре части:
-
реализация универсального HTTP-сервиса;
-
создание мобильного приложения в части заказов, написание обменов;
-
реализация поступлений и установка цен;
-
описание функциональности для будущей поддержки.
При постановке задачи клиент выставлял следующие требования:
-
Мобильное приложение должно работать в основном офлайн, но нужна возможность обмениваться данными онлайн.
-
Должен быть реализован подбор по штрихкодам с использованием камеры телефона.
-
Требовалось максимально уйти от сеансов.
Подсистема с универсальным HTTP-сервисом PAPI
Начал я с разработки универсального HTTP-сервиса, но в итоге у меня получилась целая подсистема – ее состав можно видеть на слайде.
В подсистеме присутствуют алгоритмы для различных вычислений – некие куски кода. Алгоритмы вы можете встречать и в других решениях, но мне эти решения казались очень громоздкими, или наоборот – очень маленькими, и я решил создать что-то свое.
В параметрах у меня можно указывать либо какие-то параметры, либо другой алгоритм. А в выбранном алгоритме может быть параметром еще какой-то алгоритм – это дает некую вложенность алгоритмов.
Также я реализовал возможность выполнять алгоритмы в фоновом задании, даже отложенно – для этого есть регистр, куда пишутся:
-
алгоритм;
-
некий ключ поиска;
-
и хранилище значений, в которое подаются параметры для выполнения;
-
когда алгоритм выполняется, проставляется статус «Выполнен» – если была ошибка, будет статус «Ошибка» и описание самой ошибки.
Кроме алгоритмов есть справочник «Методы», где описывается, что HTTP-сервис должен получить, как обработать данные и что отдать.
При создании определяется, каким образом будет реализован запрос – можно выбрать один метод или сразу все методы.
Здесь есть возможность версионирования, логирования, обработки параметров и обработки тела запроса.
В методе можно задать заголовки ответа, а сами вычисления могут быть оформлены как произвольный алгоритм или заданы изменением конкретных реквизитов объектов.
Создание мобильного приложения
В общем, немножко я затянул с созданием этого решения. Но в один прекрасный момент я сказал себе, что пора переходить к заказу и занялся уже разработкой приложения на мобильной платформе.
Первым делом я проранжировал данные, разбил данные на пакеты.
-
Простые пакеты – это документы и справочники.
-
Глобальные пакеты – различные срезы данных. Это может быть себестоимость, остатки по складам.
-
Разовые пакеты – это пакеты, запрошенные с мобильного приложения.
-
Есть еще данные, влияющие на доступность – это группы доступа, сегменты и т.п.
В обмене участвует 9 справочников, 6 документов, различные срезы данных и механизмы (сегментация, установка цен, остатки по складам, себестоимость, скидки).
На слайде изображен результат первоначального обмена с мобильным приложением у владельца восьми франшизных точек – этот партнер работает уже давно, у него очень много данных, и мы видим, что при первом обмене ему было передано чуть больше 13 МБ.
У владельца одной франшизной точки данных будет на 50-70% меньше.
Регистрация данных в «Рознице» была продумана таким образом, что можно было «на ходу» подключать к регистрации справочники и документы.
Для этого у меня используются подписки на события «ПередЗаписью» и регистр сведений «Объекты регистрации».
В регистре сведений «Объекты регистрации» можно выбирать типы объектов и указывать для них алгоритмы регистрации.
Например, для справочника «Номенклатура» здесь выбран алгоритм для регистрации, и в алгоритме регистрации указан один общий узел.
Все данные регистрируются на один общий узел, далее по регламенту распределяются на узлы устройств, и по последующему уже регламенту происходит пакетирование для устройства.
Создание узлов происходит при первом подключении устройства. Поиск узла происходит по идентификатору устройства и текущему пользователю.
Схематично это выглядит таким образом:
-
клиент считывает настройки с QR-кода и нажимает «подключиться»;
-
дальше отрабатывает метод, проверяющий первое подключение;
-
если все нормально, то возвращается информация по узлу, в том числе «Идентификатор узла».
Здесь изображена схема работы метода «Проверка подключения»:
-
Выполняется запрос – существует узел или нет. Если не существует, узел создается.
-
Потом идет проверка, нужно ли подготавливать данные для первого подключения.
-
Если нужно их готовить, запускается в фоновом задании алгоритм «Заполнение первоначальных данных на узле», который записывает данные на вновь созданный узел.
-
Если данные готовить не нужно, то просто возвращается информация по узлу.
-
-
Когда данные записаны на узел, в фоновом задании запускается еще один алгоритм, который пакетирует данные.
На слайде показано, как выглядит сам узел – он формируется на основе ключевых полей «Пользователь» и «Ключ устройства».
Узлу можно задать доступные данные – это некая фильтрация данных для устройства. Она заполняется на основе групп доступа.
Пакетирование
Хочу немного поговорить про пакетирование.
Чаще всего в стандартных и не только конфигурациях наблюдаю такое решение: берется файл или какая-то информация, режется на кусочки, и получатель, только когда получит все кусочки, может склеить все воедино и прочитать переданную информацию.
Так как я еще помню дискеты, меня такой подход не устраивал. Я хотел, чтобы мои части пакетов не зависели друг от друга, поэтому в пакетах я храню структуры элементов в формате JSON.
На слайде схематично показано, как происходит пакетирование.
В двух словах:
-
обходим все типы элементов, участвующих в обмене, получаем вес типа и согласно ему раскладываем элементы по порциям;
-
далее пакетируем порцию данных в массив, и этот массив переводим в формат JSON;
-
проверяем, что JSON читается – если прочитать не удалось, регистрация остается на узле, если все в порядке, то пакет записывается для дальнейшей передачи, а данные с узла чистятся.
Мобильному устройству остается только проверить, какие пакеты ждут передачи, забрать их и поставить статус «Принято» – обработать эти данные можно уже в офлайне.
Вычисление порции для типов элементов организовано так, как показано на слайде.
Есть регистр сведений «Коэффициенты порций», где для каждого типа данных хранится вес типа. Сам размер порций устанавливается на узле.
При формировании простых пакетов изменения элементов я определяю через:
-
свойство «ВерсияДанных» для справочников и документов – вы можете посмотреть это свойство через консоль запросов, оно есть у каждого элемента;
-
для табличных частей документов я использую хеш-суммы.
На слайде показана функция, которая переводит значение свойства «ВерсияДанных» в более понятный вид – из строки к числу.
Глобальные пакеты уже не могут использовать свойство «ВерсияДанных». Поэтому при пакетировании я использую хеш-сумму пакета и дату создания. И по этим двум параметрам уже можно понять, нужен пакет мобильному устройству или нет.
Небольшой пример, как создаются хеш-суммы. Допустим, у нас есть запрос, который получает данные, отсортированные в определенном порядке:
-
мы записываем выборку запроса в массив структур
-
потом переводим этот массив в JSON,
-
и уже этот JSON подаем в функцию для получения хеш-суммы.
На слайде представлена сама функция по формированию хеш-суммы.
Мы видим, что было подано, и что вернулось в зависимости от выбранных хеш-функций. Я обычно использую CRC32, но многие используют MD5 – кому как нравится.
Все регламенты по пакетированию, очистке устаревших данных и хранению настроек реализованы во внешней обработке, загруженной в подсистему «Дополнительные отчеты и обработки». Это сделано для того, чтобы можно было дорабатывать конфигурацию без проблем.
Основные возможности мобильного приложения
На слайде показан порядок формирования рекомендованного заказа.
-
Клиент на мобильном телефоне выбирает некие параметры, нажимает «Сформировать», эти параметры передаются в «Розницу».
-
В «Рознице» данные обрабатываются, и для заказа возвращается статус «Новый».
Всего у заказа может быть пять статусов:
-
Проект – это рекомендованный заказ, созданный в мобильном приложении, но ожидающий, когда данные придут из «Розницы»;
-
Новый – это заказ, данные которого уже были загружены в «Розницу», либо этот заказ был создан в «Рознице» вручную;
-
Заказан – это оформленный заказ, который еще не исполнен, еще есть возможность его отмены вручную;
-
Исполнен – заказ, который уже был обработан оператором, его можно отменить только через звонок менеджеру;
-
Отменен – отмененный заказ.
Подбор товаров происходит либо по штрих-коду, либо в ручном режиме.
Когда мы выбираем товары, они выделяются зеленым цветом, повторно их выбрать уже нельзя, но можно зайти в закладку «Подобранный товар» и убрать.
Если мы товары перенесли в документ и вдруг опять решили подобрать, товар из документа у нас уже подсвечивается жёлтым цветом, а вновь подобранный товар – зеленым.
Таким образом происходит установка цен – здесь используется точно такая же форма, как у заказов.
При подборе товара мы сразу видим его себестоимость и старую цену – это все хранится уже в телефоне.
Клиент указывает новую цену, нажимает «Оформить», и цена меняется в «Рознице».
Для ограничения подбора товара в заказах и установке цен используется сегментация.
Сегменты не видны клиентам, они видны только под суперпользователем.
JSON. Несколько шагов по уменьшению размера данных
Все данные у меня находятся в JSON. Почему, можно прочитать в статье.
Рассмотрим небольшой пример, как за несколько шагов можно немножко уменьшить объем информации.
Допустим, у нас есть пять элементов справочника Номенклатура. Мы формируем из них массив структур и переводим его в JSON.
Мы видим, что в этом JSON для каждого элемента повторяется тип «Номенклатура», и всего здесь 1198 символов.
Вторым шагом мы выносим тип за пределы – производим группировку по типу элементов.
Формируем массив структур, в котором есть:
-
свойство «ObjectType» – это тип «Справочник.Номенклатура»
-
свойство «Items», куда записывается уже массив структур без типа.
Теперь количество символов стало 1080 – это меньше на 9,84%.
Чтобы еще уменьшить, мы смотрим, что повторяется, какие данные есть по умолчанию.
Например, элементы с пометкой на удаление мы передаем реже чем без пометки, и группы у нас передаются реже чем элементы.
Убрав повторения и значения по умолчанию, мы получаем сокращение примерно на 27%. Теперь у нас 875 символов.
Что получил клиент от внедрения мобильного приложения на базе 1С
-
быструю реализацию мобильного приложения – клиент уже имел опыт заказа нативного приложения, его делали более 3-х лет, и это приложение до сих пор дорабатывается;
-
HTTP-сервисы, которые можно настраивать на клиенте;
-
это дало еще и уменьшение количества запущенных сеансов;
-
возможность быстрой доработки текущими силами (у них в основном программисты 1С);
-
и экономию финансов.
Разрабатывалось приложение на мобильной платформе версии 8.3.15.105.
Для тестирования использовался эмулятор для запуска Android-приложений BlueStacks, я его очень рекомендую.
Кроме этого, приложение тестировалось на моделях телефонов, перечисленных на слайде. Телефоны использовать для тестирования обязательно, потому что бывает, что на эмуляторе все нормально работает, а в телефоне могут выпадать ошибки. У меня такая ситуация была.
Сборка происходила сборщиком мобильных приложений 2.010.77.
Я словил интересную ошибку, но я думаю, что это непосредственно ошибка конфигурации сборщика приложений. У меня при сборке была такая ошибка «Разряд версии (28.0.0-rc1) не может быть преобразован в число». По точке останова я узнал, что в папке SDK есть некая папка build-tools, а в ней лежат различные версии сборщиков. У меня там лежало два релиза кандидата - «28.0.0-rc1» и «28.0.0-rc2». Когда я их оттуда убрал, сборщик уже нормально все прожевал. Видимо, в фирме 1С не предусмотрели, что могут быть релизы кандидаты.
Заключение
Подытожу: клиент получил мобильное приложение, а я подтянул свои знания по мобильной платформе и реализовал прототип системы универсальных HTTP-сервисов.
Сервис, который я разработал, я еще немного доделаю и выложу по этой ссылке. Сейчас там просто зарезервировано под статью. Будет, наверное, в виде расширения.
Все. Спасибо всем за внимание.
Вопросы
-
Как рассчитывается количество лицензий на мобильные рабочие места в случае, если используется мобильное приложение или мобильный клиент?
-
У меня используется мобильная платформа. Мобильный клиент требует лицензии, а мобильная платформа, если приложение распространяется бесплатно, лицензию не требует. На текущий момент приложение разработано и тестируется, оно пока еще не запущено в массы. А вопрос с лицензированием заказчик взял на себя.
-
Срезы – это какие-то регистры накопления сведений, где агрегируется какая-то информация?
-
Срезы – это документы, которые делают движение в регистре.
-
То есть там запускается какое-то фоновое задание, оно собирает какие-то данные?
-
Да, там есть обработка, которая лежит в «Дополнительных обработках и отчетах», в ней выбрано, какие срезы нужно заполнять, на сколько дней они должны проваливаться назад. Бывает, что нужна обработка задним числом, это переформируется, затем обрабатывается.
-
Я так понимаю, что вы специально разделили аналитическую и транзакционную нагрузку, определяя логику на стороне клиента. Но когда код приходится писать не в конфигураторе, а в подобных полях ввода, где даже нет подсветки, как это отлаживать?
-
Не вижу в этом проблемы. У меня на одном из слайдов, показано, что можно включить логирование – пишутся ошибки, где что и как смотреть. Но в целом пишется обычная обработка, в которой все отлаживается, и уже готовый код вставляется. Потом если нужно доотладить, дорабатываем.
-
Вопрос по обмену данными. Насколько я понял, данные группируются в некоторые группы, которые как бы имеют свой вес. И когда новый клиент к вам подключается, ему на мобильное приложение отправляются данные, которые имеют больший вес, которые более важны. А потом скачиваются остальные. Это так?
-
Есть некоторые данные, которые клиент должен получить по умолчанию. Они известны. По номенклатуре, по магазину, цены на товары. У каждого магазина четыре цены – это закупочная/розничная цена, ночная/дневная, налом/безналом. Их много.
-
Если данных много, как соблюдается их консистентность? Может ли быть такое, что клиенту отправили какой-то пакет, клиент что-то не получил или не подтвердил получение, и в итоге видит какие-то несогласованные данные?
-
Нет, такого не может случиться. Когда клиент получает данные, он получает оповещения, что все получил, и если у него что-то не прочиталось, допустим, виды цен, то оно попробует прочитаться в следующий раз. То есть все равно рано или поздно они прочитаются.
-
Не бывает такого, что пришла, например, одна цена, а другая не пришла?
-
Нет. Такого быть не может.
-
Какие проблемы при использовании мобильного приложения есть на сегодня с точки зрения пользователя, с точки зрения разработчика и с точки зрения руководителя?
-
Для руководителя, наверное, не важно, что там будет использоваться. С чем я столкнулся – нет фоновых заданий. Но мы все знаем, как это обходить. В остальном, если вы в платформе разрабатываете, то никаких сложностей не должно возникнуть.
*************
Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Ekaterinburg.Online.
