- Выбор способа обмена. Описание API.
- Реализация API на стороне 1С.
- BroadcastReceiver. Получаем штрихкод на примере АТОЛ Smart.Lite.
- OnKeyUp. Получаем штрихкод со сканера с эмуляцией клавиатуры
- Android. Cтруктура приложения.
- Реализуем обмен и хранение данных. Используем Retrofit 2, Room, Coroutines.
- Пользовательский интерфейс. LiveData, PagedList.
Для кого
Первые две главы это попытка структурировать опыт интеграции 1С с другими приложениями и веб сервисами. Сам цикл думаю будет интересен программистам 1С, которые пытаются выйти за рамки платформы, и попробовать что-то новое. Разработчики Android приложений ничего нового для себя не узнают, но возможно им будет интересно, а как это выглядит на стороне 1С. Начиная с четвертой части будет попытка объединить несколько разрозненных статей из интернета по использованию библиотек, а также актуализировать данные по ним. Цикл задумывался как учебник, в котором описан опыт разработки реального приложения. Сам я не являюсь разработчиком под Android. Но к окончанию серии надеюсь им стать.
2. Выбор способа обмена. Описание API
В текущем виде с 1С можно связаться тысячей и одним способом. Рассмотрим несколько вариантов, и почему я их не использовал.
- Native компонента — По большей части ее хорошо использовать для Offline обмена. Для Online она плохо приспособлена. Еще хуже стало, когда 1С начала внедрять свои стандарты для обмена с торговым оборудованием. А так же данная компонента вызывается на стороне 1С. Мне не подходит.
- WEB-Сервисы — Больше предназначены для обмена между приложениями которые разрабатывают разные команды. Тяжеловесны, используют XML. Лично для меня очень тяжело разрабатывать. И еще тяжелей интегрировать в JavaScript, Golang и т.д. Не подходит.
- HTTP-Сервисы — Почти тоже самое что и WEB-сервисы, но логику работы и протоколы обмена, мы описываем полностью сами. Здесь мы не ограничены в изобретение собственного велосипеда. По этой причине был выбран именно этот механизм обмена.
Задачи которые решает наше приложение. “Все, что можно сделать на ТСД, надо делать на ТСД”. Ну а так стандартный набор: приемка, инвентаризации, этикетки, ценники.
- Работа с товарами: Печать этикеток и ценников, присвоение штрихкода(ШК), проверка ШК, удаление ШК, просмотр цен и количества по складам.
- Инвентаризация — Собственно проведение инвентаризаций.
- Поступление — Приемка товара по накладной, печать расхождений, печать внутренних документов, статусы накладной.
- Сбор товара, Реализация(Розничная) — Идея состоит в том, что продавцы не находятся за кассой, а ходят или вместе с покупателем, или собирают товар по заявке и т.д. На кассе стоит только один человек, с ТСД передается готовый чек. Покупатель, только оплачивает товар.
- Сбор товара, Реализация (Оптовая) — Собираем товар по счету. Проверяем что есть в наличии. Формируем отгрузку(с пакетом нужных документов). Не забываем про проверку на возможность отгрузки контрагенту.
- Сбор товара, подготовка к отгрузке — Собираем товар по заявкам, складываем на паллету, печатаем документы: упаковочная ведомость и т.д.
- Перемещение — Собираем товар по перемещению, отдаем в доставку.
- Сбор товара, произвольный список — Нужен для проведения переоценок, обновления ценников, этикеток, прочих подобных операций.
Возвращаемся к структуре API. Обмен между ТСД и 1С будет производится в формате JSON. В ответе у нас будет всего два объекта {result, payload} соответственно: результат и полезная нагрузка. В результат мы будет отдавать два поля {code, msg}. И всегда будем отвечать HTTP кодом 200. Так нам будет проще на стороне клиента разбирать структуру ответа. Все остальные ответы будут приходить в виде строки. 1С нам не позволяет кастомизировать ответы вне платформы.
Теперь у нас получается следующая схема. Если ответ 200, то значит наши процедуры в 1С отработали нормально. Если другой ответ, значит у нас проблема ниже. Тут мы можем сильно не углубляться, что же пошло не так, а сразу показать пользователю какая ошибка, и ее описание. Кто-то может сказать, что ошибки нужно обрабатывать без участия пользователя, но у нас может быть две ситуации: 1 — сервер вернул ошибку. 2 — банально нет связи. В первом случае мы даже можем не узнать, что что-то сломалось(Например ошибка 404: приложение запросило не существующий метод. 500: Платформа упала с исключением). Во втором мы не можем передать результат для анализа на сервер. По этому показываем ошибку, и ждем дальнейших действий пользователя.
Полезная нагрузка будет содержать разные объекты. Это может быть список товаров, список документов, там же будет передаваться список действий. На стороне приложения мы их будем описывать моделями и аккуратно складывать в БД. Список действий будем запускать на исполнение, и результаты аккуратно складывать в БД.
Цикл обмена с ТСД будет следующий:
- Приложение по команде отправляет запрос к 1С.
- 1С формирует ответ и возвращает структуру с результатом и данными. В 1С в регистрах сведений накапливаются измененные данные в разрезе ТСД(веб сервиса).
- По запросу от приложения, отправляется список методов, которое должны быть вызваны.
Такая схемы выбрана по причине того, что ТСД может быть выключенным, вне сети и т.д. Но нам ничего не мешает доработать 1С так, чтобы при изменении данных, уведомить об этом другое приложение(веб сервис). При таком обмене мы сообщаем, что есть новые данные. Приложение запрашивает какие данные есть, и цикл повторяется. Пример обмена представлен на диаграмме.
На этом всё. Если есть вопросы, замечания, предложения, прошу писать в комментариях.
Комментарии (41)
kolu4iy
29.10.2019 21:17Посмотрите лучше недорогой продукт от cleverence. Я к нему отношусь как покупатель исключительно, но к 1с цепляется влет (целая куча готовых сценариев может быть куплена), а можно купить платформу разработки, которая интегрируется со всем вообще (это мой сценарий использования).
loki82 Автор
29.10.2019 21:39Раньше я писал приложения на их платформе. Интеграция была через COM-коннектор из сторонней БД. Как сейчас не знаю. Но вот нашел я у них то, что мне нужно под JSON, и цена там выскочила 58к.
1c80
29.10.2019 22:45Да, хорошая штука, недорогая, легко кастомизируется и надежно работает, есть мелкие косячки, но они легко устраняются
Fragster
29.10.2019 10:55Я сделал несколько приложений в виде pwa с обменом с 1с через http сервисы. Сканер ШК был в режиме клавиатуры, перехват сканирования через отслеживание клавиатурных событий для всего, кроме инпута: github.com/FragsterAt/barcode_hid_reader Получается вполне симпатично (уж лучше, чем мобильное приложение от 1с).
lishniy
29.10.2019 12:15Когда-то работал с exeed WMS и у них был замечательный способ работы ТСД. Подключение устанавливалось через telnet. Выглядело это как-то так.
Как по мне это идеальное решение и в разы удобней чем работа через браузер или RDP. И, что важно, не требует писать под тсд специальный софт. Может кто подскажет как сделать такую систему?loki82 Автор
29.10.2019 12:25Есть один недостаток. Я так понимаю, это чисто on-line решение. Нечто подобное я видел на всем известном сайте. Там на HTML описываются формы и дейтсвия. Это все крутится под андроид. Какой там формат обмена не знаю. Вроде доработан и off-line режим. Сам не пробовал. Если с точки зрения технологии, то это мне напоминает обмена с Asterisk через внешнюю компоненту. От туда внешние события, туда пакеты с командами разделенные двумя
CRLF
gennayo
29.10.2019 13:55Идеальное? Чтобы вам с ним каждый день по 12 часов на складе работать :))
lishniy
29.10.2019 16:14Так и работал. Правда не со стороны работника склада. В процессе обучения новых людей никаких сложностей и желаний разбить терминал небыло. С RDP это были боль и страдания причем с двух сторон, и как программиста и как пользователя. Если Вы подскажите что-то более стоящее, буду только рад )
Fragster
29.10.2019 16:18Полуоффлайн клиент, загружающий в себя задания для сборки/размещения в месте с нормальной связью (да и сами данные по большому счету не такие большие) и последующей оффлайн работой. Затем результат выполнения — выгружающий обратно в информационную систему. Уж реализовать связь в зоне погрузки/разгрузки или каптерке не такая сложная задача (как полное покрытие склада включая всякие закоулки и ярусы)
lishniy
29.10.2019 16:37оффлайн работа накладывает очень много ограничений. Возможно часть этих ограничений не требуется на конкретно вашем складе. Что нужно было нам(из того что сразу на ум приходит).
1. Возможность отменить заказ пусть даже частично отобранный.
2. В случае если отборщик не нашел товар на месте хранения, убрать задание с этого места у остальных отборщиков
3. Возможность провести частичную инвентаризацию без остановки склада.loki82 Автор
29.10.2019 16:43Эти вопросы как раз будет закрывать моё приложение. Постоянное соединение держать не надо. Достаточно дёрнуть сервис раз в н секунд. Там будет ещё прослойка в виде прокси. Она будет отслеживать ТСД в офлайне. И если надо отменить заказ, а тсд не доступен, то ой. С этим надо что будет делать. В текущей реализации такого не будет это будет opensource. Бери и допиливай. Ещё планируется платная реализация. И там все это будет.
lishniy
29.10.2019 16:49Звучит интересно. Приложение на WinCE будет работать?
loki82 Автор
29.10.2019 16:53Нет. Это нативное приложение под андроид. Решил что, под wince и терминалов то почти не осталось. Точнее их миллионы. Но там уже эти вопросы закрыты. Тихонько пилится своими силами. Жду волны смены оборудования. Как раз где то 7-10 лет прошло массовых внедрений.
lishniy
29.10.2019 16:58В прошлом году запускали склад, брали новые терминалы Motorolla на wince. Рановато его закапывать еще.
loki82 Автор
29.10.2019 17:03Я б его давно уже похоронил. Учебников от Микрософта почти нет. Лучших практик тоже. Пальцеориентированный интерфейс? А что это? Мой выбор это ТСД на андроид. Может конечно я не умею их готовить, но нет, wince фу-фу-фу.
loki82 Автор
29.10.2019 16:48Кстати в третьей части я рассмотрел получение широковещательных сообщений. Андроид прекрасно справляется с оповещением о потери сети и о возобновлении. Можно не пытаться сто мильенов раз установить соединение. А терпеливо подождать.
Fragster
29.10.2019 17:01Ну в том-то и «полуоффлайновость», фантазию тут можно проявить очень сильно. Например все, о чем вы пишете требует запросы к серверу. Можно их делать при наличии связи или ставить в очередь (с автоотправкой при появлении связи), например. В любом случае задача минимизации трафика отдельным клиентом и отельным сервером с обменом через те же json решается. И простор для творчества тут очень широкий.
loki82 Автор
29.10.2019 17:10В статье как раз и описан цикл опроса. И чтобы не плодить единичные ЗАПРОСЫ, Все изменения под конкретный ТСД собираются в пачки по функционалу. А чтоб не потерять изменения. Блокируем пачку набора записей. Не думаю что их будет больше 1000. Помечаем ид, хэшем, номером сообщения. И отправляем на ТСД. Тем самым мы гарантируем передачу пачки. И минимизируем трафик. Там же описан кейс когда мы можем оповестить другой сервис. Но логика остаётся прежней. Без больших трудозатрат мы получаем гибкое решение.
Fragster
29.10.2019 18:45Вы делаете аналог планов обмена. Это считай что оффлайн. Полуоффлайновость же заключается в одновременной работе онлайн запросов и оффлайн (по функционалу). Например в некоторых случаях можно в ТСД подгрузить НСИ (целиком или частично), а потом при необходимости догружать. И при сканировании выдавать информацию не делая доп запросов к серверу.
loki82 Автор
29.10.2019 19:05Ну да. Считаю что 5-10 сек не критично скажется. А держать сокет открытым? Зачем на ТСД активное соединение? Чтоб батарейку выжирать быстрей? Только вот планы обмена 1С это очень и очень тяжело. Я наверное понимаю о чем вы. Делаем запрос к БД, смотрим наличие данных там, если не нашли идем на сервер. Но вот как отдать в ТСД новые данные? Это не сервер который может круглосуточно работать. У нас два варианта. Держать открытым соединение. Тогда прощай стандартные механизмы 1С. И у нас остаются два варианта. Native с TCP-сокетом. Или ReverseProxy с двунаправленным вызовом процедур. А Proxy уже поднимает TCP сокет. По моему это работа ради работы. Нам придется поддерживать 1С, Прокси, Android.
Fragster
30.10.2019 10:46Еще раз: у вас аналог планов обмена. Оффлайн работа, даже при цикле обменов раз в пять секунд. Я же реализовывал событийную модель. Вернее её смесь с обменами. Например на приемке и выдаче — в зоне покрытия — целиком онлайн. Для сборки и раскладки — получение списка заданий по кнопке, загрузка и их блокировка в 1с по другой кнопке (включая загрузку соответствующей НСИ), а далее оффлайн работа с ними. Если что-то отсканированное отсутствует в загруженной НСИ — то запрос на сервер за ней для отображения, но даже если не получилось — то все равно это собирать/раскладывать не надо, выводится окно только со ШК, без НСИ. По окончании работы — в зоне с доступом к сети — по кнопке выгрузка в 1с результатов.
loki82 Автор
30.10.2019 11:44Наверное опять не так выразился. Клиент когда ему надо ходит в online на сервер. При отсутствии товара, при протухшей метке времени. При печати этикеток, ценников. При работе вместо сканера кассира. Блокировка строк документов так же есть. Еще в планах «переключашка». Offline сбор данных, или online. При online можно совместно работать над документом приемки, инвентаризации, отгрузке. Разделив его на задания. Это не тема данного АПИ, это уже конкретная реализация действий сервера. Периодический обмен требуется для подгрузки изменений в справочниках. И раздачи заданий работникам. Некий гибрид. В API же описан хребет всей этой бизнес логики. На базе такой схемы можно реализовать любой механизм. Еще раз.
- Когда клиенту что-то надо, он идет незамедлительно на сервер.
- Когда серверу что-то надо, он это накапливает, и с очередным запросом от клиента, отдает
gennayo
29.10.2019 16:25А в чём были проблемы с RDP? Или, терминалы были не очень хорошие? Так-то даже и 1С по RDP на нормальных терминалах и с нормальным вайфаем вполне себе ничего выглядит…
loki82 Автор
29.10.2019 16:32Я думаю в этом и проблема. На больших складах разворачивать бесшовный WiFi. Та ещё задачка. И экономически не целесообразно. Плюс оверхэд на передачу картинки. Тут же текстовый протокол. Ну и принцип работы. Чай попил, задачу получил. Выполнил. Вернулся. Выгрузил. Повторил цикл. Я как раз к этому и стремлюсь. Онлайн офлайн режим. Протокол тот же текстовый с небольшим оверхэдом. Но возможностей получится больше. Тсд не только в роли дата коллектора, но и активный терминал с возможностью печати и обратной связью. А ля рабочее место не только кладовщика.
gennayo
29.10.2019 16:37Да вроде сейчас бесшовный вайфай не так уж и дорого собрать, на тех-же Ubiquiti. Но если бюджета на онлайн нет, может для не очень нагруженных складов и тестовый интерфейс подойдёт.
loki82 Автор
29.10.2019 16:44Тут вопрос не в оборудовании, а смонтировать это все под потолком на работающем складе.
tuxi
Это можно сделать на 1С 8.2? Если да, то завтра же пойду к 1С-кам тыкать им в лицо этой ссылкой :)
loki82 Автор
Там к сожалению придется идти сложным путем. Через WEB-сервисы. XML, WSDL. Но видел реализации, где в качестве сервера 8.3, и через COM-коннектор доступ в 8.2
sorgery
есть рабочий такой вариант: веб сервис 8.2 <-> веб-сервис (nginx+net core) <-> клиент приложение на ТСД. Прослойка по середке трансформирует сервисы 1с в веб апи + доступна из вне (авторизация и все такое)
tuxi
Ну вот у нас такое как раз и пилится регулярно и по ряду причин это надоело уже и хочется прямых и близких отношений. Но 1С-ки говорят, что в 8.2 все плохо с этим.
loki82 Автор
Я не совсем близко знаком со всеми технологиями. Но разве нет никакого конвертера xmlToJson на GoLang? Это бы сильно упростило жезнь.
tuxi
Через структуры что угодно можно. Не очень гибко, но все будет быстро.
У меня вопрос несколько иной: хочется работать с 1С, как с типовым REST сервисом и чтобы она могла работать с REST сервисами.
А в 8.2 «все через одно место» со слов парней из 1С отдела.
Из последнего:
— хэш md5 не могут генерировать.
— запрос по https отправить вместо http — несколько дней ушло.
— POST запрос сделать не могут.
Ощущение непрерывного путешествия по минному полю.
loki82 Автор
Давно бы уже свою функцию запилили.
Вот это уже странно. Там же просто.
УстановитьТелоИзСтроки()
ОтправитьДляОбработки(<HTTPЗапрос>, <ИмяВыходногоФайла>)
Вообще, 1С старается двигаться навстречу нормальным методам обмена. То что она у себя внутри все ломает это да.
Neikist
Так про 8.2 речь, она только в веб сервисы умеет насколько помню, в http сервисы не умеет.
З.Ы., а отправка POST из 1с, это да, и 8.2 умеет, правда не факт что всех версий.
loki82 Автор
Отправка POST существует еще со времен 7.7. Правда там использовался COM объект. Но все работало стабильно. Знаю точно что в 8.1 уже работало из коробки. Про WEB-сервисы. Нашел вот такую штуку. github.com/basgys/goxml2json. И тут на стороне 1с можем стандартные xml, на стороне приложения json.
Neikist
Com объект учитывая заявленную 1с кроссплатформенность это такое себе))
А насчет объекта HTTPСоединение да, я не очень помню с какой он версии есть, я даже 8.2 не сильно застал.
sorgery
в 8.2 да, а вот в 8.3 есть теоретический шанс через управляемые формы реализовать веб клиента под ТСД. Но с той конфой что есть, нам проще/дешевле периодически допиливать клиента ТСД чем переписывать всю конфу.
iliabvf
Давно уже реализал онлайн-офлайн андроид приложение на мобильной платформе 1С со своим обменом, как через HTTP так и Web сервисы. Можно и с 1С 8.2 и с 8.3 работать, как и с любой конфигурацией
loki82 Автор
Вот я трижды пробовал мобильную платформу, и трижды она не работала. То с одной ошибкой упадет, то с другой. Достаточно медленная. Пока добрые люди не «запилили» внешние компоненты для отлова Broadcast'ов, управления звуками, ну и еще по мелочи платформой пользоваться было нельзя. Там починили Push FCM? Или так и предлагают свой сервис использовать?
iliabvf
А можете поделиться компонентой для отлова Broadcast-ов и прочим?
С Push проблемы, но в остальном все суперстабильно.
loki82 Автор
У меня ее нет. Читал на других ресурсах, что существует и работает.