Политики преобразования службы управления API

В этой статье рассматриваются приведенные ниже политики управления API. Дополнительные сведения о добавлении и настройке политик см. в статье о политиках в управлении API.

Политики преобразования

Преобразование JSON в XML

Политика json-to-xml преобразует текст запроса или ответа в формате JSON в формат XML.

Правило политики

<json-to-xml apply="always | content-type-json" consider-accept-header="true | false" parse-date="true | false"/>

Пример

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <json-to-xml apply="always" consider-accept-header="false" parse-date="false"/>
    </outbound>
</policies>

Элементы

Название Описание Обязательно
json-to-xml Корневой элемент. Да

Атрибуты

Имя Описание Обязательно По умолчанию
apply Для атрибута нужно задать одно из следующих значений:

— всегда — всегда применять преобразование.
-Content-Type-JSON — Convert только в том случае, если заголовок ответа Content-Type указывает на наличие JSON.
Да Н/Д
consider-accept-header Для атрибута нужно задать одно из следующих значений:

-true — применить преобразование, если XML запрашивается в заголовке запроса Accept.
-false — всегда применять преобразование.
Нет true
parse-date Если задано значение false, значения даты просто копируются при преобразовании. Нет true

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound, on-error.

  • Области политики: все области.

Преобразование XML в JSON

Политика xml-to-json преобразует текст запроса или ответа в формате XML в формат JSON. Эту политику можно использовать для модернизации интерфейсов API, основанных на серверных веб-службах (только XML).

Правило политики

<xml-to-json kind="javascript-friendly | direct" apply="always | content-type-xml" consider-accept-header="true | false"/>

Пример

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <xml-to-json kind="direct" apply="always" consider-accept-header="false" />
    </outbound>
</policies>

Элементы

Название Описание Обязательно
xml-to-json Корневой элемент. Да

Атрибуты

Имя Описание Обязательно По умолчанию
kind Для атрибута нужно задать одно из следующих значений:

— понятное для JavaScript — преобразованный JSON имеет форму, понятную разработчикам JavaScript.
-Direct — преобразованный код JSON отражает структуру исходного XML-документа.
Да Н/Д
apply Для атрибута нужно задать одно из следующих значений:

-всегда — преобразование всегда.
-Content-Type-XML — Convert только в случае, если заголовок Response Content-Type указывает на присутствие XML.
Да Н/Д
consider-accept-header Для атрибута нужно задать одно из следующих значений:

-true — применить преобразование, если JSON запрашивается в заголовке запроса Accept.
-false — всегда применять преобразование.
Нет true

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound, on-error.

  • Области политики: все области.

Поиск и замена строки в тексте

Политика find-and-replace отыскивает подстроку запроса или ответа и заменяет ее на другую подстроку.

Правило политики

<find-and-replace from="what to replace" to="replacement" />

Пример

<find-and-replace from="notebook" to="laptop" />

Элементы

Название Описание Обязательно
find-and-replace Корневой элемент. Да

Атрибуты

Имя Описание Обязательно По умолчанию
из Искомая строка. Да Н/Д
значение Строка замены. Укажите строку замены с нулевой длиной для удаления строки поиска. Да Н/Д

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound, backend, on-error.

  • Области политики: все области.

Маскировка URL-адреса в содержимом

Политика redirect-content-urls перезаписывает (маскирует) ссылки в тексте ответа так, чтобы каждая из них указывала на эквивалентную ссылку через шлюз. Используйте в разделе outbound, чтобы перезаписать ссылки текста ответа так, чтобы они указывали на шлюз. Используйте в разделе inbound для обратного эффекта.

Примечание

Эта политика не изменяет значения заголовка, например заголовка Location. Чтобы изменить значения заголовка, используйте политику set-header.

Правило политики

<redirect-content-urls />

Пример

<redirect-content-urls />

Элементы

Название Описание Обязательно
redirect-content-urls Корневой элемент. Да

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound.

  • Области политики: все области.

Задание внутренней службы

Используйте политику set-backend-service для перенаправления входящего запроса во внутреннюю службу, отличную от указанной в параметрах API для этой операции. Эта политика изменяет базовый URL-адрес внутренней службы входящего запроса на URL-адрес, указанный в политике.

Правило политики

<set-backend-service base-url="base URL of the backend service" />

или

<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service" />

Примечание

Серверными сущностями можно управлять на портале Azure, с помощью API управления и PowerShell.

Пример

<policies>
    <inbound>
        <choose>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2013-05")">
                <set-backend-service base-url="http://contoso.com/api/8.2/" />
            </when>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2014-03")">
                <set-backend-service base-url="http://contoso.com/api/9.1/" />
            </when>
        </choose>
        <base />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

В этом примере политика задания внутренней службы направляет запросы на основе значения версии, переданного в строке запроса во внутреннюю службу, отличную от указанной в API.

Изначально базовый URL-адрес внутренней службы является производным от параметров API. Поэтому URL-адрес запроса https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdef становится http://contoso.com/api/10.4/partners/15?version=2013-05&subscription-key=abcdef, где http://contoso.com/api/10.4/ — URL-адрес внутренней службы, указанной в параметрах API.

При применении инструкции SELECT Policy базовый URL-адрес внутренней службы может снова измениться на или, в зависимости от значения параметра запроса версии. >http://contoso.com/api/8.2http://contoso.com/api/9.1 Например, если значение — "2013-15", URL-адрес последнего запроса становится http://contoso.com/api/8.2/partners/15?version=2013-05&subscription-key=abcdef.

Если требуются дополнительные преобразования запроса, можно воспользоваться другими политиками преобразования. Например, чтобы удалить параметр запроса версии теперь, когда запрос направляется на серверную часть версии, можно использовать политику Set Query Parameter , чтобы удалить атрибут избыточной версии.

Пример

<policies>
    <inbound>
        <set-backend-service backend-id="my-sf-service" sf-partition-key="@(context.Request.Url.Query.GetValueOrDefault("userId","")" sf-replica-type="primary" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

В этом примере политика направляет запрос к внутренней службе Service Fabric, используя строку запроса userId в качестве ключа секции и используя первичную реплику секции.

Элементы

Название Описание Обязательно
set-backend-service Корневой элемент. Да

Атрибуты

Имя Описание Обязательно По умолчанию
base-url Новый базовый URL-адрес внутренней службы. Необходимо указать base-url или backend-id. Н/Д
backend-id Идентификатор серверной части для перенаправления. (Внутренними сущностями можно управлять на портале Azure, с помощью API или PowerShell.) Необходимо указать base-url или backend-id. Н/Д
sf-partition-key Применяется только, когда серверной частью является служба Service Fabric и она задана с помощью атрибута backend-id. Используется для разрешения определенной секции в имени службы разрешения имен. Нет Н/Д
sf-replica-type Применяется только, когда серверной частью является служба Service Fabric и она задана с помощью атрибута backend-id. Контролирует, куда должен отправляться запрос: в первичную или вторичную реплику секции. Нет Н/Д
sf-resolve-condition Применяется только, когда серверной частью является служба Service Fabric. Условие, определяющее, необходимо ли повторить вызов к серверной части Service Fabric с новым разрешением. Нет Н/Д
sf-service-instance-name Применяется только, когда серверной частью является служба Service Fabric. Разрешает изменение экземпляров службы в среде выполнения. Нет Н/Д
sf-listener-name Применяется, только когда серверной частью является служба Service Fabric, а также при определении с помощью атрибута backend-id. Reliable Services Service Fabric позволяют создавать несколько прослушивателей в одной службе. Этот атрибут используется для выбора конкретного прослушивателя, когда у серверной службы Reliable Service есть больше одного прослушивателя. Если этот атрибут не указан, управление API попытается использовать прослушиватель без имени. Прослушиватель без имени часто используются службами Reliable Services, у которых есть только один прослушиватель. Нет Н/Д

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, backend.

  • Области политики: все области.

Задание текста

Используйте политику set-body, чтобы задать текст сообщения для входящих и исходящих запросов. Для доступа к тексту сообщения можно использовать свойство context.Request.Body или context.Response.Body в зависимости от того, где находится политика: в разделе inbound или outbound.

Важно!

Обратите внимание, что по умолчанию при доступе к тексту сообщения с помощью context.Request.Body или context.Response.Body исходный текст сообщения теряется и его необходимо задать, возвратив текст обратно в выражение. Чтобы сохранить содержимое текста, при доступе к сообщению присвойте параметру preserveContent значение true. Если для параметра preserveContent задано значение true и в выражении возвращается другой текст, используется возвращаемый текст.

Учтите следующие рекомендации при использовании политики set-body.

  • Если для возврата нового или обновленного текста используется политика set-body, для параметра preserveContent не требуется задавать значение true, так как вы явно указываете новое содержимое текста.
    • Сохранять содержимое ответа во входящем конвейере не имеет смысла, так как ответа еще нет.
    • Сохранять содержимое запроса в исходящем конвейере не имеет смысла, так как на этом этапе запрос уже был отправлен в серверную часть.
    • Если эта политика используется при отсутствии текста сообщения, например во входящем параметре GET, возникает исключение.

Дополнительные сведения см context.Request.Body . в разделах, context.Response.Body и IMessage в таблице context.Request.Body .

Правило политики

<set-body>new body value as text</set-body>

Примеры

Пример литерального текста

<set-body>Hello world!</set-body>

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

<set-body>
@{ 
    string inBody = context.Request.Body.As<string>(preserveContent: true); 
    if (inBody[0] =='c') { 
        inBody[0] = 'm'; 
    } 
    return inBody; 
}
</set-body>

Пример доступа к тексту как к объекту JObject Обратите внимание, что мы не резервировали исходный текст запроса, поэтому попытка получить к нему доступ позже в конвейере приведет к возникновению исключения.

<set-body> 
@{ 
    JObject inBody = context.Request.Body.As<JObject>(); 
    if (inBody.attribute == <tag>) { 
        inBody[0] = 'm'; 
    } 
    return inBody.ToString(); 
} 
</set-body>

Фильтрация ответа в зависимости от продукта

В этом примере показано, как выполнить фильтрацию содержимого путем удаления элементов данных из ответа, полученного из внутренней службы при использовании продукта Starter. Пример настройки и использования этой политики см. в видео Cloud Cover Episode 177: More API Management Features with Vlad Vinogradsky (Cloud Cover, эпизод 177: возможности управления API с Владом Виноградским) с отметки времени 34:30. Начните с отметки времени 31:50, чтобы узнать общие сведения о прогнозном API Dark Sky, используемом для этого примера.

<!-- Copy this snippet into the outbound section to remove a number of data elements from the response received from the backend service based on the name of the api product -->
<choose>
  <when condition="@(context.Response.StatusCode == 200 && context.Product.Name.Equals("Starter"))">
    <set-body>@{
        var response = context.Response.Body.As<JObject>();
        foreach (var key in new [] {"minutely", "hourly", "daily", "flags"}) {
          response.Property (key).Remove ();
        }
        return response.ToString();
      }
    </set-body>
  </when>
</choose>

Использование шаблонов Liquid с политикой set-body

set-bodyПолитика может быть настроена на использование языка шаблонов set-body для преобразования текста запроса или ответа. Это может быть очень эффективным, когда требуется полностью изменить формат сообщения.

Важно!

Реализация шаблонов Liquid, используемая в политике set-body, настраивается в режиме C#. Это особенно важно при выполнении действий, таких как фильтрация. Например, если применяется фильтр по дате, то необходимо использовать стиль Pascal и форматирование даты C#, как в следующем примере:

{{body.foo.startDateTime| Date:"yyyyMMddTHH:mm:ssZ"}}

Важно!

Чтобы с помощью шаблона Liquid правильно выполнить привязку к тексту XML, используйте политику set-header. Задайте для Content-Type значение application/xml или text/xml (или любой другой тип, заканчивающийся на +xml). Для текста JSON значение должно быть application/json или text/json (или любой другой тип, заканчивающийся на +json).

Преобразование JSON в SOAP с помощью шаблона Liquid

<set-body template="liquid">
    <soap:Envelope xmlns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body>
            <GetOpenOrders>
                <cust>{{body.getOpenOrders.cust}}</cust>
            </GetOpenOrders>
        </soap:Body>
    </soap:Envelope>
</set-body>

Преобразование JSON с помощью шаблона Liquid

{
"order": {
    "id": "{{body.customer.purchase.identifier}}",
    "summary": "{{body.customer.purchase.orderShortDesc}}"
    }
}

Элементы

Название Описание Обязательно
set-body Корневой элемент. Содержит текст или выражения, которые возвращают текст. Да

Свойства

Имя Описание Обязательно По умолчанию
шаблон Используется для изменения режима шаблона, в котором будет выполняться политика set-body. В настоящее время поддерживается только одно значение:

- liquid — политика set-body будет использовать подсистему шаблонов Liquid.
Нет

Для доступа к сведениям о запросе и ответе шаблон Liquid можно привязать к объекту context с помощью следующих свойств:

context.
    Request.
        Url Method OriginalMethod OriginalUrl IpAddress MatchedParameters HasBody ClientCertificates Headers
    Реагирование.
        URL-адрес заголовков метода StatusCode.
    Scheme Host Port Path Query QueryString ToUri ToString
OriginalUrl.
    Scheme Host Port Path Query QueryString ToUri ToString

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound, backend.

  • Области политики: все области.

Задание заголовка HTTP

Политика set-header назначает значение имеющемуся заголовку ответа и/или запроса или добавляет новый заголовок ответа и/или запроса.

Вставляет список HTTP-заголовков в HTTP-сообщение. Если эта политика находится во входящем конвейере, она устанавливает HTTP-заголовки для запроса, передаваемого в целевую службу. Если эта политика находится в исходящем конвейере, она устанавливает HTTP-заголовки для ответа, отправляемого клиенту шлюза.

Правило политики

<set-header name="header name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple headers with the same name add additional value elements-->
</set-header>

Примеры

Пример. Добавление заголовка, переопределение существующего

<set-header name="some header name" exists-action="override">
    <value>20</value>
</set-header>

Пример. Удаление заголовка

 <set-header name="some header name" exists-action="delete" />

Пересылка контекстных сведений во внутреннюю службу

В этом примере показано, как применить политику на уровне API для предоставления контекстных сведений внутренней службе. Пример настройки и использования этой политики см. в видео Cloud Cover Episode 177: More API Management Features with Vlad Vinogradsky (Cloud Cover, эпизод 177: возможности управления API с Владом Виноградским) с отметки времени 10:30. На отметке времени 12:10 демонстрируется вызов операции на портале разработчика, где можно просмотреть политику в действии.

<!-- Copy this snippet into the inbound element to forward some context information, user id and the region the gateway is hosted in, to the backend service for logging or evaluation -->
<set-header name="x-request-context-data" exists-action="override">
  <value>@(context.User.Id)</value>
  <value>@(context.Deployment.Region)</value>
</set-header>

Чтобы узнать больше, см. статью API Management policy expressions (Выражения политики управления API) и раздел Context variable (Переменная контекста).

Примечание

Несколько значений заголовка сцепляются в строку CSV, как показано в примере: headerName: value1,value2,value3.

Исключения включают в себя стандартизированные заголовки, значения которых:

  • могут содержать запятые (User-Agent, WWW-Authenticate, Proxy-Authenticate);
  • могут содержать дату (Cookie, Set-Cookie, Warning);
  • содержат дату (Date, Expires, If-Modified-Since, If-Unmodified-Since, Last-Modified, Retry-After).

В случае таких исключений несколько значений заголовка не будут сцеплены в одну строку и будут передаваться как отдельные заголовки, например: User-Agent: value1User-Agent: value2User-Agent: value3.

Элементы

Название Описание Обязательно
set-header Корневой элемент. Да
значение Указывает значение заголовка, которое должно быть установлено. Для нескольких заголовков с одним и тем же именем добавьте дополнительные элементы value. Нет

Свойства

Имя Описание Обязательно По умолчанию
exists-action Указывает действие, которое должно быть выполнено, когда заголовок уже задан. Атрибут должен иметь одно из следующих значений:

— override — заменяет значение имеющегося заголовка;
— skip — не заменяет значение имеющегося заголовка;
— append — добавляет значение к значению имеющегося заголовка;
— delete — удаляет заголовок из запроса.

Если установлено значение override, перечисление нескольких записей с одним и тем же именем будет приводить к тому, что заголовок будет устанавливаться в соответствии со всеми записями (будут перечисляться несколько раз). В результате будут установлены только перечисленные значения.
Нет override
name Указывает имя заголовка, которое должно быть установлено. Да Н/Д

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound, backend, on-error.

  • Области политики: все области.

Задание параметра строки запроса

Политика set-query-parameter добавляет, заменяет значение или удаляет параметр строки запроса. Можно использовать для передачи параметров запроса, ожидаемых внутренней службой, которые являются необязательными или никогда не присутствуют в запросе.

Правило политики

<set-query-parameter name="param name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple parameters with the same name add additional value elements-->
</set-query-parameter>

Пример


<set-query-parameter name="api-key" exists-action="skip">
  <value>12345678901</value>
</set-query-parameter>

Пересылка контекстных сведений во внутреннюю службу

В этом примере показано, как применить политику на уровне API для предоставления контекстных сведений внутренней службе. Пример настройки и использования этой политики см. в видео Cloud Cover Episode 177: More API Management Features with Vlad Vinogradsky (Cloud Cover, эпизод 177: возможности управления API с Владом Виноградским) с отметки времени 10:30. На отметке времени 12:10 демонстрируется вызов операции на портале разработчика, где можно просмотреть политику в действии.

<!-- Copy this snippet into the inbound element to forward a piece of context, product name in this example, to the backend service for logging or evaluation -->
<set-query-parameter name="x-product-name" exists-action="override">
  <value>@(context.Product.Name)</value>
</set-query-parameter>

Чтобы узнать больше, см. статью API Management policy expressions (Выражения политики управления API) и раздел Context variable (Переменная контекста).

Элементы

Название Описание Обязательно
set-query-parameter Корневой элемент. Да
значение Указывает значение параметра запроса, которое должно быть установлено. Для нескольких параметров запроса с одним и тем же именем добавьте дополнительные элементы value. Да

Свойства

Имя Описание Обязательно По умолчанию
exists-action Указывает действие, которое должно быть выполнено, когда параметр запроса уже задан. Атрибут должен иметь одно из следующих значений:

-override — заменяет значение существующего параметра.
-Skip — не заменяет существующее значение параметра запроса.
-Append — добавляет значение к существующему значению параметра запроса.
-Delete — удаляет параметр запроса из запроса.

Если установлено значение override, перечисление нескольких записей с одним и тем же именем будет приводить к тому, что параметр запроса будет устанавливаться в соответствии со всеми записями (будут перечисляться несколько раз). В результате будут установлены только перечисленные значения.
Нет override
name Указывает имя параметра запроса, которое должно быть установлено. Да Н/Д

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, backend.

  • Области политики: все области.

Замена URL-адреса

Политика rewrite-uri преобразовывает URL-адрес запроса из его общедоступной формы в форму, ожидаемую веб-службой, как показано в следующем примере.

  • Открытый URL — http://api.example.com/storenumber/ordernumber.

  • URL-адрес запроса — http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&State.

    Эту политику можно использовать, когда дружественный для пользователя и/или браузера URL-адрес должен быть преобразован в формат URL-адреса, ожидаемый веб-службой. Эту политику необходимо применять только при указании URL-адресов в другом формате, например "чистых" URL-адресов, URL-адресов типа RESTful, дружественных для пользователя URL-адресов или дружественных для SEO URL-адресов, которые представляют собой чисто структурные URL-адреса, не содержащие строку запроса. Вместо этого они содержат только путь к ресурсу (после схемы и полномочий). Это часто делает в эстетических целях, для удобства и простоты использования или для оптимизации поисковых систем (SEO).

Примечание

Используя политику, можно добавлять только параметры строки запроса. Нельзя добавлять дополнительный параметр пути к шаблону в URL-адрес перезаписи.

Правило политики

<rewrite-uri template="uri template" copy-unmatched-params="true | false" />

Пример

<policies>
    <inbound>
        <base />
        <rewrite-uri template="/v2/US/hardware/{storenumber}&{ordernumber}?City=city&State=state" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put?c=d -->
<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" copy-unmatched-params="false" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put -->

Элементы

Название Описание Обязательно
rewrite-uri Корневой элемент. Да

Атрибуты

Атрибут Описание Обязательно По умолчанию
шаблон Фактический URL-адрес веб-службы с любыми параметрами строки запроса. При использовании выражений все значение должно быть выражением. Да Н/Д
copy-unmatched-params Указывает, добавляются ли в определяемый шаблоном перезаписи URL-адрес параметры запроса во входящем запросе, отсутствующие в исходном шаблоне URL-адреса. Нет true

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound.

  • Области политики: все области.

Преобразование XML с помощью XSLT

Политика Transform XML using an XSLT применяет преобразование данных в формате XSL в формат XML в тексте запроса или ответа.

Правило политики

<xsl-transform>
    <parameter name="User-Agent">@(context.Request.Headers.GetValueOrDefault("User-Agent","non-specified"))</parameter>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:output method="xml" indent="yes" />
        <xsl:param name="User-Agent" />
        <xsl:template match="* | @* | node()">
            <xsl:copy>
                <xsl:if test="self::* and not(parent::*)">
                    <xsl:attribute name="User-Agent">
                        <xsl:value-of select="$User-Agent" />
                    </xsl:attribute>
                </xsl:if>
                <xsl:apply-templates select="* | @* | node()" />
            </xsl:copy>
        </xsl:template>
    </xsl:stylesheet>
  </xsl-transform>

Пример

<policies>
  <inbound>
      <base />
  </inbound>
  <outbound>
      <base />
      <xsl-transform>
          <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
            <xsl:output omit-xml-declaration="yes" method="xml" indent="yes" />
            <!-- Copy all nodes directly-->
            <xsl:template match="node()| @*|*">
                <xsl:copy>
                    <xsl:apply-templates select="@* | node()|*" />
                </xsl:copy>
            </xsl:template>
          </xsl:stylesheet>
    </xsl-transform>
  </outbound>
</policies>

Элементы

Название Описание Обязательно
xsl-transform Корневой элемент. Да
параметр Используется для определения переменных, используемых при преобразовании. Нет
xsl:stylesheet Корневой элемент таблицы стилей. Все определенные элементы и атрибуты соответствуют стандарту спецификации XSLT. Да

Использование

Эта политика может использоваться в следующих разделах и областях.

  • Разделы политики: inbound, outbound.

  • Области политики: все области.

Следующие шаги

Дополнительные сведения см. в следующих разделах: