Configurando a política XSLT para DataPower API Gateway

Siga estas etapas para configurar a política XSL para DataPower® API Gateway na interface com o usuário do conjunto.

Sobre essa tarefa

Nota: Este tópico descreve a implementação da política XSLT no DataPower API Gateway. Se você estiver usando o DataPower Gateway (v5 compatible), consulte Configurando a política XSLT para o DataPower Gateway (compatível com o v5 ). Para obter mais informações sobre os diferentes tipos de gateway, consulte API Connect tipos de gateway.

Para obter informações sobre como configurar a política na sua fonte do ` OpenAPI `, consulte xslt.

Procedimento

No painel de navegação, clique em Desenvolver e, em seguida, selecione a guia APIs.
A página Desenvolver é aberta..
Clique no título da API com a qual deseja trabalhar ou crie uma nova API.
Selecione a guia Gateway , em seguida, clique em Políticas na área de janela de navegação.
Para obter mais informações sobre como trabalhar com o editor de assemblies de uma API, consulte O editor de assemblies.
Localize a política XSLT na paleta e arraste a política para sua tela.

Especifique as seguintes propriedades.

Tabela 1. Propriedades de política do XSLT
Rótulo da propriedade	Obrigatório	Descrição	Tipo de dados
Título	True	O título da política. O valor padrão é `xslt`.	sequência
Descrição	Não	Uma descrição da política.	sequência
Entrada	Não	Indica se esse documento de entrada XSLT usa a carga útil atual do contexto, ou se não há nenhuma entrada. A caixa de seleção é desmarcada por padrão, o que indica que não há nenhuma entrada.	booleano
Serializar saída	Não	Se você selecionar essa opção, a árvore de saída gerada pela política XSLT será serializada. O conteúdo de `message.body` é atualizado com os dados binários serializados em vez da árvore XML. A caixa de seleção é desmarcada por padrão, o que indica que a árvore de saída não é serializada.	booleano
Origem	True	A origem de transformação XSLT a ser executada.	sequência
Versão do XSLT	Não	A versão do processador XSLT.. O valor padrão é XSLT10.	sequência
Estrito	Não	Se deve ativar a verificação de erro XSLT estrita. As operações não estritas tentam se recuperar de determinados erros, como o uso de variáveis não declaradas, a chamada de modelos não declarados e assim por diante. Por padrão, a verificação estrita de erro XSLT está ativada.	booleano
Regra de perfil	Não	Se o perfil da folha de estilo deve ser ativado. Essa opção não deve ser usada em ambientes de produção. Por padrão, a criação de perfil da folha de estilo está desativada.	booleano
Regra de depuração	Não	Se deve executar a folha de estilo, o script XQuery e o script JSONiq no modo de depuração. Quando uma folha de estilo, um script XQuery ou um script JSONiq é executado no modo de depuração, ele gera uma página da web customizada em vez de exibir a sua saída normal. A página da web detalha exatamente o que ocorreu durante a execução, incluindo os valores de variáveis e de onde vieram as partes específicas da saída. Essa opção não deve ser usada em ambientes de produção. Por padrão, o modo de depuração está desativado.	booleano
Regra de fluxo	Não	Se a folha de estilo deve ser executada no modo de fluxo. A transformação do documento começa antes da análise completa da entrada. Nem todas as folhas de estilo podem ser transmitidas. Se não for possível transmitir a folha de estilo, um erro será gerado e a entrada não será processada. Por padrão, o modo de fluxo está desativado.	booleano
Tentar aplicar a regra de fluxo	Não	Se deve-se tentar executar a folha de estilo no modo de fluxo. A transformação do documento começa antes da análise completa da entrada. Nem todas as folhas de estilo podem ser transmitidas. Se não for possível transmitir a folha de estilo, um aviso será gerado durante a compilação e a folha de estilo será lida normalmente em toda a entrada no tempo de execução. Por padrão, a tentativa de executar a folha de estilo no modo de fluxo está desativada.	booleano
Regra mínima de escape de saída	Não	Se deve-se escapar a saída produzida da folha de estilo durante o processamento. O escape mínimo é útil, principalmente ao manipular conjuntos de caracteres que não estão em inglês. Por padrão, o escape mínimo está desativado.	booleano
Tamanho máximo de pilha	Não	O número máximo de bytes que a pilha tem permissão para usar ao executar uma folha de estilo ou outro conteúdo compilado. Essa configuração é usada para bloquear a recursão infinita. O valor mínimo é 10 kilobytes ou 10.240 bytes. O valor máximo é 100 megabytes ou 104.857.600 bytes. O valor padrão é 1 megabyte ou 1.048.576 bytes.	número inteiro
Validação do WS-I Basic Profile	Não	O comportamento de validação para aplicar a arquivos WSDL que são verificados para conformidade com a seção 5 do WS-I Basic Profile (versão 1.0, abril de 2004). A configuração padrão é Avisar. Ignorar Desativa a verificação de conformidade. Avisar Registra avisos sobre violações. Falha Obriga ao cumprimento. Falha se o arquivo contiver alguma violação.	sequência
Validar corpo da mensagem	Não	O comportamento de validação para o `soap:Body` A configuração padrão é Estrito. Estrito Valida esta parte da mensagem em relação à definição WSDL. Permite apenas mensagens que contenham essa parte e que correspondam à definição WSDL. Lax Valida esta parte da mensagem em relação à definição WSDL. Se a mensagem contiver essa parte e a definição WSDL não a definir, permita a mensagem. Se a mensagem contiver essa parte e a definição WSDL definir essa parte, permita a mensagem somente quando houver uma correspondência. Ignorar Desativa a validação desta parte da mensagem.	sequência
Validar cabeçalhos da mensagem	Não	O comportamento de validação para o `soap:Header` A configuração padrão é Lax. Estrito Valida esta parte da mensagem em relação à definição WSDL. Permite apenas mensagens que contenham essa parte e que correspondam à definição WSDL. Lax Valida esta parte da mensagem em relação à definição WSDL. Se a mensagem contiver essa parte e a definição WSDL não a definir, permita a mensagem. Se a mensagem contiver essa parte e a definição WSDL definir essa parte, permita a mensagem somente quando houver uma correspondência. Ignorar Desativa a validação desta parte da mensagem.	sequência
Validar detalhes de falha da mensagem	Não	Especifica o comportamento de validação do detalhe de falha. A configuração padrão é Estrito. Estrito Valida esta parte da mensagem em relação à definição WSDL. Permite apenas mensagens que contenham essa parte e que correspondam à definição WSDL. Lax Valida esta parte da mensagem em relação à definição WSDL. Se a mensagem contiver essa parte e a definição WSDL não a definir, permita a mensagem. Se a mensagem contiver essa parte e a definição WSDL definir essa parte, permita a mensagem somente quando houver uma correspondência. Ignorar Desativa a validação desta parte da mensagem.	sequência
Requerer wrappers em detalhes de falha especificados por tipo	Não	Se deve exigir compatibilidade com wrappers do tipo ` RPC `. Por padrão, os wrappers do estilo RPC não são necessários.	booleano
Permitir especificamente a regra xsi:type='SOAP-ENC:Array'	Não	Se o esquema deve aceitar a maioria dos usos de elementos com`xsi:type='SOAP-ENC:Array'` consistente com SOAP 1.1 Seção 5, mesmo quando esses atributos violam a especificação do Esquema XML. Normalmente, o atributo `xsi:type` deve nomear um tipo igual ou derivado do tipo real do elemento. Para esquemas compilados com essa opção, `xsi:type` é aceito especificamente para o tipo complexo 'Matriz' SOAP 1.1 se o tipo de elemento for derivado de `SOAP-ENC:Array`. O oposto é o caso normal permitido. Por padrão, os elementos com `xsi:type='SOAP-ENC:Array'` não são aceitos	booleano
Validar regra de codificação SOAP 1.1	Não	Se a validação de esquema extra deve ser executada seguindo as regras de codificação no SOAP 1.1 Seção 5. Quando a opção é ativada, os membros das matrizes SOAP são validados, atributos como @id e @href são permitidos, mesmo quando não permitidos pelo esquema e os valores de @href são verificados, para assegurar que tenham um elemento @id correspondente. Por padrão, a validação adicional não é executada.	booleano
Os curingas ignoram a regra xsi:type	Não	Se os elementos `xs:any` no esquema validam apenas elementos filhos por nome. A especificação de Esquema XML requer que, se um curinga corresponder a um elemento, mas esse elemento não tiver uma declaração de elemento, o elemento será validado de acordo com um atributo `xsi:type` nele. Essa opção ignora esses atributos do `xsi:type` Ela deve ser usada para casos como a validação do envelope SOAP, em que uma etapa de validação adicional validará o conteúdo correspondente ao curinga, possivelmente usando as regras de codificação SOAP 1.1. Por padrão, atributos `xsi:type` não são ignorados.	booleano
Versão de envelope SOAP estrita	Não	Se deve seguir estritamente a ligação SOAP no WSDL. Quando ativada, apenas as mensagens ligadas ao SOAP 1.2 aparecem em envelopes SOAP 1.2 e apenas as mensagens ligadas ao SOAP 1.1 aparecem em envelopes SOAP 1.1. Por padrão, a ligação SOAP estrita está desativada.	booleano
Política XACML de depuração	Não	Se as políticas XACML devem ser compiladas com as informações de depuração Observe que as mensagens de depuração XACML também são controladas pelo evento de log na categoria XACML. Use o nível de log de depuração para visualizar as mensagens de depuração XACML. Por padrão, as políticas XACML não são compiladas com informações sobre depuração.	booleano
Aceitar as mensagens otimizadas por MTOM/XOP	Não	Especifica se o esquema ou o documento WSDL aceita mensagens nas quais o conteúdo binário codificado em base64 foi otimizado de acordo com as especificações de MTOM/XOP. A otimização binária XOP substitui dados binários base64-encoded por um elemento de referência `xop:Include` que faz referência aos dados binários não codificados localizados em um anexo. Por padrão, as mensagens otimizadas por MTOM/XOP estão desativadas. Quando desativadas, essas mensagens otimizadas são rejeitadas durante a validação do formulário otimizado. A rejeição ocorre porque o esquema especifica um tipo simples que aceita dados base64-encoded , como `xs:base64Binary` ou `xs:string`, mas a mensagem contém um elemento `xop:Include` . Quando ativado, um elemento `xop:Include` pode opcionalmente aparecer no lugar do conteúdo para qualquer tipo simples de Esquema XML que valida dados binários base64-encoded . O elemento `xop:Include` em si será validado de acordo com o esquema integrado em `store:///schemas/xop.xsd`	booleano

Especifique uma versão para a política clicando no ícone "Fonte " e preenchendo a version seção do YAML da política. Por exemplo:
```
execute:
  - xslt:
      version: 2.1.0
      title: xslt
  ...
```
Deve-se especificar uma versão para a política compatível com o gateway que você está usando. Quando a API for publicada, se a versão for incompatível com o gateway, será lançado um erro de validação que especifica as versões disponíveis
Clique em Salvar.