1Cv8 Mobile Module05

Курс дистанционного обучения
Разработка мобильных
приложений на
1С:Предприятие 8.3
Модуль 5
Отладка, публикация, HTTP-сервисы
Проект Курсы-по-1С.рф
2016
Курсы-по-1С.рф Профессиональные курсы по 1С
по всей России, в любое время
Оглавление
Публикация 1С на веб сервере ........................................................................................................................... 3
Отладка по HTTP............................................................................................................................................... 3
Особенности работы с отладкой по HTTP ...................................................................................................... 7
Публикация базы данных на веб-сервере ....................................................................................................... 11
Публикация базы данных на Apache ............................................................................................................ 12
Публикация базы данных на IIS .................................................................................................................... 16
Web-сервисы ...................................................................................................................................................... 22
Структура HTTP-сервисов .............................................................................................................................. 23
Строка URL .................................................................................................................................................. 24
Заголовок .................................................................................................................................................... 25
Тело запроса ............................................................................................................................................... 26
Методы запроса ......................................................................................................................................... 26
Код состояния............................................................................................................................................. 28
Итоги ........................................................................................................................................................... 29
HTTP-сервисы в 1С ......................................................................................................................................... 29
Итоги по HTTP-сервисам................................................................................................................................ 35
Протокол HTTPS.................................................................................................................................................. 37
Практические задания ....................................................................................................................................... 40
Задание 5.1 Оперативная информация ........................................................................................................... 40
Задание 5.2 Использование HTTPS ................................................................................................................... 41
Страница 2 из 41
Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

http://курсы-по-1с.рф/free/ Телефоны: 8-800 1000-613, +7(495) 7777-096
Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

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

В целом, 1С работает с веб-серверами в трех разных режимах:
1. Публикация конфигурации мобильного приложения (рассмотрено в предыдущих модулях)

2. Публикация базы данных для возможности взаимодействия с её объектами (веб-клиент, тонкий
клиент, HTTP-сервисы и т.д.)
3. Публикация сервера отладки для возможности работы с отладкой на мобильных устройствах,
стационарных компьютерах, а также работы с EDT.
Сейчас будет идти разговор о третьем режиме, а именно – об отладке по HTTP-протоколу. Так как
это нам сильно поможет при работе на втором этапе – при отладке мобильного приложения.
Отладка по HTTP
В версии 8.3.7 появился новый вариант отладки – по HTTP. Выглядит это так:
1. Поднимается сервер отладки на конкретный адрес и порт на стороне сервера

2. На стороне клиента – прописывается этот путь для отладки в режиме HTTP, клиентами
отладки могут выступать как другие стационарные 1С, так и мобильные клиенты (в том числе
и скомпилированные версии)
3. В момент отладки обращение идет через сервер отладки, т.е. каждый момент времени
мобильная 1С обращается к серверу отладки и забирает у него информацию о точках
останова и, находя такую в мобильной конфигурации, отправляет на сервер информацию о
значениях остановки, в том числе и значения всех переменных.
Для того чтобы настроить сервер отладки по HTTP, нам не нужен веб-сервер (ни Apache, ни IIS),
поэтому, если вы планируете использовать только отладку по HTTP, вам не нужно устанавливать
какой-либо веб-севрер.
Для этого 1С имеет специальную утилиту:
C:\Program Files (x86)\1cv8\8.3.7.1759\bin\dbgs.exe


Именно она умеет слушать определенный порт и взаимодействовать с ним. Минимальная установка
может выглядеть так:
Обратите внимание – нам не нужен даже модуль расширения веб-сервера.
Теперь необходимо включить эту утилиту для возможности отладки по HTTP. Делается это так:
1. Заходим в Сервис – Параметры:


2. Тут нужно указать протокол отладки, в нашем случае это будет отладка по HTTP.
3. Указать сервер отладки (можно использовать как свой локальный сервер, так и удаленный
сервер или кластер в случае использования клиент-сервера).
Важно! Необходимо указать именно адрес сетевой карты, а не localhost или 127.0.0.1, так как у
1С утилита dbgs – не полноценный веб-сервер и умеет слушать только один конкретный IP
адрес! 127.0.0.1 или localhost можно указывать только в том случае, если вы планируете
отладку исключительно на текущем компьютере, но тогда использование данного вида отладки
не имеет никакого смысла.
Далее необходимо указать порт отладки, причем он не должен быть занят. Лучше указывать
порт, начиная с 10 000. И затем – перезапустить конфигуратор.
4. После перезапуска при первом включении – может появится вот такое окно:


В котором Windows просит открыть доступ для этого приложения на входящие соединения.
Если нажать «Разрешить доступ», то Windows создаст правило для входящих соединений в
брандмауэре. В случае отмены правило не будет создано, и его нужно будет создать
вручную. Если этого не сделать, то при перезапуске конфигуратора появится вот такое окно:
5. Если все настройки выполнены верно, то откроется окно конфигуратора. И теперь можно
делать отладку, в том числе и по сети. Кроме того, отладку можно проверить и через браузер,
для этого достаточно ввести в адресную строку адрес и порт, который мы указали в
настройках. Должно появится вот такое окно:


Особенности работы с отладкой по HTTP

У работы с отладкой в данном режиме есть несколько особенностей, на которые нужно обращать
внимание:
1. Каждый открытый конфигуратор может (и должен в случае отладки в файловой базе)

запускать свой отдельный процесс dbgs на ОТДЕЛЬНЫЙ порт. Т.е. если есть необходимость
открывать 2 конфигуратора для отладки, то у каждого из них нужно прописать свой порт.
Выглядеть это будет так:
2. При настройке отладки можно указать дополнительно имя базы, но оно используется только в
том случае, если вы используете кластер отладки. То же самое касается и пароля для
сервера отладки.
3. В случае мобильного устройства отладку можно включать вручную, ее необходимо прописать
в настройках подключения базы данных, причем неважно, платформа ли это для
разработчиков (слева), или же скомпилированная версия (справа):


В данном случае – сервер обновления конфигурации отличается от сервера отладки, и на

сервере обновлений тоже подключен свой сервер отладки.
4. Однако есть смысл указывать адрес отладки вручную только в скомпилированной версии или
же в случае, если отличается адрес сервера отладки от адреса, указанного в настройках
отладки в конфигураторе. Когда такое может быть? Например, если нужно подключиться
через внешний IP адрес. Однако если работа идет в локальной сети, то нет смысла указывать
адрес сервера отладки, так как он будет браться из файла 1cemarun.xml:
<?xml version="1.0" encoding="UTF-8" ?>
<run modifyTime="20151124182034" debugURL="http://192.168.0.2:45455" />
Для возможности работы с отладкой по сети необходимо, чтобы обязательно стоял флаг
«Перезапуск из конфигуратора» и перезапуск конфигурации был выполнен с сервера
публикации.
5. В случае Android устройств при запуске через ADB также будет подключаться отладка, и если
вы не перевели отладку в конфигураторе в режим HTTP, то при запуске может появляться вот
такая ошибка:


6. Есть возможность отлаживать конфигурации, отличные друг от друга. Например, есть

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


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


Но стоит отметить, что, так как отладка по HTTP использует обычный протокол HTTP, каждый раз,
когда проверяется значение некой переменной, идет запрос на веб-сервер, и, естественно, если вы
хотите получить значение переменной вида ХранилищеЗначений, в котором содержится, например,
большое фото, то 1С начнет передавать это фото на сервер, и так будет каждый раз, когда вы
захотите получить значение этой переменной. Кстати, при отладке 1С сжимает трафик, так что нет
смысла специально помещать данные в хранилище с целью их архивации. Но все же лучше это
делать по другой причине, а именно – данные могут содержать запрещенные символы, поэтому
лучше или помещать их в хранилище, или же передавать в виде Base64.
Подробнее – в видеоуроке Отладка.
Публикация базы данных на веб-сервере

Публикация базы данных на веб-сервере преследует несколько основных целей:
1. Публикация базы для доступа к ней при помощи веб-браузера или тонкого клиента (возможна
работа только при использовании управляемых форм)
2. Публикация HTTP- и WS-сервисов, которые используются для доступа к внешним функциям
публикуемой базы из разных клиентов, например, другой базы 1С или интернет-магазина
3. Публикация протокола OData, который позволяет получить доступ к данным в виде xml
элементов специальной структуры, что дает возможность подключить 1С к программным
комплексам, которые способны понимать этот формат, например, Power Bi
4. В случае использования файловой базы данных – для работы фоновых заданий.
Текущая задача – рассмотреть особенности публикации 1С для доступа через веб и публикацию
HTTP-сервисов.
Весь процесс можно условно разбить на несколько этапов:
1. Настройка веб-серверов для работы с 1С (IIS и Apache)

2. Публикация базы для работы через веб-клиент и тонкий клиент вместе с публикацией веб-
сервисов и их отладкой
3. Настройка защищенного соединения HTTPS для использования большего уровня
безопасности
4. Настройка клиентов для работы со всеми этими механизмами.
Будем публиковать базу, предоставленную в раздаточных файлах, так как в ней уже есть созданные
HTTP-сервисы.


Публикация базы данных на Apache

Начнем с этого веб-сервера, так как все то, что мы сделали ранее, позволяет выполнить публикацию
без дополнительных настроек.
Для того чтобы опубликовать базу, достаточно зайти в настройки публикации (Администрирование
– Публикация базы на веб-сервере):
В нашем случае для публикации базы достаточно прописать имя (не забываем про регистр букв и
используем только латиницу) и указать путь (только латиница, без пробелов и короткий путь), куда
будет в дальнейшем добавлен специальный файл (default.vrd), необходимый веб-серверу, чтобы
знать, где находится база, какие опубликованные веб-сервисы присутствуют и т.д.


Ну и, конечно же, необходимо поставить флаг Публиковать тонкий и веб-клиент.
После указания всех параметров нажимаем Опубликовать, нас спросят, хотим ли мы перезапустить
Apache – соглашаемся. И теперь, если зайти по адресу: http://localhost:8080/DB (не забываем
указывать порт, если он отличен от 80), скорее всего, появится сообщение о том, что ресурс не
найден:
В этом случае необходимо вручную перезапустить Apache еще раз:
После перезапуска веб-клиент должен работать. Но, например, в случае браузера Chrome может
блокироваться часть опций 1С, так как браузер считает их всплывающими окнами и по умолчанию
блокирует их:
Необходимо разрешить всплывающие окна для этого ресурса:


Потом нужно вручную перезагрузить страницу и после этого получится зайти в 1С.
Обратите внимание на путь, который нам отдает 1С: мы указали путь http://localhost:8080/DB, но 1С
сделала редирект (перенаправление) на адрес: http://localhost:8080/DB/en_US, и в этом случае будет
использоваться английский язык, но достаточно изменить путь на: http://localhost:8080/DB/ru_RU – и
все будет на русском. Это актуально, если локаль или язык системы/браузера отличается от того,
которым вы привыкли пользоваться. В данном случае – язык браузера английский (en), а локаль
США (US). Мы же можем прописать ru_RU (регистр букв важен), тогда локаль и язык будут русские, а
можем – ru_UA, тогда язык будет русский, а локаль – украинская.
Сразу отметим, что количество вариантов ограничено, и нельзя ставить язык английский, а локаль
русскую. Кстати, локаль – это форматирование представления данных по умолчанию, посмотреть
примеры можно в конфигураторе – Региональные установки ИБ:


Для подключения по тонкому клиенту достаточно добавить новую информационную базу и указать,
что она находится на веб-сервере:
Если такой опции нет, значит, при установке не был выбран тонкий клиент, просто нужно изменить
установку через панель управления и добавить этот пакет:
Указываем путь в виде URL:
И можем проверять – все должно работать.

Конечно, мы рассмотрели самую поверхностную настройку Apache, на самом деле на
высоконагруженных системах нужно проводить тонкую настройку Apache, но это выходит за рамки
текущего курса.


Публикация базы данных на IIS

С Apache все было очень просто, так как стандартная установка содержит в себе все необходимые
компоненты, а вот в случае IIS их нужно включать отдельно. Ранее, в первом модуле, мы
подключали IIS только в качестве сервера файлов, если так можно выразиться, т.е. мы получали
доступ к определенным файлам через HTTP-протокол, а в случае публикации базы данных – нам
необходимо уже работать с веб-приложениями.
Для начала попробуем опубликовать базу без дополнительных настроек и подробно разберем все
нюансы.
Заходим в настройки публикации и указываем публикацию на IIS (запускаем 1С от имени

администратора):
И при попытке опубликовать базу появится вот такая ошибка:
Из описания ошибки понятно, что у пользователя IUSR нет доступа к каталогу с базой 1С. Значит,
его нужно предоставить.
Ищем папку с базой, нажимаем правой кнопкой Свойства:


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


Нажимаем Дополнительно, и откроется окно выбора пользователей:
Нажимаем Поиск, выбираем нужного пользователя (группу) и нажимаем ОК.


Как видно, мы могли бы просто прописать имя пользователя прямо в этом поле, и если после
нажатия Проверить имена не появилось ничего, значит, имя указано верно, иначе – откроется окно
с заголовком «Имя не найдено».
Теперь наше окно со списком доступных пользователей выглядит вот так:


Добавляем полный доступ и соглашаемся с изменениями. Теперь можно проверить, работает ли

доступ к базе через веб:
Увы, не работает, так как не подключен IsapiModule, а без него ничего не получится, этот модуль
является прослойкой между браузером и базой данных. Подключить модуль ISAPI можно через
Панель управления – Программы и компоненты – Включение компонентов Windows:


После обновления страницы мы уже увидим другую ошибку:
Для ее исправления необходимо зайти в Диспетчер служб IIS, открыть пулы приложений, нажать
правой кнопкой – Дополнительные параметры:
И указать, что в нашем случае разрешены 32-разрядные приложения.
После этого обновляем страницу, и должна появится страница с 1С:


Кстати, обратите внимание на то, что теперь есть возможность работать сразу с нескольких веб-
серверов:
Но этого делать не следует, если есть необходимость установить несколько веб-серверов (обычно
это делается с целью распределения нагрузки), то лучше создавать несколько экземпляров одного
веб-сервера.
Переходим к видеоуроку Публикация базы данных.
Web-сервисы
Достаточно давно в 1С появились WS-сервисы, которые представляют собой работу с SOAP
протоколом, где все данные описываются с помощью определенных правил, которые, в свою
очередь, каждый пользователь может создавать сам (XDTO пакеты), или же пользоваться
стандартными описаниями из пространства имен w3org (примитивные типы), или же v8 – где
описывались типы 1С (структуры, объекты, метаданные и т.д.).


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

которые появлялись при использовании WS-сервисов.
HTTP-сервисы базируются на стандартных HTTP-запросах, таких как POST, GET, PUT и т.д.
В целом разделение на методы условное и носит рекомендательный характер, так как почти все
задачи можно решить при помощи метода POST и GET.
Достаточно подробно про HTTP-запросы можно почитать тут. А в данном методическом пособии мы
коснемся некоторых вопросов – этого будет достаточно, чтобы понять, как создавать свои HTTP-
сервисы.
Структура HTTP-сервисов
В целом почти любой запрос состоит из нескольких основных составляющих:
1. URL, но URL может нести в себе информацию не только про адрес ресурса, но и, например,
дополнительные параметры
2. Заголовок запроса. Если попробовать перевести на язык 1С, то он представляет собой
массив соответствий, в которых описывается служебная информация, например, версия
клиента, тип передаваемых данных, язык, и много другое
3. Тело запроса. В теле запроса уже передается необходимая информация в обе стороны.
Информация может быть разного типа, и тип описывается в заголовках. Ранее мы уже с этим
сталкивались, когда работали с намерениями в Android, например, когда хотели открыть
картинку, мы должны были указать MIME-тип, вот и тут то же самое: чтобы сервер понимал,
что делать с этими данными, он смотрит на заголовок, а не на само тело. В некоторых
вариантах тело может не использоваться.
4. Метод запроса – те самые POST, GET и т.д.
5. Состояние запроса, обычно в виде кода, например, код 200 – говорит о том, что соединение
прошло успешно и был получен ожидаемый ответ от сервера. А вот код 500 – вернет нам в
теле ошибку сервера.
В целом алгоритм работы с HTTP-запросами можно описать достаточно просто. Представим себе,
что нам нужно отправить картинку на сервер и получить в ответ ее некий идентификатор.
Алгоритм будет выглядеть следующим образом:
1. Определяем место, где находится картинка

2. Создаем HTTP-запрос:
a. Формируем URL, на этом этапе нужно понять, будут ли передаваться какие-то
дополнительные параметры запроса


b. Формируем заголовки запроса, тут следует указать, какой тип данных передается,
например, «image/png»
c. Формируем тело запроса, в данном случае – картинку можем передать как двоичные
данные.
3. Отправляем данные на сервер и указываем метод, который позволит это сделать, в нашем
случае это может быть метод POST
4. На сервере:
a. Проверяем, есть ли дополнительные параметры в URL
b. Проверяем, какой тип данных указан в заголовках, обычно в заголовках передается
размер данных в длине символов
c. Проверяем, что находится в теле, если это двоичные данные, то забираем и
обрабатываем, например, помещаем в некую таблицу
5. Готовим ответ для клиента:
a. Если мы успешно получили картинку и добавили ее в таблицу, то теперь в тело
запроса можем вернуть ID картинки, и устанавливаем код состояния = 201, что
соответствует понятию «создано»
b. Если же произошла ошибка, то нужно определить причину, и уточнить, где она
возникла: на клиенте или на сервере. Например, мы на сервере ожидаем тип
«image/png», но клиент отправил тип «image/jpg», а нам это не подходит, в этом случае
мы возвращаем клиенту код состояния = 415. Если мы попытались записать данные на
сервере, но произошла ошибка записи, тогда мы возвращаем код состояния 500.
6. Клиент, получив ответ от сервера, первым делом смотрит на код состояния, и, если он
отличен от 2ХХ, тогда произошла ошибка. Если же все хорошо, то мы получаем в теле
запроса ID картинки и считаем запрос выполненным успешно.
Далее – рассмотрим каждый из этих пунктов.
Строка URL
Строка URL – это URI (о том, что такое URI мы говорили ранее), в котором содержится вся
необходимая информация для однозначной идентификации ресурса. Общий вид URL выглядит так:
<схема>://<логин>:<пароль>@<хост>:<порт>/<URL‐путь>?<параметры>#<якорь>
Примеры:
https://docs.google.com/document/d/1_3UVXw8yaBA/edit#heading=h.xnhq3
http://partners.v8.1c.ru/forum/message/1421?onlyMyThemesInput=true#m_142
Тут стоит сказать только о том, что параметры передавать на сервер можно любые, в том смысле,
что нет четкой привязки к имени параметра и его значению, параметры фильтрует уже сам сервер,
если он какой-то из них не понимает, то может либо выдать ошибку, либо проигнорировать. Т.е. это
не как в случае с 1С, где мы обязаны указывать определенное количество параметров при вызове
функции и не можем указать параметров больше, чем определено в функции, а тут – сколько хотим,
столько и делаем.


А <якорь> обычно используется для того, чтобы отобразить нужный элемент, например, вы можете
дать ссылку не только на форум, но и на конкретный комментарий.
Заголовок
Заголовок – это набор необходимых параметров, например, чтобы сервер знал, какой тип данных вы
ему отправляете, или наоборот – чтобы клиент понимал, например, состояние соединения.
Вот пример запроса на сервер.
1. OPTIONS http://192.168.0.2/
2.
3. --response --
4. 200 OK
5. Date: Thu, 26 Nov 2015 14:56:58 GMT
6. Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/0.9.8r
7. Allow: GET,HEAD,POST,OPTIONS,TRACE
8. Content-Length: 0
9. Keep-Alive: timeout=5, max=99
10. Connection: Keep-Alive
11. Content-Type: text/html
Как видно из статуса (4) – все прошло успешно. В (1) мы делаем запрос OPTIONS, а дальше – ответ
от сервера, в данном случае задача запроса только в одном – описать поддерживаемые типы
запросов, и они описаны в (7). Все строки (5-11) – это заголовки.
Далее – пример POST-запроса, но уже неудачный:
1. POST http://192.168.0.2/tst/hs/DT/SD/PostData
2. Content-Type: application/json
3.
4. -- response --
5. 500 Internal server error
6. Date: Thu, 26 Nov 2015 11:27:49 GMT
7. Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/0.9.8r
8. Content-Length: 78
9. Connection: close
10. Content-Type: text/plain; charset=UTF-8
11.
12. Ошибка инициализации библиотеки модулей
В строке (5), код состояния = 500, что соответствует ошибке со стороны сервера. А вот в (12) –
описывается причина ошибки, кстати (12) – это уже тело запроса. А (2) и (6-10) – это заголовки,
вначале заголовок от клиента, далее – от сервера.
В заголовках передается очень важная информация, как уже ранее было сказано, это и тип данных,
его размер, и различные дополнительные данные, такие как состояние соединения. И если, к
примеру, на некий популярный веб-сервер попробовать отправить запрос с целью разместить там
картинку, то он будет проверять соответствие данных в заголовках тому, что было отправлено в
теле, и, если не совпадет, например, тип данных, будет вызвано исключение.


Тело запроса
Тело запроса – это тоже строка, телом запроса считается все, что идет после заголовка. Тело и
заголовок должны быть разделены минимум одной пустой строкой. Обычно при передаче файлов
применяется подход, который заключается в том, что в заголовках указывают тип – multipart и
дополнительно указывают boundary=HD8WD43. Второй параметр указывает, какие части
используются.
Однако в 1С это все делается автоматически.
Методы запроса
Как было сказано ранее, существуют разные методы работы с веб-сервисами. Рассмотрим те, что
поддерживает 1С, а их достаточно много, намного больше, чем обычно используется на практике.
Основные методы и их краткое описание:
 CONNECT – используется для работы с прокси, которые могут переходить в режим

защищенного соединения. Можно построить тунель между несколькими прокси серверами
 OPTIONS – используется для проверки доступных методов на указанном ресурсе. Методы надо
вернуть в заголовках Allow. Также в теле можно вернуть ожидаемую структуру параметров и
типов данных, с которыми работают методы
 TRACE – используется для отладки. Позволяет получить данные, которые могут быть
добавлены промежуточными серверами, если таковые были
 GET – используется для получения данных из некоторого ресурса, использование данного
метода, подразумевает только запрашивание нужной информации, но не передачу какой-либо
информации, не относящейся к поиску информации на сервере. Например, можно передать
параметры в URL и добавить что-то в заголовки, но вот передавать картинку в теле не
рекомендуется, если, конечно, она не поможет в обработке данных. Найдя запрашиваемые
данные, нужно вернуть их в теле запроса
 HEAD – то же самое, что и GET, за исключением того, что тут не используется тело запроса ни
на прием, ни на передачу. Чаще всего таким образом проверяют валидацию (достоверность,
работоспособность) ссылок или запроса в целом. Например, мы хотим получить картинку, но не
знаем, сколько она будет весить. Делаем запрос HEAD, он нам возвращает то же самое, что и
GET (а GET нам вернет размер тела в заголовках), и, зная размер, можно уже понять, стоит
загружать картинку или нет
 POST – этот метод может все, по сути, это один из самых используемых методов, так как с его
помощью можно и отправить данные, и получить результат. Если мы хотим отправить картинку,
то воспользоваться этим методом, поместив картинку в тело и отправив ее
 PUT – то же самое, что и POST, за исключением того, что POST – это обработка данных, а PUT
– создание, например, если мы отправляем картинки методом POST, то должны на стороне
сервера сделать всю проверку данных на соответствие, например, умеет ли данный сервер
работать с данным типом MIME, не слишком ли большой файл и т.д. А метод PUT
подразумевает, что клиент уже точно знает, какой структуры должен быть пакет данных, и
отправляет его, и сервер, в таком случае, не обязан проверять эти данные.


Почти все описанные выше методы достаточно часто применимы в реальной практике, но кроме
этих методов есть еще и дополнительные методы (WebDAV), которые нацелены на расширение
методов запросов, однако они используются только в определенных случаях, например, при работе
с протоколом OData.
Особенностью данных методов является работа с данными на сервере, они поддерживают описание
коллекций и работу сразу с несколькими объектами. Основная цель этих расширений – работа с
объектами сервера. Если провести аналогию с 1С, то это очень похоже на работу с хранилищем, где
мы блокируем объекты, объединяем, создаем, заменяем и т.д., и это не странно, так как работа с
объектами и их версиями – одно из предназначений этих методов.
Вкратце познакомимся с ними:
 COPY – скопировать ресурс из одного URI в другое

 DELETE – удалить ресурс по URI
 MOVE – перенести ресурс из одного URI в другой
 PATCH – изменить часть данных в ресурсе по URI
 LOCK – заблокировать данные по URI (по типу блокировки в 1С)
 UNLOCK – разблокировать
 MERGE – то же самое, что и PATCH
 MKCOL – создать описание коллекции
 PROPFIND – получить данные/описание коллекции
 PROPPATCH – изменить данные.
Больше про эти методы мы говорить не будем, но посмотрим один из запросов, чтобы понимать, как
вообще это все происходит:
PROPPATCH /sell.html HTTP/1.1

Host: www.1С.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:Товары>
<Z:Номенклатура>Кресло</Z:Номенклатура>
<Z:Номенклатура>Стол</Z:Номенклатура>
</Z:Товары>
</D:prop>
</D:set>
<D:remove>
<D:prop>
<Z:Договор/>
</D:prop>
</D:remove>
</D:propertyupdate>


В данном случае мы пытаемся изменить свойство некоего объекта, например, документ продажи,
где мы удаляем договор и добавляем товар. Т.е. WebDAV – это надстройка над простым HTTP,
который предполагает обмен простыми текстовыми данными и превращает его в обмен
инструкциями.
Код состояния
Все, кто работает с интернетом, должны знать «страшное» число 404. Когда мы ищем важную
информацию, и тут попадается ссылка на ресурс, где точно есть то, что нужно, но при переходе на
него – появляется ошибка 404.
Вот эта цифра – это и есть код состояния запроса. Так как причин ошибок может быть много, но
вариант HTTP всегда предполагает работу в клиент-серверном варианте, то и ошибки можно
разделить на ошибки клиента и ошибки сервера. Но создатели пошли дальше – зачем
ограничиваться только ошибками? Ведь для HTTP нет разницы между тем, была ошибка на сервере
или нет, все равно придет ответ от сервера, или не придет, но соединение ведь было. Поэтому были
введены коды состояний, условно их можно разделить на 5 основных категорий:
1хх – информационные коды, они обычно используются для информирования клиента о неких
процессах на сервере и не выводятся пользователю вообще. Например, код 102 информирует о
том, что сервер получил данные, и теперь ведется их обработка, и она может занять длительное
время, тут же может быть возвращен ID сессии, по которому клиент может сделать повторный
запрос для получения текущего состояния процесса.
2хх – эта серия кодов говорит о том, что операция выполнена успешно, код 200 – сообщает о том,
что все прошло так, как было задумано. Однако если мы, к примеру, должны были создать в 1С
заказ покупателя, то после его добавления на сервере можем вернуть код 201 и вернуть клиенту
ссылку на этот документ.
3хх – информируют клиента о том, что необходимо сделать перенаправление на другой адрес. К
примеру, у нас есть веб-сервер, куда мы делаем запросы для получения картинки по коду, однако
случилось так, что сервер, где хранились фото, был перемещен в другую страну, и у него изменился
IP, но у нас есть множество ссылок у клиентов, которые все также заходят по старым IP, и вот чтобы
они были перенаправлены, мы говорим серверу, что надо сделать редирект на новый адрес.
4хх – ошибки клиента. Например, самая частая ошибка, с которой мы можем встречаться на пути
обучения – это ошибка с кодом 400, которая говорит о том, что произошла ошибка разбора запроса,
вторая по частоте – ошибка 403, которая говорит о том, что у нас нет права доступа к этому ресурсу.
Ну и самая популярная ошибка – 404, она значит, что запрашиваемый ресурс не найден.
5хх – ошибки сервера, причем не только конечного сервера, но и промежуточных. К примеру –

создаем подключение к некоему серверу, но промежуточный сервер не получил от него ничего,
тогда мы можем получить ошибку 504, т.е. мы вначале установили соединение, а потом – у нас
произошел разрыв (поломка на стороне провайдера), в этом случае – доступ к серверу провайдера
есть, а вот он уже не может достучаться.


Итоги
В итоге хочется отметить только одно: все ошибки, запросы, обработку данных и т.д. – необходимо
выполнять самостоятельно, т.е. если картинка неуспешно записалась на сервере, то мы
возвращаем код 5хх, а если успешно, то 2хх. Поэтому заметьте – если делать все по правилам, то
предстоит очень много работы, в отличие от 1С, где мы привыкли все делать через
попытку/исключение, ну и если ошибка, то описывается причина.
HTTP-сервисы в 1С
Выше была рассмотрена теория, причем неважно, на базе чего будет работать сам сервер, это
будет некая CMS, или 1С. Тут важен именно сам подход. Далее – решим задачу, которая
заключается в написании механизма для тестирования HTTP-сервисов, и по ходу его создания будут
разобраны некоторые особенности HTTP-сервисов в 1С. Ограничим задачу тем, что рассмотрим
только два метода – POST, GET и Любой метод.
Общий вид конечного URL будет выглядеть таким образом:
http://[адрес]:[порт]/[имя базы]/hs/[URL http сервиса]/[шаблон]?[параметр1]&[параметр2]
Например:
http://192.168.0.2/DB/hs/DT/SD/12/New?P1=11111&P2=SomeStr
Обратите внимание: вначале идет адрес, потом имя базы, далее идет зарезервированный адрес hs,
именно он ведет нас к HTTP-сервисам, и он обязателен для заполнения. После этого идет корневой
URL, который мы указываем у добавленного HTTP-сервиса, и заканчивается все шаблоном URL,
причем шаблон может быть достаточно длинным, состоять из нескольких секций, разделенных «/».
Ну и в окончании идут параметры. Теперь рассмотрим все подробнее.
Вначале нам необходимо построить структуру HTTP сервиса:
В первую очередь создаем сам сервис DT, после этого – шаблон URL, в нашем случае создаем два
шаблона SomeData и Test, а потом указываем методы, которые они смогут обрабатывать.
При создании сервиса нужно указать следующие данные:


Обратите внимание на корневой URL, именно его мы в дальнейшем будем указывать в браузере,
поэтому сделаем его покороче. Не забываем про Apache, где важен регистр букв.
Для того чтобы можно было обратиться к этому сервису, необходимо указать следующий URL:
http://192.168.0.2/DB/hs/DT
Т.е. на текущий момент был создан путь до DT, но сам по себе HTTP-сервис делать ничего не умеет,
ему обязательно нужно подключить шаблоны и обработчики. Добавляем новый ШаблонURL и
укажем для него следующий шаблон:
Теперь уже сформирована полная строка URL, которая может выглядеть так:
http://192.168.0.2/DB/hs/DT/SD/12
Обратите внимание, так как указан не просто шаблон /SD, то необходимо добавить дополнительно
еще один параметр, в нашем случае это 12. Если он не будет указан, то это будет невалидный URL.
Теперь можно создать обработчики:
Таким образом, если мы делаем POST запрос к ресурсу:
http://192.168.0.2/DB/hs/DT/SD/12


Будет вызвана функция SomeDataPostData. Если же мы делаем GET запрос, тогда будет вызвана
функция SomeDataGetData. А если сделаем, к примеру, PUT запрос, то будет вызвана ошибка от 1С
с кодом состояния 405 Method Not Allowed. Ну и конечно, если допустим ошибку в написании URL,
например, напишем так (в случае Apache):
http://192.168.0.2/DB/hs/DT/Sd/12
Будет вызвана ошибка 404.
Теперь обновим функции и сделаем из них тестовые функции, чтобы более детально рассмотреть
запросы:
Функция SomeDataPostData(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type","text/plain; charset=UTF-8");
Ответ.УстановитьТелоИзСтроки(ВернутьДанныеЗапросаОтКлиента(Запрос));
Возврат Ответ;
КонецФункции
Функция SomeDataGetData(Запрос)
Ответ.УстановитьТелоИзСтроки(ВернутьДанныеЗапросаОтКлиента(Запрос));
Функция ВернутьДанныеЗапросаОтКлиента(Запрос)
СтрОтвет = "";
СтрОтвет = СтрОтвет + "HTTPМетод: " + Запрос.HTTPМетод + Символы.ПС;
СтрОтвет = СтрОтвет + "БазовыйURL: " + Запрос.БазовыйURL + Символы.ПС;
СтрОтвет = СтрОтвет + "ОтносительныйURL: " + Запрос.ОтносительныйURL +
Символы.ПС;
СтрОтвет = СтрОтвет + Символы.ПС;
СтрОтвет = СтрОтвет + "Заголовки: " + Символы.ПС;
Для Каждого Стр Из Запрос.Заголовки Цикл
СтрОтвет = СтрОтвет + " " + Стр.Ключ + ": " + Стр.Значение + Символы.ПС;
КонецЦикла;

СтрОтвет = СтрОтвет + "ПараметрыURL: " + Символы.ПС;
Для Каждого Стр Из Запрос.ПараметрыURL Цикл

СтрОтвет = СтрОтвет + "ПараметрыЗапроса: " + Символы.ПС;
Для Каждого Стр Из Запрос.ПараметрыЗапроса Цикл
Возврат СтрОтвет


Обновим базу и опубликуем HTTP-сервисы. Делается это в той же настройке публикации базы
данных:
После публикации можно в браузере протестировать то, что мы написали, для этого перейдем по
ссылке:
http://192.168.0.2/tst/hs/DT/SD/12?P1=11111&P2=SomeStr
И в браузере, если все прошло хорошо, увидим следующий ответ:
HTTPМетод: GET
БазовыйURL: http://192.168.0.2/DB/hs/DT
ОтносительныйURL: /SD/12
Заголовки:
Content-Length: 0
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Host: 192.168.0.2
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/46.0.2490.86 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate
Cache-Control: max-age=0
Connection: keep-alive
ПараметрыURL:
ID: 12
ПараметрыЗапроса:
P1: 11111
P2: SomeStr


Обратите внимание на следующее:
 Браузер делает GET запрос, а не POST

 ПараметрыURL отличаются от ПараметрыЗапроса только тем, что параметры URL
указываются в основном пути URL и являются обязательными для указания, ну и кроме этого –
имеют фиксированные имена. Например, если у нас стоит задача получать цену по товару, то
артикул мы можем сделать параметром URL, так как этот параметр обязателен для
заполнения, а вот вид цены – можно или вообще не указывать, или указывать именно в
параметрах запроса.
Так как мир не идеален, и могут быть ситуации, когда URL указан неверно, то их тоже надо
предусмотреть. Например, если мы сейчас через браузер укажем путь:
http://192.168.0.2/DB/hs/DT/
То в результате откроется пустая страница, не будет никакой явной ошибки, что URL указан
неверно, хотя, если открыть отладчик браузера, там будет видно:
Но неудобно, во-первых, открывать всегда отладчик, а во-вторых, объяснять это пользователю.

Поэтому можно сделать один интересный шаг – мы добавим ловушки для багов, сделаем это при
помощи еще двух шаблонов, в итоге все будет выглядеть так:
Новый шаблон Test будет выглядеть так:


Обратите внимание, на сам шаблон «/*» – это значит, что сюда будут попадать все запросы, которые
не смогли обработать остальные шаблоны.
А сам метод будет выглядеть одинаково в обоих шаблонах:
В данном случае эта функция будет ловить все методы, которые не обработали другие методы. А
сама функция будет такая:
//Пингуем сервер и ловим все не верные УРЛ

Функция TestConnection(Запрос)
СтрОтвет = ВернутьДанныеЗапросаОтКлиента(Запрос);
СтрОтвет = "Вы указали не верный URL!" + Символы.ПС + СтрОтвет;
Ответ.УстановитьТелоИзСтроки(СтрОтвет);
И протестируем на следующем адресе:
http://192.168.0.2/DB/hs/DT/
Теперь будет получен ответ (заголовки убраны):
Вы указали не верный URL!

HTTPМетод: GET
ОтносительныйURL:
*:
По начальной строке видно, что отработала функция-ловушка. Проверим еще один вариант:
http://192.168.0.2/DB/hs/DT/SD/12/New?qqwe


Получим ответ:
Вы указали не верный URL!

HTTPМетод: GET
ОтносительныйURL: /SD/12/New
*: /SD/12/New
qqwe:
В данном случае мы тоже попали в функцию-ловушку, но уже ту, которая находится в шаблоне SD.
И обратите внимание на параметры URL – был указан URL с ориентиром на то, что задано 2
параметра в шаблоне, но у нас по факту только 1 параметр в шаблоне – {ID}, и если такое
происходит, то 1С не определяет никакой параметр. Вывод отсюда можно сделать такой:
неопределенные параметры URL не игнорируются, т.е. 1С не пытается определить первый
параметр, потом второй и т.д., в случае непопадания в шаблон – игнорируется запрос в целом.
С другой стороны, дополнительные параметры запроса могут быть указаны в любой

последовательности и количестве. Однако лимит длины строки все равно есть, так что передать в
URL сериализованную таблицу значений не выйдет. Ну и, конечно, нужно, чтобы эти параметры
указывались с правильными именами, иначе мы их просто не найдем.
Итоги по HTTP-сервисам
Как видно из материала, работа с HTTP-сервисами достаточно простая, и, по сути, не требует
знания HTML-языка вообще, если только не планируется делать сайт.
Сам HTTP-сервис можно представить в виде некой внешней функции, куда мы передаем параметры
и получаем результат, но, в отличие от WS ссылок, все происходит гораздо быстрее, так как не
нужно проходить валидацию данных, получать вначале описание типов, а потом формировать XDTO
пакеты и т.д. В этом большое преимущество HTTP-сервисов, перед WS-сервисами, но и это же
является их слабостью. Так как вся проверка данных лежит на сервере.
Где и когда можно использовать HTTP-сервисы?
1. Можно сделать веб-страничку с заказами или остатками, чтобы любой торговый агент, даже без
мобильной платформы, мог отслеживать остатки/цены и т.д. То же самое касается ситуаций,
когда в магазинах выключают свет/интернет, и продавцы не могут пробить дисконты, цены,
остатки и т.д., а написав простую страничку, можно им позволить все это делать со своих
мобильных устройств, пока не появится возможность вести полноценную работу
2. Простыми POST-запросами можно получать мгновенно остатки, цены, статусы заказов в
мобильной платформе, или, например, на сайте. Теперь не нужно объяснять веб-
программистам, что такое SOAP (увы, далеко не все с ним сталкивались), а потом еще и
объяснять, что в 1С это не совсем то же самое, что и везде


3. Можно создать сервис RSS-лент и публиковать там любую информацию из 1С в виде

заголовков. Особенность RSS-ленты в том, что это простой XML-файл, который можно
сгенерировать и в 1С, и при этом есть много разных программ под все мобильные (и не только)
устройства, которые позволяют обновлять ленту автоматически.
Однако, стоить понимать, что, хотя 1С и позволяет делать rest-запросы, и мы можем, по сути,
написать много чего, не стоит путать 1С с полноценным веб-сервером, поэтому не нужно забывать
кешировать данные и пускать поменьше пользователей в центральную базу. С другой стороны,
всегда можно сделать вторую базу, куда будет стекаться вся нужная информация, и из нее уже
публиковать все, что нужно, это повысит безопасность и снизит нагрузку на центральную базу,
однако – не стоит применять 1С там, где применять ее не следует.
Далее переходим к видеоуроку «Отладка и тест HTTP-сервисов».
В этом видео рассматривается работа с плагинами к Chrome и FireFox, которые помогают

тестировать HTTP сервисы:
 Advanced REST client (для Chrome)

 HttpRequester (для FireFox)
Видеоурок Отладка и тест HTTP-сервисов.
В видеоуроке «Создание простейшего сайта с поиском и отладка веб-страниц» пойдет речь о том,
как можно создать простейшую страничку, на которой, например, можно будет проверять остатки
товара, цены, дисконты. Особенно актуальна данная тема для розничных сетей: когда выключают
свет/интернет, тогда сотрудники могут получать информацию вот таким образом.
Также будет рассмотрен вопрос важности заголовков, отладки веб-страниц, особенностей IIS и
Apache, при запросе данных внутри самой страницы.
Переходим к видеоуроку Создание простейшего сайта с поиском и

отладка веб-страниц.


Далее смотрим видео «Подпись онлайн». Основная цель этого урока – сформировать понимание
того, как можно быстро переделать некоторые готовые решения для применения в сфере 1С. В
частности, рассмотрим, как можно передавать данные POST-запросом внутри самой страницы, и
применим полученные ранее навыки для решения данной задачи.
Переходим к видеоуроку Подпись онлайн.
Протокол HTTPS
Из предыдущей темы видно, что HTTP-протокол – это просто общение с сервером при помощи
запросов в виде обычного текста. И пока мы говорим о неких безобидных данных, например, о
розничной цене на товар и остатках – все нормально. Но что, если мы хотим передавать данные,
которые являются коммерческой тайной, например, директору на мобильное устройство выгружаем
долги по клиентам и прибыль компании. Вот тут и появляется дополнительный вопрос – а насколько
это безопасно?
И действительно, протокол HTTP вообще не является безопасным, это же просто текстовые данные,
и он вообще никак не устойчив к атакам вида MITM (Man in the middle, или Человек посередине).
Суть данных атак заключается в том, что есть возможность вклиниться в передачу данных между
клиентом и сервером и не только скопировать эти данные, но и изменить их.
С другой стороны, мы можем защитить соединение, используя HTTPS протокол. По свой сути –
HTTPS протокол, это тот же самый HTTP протокол, однако он (в идеале) не подвержен MITM атакам,
за счет того, что данные между сервером и клиентом шифруются. В таком случае, если
злоумышленник перехватит ваш трафик, то он получит просто контейнер зашифрованных данных,
которые он не сможет просто так расшифровать.
Для того чтобы установить такое соединение между клиентом (в нашем случае мобильной
платформой 1С) и сервером, нам необходимо создать сертификаты, с их помощью и будет
устанавливаться безопасное соединение и шифроваться трафик.
Сертификаты клиента и сервера генерируются при помощи сертификатов центра сертификации.

Центр сертификации может быть создан самостоятельно (такие сертификаты считаются
самоподписанными, и их достаточно просто можно подменить), или же сертификат покупается у
специализированных центров сертификации, например: https://ssl.comodo.com/.


При покупке сертификата можно выбирать разные варианты, например, это может быть:
 Самый простой и дешевый сертификат (именно такой и нужен для мобильной платформы), в
браузере он выглядит вот так:
 Либо это может быть сертификат с зеленой строкой, сайты где применяется такой сертификат
выглядят вот так:
 Кроме этого, сертификаты покупаются обычно сразу на домен и субдомен, например, test.com
и www.test.com. Но можно покупать и на дополнительные субдомены.
Простота использования таких сертификатов заключается в том, что все центры сертификации,
которые выдают эти сертификаты, уже прописаны на всех устройствах, и устройства им доверяют
автоматически. Т.е. для установки HTTPS-соединения достаточно купить сертификат и подключить к
веб-серверу, и все будет работать.
Но, у таких сертификатов есть один минус (то что они платные, за минус не считаем). Минус
заключается в том, что они выдаются только на домен. Т.е. если необходимо настроить HTTPS-
соединение, нам необходимо купить сначала некий домен, который надо подтвердить в момент
покупки сертификата.


А что делать, если нужно построить безопасную сеть внутри компании? У нас там доменов нет, есть
IP адрес сервера 192.168.0.2, на него мы не можем получить сертификат, но ничего не стоит точно
также любому сотруднику запустить сниффер и получить данные в момент обновления отчета на
мобильном устройстве директора, и не только данные, но еще и пароль.
В таких случаях можно использовать самоподписанные сертификаты, которые вообще не

рекомендуется использовать при работе через браузер, а вот для обмена данными между
мобильной платформой (например) и сервером они подойдут.
В нашем случае для реализации HTTPS-протокола необходимо создать сертификат центра

сертификации и сертификат сервера, подписанный сертификатом центра.
О том, как это все сделать, смотрим видео «Генерация SSL ключей»
В данном уроке будет рассмотрен вариант генерации сертификатов для сервера и центра
авторизации. Обратите внимание на заполнение полей.
Переходим к видеоуроку Генерация SSL ключей.
О том, как подключить созданные ранее сертификаты – смотрите видео «Настройка HTTPS на IIS» и
«Настройка HTTPS на Apache». Стоит обратить внимание на то, каким образом правильно
подключаться именно по протоколу HTTPS. И как отключить HTTP.
Переходим к видеоурокам Настройка HTTPS на IIS и Настройка HTTPS

на Apache.
В видео «HTTPS и мобильная платформа» рассмотрим подключение сертификатов на мобильные

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


Android:
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found
На iOS:
Ошибка работы с Интернет: Не удалось завершить операцию. (NSURLErrorDomain, ошибка -1012)
На WinPhone:
Ошибка при вызове метода контекста (ОтправитьДляОбработки):

Ошибка работы с Интернет: INTERNET_SEC_INVALID_CERT
Это значит, ошибка в том, что данное устройство не доверяет центру, выдавшему этот сертификат.
Переходим к видеоуроку HTTPS и мобильная платформа.
Практические задания
Задание 5.1 Оперативная информация
Нужно взять любую конфигурацию (неважно, управляемые формы или нет), на платформе 8.3.5 (или
выше) и переписать мини страничку с поиском таким образом, чтобы можно было выполнять поиск
остатков по товару. Товар искать по артикулу, коду, штрих-коду или наименованию.
В таблице выводить список складов и количество остатка на нем. Если найдено более одной
позиции – тоже выводить, если найдено более 10 позиций, тогда выводить сообщение с просьбой
уточнить поиск. Если не было найдено ни одной позиции – аналогично. Если в базе нет товаров, то
можно выводить любую другую информацию (например, долги по клиентам).
В качестве отчета предоставьте скриншоты экрана мобильного устройства, где видно поле ввода с
введенным артикулом товара и выведенным списком остатков (если нет базы с товарами, то можно
с любой информацией).


Задание 5.2 Использование HTTPS

Настроить доступ к решению первой задачи по HTTPS, причем неважно, самоподписанный
сертификат или сертификат, выданный официальным центром.
В качестве отчета предоставьте скриншот с мобильного устройства, на котором видно описание
сертификата безопасности страницы.


1Cv8 Mobile Module05

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

1Cv8 Mobile Module05

Загружено:

Авторское право:

Доступные форматы

Курс дистанционного обучения

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Публикация 1С на веб сервере

1. Публикация конфигурации мобильного приложения (рассмотрено в предыдущих модулях)

1. Поднимается сервер отладки на конкретный адрес и порт на стороне сервера

Для этого 1С имеет специальную утилиту:

C:\Program Files (x86)\1cv8\8.3.7.1759\bin\dbgs.exe

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Обратите внимание – нам не нужен даже модуль расширения веб-сервера.

1. Заходим в Сервис – Параметры:

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Особенности работы с отладкой по HTTP

1. Каждый открытый конфигуратор может (и должен в случае отладки в файловой базе)

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

В данном случае – сервер обновления конфигурации отличается от сервера отладки, и на

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

6. Есть возможность отлаживать конфигурации, отличные друг от друга. Например, есть

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Подробнее – в видеоуроке Отладка.

Публикация базы данных на веб-сервере

Весь процесс можно условно разбить на несколько этапов:

1. Настройка веб-серверов для работы с 1С (IIS и Apache)

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Публикация базы данных на Apache

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Ну и, конечно же, необходимо поставить флаг Публиковать тонкий и веб-клиент.

В этом случае необходимо вручную перезапустить Apache еще раз:

Необходимо разрешить всплывающие окна для этого ресурса:

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Указываем путь в виде URL:

И можем проверять – все должно работать.

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Публикация базы данных на IIS

Заходим в настройки публикации и указываем публикацию на IIS (запускаем 1С от имени

И при попытке опубликовать базу появится вот такая ошибка:

Ищем папку с базой, нажимаем правой кнопкой Свойства:

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Нам нужно добавить сюда еще одного пользователя. Нажимаем Добавить:

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Нажимаем Дополнительно, и откроется окно выбора пользователей:

Нажимаем Поиск, выбираем нужного пользователя (группу) и нажимаем ОК.

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru

Copyright © 2012-2015, Насипов Фарит и Евгений Гилев, ООО «ОдинКурс»

Бесплатные материалы проекта: Электронная почта: support@Kursy-po-1C.ru