- PVSM.RU - https://www.pvsm.ru -
Первые две главы это попытка структурировать опыт интеграции 1С с другими приложениями и веб сервисами. Сам цикл думаю будет интересен программистам 1С, которые пытаются выйти за рамки платформы, и попробовать что-то новое. Разработчики Android приложений ничего нового для себя не узнают, но возможно им будет интересно, а как это выглядит на стороне 1С. Начиная с четвертой части будет попытка объединить несколько разрозненных статей из интернета по использованию библиотек, а также актуализировать данные по ним. Цикл задумывался как учебник, в котором описан опыт разработки реального приложения. Сам я не являюсь разработчиком под Android. Но к окончанию серии надеюсь им стать.
В текущем виде с 1С можно связаться тысячей и одним способом. Рассмотрим несколько вариантов, и почему я их не использовал.
Задачи которые решает наше приложение. “Все, что можно сделать на ТСД, надо делать на ТСД”. Ну а так стандартный набор: приемка, инвентаризации, этикетки, ценники.
Возвращаемся к структуре API. Обмен между ТСД и 1С будет производится в формате JSON. В ответе у нас будет всего два объекта {result, payload} соответственно: результат и полезная нагрузка. В результат мы будет отдавать два поля {code, msg}. И всегда будем отвечать HTTP кодом 200. Так нам будет проще на стороне клиента разбирать структуру ответа. Все остальные ответы будут приходить в виде строки. 1С нам не позволяет кастомизировать ответы вне платформы.
Теперь у нас получается следующая схема. Если ответ 200, то значит наши процедуры в 1С отработали нормально. Если другой ответ, значит у нас проблема ниже. Тут мы можем сильно не углубляться, что же пошло не так, а сразу показать пользователю какая ошибка, и ее описание. Кто-то может сказать, что ошибки нужно обрабатывать без участия пользователя, но у нас может быть две ситуации: 1 — сервер вернул ошибку. 2 — банально нет связи. В первом случае мы даже можем не узнать, что что-то сломалось(Например ошибка 404: приложение запросило не существующий метод. 500: Платформа упала с исключением). Во втором мы не можем передать результат для анализа на сервер. По этому показываем ошибку, и ждем дальнейших действий пользователя.
Полезная нагрузка будет содержать разные объекты. Это может быть список товаров, список документов, там же будет передаваться список действий. На стороне приложения мы их будем описывать моделями и аккуратно складывать в БД. Список действий будем запускать на исполнение, и результаты аккуратно складывать в БД.
Цикл обмена с ТСД будет следующий:
Такая схемы выбрана по причине того, что ТСД может быть выключенным, вне сети и т.д. Но нам ничего не мешает доработать 1С так, чтобы при изменении данных, уведомить об этом другое приложение(веб сервис). При таком обмене мы сообщаем, что есть новые данные. Приложение запрашивает какие данные есть, и цикл повторяется. Пример обмена представлен на диаграмме.
На этом всё. Если есть вопросы, замечания, предложения, прошу писать в комментариях.
Автор: loki82
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/android/334789
Ссылки в тексте:
[1] Реализация API на стороне 1С.: https://habr.com/ru/post/473546/
[2] Источник: https://habr.com/ru/post/473500/?utm_campaign=473500&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.