Содержание

1С — WEB и HTTP сервисы, отличия и сходства, практика

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

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

С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С  и веб-серверы, и клиент, подключающийся к сервису.

1. Зачем это нужно?

2. WEB и HTTP сервисы: сходства и отличия

3. О форматах данных

4. Про проектирование

5. Про документацию

6. Будь мужиком! Пиши логи!

7. Разделяй код и властвуй над ним

 

Зачем это нужно?

Изначально сервисы разрабатывались для поддержки внешних систем: сайтов, интернет-магазинов, корпоративных порталов. В дальнейшем технология получила широкое распространение и сейчас используется в широком спектре схожих задач:

  • Обмен с внешними системами (сайты, магазины, мобильные приложения),
  • Обмен данными между базами 1С (гетерогенные, РИБ),
  • Работа с внешним оборудованием (телефония, ТСД, весы),
  • Предоставление упрощенного интерфейса для пользователей,
  • Предоставление API для сторонних систем или партнеров.

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

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

Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP.

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

Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис:

Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:

Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее.

 

WEB и HTTP сервисы: сходства и отличия

WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что:

  • Предназначены для доступа к базе данных снаружи,
  • Работают посредством веб-технологий, поверх протокола TCP,
  • Оба поддерживают технологии XML и JSON.

Теперь расскажем о различиях.

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/{id}/attachedInvoices. Эти сущности идентичны, по обоим ресурсам можно получить одни и те же объекты, но именуются они по-разному, для отражения особенностей их получения.  Это еще одна из рекомендаций протокола HTTP.

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

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

 

Про документацию

Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры.

В самом начале мы «забивали» на документацию, а когда  партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть.

Документацию мы рекомендуем вести в таком виде:

  1. Адрес метода, предназначение, описание
  2. Входные и выходные параметры
  3. Описание структур данных в виде таблиц
  4. Описание обработки ошибок
  5. Примеры

Вот пример документации. Заголовок, ответ, пример, описание полей данных:

 

Будь мужиком! Пиши логи!

На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем.

 

Разделяй код и властвуй над ним

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

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

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

Разбор запроса включает в себя чтение и подготовку всех параметров запроса, проверку обязательных параметров и валидацию их корректности.

После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа.

Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром).

 

Подготовка сервиса и веб‑сервера — Модуль маркетплейса Яндекс Маркета для 1С:Предприятия. Справка

Примечание. Раздел относится только к партнерам, подключенным к маркетплейсу Яндекс Маркет по модели FBS или DBS. Подробнее об этих моделях работы см. в Справке Маркета.

Чтобы начать обрабатывать заказы, необходимо подготовить сервис «1С:Предприятия» и веб‑сервер, на который Маркет будет отправлять запросы. Именно при помощи API‑запросов происходит взаимодействие по обработке заказов между Маркетом и «1С:Предприятием».

Рекомендуем, чтобы подготовку сервиса и веб‑сервера проводил администратор «1С:Предприятия».

  1. Шаг 1. Опубликуйте сервис на веб‑сервере
  2. Шаг 2. Создайте пользователя
  3. Шаг 3. Установите сертификат и предоставьте ссылку на сервис

Перед публикацией сервиса:

  • Установите компонент «Модуль расширения веб‑сервера», если его нет в вашей версии «1С:Предприятия». Это можно сделать через повторную установку дистрибутива «1С:Предприятия».

  • Установите и настройте веб‑сервер (Apache или IIS).

Чтобы опубликовать сервис на вашем веб‑сервере:

  1. Запустите «1С:Предприятие» от имени администратора и нажмите кнопку Конфигуратор.

  2. В верхней панели выберите Администрирование → Публикация на веб‑сервере.

  3. В поле Каталог введите путь к папке, в которой будут находится файлы, созданные в результате публикации сервиса.

  4. Отключите опции Публиковать тонкий клиент и веб‑клиент и Публиковать стандартный интерфейс OData, если они вам не потребуются. На работу модуля они не влияют.

  5. На вкладке Web‑сервисы отключите сервисы, которые вам не потребуются.

    На работу модуля это не повлияет.

  6. Перейдите на вкладку HTTP сервисы и включите опции Публиковать HTTP сервисы расширений по умолчанию и Публиковать HTTP сервисы по умолчанию.

  7. Нажмите кнопку Опубликовать.

    1. Если у клиента уже есть публикация, то нужно сделать еще одну для работы под новым пользователем в отдельную папку.

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

  1. В конфигураторе в верхней панели выберите Администрирование → Пользователи.

  2. Введите данные пользователя, который будет использоваться для доступа к сервису.

  3. Перейдите на вкладку Прочие, выберите в списке пункт Полные права и нажмите кнопку OK.

  4. На компьютере перейдите в каталог публикации, который вы указали на предыдущем шаге (см. шаг 1, п. 3), и откройте файл default. vrd.

  5. В строке подключения укажите логин и пароль созданного пользователя.

    • В случае добавления новой публикации, в файле «default.vrd» нужно найти строку: <httpServices publishExtensionsByDefault="true"> и заменить параметр «true» на «false» .

      <service name="Беру_ПолучениеЗаказовПоAPI_1_7_31"
rootUrl="Marketplace_API"
enable="true"
reuseSessions="autouse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>

      При этом в публикации из всех расширений будет доступен только сервис маркетплейса.

    • Для файловой базы:

      Строку "ib="File=&quot;C:\Base\BaseName&quot;;" замените на "ib="File=&quot;C:\Base\BaseName &quot;;Usr=&quot;Логин&quot;;Pwd=&quot;Пароль&quot;;"

      .

    • Для клиент-серверной базы:

      Строку "ib="Srvr=&quot;localhost&quot;;Ref=&quot;BaseName&quot;;" замените на "ib="Srvr=&quot;localhost&quot;;Ref=&quot; BaseName&quot;;Usr=&quot;Логин&quot;;Pwd=&quot;Пароль&quot;;"

  1. Перейдите в раздел «1С:Предприятия» НСИ и администрирование → Настройки пользователей и прав и нажмите ссылку Пользователи.

  2. В открывшемся окне нажмите кнопку Создать, заполните поле Полное имя и установите пароль.

    Остальные поля заполните при необходимости.

  3. Нажмите кнопку Записать.

  4. Перейдите по ссылке Права доступа и на вкладке Группы доступа нажмите кнопку Включить в группу. В появившемся окне выберите группу, которая обладает полными правами:

    • MarketplaceApi — для пользователя, под которым работает HTTP-сервис для работы с заказами;

    • Marketplace User — для остальных пользователей модуля.

    Перейдите на вкладку Разрешенные действия (роли), чтобы проверить наличие полных прав у пользователя.

  5. Нажмите кнопку Записать.

  6. Укажите остальные настройки для пользователя при необходимости.

  7. На компьютере перейдите в каталог публикации, который вы указали на предыдущем шаге (см. шаг 1, п. 3), и откройте файл default.vrd.

  8. В строке подключения укажите логин и пароль созданного пользователя.

    • В случае добавления новой публикации, в файле «default.vrd» нужно найти строку: <httpServices publishExtensionsByDefault="true"> и заменить параметр «true» на «false» .

      <service name="Беру_ПолучениеЗаказовПоAPI_1_7_31"
rootUrl="Marketplace_API"
enable="true"
reuseSessions="autouse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>

      При этом в публикации из всех расширений будет доступен только сервис маркетплейса.

    • Для файловой базы:

      Строку "ib="File=&quot;C:\Base\BaseName&quot;;" замените на "ib="File=&quot;C:\Base\BaseName &quot;;Usr=&quot;Логин&quot;;Pwd=&quot;Пароль&quot;;".

    • Для клиент-серверной базы:

      Строку "ib="Srvr=&quot;localhost&quot;;Ref=&quot;BaseName&quot;;" замените на "ib="Srvr=&quot;localhost&quot;;Ref=&quot; BaseName&quot;;Usr=&quot;Логин&quot;;Pwd=&quot;Пароль&quot;;"

Если вы добавили новую публикацию:

  1. В файле default. vrd найдите строку <httpServices publishExtensionsByDefault="true">.

  2. Параметр "true" смените на "false".

  3. Ниже добавьте блок:

    <service name="Беру_ПолучениеЗаказовПоAPI_1_7_31"

    rootUrl="Marketplace_API"

    enable="true"

    reuseSessions="autouse"

    sessionMaxAge="20"

    poolSize="10"

    poolTimeout="5"/>

При этом в публикации из всех расширений будет доступен только сервис Маркетплейса.

  1. Установите SSL-сертификат.

  2. Перейдите на страницу Настройки → Настройки API в личном кабинете для партнеров Маркета.

  3. Нажмите Изменить у поля URL для запросов API.

  4. В открывшемся окне вставьте ссылку на сервис вида [Cсылка_на_базу]/hs/Marketplace_API, например: https://mysite.

    ru/UT/hs/Marketplace_API.

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

Объект 1С «HTTP-сервисы»

Понятие и назначение HTTP-сервисов в 1С

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

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

Возможность создания собственных произвольных HTTP-сервисов в прикладном решении реализована в дополнение к автоматическому REST интерфейсу прикладного решения.

Подробнее о REST-интерфейсе

REST (Representational state transfer) – это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб.

Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола.

Системы, поддерживающие REST, называются RESTful-системами.

Подробнее на Хабре.

[свернуть]

HTTP-сервисы  позволяют самостоятельно, с помощью встроенного языка, сформировать ответ на HTTP-запрос.

По сравнению с имеющимися в платформе SOAP web-сервисами, HTTP-сервисы имеют ряд преимуществ:

  1. простота программирования клиента таких сервисов;
  2. потенциально меньший объем передаваемых данных;
  3. потенциально меньшая вычислительная нагрузка;
  4. HTTP-сервисы ориентированы на «ресурсы», в то время как SOAP-сервисы ориентированы на «действия».

Первые три фактора особенно важны для приложений, работающих на мобильных устройствах.

Использование HTTP-сервисов в прикладном решении 1С

Вы можете использовать HTTP-сервисы как «легкие» RPC-сервисы, не требующие сложной подготовки XML-пакетов. Методы могут идентифицироваться в URL, а параметры могут передаваться в опциях запроса, или в его теле. В последнем случае такие сервисы уже вплотную приближаются как SOAP, проигрывая ему в четкости спецификации, но выигрывая в гибкости.

RPC-сервис

Удалённый вызов процедур или Вызов удалённых процедур (от англ. Remote Procedure Call, RPC) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах).

Обычно реализация RPC-технологии включает в себя два компонента:

  1. сетевой протокол для обмена в режиме клиент-сервер;
  2. язык сериализации объектов (или структур, для необъектных RPC).

[свернуть]

По своему исполнению HTTP-сервисы очень напоминают Web-сервисы, имеющиеся в платформе.

Объекты «HTTP-сервисы» добавляются в ветке конфигурации «Общие — HTTP-сервисы».

Каждый HTTP-сервис может содержать в себе один или несколько шаблонов URL, и для каждого шаблона можно создать один или несколько методов, выполняющих обработку данных:

Шаблон HTTP-сервиса задаёт путь, по которому может происходить обращение к HTTP-сервису. В шаблоне могут использоваться определённые наборы символов, в том числе параметризованные сегменты вида {какой-то текст}.

Для каждого метода шаблона HTTP-сервиса 1С необходимо:

  1. указать обрабатываемый HTTP-метод;
  2. создать процедуру на встроенном языке, которая будет выполнять обработку данных (свойство «Обработчик»).

В качестве HTTP-метода из раскрывающегося списка «HTTP-метод» можно выбрать один из следующих: GET, POST, PUT, DELETE, PATCH, MERGE, CONNECT, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK (или выбрать «Любой», в этом случае можно использовать любой метод из приведённого списка).

При обращении к HTTP-сервису платформа сначала попытается сопоставить URL, по которому произошло обращение, с одним из имеющихся шаблонов и методов. Если сопоставить не удалось, то платформа выдаст код ответ 404 Not Found. Если подходящий метод будет найден, то платформа начнёт выполнение его обработчика, передав в него все имеющиеся в запросе данные в виде объекта встроенного языка HTTPСервисЗапрос.

С помощью объекта встроенного языка HTTPСервисЗапрос можно получить, например, параметры, содержащиеся в исходном URL, и использовать их для извлечения из базы нужных данных.

Пример

Отсюда

[свернуть]

Полученные с помощью HTTP-запроса данные можно вернуть в разных форматах, (например, преобразовать в XML, как на картинке выше, или просто в текстовую строку с разделителями).

Ответ сервиса формируется специальным объектом встроенного языка HTTPСервисОтвет, в тело которого вы можете поместить подготовленные данные.

Публикация HTTP-сервисов выполняется аналогично тому, как публикуются Web-сервисы 1C. Также аналогичным образом для них работает аутентификация, использование разделения данных и отладка.

Довольно подробная статья для начинающих Как настроить обмен 1С с интернет-сервисами

Простейший пример

Публикация и проверка HTTP-сервиса

Пример создания HTTP-сервисов на платформе «1С:Предприятие»

Практические примеры поискать здесь.

HTTP-сервисы — Orbeon Forms

HTTP-сервисы

Редактор HTTP-сервисов позволяет создавать простые REST-сервисы. Идея состоит в том, что форма может вызывать службу, обычно передавая XML туда и обратно.

Чтобы создать новую службу HTTP, щелкните значок «Добавить» в разделе «Службы HTTP». Откроется Редактор службы HTTP.

На следующем снимке экрана показан пример заполненной услуги:

Вкладка «Определение»

Основные настройки

Вкладка «Определение» позволяет установить основные параметры услуги:

  • Имя службы

      Это имя службы, которое видит Form Builder. Должен начинаться с буквы и не может содержать пробелов.

    • [С Orbeon Forms 2020.1] Службу можно переименовать, а действия, использующие эту службу, автоматически обновляются.

  • URL-адрес ресурса

    • HTTP или HTTPS URL-адрес, по которому должна быть вызвана служба.

    • Значение представляет собой шаблон значения XPath, что означает, что URL-адрес может быть динамическим. Например, в Orbeon Forms 2018.1 функция fr:control-string-value() :

      https://example. org/{fr:control-string-value(‘control-1’)}

  • Метод

    • Используемый метод HTTP: GET , POST , PUT или DELETE 90.

  • Тело запроса

    • Это относится к методам POST и PUT .

    • XML-документ для отправки в службу. При использовании сериализации "HTML Form" это преобразуется в пары имя/значение.

Сериализации

Основы

Сериализации применяются только к методам POST и PUT .

XML-сериализация

При сериализации "XML" данные XML передаются с использованием внешнего формата данных.

В сети эта сериализация использует тип содержимого application/xml .

Сериализация HTML-формы

При сериализации «HTML-форма» конечные элементы XML в теле запроса XML преобразуются в пары имя/значение.

В сети эта сериализация использует кодировку application/x-www-form-urlencoded , как и для стандартных веб-форм.

Параметры URL

[С Orbeon Forms 2016.1]

  • Это относится к методам GET и DELETE .

  • Вы можете добавить столько параметров URL, сколько необходимо.

  • Непустой параметр URL указывает значение по умолчанию для параметра.

  • Действие может установить значение параметра.

Вот как установить параметры URL из действия.

Поддержка JSON

[ПОСЛЕ Orbeon Forms 2016.1]

Ответ JSON от службы обрабатывается и преобразуется в XML-документ по схеме XForms 2.0 (см. Поддержка JSON).

Подробнее об отправке JSON в службы см. #2480.

Параметры URL до Orbeon Forms 2016.1

До Orbeon Forms 2016.1 «тело запроса» является обязательным для методов GET и DELETE . Тело не отправляется службе, а используется для настройки параметров запроса.

Содержимое формы «Тело запроса» должно быть правильно сформированным XML-документом. Имя корневого элемента не имеет значения, но обычно используется params или request . Каждый дочерний элемент определяет параметр, как показано в следующем примере:

1

test

URL-адрес:

lt;URL-адрес ресурса>?userId=1&userName=test

, где lt;URL-адрес ресурса> — это содержимое поля ввода «URL-адрес ресурса».

Обязательно выберите HTML-форму в раскрывающемся списке Сериализация , иначе параметры URL-адреса не будут добавлены к URL-адресу запроса.

Вкладка «Дополнительно» позволяет установить дополнительные параметры службы:

  • Ответ службы имеет двоичное содержимое

    • [С ПОСЛЕ Orbeon Forms 2020.1]

      92027 013 Установите этот флажок, если вы знаете, что служба возвращает двоичное содержимое, например изображение. Это необходимо, если действие использует ответ.

  • HTTP-аутентификация

    • Использовать ли HTTP-аутентификацию.

    • Имя пользователя: Имя пользователя для использования.

    • Пароль: Пароль для использования.

  • SOAP Service

    • Будь то SEAP Service

  • Действие SOAP

    • IF SELECTED, значение SOALCACTACTACTACTACTACTACTACTACE 444444.

Вкладка «Дополнительно»

Основы

Кнопка «Тест» позволяет протестировать сервис. Прежде чем сделать это, вы должны установить данные в теле запроса для запроса POST или PUT , или вы можете установить параметры URL для ПОЛУЧИТЬ или УДАЛИТЬ . Form Builder выполняет службу, а затем предоставляет информацию о возвращенном ответе, в том числе:

  • Произошла ли ошибка (выделено зеленым или красным цветом)

  • URL-адрес с названием

  • Код состояния ответа

    • 5 Заголовки ответов

  • Тело ответа

Это поможет вам устранить неполадки при вызове службы поддержки.

Вкладка «Результаты теста» с заголовками ответов

Вкладка «Результаты теста» с текстом ответа

XML-представление ответов JSON

[ПОСЛЕ Orbeon Forms 2019.1]

.

Это полезно, когда вы хотите использовать выражения XPath для доступа к ответу JSON, например, с наборами данных или выбором элементов.

См. также поддержку JSON.

Вкладка «Результаты теста» с телом ответа XML

После того, как ваш сервис определен, кнопки «Сохранить» сохраняют его в форме. Вы можете вернуться к нему и изменить его позже, нажав на значок «Редактировать» рядом с названием сервиса. Вы также можете удалить сервис с помощью значка корзины.

Вы можете удалить сохраненную услугу с помощью кнопки «Удалить».

[С Orbeon Forms 2020.1]

Orbeon Forms предупредит вас о существующих действиях, относящихся к службе.

  • ​Действия​

  • ​Database services​

  • ​Synchronizing repeated content​

  • ​Datasets​

  • ​JSON support​

Previous

Services and actions

Database services

Last modified 2mo ago

Скопировать ссылку

На этой странице

Введение

Определение службы

Основные настройки

Сериализации

Параметры URL

json support

параметры URL перед Forms Forms 2016. 1

Усовершенствованные параметры

Тестирование A Service

Основы

View of JSON Ответы

Сохранение сервиса

Удаление сервиса

См. Также

. Траефик

Настройка доступа к службам

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

Примеры конфигурации

Объявление службы HTTP с двумя серверами — использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - URL: "http://<частный-ip-сервер-1>:<частный-порт-сервер-1>/"
        - url: "http://:/"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.my-service.loadBalancer]
    [[http.services.my-service.loadBalancer.servers]]
      url = "http://<частный-ip-сервер-1>:<частный-порт-сервер-1>/"
    [[http. services.my-service.loadBalancer.servers]]
      url = "http://<частный-ip-сервер-2>:<частный-порт-сервер-2>/"
Объявление службы TCP с двумя серверами — с помощью поставщика файлов

YAML

 tcp:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - адрес: "<приватный-ip-сервер-1>:<приватный-порт-сервер-1>"
        - address: ":"

TOML

 ## Динамическая конфигурация
[tcp.services]
  [tcp.services.my-service.loadBalancer]
     [[tcp.services.my-service.loadBalancer.servers]]
       address = "<частный-ip-сервер-1>:<частный-порт-сервер-1>"
     [[tcp.services.my-service.loadBalancer.servers]]
       address = "<частный-ip-сервер-2>:<частный-порт-сервер-2>"
Объявление службы UDP с двумя серверами — с помощью поставщика файлов

YAML

 udp:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - адрес: "<приватный-ip-сервер-1>:<приватный-порт-сервер-1>"
        - address: ":"

TOML

 ## Динамическая конфигурация
[udp. services]
  [udp.services.my-service.loadBalancer]
     [[udp.services.my-service.loadBalancer.servers]]
       address = "<частный-ip-сервер-1>:<частный-порт-сервер-1>"
     [[udp.services.my-service.loadBalancer.servers]]
       address = "<частный-ip-сервер-2>:<частный-порт-сервер-2>"

Настройка служб HTTP

Балансировщик нагрузки серверов

Балансировщики нагрузки могут балансировать нагрузку запросов между несколькими экземплярами ваших программ.

У каждой службы есть балансировщик нагрузки, даже если есть только один сервер, на который перенаправляется трафик.

Объявление службы с двумя серверами (с балансировкой нагрузки) — использование поставщика файлов

YAML

 http:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.my-service.loadBalancer]
    [[http.services.my-service.loadBalancer.servers]]
      URL-адрес = "http://частный-ip-сервер-1/"
    [[http.services.my-service.loadBalancer.servers]]
      URL-адрес = "http://частный-ip-сервер-2/"
серверов

Серверы объявляют один экземпляр вашей программы. Параметр url указывает на конкретный экземпляр.

Пути в url серверов не действуют. Если вы хотите, чтобы запросы отправлялись по определенному пути на ваших серверах, настроить свой маршрутизаторы для использования соответствующего промежуточного программного обеспечения (например, AddPrefix или ReplacePath).

Служба с одним сервером — использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
          - URL: "http://private-ip-server-1/"

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.my-service.loadBalancer]
    [[http.services.my-service.loadBalancer.servers]]
      url = "http://private-ip-server-1/"
Балансировка нагрузки

На данный момент поддерживается только циклическая балансировка нагрузки:

Балансировка нагрузки — использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.my-service.loadBalancer]
    [[http.services.my-service.loadBalancer.servers]]
      URL-адрес = "http://частный-ip-сервер-1/"
    [[http.services.my-service.loadBalancer.servers]]
      url = "http://private-ip-server-2/"
Закрепленные сессии

Когда закрепленные сеансы включены, в начальном ответе устанавливается заголовок Set-Cookie , чтобы сообщить клиенту, какой сервер обрабатывает первый ответ. При последующих запросах, чтобы сохранить сеанс с тем же сервером, клиент должен отправить файл cookie с установленным значением.

Добавление прилипания — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    моя служба:
      loadBalancer:
        липкий:
         куки: {}

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.my-service]
    [http.services.my-service.loadBalancer.sticky.cookie]
Добавление прилипания с помощью настраиваемых параметров — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    моя служба:
      loadBalancer:
        липкий:
          куки:
            имя: my_sticky_cookie_name
            безопасный: правда
            httpOnly: true

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.my-service]
    [http.services.my-service.loadBalancer.sticky.cookie]
      имя = "my_sticky_cookie_name"
      безопасный = истинный
      httpOnly = Истина
      тот же сайт = "нет"
Настройка прилипания на всех требуемых уровнях — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    врр1:
      взвешенный:
        липкий:
          куки:
            имя: lvl1
        Сервисы:
          - имя: whoami1
            вес: 1
          - имя: whoami2
            вес: 1
    кто1:
      loadBalancer:
        липкий:
          куки:
            имя: lvl2
        серверы:
          - адрес: http://127.0.0.1:8081
          - адрес: http://127.0.0.1:8082
    кто2:
      loadBalancer:
        липкий:
          куки:
            имя: lvl2
        серверы:
          - адрес: http://127.0.0.1:8083
          - адрес: http://127.0.0.1:8084

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.wrr1]
    [http.services.wrr1.weighted.sticky.cookie]
      имя = "lvl1"
    [[http.services.wrr1.weighted.services]]
      имя = "ктоами1"
      вес = 1
    [[http.services.wrr1.weighted.services]]
      имя = "ктоами2"
      вес = 1
  [http.services.whoami1]
    [http.services.whoami1.loadBalancer]
      [http.services.whoami1.loadBalancer.sticky.cookie]
        имя = "lvl2"
      [[http.services.whoami1.loadBalancer.servers]]
        URL-адрес = "http://127.0.0.1:8081"
      [[http.services.whoami1.loadBalancer.servers]]
        URL-адрес = "http://127.0.0.1:8082"
  [http.services.whoami2]
    [http.services.whoami2.loadBalancer]
      [http.services.whoami2.loadBalancer.sticky.cookie]
        имя = "lvl2"
      [[http.services.whoami2.loadBalancer.servers]]
        URL-адрес = "http://127.0.0.1:8083"
      [[http.services.whoami2.loadBalancer.servers]]
        URL-адрес = "http://127.0.0.1:8084"

Чтобы сеанс с одним и тем же сервером оставался открытым, клиенту потребуется указать два уровня в файле cookie для каждого запроса, например. с завитком:

 curl -b "lvl1=whoami1; lvl2=http://127.0.0.1:8081" http://localhost:8000
Проверка здоровья

Настройте проверку работоспособности, чтобы исключить неработоспособные серверы из ротации балансировки нагрузки. Traefik будет считать ваши серверы работоспособными, если они возвращают коды состояния между 2XX и 3XX на запросы проверки работоспособности (выполняется каждые интервал ).

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

Ниже приведены доступные параметры механизма проверки работоспособности:

  • путь (обязательно), определяет путь URL-адреса сервера для конечной точки проверки работоспособности.
  • схема (необязательно) заменяет URL-адрес сервера схемы для конечной точки проверки работоспособности.
  • hostname (необязательно), задает значение hostname в заголовке Host запроса проверки работоспособности.
  • , порт (необязательно), заменяет URL-адрес сервера , порт для конечной точки проверки работоспособности.
  • interval (по умолчанию: 30 с), определяет частоту вызовов проверки работоспособности.
  • timeout (по умолчанию: 5 с), определяет максимальную продолжительность, в течение которой Traefik будет ожидать запроса на проверку работоспособности, прежде чем считать сервер неработоспособным.
  • заголовки (необязательно) определяет настраиваемые заголовки для отправки на конечную точку проверки работоспособности.
  • followRedirects (по умолчанию: true), определяет, следует ли выполнять перенаправления во время вызовов проверки работоспособности.
  • метод (по умолчанию: GET) определяет метод HTTP, который будет использоваться при подключении к конечной точке.

Проверка работоспособности с помощью Kubernetes

В Kubernetes есть механизм проверки работоспособности для удаления неработоспособных модулей из сервисов Kubernetes (см. проверку готовности). Поскольку у неработоспособных модулей нет конечных точек Kubernetes, Traefik не будет перенаправлять на них трафик. Поэтому проверка работоспособности Traefik недоступна для kubernetesCRD и kubernetesIngress поставщиков.

Пользовательский интервал и тайм-аут — использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис-1:
      loadBalancer:
        проверка здоровья:
          путь: /здоровье
          интервал: "10 с"
          тайм-аут: "3s"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.Service-1]
    [http.services.Service-1.loadBalancer.healthCheck]
      путь = "/здоровье"
      интервал = "10 с"
      таймаут = "3с"
Пользовательский порт — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис-1:
      loadBalancer:
        проверка здоровья:
          путь: /здоровье
          порт: 8080

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.Service-1]
    [http.services.Service-1.loadBalancer.healthCheck]
      путь = "/здоровье"
      порт = 8080
Пользовательская схема — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис-1:
      loadBalancer:
        проверка здоровья:
          путь: /здоровье
          схема: http

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.Service-1]
    [http.services.Service-1.loadBalancer.healthCheck]
      путь = "/здоровье"
      схема = "http"
Дополнительные заголовки HTTP — использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис-1:
      loadBalancer:
        проверка здоровья:
          путь: /здоровье
          заголовки:
            Мой пользовательский заголовок: foo
            Мой-Заголовок: бар

ТОМЛ

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.Service-1]
    [http.services.Service-1.loadBalancer.healthCheck]
      путь = "/здоровье"
      [http.services.Service-1.loadBalancer.healthCheck.headers]
        Мой-Custom-Header = "foo"
        Мой-Заголовок = "бар"

passHostHeader позволяет пересылать заголовок хоста клиента на сервер.

По умолчанию passHostHeader имеет значение true.

Не пересылать заголовок хоста — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис01:
      loadBalancer:
        passHostHeader: false

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.Service01]
    [http.services.Service01.loadBalancer]
      passHostHeader = ложь
СерверыТранспорт

serverTransport позволяет ссылаться на конфигурацию ServersTransport для связи между Traefik и вашими серверами.

Укажите транспорт — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис01:
      loadBalancer:
        serverTransport: mytransport

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.Service01]
    [http.services.Service01.loadBalancer]
      серверыТранспорт = "мой транспорт"
Переадресация ответа

Этот раздел посвящен настройке того, как Traefik пересылает ответ от внутреннего сервера клиенту.

Ниже приведены доступные параметры механизма переадресации ответов:

  • FlushInterval указывает интервал между сбросами на клиент при копировании тела ответа. Это продолжительность в миллисекундах, по умолчанию равна 100. Отрицательное значение означает сброс сразу после каждой записи клиенту. FlushInterval игнорируется, когда ReverseProxy распознает ответ как потоковый; для таких ответов записи немедленно сбрасываются клиенту.
Использование пользовательского FlushInterval — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    Сервис-1:
      loadBalancer:
        ответная переадресация:
          flushInterval: 1 с

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.Service-1]
    [http.services.Service-1.loadBalancer.responseForwarding]
      флешинтервал = "1с"

СерверыТранспорт

ServersTransport позволяет настроить транспорт между Traefik и вашими серверами.

ИмяСервера

Дополнительно

serverName настроить имя сервера, которое будет использоваться для SNI.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      serverName: "myhost"

Файл (TOML)

 ## Динамическая конфигурация
[http. serversTransports.mytransport]
  serverName = "myhost"

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    имя_сервера: "тест"
Сертификаты

Дополнительно

сертификаты — это список сертификатов (в виде путей к файлам или байтов данных) которые будут установлены в качестве клиентских сертификатов для mTLS.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      сертификаты:
        - файл сертификата: foo.crt
          keyFile: bar.crt

Файл (TOML)

 ## Динамическая конфигурация
[[http.serversTransports.mytransport.certificates]]
  certFile = "foo.crt"
  ключевой файл = "bar.crt"

Kubernetes

 apiVersion: traefik. containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    сертификатыСекреты:
    - мой сертификат
---
апиВерсия: v1
вид: Секрет
метаданные:
  имя: mycert
  данные:
    tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
    tls.key: LS0tLS1CRUdJTiBQUklWQVRFIETFWS0tLS0tCi0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0=
insecureSkipVerify

Дополнительно

insecureSkipVerify определяет, проверяется ли цепочка сертификатов сервера и имя хоста.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      insecureSkipVerify: true

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport]
  insecureSkipVerify = true

Kubernetes

 apiVersion: traefik. containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    insecureSkipVerify: правда
корневые ЦС

Дополнительно

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

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      корневые ЦС:
        - foo.crt
        - bar.crt

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport]
  rootCAs = ["foo.crt", "bar.crt"]

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    секреты rootCAs:
    - мика
---
апиВерсия: v1
вид: Секрет
метаданные:
  имя: Мика
  данные:
    ca. crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
максидлеконнсперхост

Дополнительно, по умолчанию = 2

Если не ноль, maxIdleConnsPerHost управляет максимальным количеством незанятых (поддерживающих активность) подключений для каждого хоста.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      maxIdleConnsPerHost: 7

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport]
  maxIdleConnsPerHost = 7

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    максидлеконнсперхост: 7
отключитьHTTP2

Необязательный, по умолчанию = false

disableHTTP2 отключает HTTP/2 для соединений с серверами.

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport]
  disableHTTP2 = true

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      disableHTTP2: true

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    отключитьHTTP2: правда
одноранговый CertURI

Необязательно, по умолчанию = false

peerCertURI определяет URI, используемый для сопоставления с URI SAN во время проверки сертификата сервера.

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport]
  peerCertURI = "foobar"

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      peerCertURI: foobar

Kubernetes

 версия API: traefik. containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    peerCertURI: foobar
таймауты переадресации

forwardingTimeouts — тайм-ауты, применяемые при пересылке запросов на серверы.

forwardingTimeouts.dialTimeout

Дополнительно, по умолчанию = 30 с

dialTimeout — максимальная продолжительность, разрешенная для установления соединения с внутренним сервером. Ноль означает отсутствие тайм-аута.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      таймауты переадресации:
        dialTimeout: "1s"

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport.forwardingTimeouts]
  dialTimeout = "1s"

Kubernetes

 apiVersion: traefik. containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    таймауты переадресации:
      dialTimeout: "1s"

Дополнительно, по умолчанию = 0 с

responseHeaderTimeout , если не равен нулю, указывает время ожидания заголовков ответа сервера. после полного написания запроса (включая его тело, если оно есть). Это время не включает время на чтение тела ответа. Ноль означает отсутствие тайм-аута.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      таймауты переадресации:
        responseHeaderTimeout: «1 с»

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport.forwardingTimeouts]
  responseHeaderTimeout = "1s"

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    таймауты переадресации:
      responseHeaderTimeout: «1 с»
forwardingTimeouts. idleConnTimeout

Дополнительно, по умолчанию = 90 с

простояКоннТимеаут — это максимальное количество времени, в течение которого бездействующее (поддерживающее) соединение будет оставаться бездействующим, прежде чем само закроется. Ноль означает отсутствие ограничений.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      таймауты переадресации:
        idleConnTimeout: "1s"

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport.forwardingTimeouts]
  idleConnTimeout = "1s"

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    таймауты переадресации:
      idleConnTimeout: «1 с»
forwardingTimeouts. readIdleTimeout

Дополнительно, по умолчанию = 0 с

readIdleTimeout — тайм-аут, по истечении которого будет выполняться проверка работоспособности с помощью ping-фрейма если при соединении HTTP/2 не получен кадр. Обратите внимание, что ответ на пинг будет считаться полученным кадром, поэтому, если на соединении нет другого трафика, проверка работоспособности будет выполняться каждые интервала readIdleTimeout . Если ноль, проверка работоспособности не выполняется.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      таймауты переадресации:
        readIdleTimeout: "1s"

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport.forwardingTimeouts]
  readIdleTimeout = "1s"

Kubernetes

 apiVersion: traefik.containo. us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    таймауты переадресации:
      readIdleTimeout: «1 с»
forwardingTimeouts.pingTimeout

Дополнительно, по умолчанию = 15 с

pingTimeout — время ожидания, по истечении которого соединение HTTP/2 будет закрыто. если ответ на пинг не получен.

Файл (YAML)

 ## Динамическая конфигурация
http:
  серверыТранспорт:
    мой транспорт:
      таймауты переадресации:
        pingTimeout: "1s"

Файл (TOML)

 ## Динамическая конфигурация
[http.serversTransports.mytransport.forwardingTimeouts]
  pingTimeout = "1 с"

Kubernetes

 apiVersion: traefik.containo.us/v1alpha1
вид: СерверыТранспорт
метаданные:
  Название: мой транспорт
  пространство имен: по умолчанию
спецификация:
    таймауты переадресации:
      pingTimeout: «1 с»

Круговая система взвешивания (услуга)

WRR может балансировать нагрузку запросов между несколькими службами на основе весов.

Эта стратегия доступна только для балансировки нагрузки между службами, но не между серверами.

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    приложение:
      взвешенный:
        Сервисы:
        - имя: appv1
          вес: 3
        - имя: appv2
          вес: 1
    приложениеv1:
      loadBalancer:
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    приложениеv2:
      loadBalancer:
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.сервисы.приложение]
    [[http.services.app.weighted.services]]
      имя = "приложение1"
      вес = 3
    [[http.services.app.weighted.services]]
      имя = "приложение2"
      вес = 1
  [http.services.appv1]
    [http.services.appv1.loadBalancer]
      [[http.services.appv1.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http. services.appv2]
    [http.services.appv2.loadBalancer]
      [[http.services.appv2.loadBalancer.servers]]
        url = "http://private-ip-server-2/"
Проверка здоровья

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

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    приложение:
      взвешенный:
        проверка здоровья: {}
        Сервисы:
        - имя: appv1
          вес: 3
        - имя: appv2
          вес: 1
    приложениеv1:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    приложениеv2:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.сервисы.приложение]
    [http.services.app.weighted.healthCheck]
    [[http.services.app.weighted.services]]
      имя = "приложение1"
      вес = 3
    [[http.services.app.weighted.services]]
      имя = "приложение2"
      вес = 1
  [http.services.appv1]
    [http.services.appv1.loadBalancer]
      [http.services.appv1.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.appv1.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http.services.appv2]
    [http.services.appv2.loadBalancer]
      [http.services.appv2.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.appv2.loadBalancer.servers]]
        url = "http://private-ip-server-2/"

Зеркалирование (услуга)

Зеркальное отображение может отражать запросы, отправленные в службу, другим службам. Обратите внимание, что по умолчанию весь запрос буферизуется в памяти во время зеркалирования. См. параметр maxBodySize в приведенном ниже примере, чтобы узнать, как изменить это поведение.

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    зеркальный API:
      зеркальное отображение:
        служба: appv1
        # maxBodySize — максимально допустимый размер тела запроса.
        # Если тело больше, запрос не зеркалируется.
        # Значение по умолчанию -1, что означает неограниченный размер.
        максбодисизе: 1024
        зеркала:
        - имя: appv2
          процент: 10
    приложениеv1:
      loadBalancer:
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    приложениеv2:
      loadBalancer:
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.services.mirrored-api]
    [http.services.mirrored-api.mirroring]
      сервис = "приложение1"
      # maxBodySize — это максимальный размер тела запроса в байтах. 
      # Если тело больше, запрос не зеркалируется.
      # Значение по умолчанию -1, что означает неограниченный размер.
      МаксБодиСизе = 1024
    [[http.services.mirrored-api.mirroring.mirrors]]
      имя = "приложение2"
      процент = 10
  [http.services.appv1]
    [http.services.appv1.loadBalancer]
      [[http.services.appv1.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http.services.appv2]
    [http.services.appv2.loadBalancer]
      [[http.services.appv2.loadBalancer.servers]]
        url = "http://private-ip-server-2/"
Проверка здоровья

HealthCheck включает автоматическую самопроверку работоспособности для этой службы, т. е. если главный обработчик службы становится недоступным, информация распространяется вверх к своему родителю.

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    зеркальный API:
      зеркальное отображение:
        проверка здоровья: {}
        служба: appv1
        зеркала:
        - имя: appv2
          процент: 10
    приложениеv1:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    приложениеv2:
      loadBalancer:
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.services.mirrored-api]
    [http.services.mirrored-api.mirroring]
      [http.services.mirrored-api.mirroring.healthCheck]
      сервис = "приложение1"
    [[http.services.mirrored-api.mirroring.mirrors]]
      имя = "приложение2"
      процент = 10
  [http.services.appv1]
    [http.services.appv1.loadBalancer]
      [http.services.appv1.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.appv1.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http.services.appv2]
    [http.services.appv2.loadBalancer]
      [http.services.appv1.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.appv2.loadBalancer.servers]]
        url = "http://private-ip-server-2/"

Аварийное переключение (служба)

Задание службы отработки отказа должно пересылать все запросы резервной службе, когда основная служба становится недоступной.

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    приложение:
      отказоустойчивость:
        сервис: основной
        запасной вариант: резервная копия
    главный:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    резервное копирование:
      loadBalancer:
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http.сервисы]
  [http.сервисы.приложение]
    [http.services.app.failover]
      сервис = "основной"
      резерв = "резервная копия"
  [http.services.main]
    [http.services.main.loadBalancer]
      [http.services.main.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.main.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http. services.backup]
    [http.services.backup.loadBalancer]
      [[http.services.backup.loadBalancer.servers]]
        url = "http://private-ip-server-2/"
Проверка здоровья

HealthCheck включает автоматическую самопроверку работоспособности для этой службы, т. е. если основной и резервный сервисы становятся недоступными, информация распространяется вверх к своему родителю.

YAML

 ## Динамическая конфигурация
http:
  Сервисы:
    приложение:
      отказоустойчивость:
        проверка здоровья: {}
        сервис: основной
        запасной вариант: резервная копия
    главный:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL-адрес: "http://private-ip-server-1/"
    резервное копирование:
      loadBalancer:
        проверка здоровья:
          путь: /статус
          интервал: 10 с
          тайм-аут: 3 с
        серверы:
        - URL: "http://private-ip-server-2/"

TOML

 ## Динамическая конфигурация
[http. сервисы]
  [http.сервисы.приложение]
    [http.services.app.failover.healthCheck]
    [http.services.app.failover]
      сервис = "основной"
      резерв = "резервная копия"
  [http.services.main]
    [http.services.main.loadBalancer]
      [http.services.main.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.main.loadBalancer.servers]]
        URL-адрес = "http://частный-ip-сервер-1/"
  [http.services.backup]
    [http.services.backup.loadBalancer]
      [http.services.backup.loadBalancer.healthCheck]
        путь = "/здоровье"
        интервал = "10 с"
        время ожидания = "3 с"
      [[http.services.backup.loadBalancer.servers]]
        url = "http://private-ip-server-2/"

Настройка служб TCP

Общий

Каждое из полей служебной секции представляет вид службы. Это означает, что для каждой указанной службы одно из полей, и только одно, должен быть включен, чтобы определить, какой сервис создается. В настоящее время доступны два типа: LoadBalancer и Weighted .

Балансировщик нагрузки серверов

Балансировщик нагрузки серверов отвечает за балансировку запросов между серверами одной и той же службы.

Объявление службы с двумя серверами — использование поставщика файлов

YAML

 ## Динамическая конфигурация
TCP:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - адрес: "хх.хх.хх.хх:хх"
        - адрес: "xx.xx.xx.xx:xx"

TOML

 ## Динамическая конфигурация
[tcp.services]
  [tcp.services.my-service.loadBalancer]
    [[tcp.services.my-service.loadBalancer.servers]]
      адрес = "хх.хх.хх.хх:хх"
    [[tcp.services.my-service.loadBalancer.servers]]
       адрес = "хх.хх.хх.хх:хх"
серверов

Серверы объявляют один экземпляр вашей программы. Параметр адреса (IP:Port) указывает на конкретный экземпляр.

Служба с одним сервером — использование поставщика файлов

YAML

 ## Динамическая конфигурация
TCP:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
          - адрес: "xx.xx.xx.xx:xx"

TOML

 ## Динамическая конфигурация
[tcp.services]
  [tcp.services.my-service.loadBalancer]
    [[tcp.services.my-service.loadBalancer.servers]]
      адрес = "хх.хх.хх.хх:хх"
ПРОКСИ-протокол

Traefik поддерживает протокол PROXY версий 1 и 2 для служб TCP. Его можно включить, установив proxyProtocol в балансировщике нагрузки.

Ниже приведены доступные параметры протокола PROXY:

  • версия указывает версию используемого протокола. Либо 1 , либо 2 .
Служба с прокси-протоколом v1 — с использованием поставщика файлов

YAML

 ## Динамическая конфигурация
TCP:
  Сервисы:
    моя служба:
      loadBalancer:
        прокси-протокол:
          версия: 1

TOML

 ## Динамическая конфигурация
[tcp. services]
  [tcp.services.my-service.loadBalancer]
    [tcp.services.my-service.loadBalancer.proxyProtocol]
      версия = 1
Задержка завершения

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

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

С этой целью, как только прокси-сервер вводит эту последовательность завершения, он устанавливает крайний срок для полного завершения соединений с обеих сторон.

Задержка завершения управляет этим сроком. Это продолжительность в миллисекундах, по умолчанию равна 100. Отрицательное значение означает бесконечный срок (т. е. соединение никогда полностью не разрывается самим прокси).

Служба с задержкой завершения — Использование поставщика файлов

YAML

 ## Динамическая конфигурация
TCP:
  Сервисы:
    моя служба:
      loadBalancer:
        terminationDelay: 200

TOML

 ## Динамическая конфигурация
[tcp.services]
  [tcp.services.my-service.loadBalancer]
    [[tcp.services.my-service.loadBalancer]]
      терминацияDelay = 200

Круговая система с взвешиванием

Балансировщик нагрузки сервисов Weighted Round Robin (псевдоним WRR ) отвечает за балансировку запросов между несколькими сервисами на основе предоставленных весов.

Эта стратегия доступна только для балансировки нагрузки между службами, но не между серверами.

YAML

 ## Динамическая конфигурация
TCP:
  Сервисы:
    приложение:
      взвешенный:
        Сервисы:
        - имя: appv1
          вес: 3
        - имя: appv2
          вес: 1
    приложениеv1:
      loadBalancer:
        серверы:
        - адрес: "xxx. xxx.xxx.xxx:8080"
    приложениеv2:
      loadBalancer:
        серверы:
        - адрес: "xxx.xxx.xxx.xxx:8080"

ТОМЛ

 ## Динамическая конфигурация
[tcp.services]
  [tcp.services.app]
    [[tcp.services.app.weighted.services]]
      имя = "приложение1"
      вес = 3
    [[tcp.services.app.weighted.services]]
      имя = "приложение2"
      вес = 1
  [tcp.services.appv1]
    [tcp.services.appv1.loadBalancer]
      [[tcp.services.appv1.loadBalancer.servers]]
        адрес = "частный-ip-сервер-1:8080/"
  [tcp.services.appv2]
    [tcp.services.appv2.loadBalancer]
      [[tcp.services.appv2.loadBalancer.servers]]
        адрес = "частный-ip-сервер-2:8080/"

Настройка служб UDP

Общий

Каждое из полей служебной секции представляет вид службы. Это означает, что для каждой указанной службы одно из полей, и только одно, должен быть включен, чтобы определить, какой сервис создается. В настоящее время доступны два типа: LoadBalancer и Weighted .

Балансировщик нагрузки серверов

Балансировщик нагрузки серверов отвечает за балансировку запросов между серверами одной и той же службы.

Объявление службы с двумя серверами — использование поставщика файлов

YAML

 ## Динамическая конфигурация
UDP:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
        - адрес: "хх.хх.хх.хх:хх"
        - адрес: "xx.xx.xx.xx:xx"

TOML

 ## Динамическая конфигурация
[udp.services]
  [udp.services.my-service.loadBalancer]
    [[udp.services.my-service.loadBalancer.servers]]
      адрес = "хх.хх.хх.хх:хх"
    [[udp.services.my-service.loadBalancer.servers]]
      адрес = "хх.хх.хх.хх:хх"
серверов

Поле Серверы определяет все серверы, входящие в эту группу балансировки нагрузки, то есть каждый адрес (IP:порт), на котором развернут экземпляр программы службы.

Служба с одним сервером — использование поставщика файлов

YAML

 ## Динамическая конфигурация
UDP:
  Сервисы:
    моя служба:
      loadBalancer:
        серверы:
          - адрес: "xx. xx.xx.xx:xx"

TOML

 ## Динамическая конфигурация
[udp.services]
  [udp.services.my-service.loadBalancer]
    [[udp.services.my-service.loadBalancer.servers]]
      адрес = "хх.хх.хх.хх:хх"

Круговая система с взвешиванием

Балансировщик нагрузки сервисов Weighted Round Robin (псевдоним WRR ) отвечает за балансировку запросов между несколькими сервисами на основе предоставленных весов.

Эта стратегия доступна только для балансировки нагрузки между службами, но не между серверами.

Эта стратегия может быть определена только с помощью файла.

YAML

 ## Динамическая конфигурация
UDP:
  Сервисы:
    приложение:
      взвешенный:
        Сервисы:
        - имя: appv1
          вес: 3
        - имя: appv2
          вес: 1
    приложениеv1:
      loadBalancer:
        серверы:
        - адрес: "xxx.xxx.xxx.xxx:8080"
    приложениеv2:
      loadBalancer:
        серверы:
        - адрес: "xxx. xxx.xxx.xxx:8080"

TOML

 ## Динамическая конфигурация
[udp.services]
  [udp.services.app]
    [[udp.services.app.weighted.services]]
      имя = "приложение1"
      вес = 3
    [[udp.services.app.weighted.services]]
      имя = "приложение2"
      вес = 1
  [udp.services.appv1]
    [udp.services.appv1.loadBalancer]
      [[udp.services.appv1.loadBalancer.servers]]
        адрес = "частный-ip-сервер-1:8080/"
  [udp.services.appv2]
    [udp.services.appv2.loadBalancer]
      [[udp.services.appv2.loadBalancer.servers]]
        адрес = "частный-ip-сервер-2:8080/"

Используете Traefik для бизнес-приложений?

Если вы используете Traefik для коммерческих целей, рассмотрите версию для предприятий. Вы можете использовать его как:

  • Kubernetes Ingress Controller
  • Входящий контроллер Docker Swarm
  • Шлюз API

Traefik Enterprise обеспечивает централизованное управление доступом, распределенный Let’s Encrypt, и другие расширенные возможности. Узнайте больше из этого 15-минутного технического пошагового руководства.

Услуги онлайн

Для правильной навигации по Services Online необходимо включить Javascript.

Службы Online позволяют пенсионерам (федеральным пенсионерам или их супругам, бывшим супругам и детям) управлять своей учетной записью в Интернете. Ваша учетная запись надежно защищена Управлением по управлению персоналом США (OPM).

Войти

Мы изменили способ входа в Services Online!

Теперь мы будем требовать от пользователей входа в систему с помощью учетной записи Login.gov. После привязки вашей учетной записи Login.gov к вашей учетной записи Services Online вам может больше не понадобиться снова входить в систему с номером заявки Services Online.

Нужно создать учетную запись на Login.gov?

Используйте кнопку «Войти» выше, а затем нажмите кнопку «Создать учетную запись» под полями входа.

Узнайте о нашем новом процессе входа в систему