Обработка типов содержимого в Azure Logic Apps

Область применения: Azure Logic Apps (Потребление + Стандартный)

Azure Logic Apps поддерживает все типы контента, такие как JSON, XML, неструктурированные файлы и двоичные данные. Хотя некоторые типы контента имеют встроенную поддержку, то есть они не требуют приведения или преобразования, другие типы контента требуют дополнительных действий для получения требуемого формата.

Чтобы определить лучший способ обработки содержимого или данных в рабочих процессах, Azure Logic Apps использует Content-Type значение заголовка в HTTP-запросах, которые рабочие процессы получают от внешних вызывающих пользователей.

В следующем списке приведены некоторые примеры Content-Type значений, с которыми может столкнуться рабочий процесс:

application/json (собственный тип)
text/plain (собственный тип)
application/xml и application/octet-stream
Другие типы содержимого

В этом руководстве описывается, как Azure Logic Apps обрабатывает различные типы контента и показывает, как правильно приводить или конвертировать эти типы при необходимости.

application/json

Для HTTP-запроса, в котором Content-Type значение заголовка — application/json, Azure Logic Apps сохраняет и обрабатывает содержимое как объект нотации объектов JavaScript (JSON). По умолчанию можно анализировать содержимое JSON без приведения или преобразования. Вы также можете проанализировать это содержимое с помощью выражения.

Например, следующее выражение использует функцию body() с My_action, которое является именем JSON для действия предшественника в рабочем процессе:

body('My_action')['client']['animal-type'][0]

В следующих шагах описывается, как выражение работает без приведения или преобразования.

Функция body() получает выходной body объект из My_action действия.
Из возвращаемого body объекта функция обращается к объекту client .

Объект client содержит свойство animal-type, которое установлено как массив.
Функция обращается к первому элементу в массиве и напрямую возвращает значение "dog" без приведения или преобразования.

Если вы работаете с данными JSON, которые не используют Content-Type заголовок, можно вручную преобразовать эти данные в JSON с помощью функции JSON(), например:

json(triggerBody())['client']['animal-type']

Функция triggerBody() получает body объект из выходных данных триггера рабочего процесса. Обычно этот объект является объектом JSON.

Источник объекта body поступает из входящего HTTP-запроса или события, полученного триггером рабочего процесса.
Функция json() явно анализирует body объект, возвращаемый из triggerBody() функции как объект JSON.

Это поведение полезно, например, если текст триггера является строкой, требующей обработки в формате JSON.

Оставшееся поведение выражения аналогично предыдущему примеру.

Создание токенов для свойств JSON

В Azure Logic Apps можно создавать понятные для пользователя маркеры, представляющие свойства в содержимом JSON. Затем эти маркеры можно использовать, чтобы можно было проще ссылаться на эти свойства и их значения в рабочем процессе.

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

Триггер запроса с именем "При получении HTTP-запроса"

При работе в конструкторе с триггером запроса можно при необходимости указать схему JSON, которая определяет объекты JSON, свойства и ожидаемые типы данных для каждого значения свойства. Если у вас нет схемы JSON, вы можете предоставить пример пейлоада для создания схемы JSON для дальнейшего использования.

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

Ниже описано, как предоставить пример полезных данных для создания схемы JSON:
1. В конструкторе выберите триггер запроса , чтобы открыть область сведений.
2. На вкладке "Параметры " в поле "Схема JSON текста запроса " выберите "Использовать пример полезных данных для создания схемы".
3. В поле «Введите или вставьте пример полезных данных JSON» введите пример, затем выберите «Готово».
  
  Созданная схема теперь отображается в триггере.
  
  В редакторе представления кода можно просмотреть базовое определение JSON для триггера запроса :
```
"triggers": { 
   "When_an_HTTP_request_is_received": {
      "type": "Request",
      "kind": "Http",
      "inputs": { 
         "schema": {
            "type": "object",
            "properties": {
               "client": {
                  "type": "object",
                  "properties": {
                     "animal-type": {
                        "type": "array",
                        "items": {
                           "type": "string"
                        },
                     },
                     "name": {
                        "type": "string"
                     }
                  }
               }
            }
         }
      }
   }
}
```
4. Чтобы активировать рабочий процесс, получите URL-адрес рабочего процесса или HTTP-адрес триггера, который создается после сохранения рабочего процесса в первый раз.
5. Чтобы протестировать рабочий процесс, используйте клиентское средство или приложение, из которого можно отправить HTTP-запрос в URL-адрес рабочего процесса или URL-адрес триггера. Убедитесь, что запрос содержит заголовок с именем Content-Type , а для значения заголовка задано значение application/json.
Анализ действия JSON

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

Подобно триггеру запроса можно предоставить или создать схему, описывающую содержимое JSON, которое необходимо проанализировать. Таким образом можно легко использовать данные из Служебной шины Azure, Azure Cosmos DB и другого.

text/plain

Если ваш рабочий процесс получает HTTP-запросы, где Content-Type значение заголовка — text/plain. Azure Logic Apps хранит и обрабатывает содержимое в необработанной форме. Если вы ссылаетесь или используете это содержимое в последующих действиях рабочего процесса без приведения или преобразования, исходящие запросы также имеют значение Content-Typeзаголовкаtext/plain.

Например, предположим, что вы работаете с плоским файлом, а в входящем HTTP-запросе значение заголовка Content-Type равно text/plain:

Date,Name,Address
Oct-1,Frank,123 Ave

При отправке этого запроса в последующее действие, использующее тело запроса для отправки другого запроса, второй запрос также имеет значение заголовка Content-Typetext/plain. Если вы работаете с данными в виде обычного текста, но не указали заголовок, можно вручную привести эти данные к тексту string()с помощью функции, например:

string(triggerBody())

application/xml и application/octet-stream

Azure Logic Apps всегда сохраняет значение заголовка Content-Type во входящем HTTP-запросе или ответе. Если рабочий процесс получает содержимое с Content-Type заданным значением application/octet-stream, и вы включаете это содержимое в последующее действие без приведения, исходящий запрос также задает значение Content-Typeapplication/octet-stream. Этот подход гарантирует, что данные не теряются во время перемещения по рабочему процессу. В рабочих процессах с отслеживанием состояния последующие действия, входные и выходные данные хранятся в объекте JSON во время перемещения состояния через рабочий процесс.

Функции преобразователя

Чтобы сохранить некоторые типы данных, Azure Logic Apps преобразует содержимое в двоичную строку в кодировке Base64. Эта строка содержит соответствующие метаданные, сохраняющие как $content, так и $content-type, которые автоматически преобразуются.

В следующем списке описывается, как Azure Logic Apps преобразует содержимое при использовании определенных функций:

json(): приведение данных к application/json.
xml(): приведение данных к application/xml.
binary(): приведение данных к application/octet-stream.
string(): приведение данных к text/plain.
base64(): преобразует содержимое в строку в кодировке Base64.
base64toString(): преобразует строку в кодировке text/plainBase64 в .
base64toBinary(): преобразует строку в кодировке application/octet-streamBase64 в .
dataUri(): преобразует строку в идентификатор ресурса (URI) данных.
dataUriToBinary(): преобразует URI данных в двоичную строку.
dataUriToString(): преобразует URI данных в строку.

Например, предположим, что триггер рабочего процесса получает HTTP-запрос, где Content-Type установлено на application/xml, в котором содержимое выглядит следующим образом:

<?xml version="1.0" encoding="UTF-8" ?>
<CustomerName>Frank</CustomerName>

Это содержимое можно привести с помощью следующего выражения, которое использует функции xml() и triggerBody().

xml(triggerBody())

Затем можно использовать полученное содержимое с последующими действиями в рабочем процессе. Вместо этого можно использовать следующее выражение, которое использует функции xpath() и xml().

xpath(xml(triggerBody()), '/CustomerName')

Другие типы содержимого

Azure Logic Apps поддерживает другие типы контента, но может потребоваться вручную получить текст сообщения из HTTP-запроса, декодируя $content переменную.

Например, предположим, что рабочий процесс получает HTTP-запрос, в котором Content-Type задано значение application/x-www-url-formencoded. Чтобы сохранить все данные, текст запроса включает $content переменную, в которой полезные данные кодируются в виде строки base64:

CustomerName=Frank&Address=123+Avenue

Этот тип контента не в формате простого текста или JSON, поэтому Azure Logic Apps сохраняет CustomerName=Frank&Address=123+Avenue с использованием следующих $content-type и $content переменных:

"body": {
   "$content-type": "application/x-www-url-formencoded",
   "$content": "AAB1241BACDFA=="
}

Azure Logic Apps также включает собственные функции для обработки данных формы, например:

Кроме того, вы можете вручную получить доступ к данным с помощью выражения, например в следующем примере:

string(body('formdataAction'))

Чтобы сделать исходящий запрос, используйте application/x-www-url-formencoded в качестве значения заголовка Content-Type, добавьте содержимое запроса в тело действия с помощью такого выражения, как body('formdataAction'), без приведения типов. Этот метод работает только если тело действия является единственным параметром в объекте входных данных body. Если вы используете выражение body('formdataAction') в запросе с типом контента application/json, возникает ошибка выполнения, поскольку тело отправляется в закодированном виде.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-10-17