Validar - DataPower API Gateway

Use a política Validar para validar a carga útil em um fluxo de conjuntos em um esquema.

Suporte de gateway

Nota: Esta página descreve a implementação da política Validar no DataPower® API Gateway... Se você estiver usando o DataPower Gateway (v5 compatible), consulte Validate - DataPower Gateway (compatível com v5 ).

Para obter informações sobre os diferentes tipos de gateway, consulte API Connect tipos de gateway.

Tabela 1. Tabela que mostra quais gateways suportam esta política e a versão correspondente da política
Gateway	Versão da política
DataPower API Gateway	2.0.0 2.1.0 (DataPower API Gateway Versão 10.0.1.0 ou posterior) 2.2.0 (DataPower API Gateway Versão 10.0.2.0 ou posterior) 2.3.0 (DataPower API Gateway Versão 10.0.2.0 ou posterior) 2.4.0 (DataPower API Gateway Versão 10.0.4.0 ou posterior) 2.5.0 (DataPower API Gateway Versão 10.5.0.0 ou posterior) 2.6.0 (DataPower API Gateway Versão 10.5.0.2 ou posterior 2.7.0 (DataPower API Gateway Versão 10.5.0.3 ou posterior

Este tópico descreve como configurar a política na interface de usuário do Assembly; para obter detalhes sobre como configurar a política na sua fonte do OpenAPI, consulte validate - DataPower API Gateway.

Sobre

Posicione esta política onde necessário no fluxo de conjuntos, conforme a seguir:

Para validar a entrada original, posicione uma política Validar no início do fluxo.
Para validar uma resposta intermediária que é retornada de outras ações ou tarefas de chamada, posicione uma política Validar após essas ações ou tarefas.
Para validar a resposta que é retornada ao aplicativo cliente, posicione uma política Validar após a tarefa que compara a resposta.

Nota: com o DataPower API Gateway, a entrada para a política Validar deve ser dados analisados. Uma maneira de gerar dados analisados é usar uma política de análise antes de uma política de validação no fluxo de montagem, o que permite controlar explicitamente a ação de análise.

Propriedades

A tabela a seguir lista as propriedades de política, indica se uma propriedade é necessária, especifica os valores válidos e padrão para entrada e especifica o tipo de dados dos valores.

Tabela 2. Validar propriedades da política
Rótulo da propriedade	Obrigatório	Descrição	Tipo de dados
Título	True	O título da política. O valor padrão é `validate`.	sequência
Descrição	Não	Uma descrição da política.	sequência
Entrada	Não	Especifica o nome de uma variável no contexto da API. O conteúdo do campo `body` da variável, que é representado por `variable_name.body`, são os dados de entrada a serem validados. Por padrão, o nome de variável é `message`.	sequência
Saída	Não	Especifica o nome de uma variável no contexto da API. Se a validação for aprovada, o campo de corpo da variável de saída, representado por `variable_name.body`, armazenará a saída da ação de validação do conjunto. Se o esquema a ser validado for um esquema JSON, a validação também incluirá quaisquer valores padrão que estiverem ausentes da carga útil. Se a validação falhar, nenhuma saída será armazenada. Se uma variável de saída não for especificada, os resultados da ação de validação do conjunto não serão salvos.	sequência
Validar com relação a	True	Especifica o esquema a ser usado para validar a carga útil. Selecione um dos valores a seguir: `definition`: selecione esse valor se quiser usar um esquema definido anteriormente para validar a carga útil que é retornada de outras ações de chamada ou tarefas no fluxo de conjuntos. A partir da lista Objeto de definição, selecione o esquema necessário. Para obter informações sobre como definir um esquema para uma definição de API do OpenAPI 2.0, consulte Definindo esquemas para uma API. Para obter informações sobre como definir um esquema para uma definição de API do OpenAPI 3.0, consulte Definindo componentes de esquema. `URL`: o esquema é identificado por um local de URL. No campo URL do esquema JSON, insira a URL do esquema JSON a ser usado para validar uma carga útil JSON. Na lista Modo de validação de XML, selecione como a validação XML deve ser executada: `None`: nenhuma validação de carga útil XML é necessária. `xsd`: um esquema XML será usado para validar uma carga útil XML. No campo URL do esquema XML, insira a URL do esquema XML. `wsdl`: um esquema WSDL será usado para validar uma carga útil SOAP. No campo URL do WSDL, insira a URL do esquema WSDL. `soap-body`: validar o corpo de uma mensagem SOAP somente com relação ao esquema XML. Nota: as limitações a seguir se aplicam aos esquemas usados para validação JSON, que incluem esquemas JSON e documentos OpenAPI que são usados como esquemas para validação. Exceder esses limites pode impactar o desempenho da compilação, o que não é suportado. Máximo de 6.500 linhas. Cada chave e cada item em uma matriz contam como uma linha. Profundidade máxima de recursão igual a 250. Máximo de 3.000 itens em listas `enum`. `WSDL`: (disponível apenas com uma API baseada em serviço SOAP) use o esquema XML no arquivo WSDL associado à operação da API ou ao caminho da API. `body-param`: validar a entrada de solicitação em relação à definição de esquema especificada no campo TYPE para o parâmetro de solicitação para essa operação. Para obter informações sobre como criar um parâmetro de solicitação, consulte Definindo parâmetros para uma operação. `response-param`: validar a resposta a ser retornada para o aplicativo cliente, em relação à definição de esquema especificada no campo SCHEMA para o parâmetro de resposta para essa operação. Para obter informações sobre como criar um parâmetro de resposta, consulte Definindo respostas para uma operação. `GraphQL`: (disponível apenas para uma API de proxy GraphQL) validar a carga útil contra o esquema GraphQL que foi importado para a API de proxy GraphQL. Além disso, a consulta ou a resposta do GraphQL, dependendo da entrada, é analisada com relação ao esquema do GraphQL para calcular o custo e o resultado é colocado no contexto da API. Para obter mais informações sobre as APIs de proxy do GraphQL, consulte “Criação de uma API de proxy do GraphQL ” e “Variáveis de contexto do GraphQL ”.	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 é necessário 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

Para exemplos, consulte validate - DataPower API Gateway.