Что нужно чтобы опубликовать web сервис и http сервис
HTTP-сервис в 1С: создание, публикация и отладка
В платформе версии 8.3.5 появилась возможность создавать HTTP-сервисы. Как и «старые» SOAP web-сервисы, HTTP-сервис позволяет получать/изменять данные, но при этом, как утверждает компания 1С, HTTP-сервисы потенциально позволяют упростить создание клиентских приложений, уменьшить объем передаваемых данных и вычислительную нагрузку, все это особенно для мобильных устройств.
В этой статья я постараюсь рассказать о том, как создавать, отлаживать и использовать HTTP-сервисы в 1С.
Начнем с того, что для создания HTTP-сервиса нам необходим веб-сервер, например Apache 2.2 (начиная с версии 8.3.8 и Apache 2.4 подойдет). Описывать установку веб-сервера думаю нет необходимости.
Создание HTTP-сервиса
Итак, создаем новый HTTP-сервис:
Корневой URL — важный параметр, входит в адрес по которому сервис будет доступен после публикации.
В соответствующем разделе создаем новый шаблон URL и метод:
У шаблона URL есть единственное свойство — шаблон. Этим свойством можно задать путь по которому будет происходить обращение к HTTP-сервису. В шаблоне можно использовать параметризованные сегменты, как на рисунке ниже (об их использовании ниже).
У метода есть свойство HTTP-метод, которое можно указать выбрав одно из следующих значений: GET, POST, PUT, DELETE, PATCH, MERGE, CONNECT, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK или Любой.
При обращении к HTTP-сервису, платформа пытается сопоставить адрес, по которому произошло обращение с одним из имеющихся шаблонов и методов. Если сопоставить удалось, то будет выполнен обработчик метода, если же сопоставить не удалось, то будет возвращен код ответа 404.
Перейдем к примеру обработчика метода, в нем я возвращаю содержимое переменной «Запрос», которая передается в обработчик:
Публикация и проверка HTTP-сервиса
Наш HTTP-сервис готов к публикации, в этом нет ничего сложного (вероятно потребуется запустить конфигуратор от имени администратора):
После публикации я могу обратиться к сервису вот по такому адресу: http://localhost/HTTPTest/hs/Obmen/test-parametr/Test/GetInfo?param=value, где:
Параметры URL, параметры запроса и заголовки представлены в виде фиксированных структур.
Вероятнее всего, при обращение к HTTP-сервису нужно будет авторизоваться (если в базе есть хоть один пользователь), есть несколько способов решения этой проблемы.
Первый — изменить файл default.vrd, который находится в каталоге публикации. В этом файле нужно дополнить строку подключения к базе, например, было:
ib=»File=»C:\Base\TEST»;»,
ib=»File=»C:\Base\TEST»;Usr=Логин;Pwd=Пароль».
В этом случае любые обращения к HTTP-сервису не будут требовать логина и пароля.
Во-вторых, можно указывать логин и пароль при подключении к HTTP-сервису:
Учимся создавать http-сервисы (часть первая)
Цель. Научиться создавать http сервисы на платформе 1С: Предприятие 8.
План обучения:
Подготовка объектов метаданных для сервиса.
Создание http сервиса:
Публикация http сервиса:
Проверка работы http сервиса:
Если все нормально, в строке браузера прописываем путь к нашему сервису по определенному правилу и получаем результат работы сервиса.
Выполнение пунктов списка
Подготовка объектов метаданных
Создаем чистую базу данных:
Добавляем в базу данных справочник «Номенклатура»
Добавляем реквизит «Артикул» в справочник «Номенклатура»
Добавим регистр сведений «Штрихкоды»
Добавляем измерение и ресурсы в регистр сведений «Штрихкоды»
Измерение «Штрихкод» тип Строка длина Строки 100, ресурс «Номенклатура» ссылка на справочник «Номенклатура»
Добавляем общий модуль «ОбщегоНазначения»
В общем модуле напишем функцию, которая вернет JSON строку с данными
Обновим конфигурацию базы данных. Запустим программу в режиме «Предприятие». Заполним тестовыми данными справочник «Номенклатура» и регистр сведений «Штрихкоды»
Переходим к следующему пункту
Создание http сервиса
Добавляем новый сервис
Закладка «Основные» поле «Имя». Задаем имя. Имя может быть любым. Желательно чтобы имя сервиса отражало его суть. Закладка «Основные» поле «Корневой URL». Необходимо задать имя корневого url.
Закладка «Шаблоны URL». Добавляем новый шаблон. Задаем ему имя. Имя может быть любым. Желательно, чтобы имя отражало предназначение шаблона.
Закладка «Шаблоны URL». Добавляем новый шаблон. Задаем ему имя. Имя может быть любым. Желательно, чтобы имя отражало предназначение шаблона
В шаблоне добавляем метод. В данном методе будем программный код шаблона.
Публикация http сервиса
ВАЖНО, НА ВАШЕМ КОМПЬЮТЕРЕ УЖЕ ДОЛЖЕН БЫТЬ УСТАНОВЛЕН ВЕБ СЕРВЕР (APACHE (2.2 ИЛИ 2.4) ИЛИ ISS)
Запускаем конфигуратор 1С: Предприятия 8 в режиме «Запуск от имени администратора»
Главное меню Администрирование – Публикация на веб-сервере
Закладка «Основные» поле имя. Необходимо задать имя. Имя должно быть сформировано по правилу формирования имен переменных. Имя не должно содержать русских букв.
Закладка «Основные» поле «Каталог». Создаем на жестком диске каталог (например, www) и указываем к нему путь. В данный каталог будет размещена публикация.
Проверка работы http сервиса.
Прописываем в строке браузера ip адрес компьютера на котором работает веб сервис (в нашем случае это наша локальная машина)
После этого если веб сервер запущен, мы должны увидеть в браузере соответствующее сообщение.
Если все нормально, в строке браузера прописываем путь к нашему сервису по определенному правилу
Рассмотрим более подробно формирования строки запроса в строке адреса браузера
localhost – ip адрес веб сервера. Если запускаем браузер с той же машины где установлен веб сервер то ip адрес либо localhost либо 127.0.0.1 либо 192.168.XXX.XXX
Таким образом получаем формулу по которой собираем адрес
Ip адрес / имя публикации / hs / корневой каталог / шаблон/
WEB/HTTP сервисы. Базовые отличия и применение на практике
WEB и HTTP сервисы — две технологии, позволяющие получить доступ к 1С из внешней системы. Причем можно получить доступ как за файрволом, так и через прокси. В общем, практически из любой точки земного шара.
С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С и веб-серверы, и клиент, подключающийся к сервису.
Зачем это нужно?
Изначально сервисы разрабатывались для поддержки внешних систем: сайтов, интернет-магазинов, корпоративных порталов. В дальнейшем технология получила широкое распространение и сейчас используется в широком спектре схожих задач:
В качестве примера можно привести сервис обмена данными, который в типовых конфигурациях в части передачи данных реализован также на WEB сервисах. По сравнению с традиционными COM-соединениями он намного более быстр, а информационные базы в этом случае могут базироваться на абсолютно разных платформах: как на версиях, так и на разных операционных системах.
HTTP сервисы, поскольку они достаточно просты, могут выполняться на несложных и недорогих устройствах: таких как микрооборудование, телефония, терминалы сбора данных, электронные весы и так далее. Например, из 1С можно обратиться к IP-телефону, АТС или системе контроля доступа. В нашей практике был кейс, когда с телефонов Yealink вызывался сервис 1С, который записывал входящие звонки. Также это работало и в обратную сторону, и мы могли позвонить непосредственно с карточки клиента одним нажатием кнопки. Реализовывается это легко и быстро.
Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP.
В нашей практике был случай, когда для заказчика нужно было сформировать внешнюю печатную форму на основании обязательной анкеты, которую заполняли клиенты на специальном планшете. Для этого для планшета была сделана веб-страничка. И пока клиенты ждали своей очереди, они заполняли эту страничку, проставляя галки в нужных местах. При нажатии на кнопку «Отправить» данные отправлялись на сервис 1С, где уже всей мощью платформы формировался документ PDF с печатью и подписью, который затем распечатывался и прикреплялся к данным клиента. Все это было сделано за полтора дня, без изменений типовой конфигурации, в расширении.
Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис:
Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:
Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее.
WEB и HTTP сервисы: сходства и различия
WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что:
Теперь расскажем о различиях.
WEB технология — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML.
HTTP сервисы же основаны практически на голом HTTP, и эта технология ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON.
Логично, что WEB-сервисы потенциально сложнее в реализации, потенциально используют больший объем передаваемых данных и дают потенциально большую вычислительную нагрузку.
О форматах данных
Примерно так выглядит XML:
Это, кстати, хороший формат, позволяющий закодировать практически любые данные. А его мощь обеспечивает возможность создания шаблонов XML — XSD-схем, что описывают формат и допустимые типы данных.
Именно поэтому его используют различного рода госорганы.
А так выглядит JSON — формат немного попроще:
Здесь есть основные типы данных: это объекты, формируемые фигурными скобками, массивы, формируемые квадратными скобками, и значение, которое формируется в виде текста.
Данные для HTTP-сервиса передаются в виде запроса HTTP, схематично изображенного ниже:
Он состоит из строки запроса, из заголовка запроса, который представляет собой ключ и значение, также есть пустая строка и тело запроса в виде обычного текста. В теле запроса можно передавать любые данные, в том числе и двоичные, предварительно закодировав их в base64.
Так выглядит строка запроса в HTTP сервисе:
Сервис HTTP ресурсно-ориентирован. Конечные точки, к которым мы можем обращаться, являются ресурсами: они представлены именами существительными. На схеме это элементы строки orders и status, обозначающие соответственно ресурсы «Заказ» и «Статус заказа». Действия над ресурсами выполняются методами HTTP, базовыми из которых являются: get (получить ресурс), post (добавить ресурс), put (обновить ресурс), delete (удалить ресурс). Количество методов HTTP ограничено, действия над ресурсами тоже. Помимо указанных методов есть еще несколько дополнительных, но используются они значительно реже.
Также имеет место понятие коллекции: несколько ресурсов одного типа, из которых можно выбрать один по идентификатору.
Про проектирование
Теперь мы поделимся той болью, которую мы пережили при проектировании API с клиентами и партнерами. И теми шагами, которые необходимо предпринять, чтобы эту боль в будущем чуть-чуть уменьшить.
При создании API предполагается, что пользоваться им будем не только мы, но и партнеры, и пользоваться достаточно долгое время. Здесь не обойтись без тщательного и взвешенного проектирования. Каждый момент должен быть учтен.
Вспоминаем, что HTTP сервис — это у нас, в первую очередь, ресурсы. А ресурсы — это имена существительные: вот таких элементов, как /GetOrders или /orders/add, где в качестве ресурсов явно указываются глаголы действия, быть не должно. В качестве действий у нас должны выступать методы HTTP (get, post, delete).
Правильное проектирование обычно идет по иерархии: коллекция, элемент, ресурс. И вот здесь мы специально отобразили один интересный момент, связанный с особенностями ресурсной иерархии. Например, к заказу у нас прикрепляются накладные. Есть заказ, есть накладные, которые выдаются по этому заказу (одна или несколько). К этим накладным мы можем дать доступ и как к отдельному ресурсу /invoices, и как к ресурсу в составе заказа — когда накладная сделана на основе заказа /orders/
Для проектирования рекомендуется элементы, ресурсы и действия сводить в таблицу, где в строках располагаются ресурсы, а в столбцах — методы HTTP. На пересечениях строк и столбцов — описание, что должно выполняться в данном случае. Пример таблицы:
Благодаря этому мы понимаем, какое действие у нас происходит в случае применения каждого из методов HTTP к соответствующему ресурсу, а также можем легко расширять набор ресурсов и действий над ними.
Про документацию
Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры.
В самом начале мы «забивали» на документацию, а когда партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть.
Документацию мы рекомендуем вести в таком виде:
Вот пример документации. Заголовок, ответ, пример, описание полей данных:
Будь мужиком! Пиши логи!
На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем.
Разделяй код и властвуй над ним
Еще один очень важный момент при проектировании, при разработке таких систем — это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики. Сначала мы делаем обработку самого HTTP запроса, расшифровываем заголовки, тело запроса и результаты передаем в процедуры обработки данных, в другой модуль — модуль бизнес-логики. Для формирование тела запроса и запроса партнеру имеет смысл использовать отдельные общие методы, включающие в себя автоматический вызов функций логирования. И, естественно, мы должны выполнять начальный контроль данных, потому что, в отличие от WEB сервисов, контроль данных у нас не производится.
На примере этого кода продемонстрировано использование указанных выше правил:
В данном случае метод выполняет получение прайса от партнера. При получении производится запись запроса в лог с указанием имени сервиса. Затем выполняется разбор запроса, подготовка данных и формирование ответа на запрос.
Разбор запроса включает в себя чтение и подготовку всех параметров запроса, проверку обязательных параметров и валидацию их корректности.
После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа.
Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром).
HTTP-сервисы
В дополнение к автоматическому REST интерфейсу прикладного решения в платформе существует возможность создания собственных произвольных HTTP-сервисов в прикладном решении.
Разработчик самостоятельно, с помощью встроенного языка, формирует ответ на запрос. При этом есть удобный доступ к телу, заголовкам и строке исходного запроса, а также есть возможность формировать код, тело и заголовки ответа по своему усмотрению.
Первые три фактора особенно важны для приложений, работающих на мобильных устройствах.
Можно использовать HTTP-сервисы как «легкие» RPC-сервисы, не требующие сложной подготовки XML-пакетов. Методы могут идентифицироваться в URL, а параметры могут передаваться в опциях запроса, или в его теле. В последнем случае такие сервисы уже вплотную приближаются как SOAP, проигрывая ему в четкости спецификации, но выигрывая в гибкости.
По своему «конструктивному исполнению» HTTP-сервисы очень напоминают web-сервисы, имеющиеся в платформе. Точно так же есть специальный объект конфигурации HTTP сервис. Такие объекты добавляются в ветку Общие — HTTP-сервисы:
Каждый HTTP-сервис может содержать в себе один или несколько шаблонов. Для каждого шаблона можно создать один или несколько методов, выполняющих обработку данных:
Шаблон задаёт путь, по которому может происходить обращение к HTTP-сервису. В шаблоне можно использовать определённый набор символов, в том числе параметризованные сегменты вида .
Для каждого метода указывается, во-первых, обрабатываемый HTTP метод, а также создаётся процедура на встроенном языке, которая и будет выполнять обработку данных. Также можно указать, что будет обрабатываться не какой-то конкретный, а любой HTTP-метод из доступных.
При обращении к такому HTTP-сервису платформа сначала попытается сопоставить URL, по которому произошло обращение, с одним из имеющихся шаблонов и методов. Если сопоставить не удалось, то платформа выдаст код ответа 404 Not Found. Если подходящий метод будет найден, то платформа начнёт выполнение его обработчика, передав в него все имеющиеся в запросе данные в виде объекта встроенного языка HТТРСервисЗапрос:
Из этого объекта можно легко получить, например, параметры, содержащиеся в исходном URL, и использовать их для извлечения из базы нужных данных.
Полученные данные можно вернуть в разных форматах. Например, их можно преобразовать в XML, как на картинке выше, или даже просто в текстовую строку с разделителями.
Ответ сервиса формируется специальным объектом встроенного языка HТТРСервисОтвет, в тело которого можно поместить подготовленные данные.
Публикация HTTP-сервисов выполняется аналогично тому, как публикуются web-сервисы. Также аналогичным образом для них работает аутентификация, использование разделения данных и отладка.
Публикация базы 1С и HTTP-сервиса в интернете на IIS
Отправить эту статью на мою почту
Статья описывает пошаговые действия по публикации в интернете базы 1С Предприятие 8.3 (Управление торговлей 11) и собственного HTTP-сервиса на веб-сервере Microsoft IIS.
Для чего публиковать 1С в интернете?
Для доступа к функционалу 1С и вашей рабочей базе через обыкновенный веб-браузер или тонкий клиент. При этом никаких ограничений в вашей работе не будет, это все-равно что 1С установлен на вашем компьютере, только доступен через веб-браузер (даже со смартфона, правда, в случае смартфона – не очень удобно будет из-за отсутствия масштабирования).
Что касается HTTP-сервиса, то это более специфический функционал, кто понимает, что такое HTTP REST API, то уже может представить, что это такое. Если кратко, то HTTP-сервисы предназначены для программного обмена информацией между интернет-ресурсами, например, в моей статье про Скайп-боты в 1С HTTP-сервис обязательно нужен – он выполняет функции приема и обработки сообщений которые отправляются Боту в Скайпе от человека.
Данная статья представлена в виде видео-инструкции:
Устанавливаем веб-сервер Microsoft IIS (Internet Information Services)
Веб-сервер рекомендую устанавливать на серверной операционной системе, в моем случае это был Microsoft Windows Server 2012 R2.
Веб-сервер IIS можно устанавливать на рабочем сервер даже с активными RDP подключениями других пользователей, не бойтесь, их не выкинет из сервера 🙂
Если вы решили установить IIS на Windows 10 (7, 8), то установка IIS будет примерно такая же, только там не будет оснастки «Диспетчер серверов», вместо этого нужно зайти в Панель управления – Удаление программ, далее слева ссылка – «Включение и отключение компонентов Windows», ставим флаг напротив «Службы IIS», далее установите флаги как было описано выше.
Проверяем корректность установки веб-сервера IIS, для этого запускаем интернет-браузер, например, Хром и в адресной строке указываем локальный адрес текущего сервера: http://127.0.0.1, если всё сделано правильно, то откроется главная страница веб-сервера IIS.
Чтобы открыть панель управления веб-сервером IIS, перейдите в Панель управления компьютером, далее кнопка Просмотр – Категория – Мелкие значки, кликаем по «Администрирование».
Открываем ярлык – «Диспетчер служб IIS».
После того как вы поняли какая разрядность у вашей платформы 1С (х32 или как на скриншоте выше – х64), в диспетчере служб IIS выберите «Пулы приложений», один раз кликните левой кнопкой мыши по «DefaultAppPool» и справа нажмите ссылку «Дополнительные параметры», далее в строке «Разрешены 32-разрядные приложения» должность стоять False, а если платформа 1С у вас была бы не х64, т.е. х32, то здесь должно быть установлено значение True.
Заранее имейте ввиду, если после публикации 1С на веб-сервере вы откроете 1С в веб-браузере, далее откроете список документов и получите ошибку «Обнаружено потенциально опасное значение Request.Path, полученное от клиента (:)», то в настройках «DefaultAppPool» рядом с «Разрешены 32-разрядные приложения» есть строка «Режим управляемого контейнера», он должен быть «Classic».
Публикуем базу 1С на веб-сервере IIS
Кликаем по ярлыку 1С правой кнопкой мыши и выбираем пункт – «Запуск от имени администратора».
Запускаем нужную базу 1С в режиме конфигуратора. Внимание! Конфигурация 1С должна быть на управляемых формах, иначе публикация будет бессмысленная, например, Управление торговлей редакции 11.х можно публиковать и иметь к ней доступ через веб-браузер, а Управление торговлей редакции 10.х нельзя. Но это не касается HTTP-сервисов, если вы создадите свой HTTP-сервис в Управление торговлей редакции 10.х, то он будет работать.
В конфигураторе нажмите кнопку меню Администрирование – Публикация на веб-сервере. Далее кнопку «Опубликовать». Только запомните название публикации, в моем случае (на скрине ниже) – «DemoTrd».
Может появиться просьба перезапустить веб-сервер IIS, соглашаемся.
Если база файловая:
То может отобразиться предупреждение при публикации на веб-сервере:
Дайте полные права пользователю IUSR на директорию в которой установлена база 1С (адрес директории отображается в окне с ошибкой о правах см. выше или в окне «О программе» также смотрите выше).
Теперь можете проверить работу 1С в режиме веб-браузера, для этого открываете веб-браузер на том же сервере где только что настраивали веб-сервер и вводите адрес: http://127.0.0.1/DemoTrd
Если всё сделали правильно, то откроется база 1С.
Публикуем HTTP-сервис 1С на веб-сервере IIS
Давайте по-быстрому создадим свой HTTP-сервис который будет просто возвращать слова «Всё хорошо!» при обращении к нему через обычный веб-браузер.
Советую более наглядно это посмотреть в моей видео-инструкции:
В конфигураторе создаем новый HTTP-сервис, с шаблоном по умолчанию и одним GET методом у которого будет обработчик такого вида:
Обновим нашу публикацию на веб-сервере, для этого снова нажмите в меню Администрирование – Публикация на веб-сервере, убедитесь, что на закладен HTTP-сервисы установлен флаг на против нашего HTTP-сервиса:
Нажимаем «Опубликовать». Должно появиться сообщение – «Публикация обновлена».
Теперь можете проверить работу опубликованного HTTP-сервиса в режиме веб-браузера, для этого открываете веб-браузер на том же сервере где только что настраивали веб-сервер и вводите адрес: http://127.0.0.1/DemoTrd/hs/test где «test» это корневой URL HTTP-сервиса, в итоге, если всё настроено верно, то получим сообщение «Все хорошо». Единственное, браузер может попросить указать логин и пароль пользователя из базы 1С.
Доступ к вашей базе 1С из любой точки земли и интернета
Если IP адрес вашего сервера внешний и статический (это можно узнать у вашего системного администратора и интернет-провайдера), то открывать вашу базу 1С и HTTP-сервис через интернет можно будет с любого компьютера подключенного к интернету, для этого в интернет-браузере вводите внешний статический IP-адрес сервера вместо 127.0.0.1 в адресах указанных выше.