В 1С существует немало возможностей для обмена данными, включая файловый обмен и COM Connector. В этой статье я расскажу, когда при интеграции 1С не обойтись без веб-сервисов, а также в чем плюсы использования SOAP или, наоборот, HTTP. Кроме этого речь пойдет про рабочие инструменты и примеры использования веб-сервисов.

Веб-сервисы — достаточно простая штука. Существует множество инструкций по их созданию, так что запустить свой сервис может почти каждый. Сложности возникают тогда, когда веб-сервисы начинают куда-то встраивать, например, в системы 1С.

Зачем встраивать веб-сервисы в 1С

Как разработчик 1С я могу назвать 5 ситуаций, когда возникает реальная потребность в использовании веб-сервисов:

Источник и получатель данных удалены друг от друга или, говоря другими словами, существуют ограничение на файловый обмен/использование общих файловых хранилищ. Конечно, в этом случае можно работать с облачными хранилищами, например, Яндекс.Диском, но такой подход не всегда удобен.

Инициатором общения выступает клиент, а значит стандартные файловые обмены 1С могут не подойти, так как они имеют ограниченный функционал. Конечно, вы можете настроить расписание или обмениваться файлами после определенных событий. Но все это не гарантирует высокой доступности данных.

В обмене данными участвуют разнородные платформы — это могут быть разные ОС, языки программирования, различный софт. Организовать обмен данными между ними без COM-Connector, библиотек интеграции или веб-сервисов будет очень сложно.

Существует необходимость высокой доступности данных, а счет идет на миллисекунды. В этом случае файловые обмены по расписанию не подходят в принципе. Даже веб-сервис нужно выстраивать правильно, чтобы обмен данными шел достаточно быстро.

Когда нет возможности использовать COM Connector, приходится заниматься веб-сервисами, например, если у нас больше 1 базы данных, и все они используют разную версию платформы. Придется придумывать способ динамически актуализировать версию COM Connector’а. Для подобных ситуаций существуют скрипты, но их реализация требует грамотного подхода и комплексной поддержки. К тому же COM Connector позволяет запускать вообще любые скрипты, и он порой оказывается запрещен именно по соображениям информационной безопасности.

Во всех этих ситуациях для решения задачи обмена данными подходят веб-сервисы. Они не позволяют исполнять на сервере произвольные скрипты, открывают возможности для ускоренного обмена данными, а также не зависит от конкретных версий ПО, платформ или характеристик канала связи.

В случае, когда речь идет об интеграции с разнородными системами, веб-сервисы помогают избежать трудоемких доработок. Например, стандартная выгрузка 1С может хорошо подойти для сайта, а также для клиентов под Windows и Linux. Но стоит добавить в эту экосистему Android, придется все переписывать и делать заново. Чтобы такое не происходило, я стараюсь делать такие интеграции через HTTP.

Нюансы создания веб-сервисов для 1С

Если выбор в пользу веб-сервисов уже сделан, далее необходимо определиться с архитектурой —- SOAP или HTTP (в терминологии 1С — Web-сервисы и HTTP-сервисы). И надо учитывать ограничения обоих форматов.

Для SOAP характерны более тяжелые сообщения. При обращении к веб-сервису происходит выгрузка всего содержимого, и пользователь получает пакет с мета-данными и описанием самого сервиса. И если сервис достаточно тяжелый, все это может занять значительное время — вплоть до нескольких секунд.

Не все платформы поддерживают SOAP и XML. Например, если у вас был опыт работы с Android, и вы пробовали настроить обмен сообщениями с Android-приложениями, то знаете, что у них нет привычных для 1С средств разбора XML и SOAP. Можно, конечно, перейти на Json, но даже это не решает всех вопросов, одновременно создавая дополнительные сложности интеграции.

Наконец, не все платформы имеют одинаковый взгляд на формат сообщений в рамках обмена. Даже четкое описание SOAP-сервиса, но с нехарактерной для 1С структурой, потребует дополнительных усилий при интеграции: в таком случае приходится парсить XML внутри конфигурации, а это — трудоемкая задача.

Подобная проблема есть и с другой стороны: некоторые платформы не могут принять пакет, сформированный в 1С, так как они ожидают получить данные в совершенно другом формате. Например, в стандартных выгрузках 1С существует проблема с нестрогой типизацией полей, которая может быть востребована в других приложениях.

Впрочем, HTTP — тоже не панацея. И если в описании SOAP-сервиса содержится все возможное — полный набор данных и метаданных, процедуры, которые он выполняет, характеристики входных данных и их форматов, у HTTP-сервисов такого нет. Ресурсно-ориентированная архитектура подразумевает наличие одной только ссылки. Как результат — отсутствие автоматизации навигации среди ресурсов.

Как следствие, для HTTP-сервисов возникает необходимость в более подробной документации. И те, кто когда-нибудь получал API, документированную на бумажке или недокументированную вовсе, не понаслышке знают об этой проблеме.

Форматы вызовов

Вот так выглядит простейший вызов SOAP-сервиса. В нем происходит запрос списка Items.

Первым запросом GET происходит запрос описания сервиса и его метаданных. Вторым запросом POST — всего остального.

В системах, которые требуют быстрого отклика, такая схема работы становится серьезным ограничением. Тут лучше выбрать HTTP-сервис, для которого необходима передача намного меньшего объема данных.

Инструменты для работы с веб-сервисами

Для работы с веб-сервисами я использую общие инструменты тестирования и отладки. В частности, очень полезны оказываются интерфейсы отправки запросов, такие как Postman, SoapUI, Advanced REST Client. На мой взгляд, Postman — один из самых развитых инструментов этой категории. Неопытный разработчик может готовить обработку, которая запускается из 1С и вызывает сервис. Но рано или поздно станет очевидно, что тестировать с помощью такой структуры, а потом — готовить документацию — оказывается сложно.

Второй обязательный инструмент экосистемы — Proxy-серверы для веб-отладки. Я использую Fiddler, Charles, mitmproxy. Они нужны в тех случаях, если нет полной уверенности в том, как идет обмен данными между системами. С помощью Proxy разработчик может увидеть, что конкретно передает или получает сервис. Proxy помогает выяснить, почему сервис не работает, а в некоторых случаях — почему он, несмотря ни на что, работает?

Proxy-сервер отслеживает все сообщения, которые проходят через HTTP-порты, а при помощи Fiddler с правильным сертификатом можно анализировать даже HTTPs-трафик.

Есть также утилиты, специально созданные для интеграции HTTP-сервисов в экосистеме 1С. В практике Neti активно используется консоль HTTP-запросов (http://infostart.ru/public/835540/). Она предоставляет функции, во многом аналогичные Postman (кроме, пожалуй, документации), а также обладает своими уникальными фичами. В консоли можно делать вызов HTTP-сервиса, но при этом генерировать код вызова для приложений 1С (когда в Postman можно работать только с Java, C++ и другими универсальными языками программирования).

Внимания заслуживает и библиотека 1CHTTP-Connector (http://infostart.ru/public/709325/). Она предлагает прекрасный способ вызова сторонних HTTP-сервисов. При работе над интеграцией, в этой библиотеке можно найти нужные методы и обработчики и без лишних затрат времени реализовать нужный функционал, а также проанализировать ответы сторонних сервисов.

Документация

При работе с веб-сервисами нужно помнить, что документация — это основная проблема при разработке API. Прежде чем сделать недокументированный сервис, подумайте о других людях…или о себе самом, когда через несколько месяцев будете пытаться вспомнить, что было запрограммировано в этом сервисе.

Простой способ генерации документации предлагает Postman. Прямо в этом ПО можно сформировать все базовые описания. Общедоступная ссылка, которую сервис дает на выходе, будет вести на страницу вашего сервиса со всеми доступными методами взаимодействия и примерами ответов. Там же можно добавить дополнительное описание, уже от себя, назначить порядок вызовов. При работе с таким API, любой пользователь сможет просто Open in Postman и сразу приступить к тестированию и интеграции.

Swagger — это еще одна альтернативная система для работы с документацией. Он чуть сложнее чем Postman, но зато совмещает в себе сервисы документирования и тестирования. В Swagger тоже можно получить готовую веб-страницу с описанием сервиса, включая методы, форматы ответов и запросов. Но при этом прямо на странице Swagger можно производить отладку.

Кейсы интеграции API

Я использую веб-сервисы в основном для интеграции разнородных систем и удаленного обмена данными с БД 1С. Из практики Neti можно привести несколько примеров подобных проектов.

Печать чеков с нескольких терминалов или с удаленного терминала. Часто компаниям не хочется или невыгодно покупать несколько принтеров чеков или кассовых терминалов. А в случае с АТОЛ печатать их можно с использованием через веб-сервер с поддержкой Json (такая фича есть в последних драйверах). Поэтому мы можем отказаться от СОМ-библиотек в 1С и печатать, используя разные сессии с разных машин. Таким методом могут пользоваться и Интернет-магазины: веб-сервисы позволяют использовать при оформлении заказа через Интернет ту же кассу, которая стоит в обычном оффлайн магазине вместо покупки или аренды фискального регистратора.

Онлайн продажа цифровых продуктов. В моей практике был случай, когда у компании имелась база 1С, и в ней хранились ключи к ПО. Заказчику хотелось сделать так, чтобы база стала центром процессинга, и продажа ключей происходила из нее практически напрямую. Наша команда сделала сайт, подключила 1С и некоторые другие платформы. И теперь, когда клиент делает покупку на сайте, он получает сразу весь комплект документов. А для партнеров появилась возможность встраивать функционал в 1С, чтобы мгновенно получать ключи — сразу после оплаты заказа. Без использования веб-сервисов это, наверное, было бы невозможно, например, как и интеграция 1С с мобильными приложениями.

Поддержка американского налогового учета. Веб-сервисы позволяют настроить получение данных из бесчисленного количества источников. Например, недавно разработчики Neti добавили функцию налогового учета по американским стандартам в 1С:Drive. Веб-сервисы помогли нам организовать поставки данных о налогах и позволили учитывать индивидуальные ставки на каждый продукт и для каждой территории. Это серьезное отличие системы налогообложения в США от России и Европы, и ее реализация в 1С без веб-сервисов была бы крайне проблематична.

Интеграция однородных систем

Веб-сервисы не менее успешно используются для онлайн-обмена с удаленными базами 1С. На одном из проектов необходимо было наладить передачу данных из центральной базы ЗУП, по распределенной сети во множество конечных точек. Другими словами, в розничные магазины нужно было доставлять информацию о кадровых изменениях.

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

Где узнать больше о разработке веб-сервисов

Приступить к работе с веб-сервисами можно, начав с чтения  ИТС. Обратить внимание стоит на такие главы, как «Механизмы интернет-сервисов», где подробно рассматривается процедура разработки.

В ИТС можно также прочитать про OData — мощный инструмент, позволяет получать данные из 1С вообще без лишних веб-сервисов. При работе с OData достаточно опубликовать БД и выбрать метаданные, которые нужно поставлять наружу. Один запрос позволяет получить, например, справочник номенклатуры или какую-то другую информацию. OData — это способ легкой интеграции, у которого есть ограничения в сложности запросов и другие особенности, но зато в ряде случаев можно вообще ничего не программировать.

Много полезной информации можно найти в книге «Профессиональная разработка в среде 1С». В ней  подробно рассмотрены различные механизмы интеграции, а также возможности OData с пошаговой инструкцией по созданию HTTP-сервисов.

И, конечно, на Infostart.ru каждый месяц на портале появляются десятки статей о том, как создавать и развивать веб-сервисы. Они могут стать хорошим подспорьем, с одной только оговоркой — в большинстве случаев о документировании придется заботиться самостоятельно.