DataPower API Gateway

validate - DataPower API Gateway

Modifier en ligne

Utilisez la stratégie validate pour valider le contenu d'un flux d'assemblage par rapport à un schéma.

Prise en charge des passerelles

Remarque: Cette page décrit l'implémentation de stratégie validate dans DataPower® API Gateway. Si vous utilisez la commande DataPower Gateway (v5 compatible)`validate`, consultez la page DataPower Gateway (compatible avec v5 ).

Pour plus d'informations sur les différents types de passerelle, voir Types de passerelleAPI Connect.

Tableau 1. Tableau indiquant les passerelles prenant en charge cette politique, ainsi que la version correspondante de la politique
Passerelle Version de la stratégie
DataPower API Gateway 2.0.0

2.1.0 (DataPower API Gateway version 10.0.1.0 ou ultérieure)

2.2.0 (DataPower API Gateway version 10.0.2.0 ou ultérieure)

2.3.0 (DataPower API Gateway version 10.0.2.0 ou ultérieure)

2.4.0 (DataPower API Gateway version 10.0.4.0 ou ultérieure)

2.5.0 (DataPower API Gateway version 10.5.0.0 ou ultérieure)

2.6.0 (DataPower API Gateway version 10.5.0.2 ou ultérieure)

2.7.0 (DataPower API Gateway version 10.5.0.3 ou ultérieure

Cette rubrique explique comment configurer la stratégie dans votre source OpenAPI; pour plus de détails sur la configuration de la stratégie dans l'interface utilisateur d', consultez la rubrique « Validate » - DataPowerAPI Gateway.

A propos de

Le format de la règle validate est le suivant:
- validate:
    version: version
    title: title
    description: description
    validate-against: validation_mechanism
         .
         .
         .
       properties_specific_to_the specified_validation_mechanism
         .
         .
         .

Appliquez cette règle en ajoutant une extension assembly avec une zone execute à votre fichier de définition OpenAPI .

Remarque: avec DataPower API Gateway, l'entrée de la règle validate doit être des données analysées. Une façon de produire des données analysées consiste à utiliser une stratégie parse avant une stratégie validate dans votre flux d'assemblage, qui fournit un contrôle explicite de l'action d'analyse.

Propriétés

Le tableau suivant décrit les propriétés de la stratégie :
Tableau 2. validate propriétés de la police
Propriété Obligatoire Descriptif Type de données
version Oui Numéro de version de la stratégie chaîne
title Non Titre de la stratégie. chaîne
description Non Description de la stratégie. chaîne
input Non Identifie une variable dans le contexte d'API. Le contenu de la zone body de la variable, qui est représentée par variable_name.body, correspond aux données d'entrée à valider. Par défaut, le nom de la variable est message. chaîne
output Non Indique le nom d'une variable dans le contexte d'API.
  • Si la validation aboutit, la zone de corps de la variable de sortie, représentée par variable_name.body, stocke la sortie de l'action de validation de l'assemblage.
  • Si le schéma à valider est un schéma JSON, la validation ajoute également toutes les valeurs par défaut qui sont manquantes dans le contenu.
  • Si la validation échoue, aucune sortie n'est stockée.
  • Si aucune variable de sortie n'est spécifiée, les résultats de l'action de validation d'assemblage ne sont pas sauvegardés.
 chaîne
validate-against Oui Spécifie le schéma à utiliser pour valider le contenu.
Valeurs valides :
  • definition : Un schéma précédemment défini sera utilisé pour valider le contenu renvoyé par d'autres tâches ou actions d'appel dans le flux d'assemblage.

    En outre, vous devez fournir une propriété definition pour spécifier le schéma requis.

  • url: le schéma est identifié par un emplacement d' URL.
    Vous devez en outre indiquer les propriétés suivantes :
    • Zone json-schema : URL du schéma JSON à utiliser pour valider un contenu JSON.
    • xml-validation-mode : Indiquez l'une des valeurs suivantes pour définir le mode de validation d'un contenu XML :
      • xsd : Utilisez un schéma XML ; vous devez également indiquer une propriété xml-schema spécifiant l'URL du schéma XML.
      • wsdl : Utilisez un schéma WSDL ; vous devez également indiquer une propriété xml-schema spécifiant l'URL du schéma WSDL à utiliser pour valider un contenu SOAP.
      • soap-body : Valide le corps d'un message SOAP en fonction du schéma XML uniquement.
      Remarque: Les limitations suivantes s'appliquent aux schémas utilisés pour la validation JSON, qui incluent les schémas JSON et les documents OpenAPI utilisés comme schémas pour la validation. Le dépassement de ces limites peut avoir un impact sur les performances de compilation et n'est pas pris en charge.
      • Maximum de 6 500 lignes. Chaque clé et chaque élément d'un tableau comptent comme une ligne.
      • Profondeur de récursivité maximale de 250.
      • Maximum de 3 000 éléments dans les listes enum.
  • wsdl : (disponible avec une API basée sur un service SOAP uniquement) Utilisez le schéma XML dans le fichier WSDL associé à l'opération API ou au chemin d'API.
  • body-param : Validez l'entrée de demande en fonction de la définition de schéma spécifiée dans la propriété schema pour le paramètre de demande correspondant à cette opération.
  • response-param : Validez la réponse à renvoyer à l'application client en fonction de la définition de schéma spécifiée dans la propriété schema pour le paramètre de réponse correspondant à cette opération.
  • graphql : (disponible avec une API de proxy GraphQL uniquement) Validez le contenu en fonction du schéma GraphQL qui a été importé dans l'API de proxy GraphQL. De plus, la requête ou la réponse GraphQL, selon l'entrée, est analysée par rapport au schéma GraphQL afin de calculer le coût, et le résultat est placé dans le contexte d'API.

    Pour plus d'informations sur les API proxy d' GraphQL, consultez les pages Création d'une API proxy d' GraphQL et Variables de contexte d' GraphQL.

    .
 chaîne
xslt-version Non Version du processeur XSLT. La valeur par défaut est XSLT10. chaîne
strict Non Indique si la vérification stricte des erreurs XSLT doit être activée. Les opérations non strictes tentent de récupérer après certaines erreurs, telles que l'utilisation de variables non déclarées, l'appel de modèles non déclarés, etc. Par défaut, la vérification stricte des erreurs XSLT est activée. booléen
profile Non Indique si le profilage de feuille de style doit être activé. Cette option ne doit pas être utilisée dans les environnements de production. Par défaut, le profilage de feuille de style est désactivé. booléen
debug Non Indique si la feuille de style, le script XQuery et le script JSONiq doivent être exécutés en mode débogage. Lorsqu'une feuille de style, un script XQuery ou un script JSONiq est exécuté en mode débogage, une page Web personnalisée est générée au lieu d'afficher sa sortie standard. La page Web détaille exactement ce qu'il s'est produit lors de l'exécution, y compris les valeurs des variables et la provenance des parties spécifiques de la sortie. Cette option ne doit pas être utilisée dans les environnements de production. Par défaut, le mode débogage est désactivé. booléen
stream Non Indique si la feuille de style doit être exécutée en mode diffusion en flux. La transformation du document commence avant que la saisie ne soit entièrement analysée. Toutes les feuilles de style ne peuvent pas être diffusées en continu. Si la feuille de style ne peut pas être diffusée en continu, une erreur est générée et l'entrée n'est pas traitée. Par défaut, le mode de diffusion en continu est désactivé. booléen
try-stream Non Indique s'il faut tenter d'exécuter la feuille de style en mode diffusion en flux. La transformation du document commence avant que la saisie ne soit entièrement analysée. Toutes les feuilles de style ne peuvent pas être diffusées en continu. Si la feuille de style ne peut pas être diffusée en continu, un avertissement est généré lors de la compilation et la feuille de style est lue dans la totalité de l'entrée en mode normal au moment de l'exécution. Par défaut, la tentative d'exécution de la feuille de style en mode diffusion en continu est désactivée. booléen
minimum-escaping Non Indique si la sortie générée à partir de la feuille de style doit être mise en échappement lors du traitement. L'échappement minimal est particulièrement utile lorsque vous manipulez des jeux de caractères non anglais. Par défaut, l'échappement minimal est désactivé. booléen
stack-size Non Nombre maximal d'octets que la pile est autorisée à utiliser lors de l'exécution d'une feuille de style ou d'un autre contenu compilé. Ce paramètre permet de bloquer la récursivité infinie. La valeur minimale est 10 kilooctets, ou 10 240 octets. La valeur maximale est 100 mégaoctets ou 104 857 600 octets. La valeur par défaut est 1 mégaoctet ou 1 048 576 octets. entier
wsi-validation Non Comportement de validation à appliquer aux fichiers WSDL dont la conformité à la section 5 du profil de base WS-I est vérifiée (version 1.0, avril 2004). Le paramètre par défaut est Warn.
Ignorer
Désactive la vérification de la conformité.
Avertissement
Enregistre les avertissements relatifs aux infractions.
Échec
Impose la conformité. Échoue si le fichier contient la moindre infraction.
 chaîne
wsdl-validate-body Non Comportement de validation pour soap:Body. Le paramètre par défaut est Strict.
Stricte
Vérifie la conformité de cette partie du message avec la définition WSDL. N'autorise que les messages qui contiennent cette partie et qui correspondent à la définition WSDL.
Souple
Vérifie la conformité de cette partie du message avec la définition WSDL. Si le message contient cette partie et que la définition WSDL ne la prévoit pas, autoriser le message. Si le message contient cette partie et que la définition WSDL définit cette partie, n'autoriser le message que s'il y a correspondance.
Sauter
Désactive la validation de cette partie du message.
 chaîne
wsdl-validate-headers Non

Comportement de validation pour soap:Header. Le paramètre par défaut est Lax.

Stricte
Vérifie la conformité de cette partie du message avec la définition WSDL. N'autorise que les messages qui contiennent cette partie et qui correspondent à la définition WSDL.
Souple
Vérifie la conformité de cette partie du message avec la définition WSDL. Si le message contient cette partie et que la définition WSDL ne la prévoit pas, autoriser le message. Si le message contient cette partie et que la définition WSDL définit cette partie, n'autoriser le message que s'il y a correspondance.
Sauter
Désactive la validation de cette partie du message.
 chaîne
wsdl-validate-faults Non Indique le comportement de validation des détails de l'erreur. Le paramètre par défaut est Strict.
Stricte
Vérifie la conformité de cette partie du message avec la définition WSDL. N'autorise que les messages qui contiennent cette partie et qui correspondent à la définition WSDL.
Souple
Vérifie la conformité de cette partie du message avec la définition WSDL. Si le message contient cette partie et que la définition WSDL ne la prévoit pas, autoriser le message. Si le message contient cette partie et que la définition WSDL définit cette partie, n'autoriser le message que s'il y a correspondance.
Sauter
Désactive la validation de cette partie du message.
 chaîne
wsdl-wrapped-faults Non Indique s'il faut exiger la compatibilité avec les wrappers de type « RPC ». Par défaut, les encapsuleurs de style RPC ne sont pas obligatoires. booléen
allow-soap-enc-array Non Indique s'il faut autoriser le schéma à accepter la plupart des utilisations d'éléments avec xsi:type='SOAP-ENC:Array' cohérent avec SOAP 1.1 Section 5, même lorsque ces attributs violent la spécification de schéma XML. Normalement, l'attribut xsi:type doit nommer un type égal ou dérivé du type réel de l'élément. Pour les schémas compilés avec cette option, xsi:type est accepté spécifiquement pour le type complexe SOAP 1.1 Encoding'Array'si le type d'élément est dérivé de SOAP-ENC:Array. Il s'agit de l'inverse du cas autorisé normal. Par défaut, les éléments avec xsi:type='SOAP-ENC:Array' ne sont pas acceptés. booléen
validate-soap-enc-array Non Indique si une validation de schéma supplémentaire doit être effectuée conformément aux règles de codage de la section 5 de SOAP 1.1 . Lorsque cette option est activée, les membres des tableaux SOAP sont validés, les attributs tels que @id et @href sont autorisés même s'ils ne sont pas autorisés par le schéma, et les valeurs @href sont vérifiées pour s'assurer qu'elles possèdent un élément @id correspondant. Par défaut, la validation supplémentaire n'est pas effectuée. booléen
wildcards-ignore-xsi-type Non Indique si les éléments xs:any du schéma valident uniquement les éléments enfant par nom. La spécification de schéma XML requiert que, si un caractère générique correspond à un élément mais que cet élément n'a pas de déclaration d'élément, l'élément soit validé en fonction d'un attribut xsi:type . Cette option ignore ces attributs xsi:type . Elle doit être utilisée pour les cas tels que la validation de l'enveloppe SOAP où une étape de validation supplémentaire valide le contenu correspondant au caractère générique, éventuellement à l'aide des règles de codage SOAP 1.1. Par défaut, les attributs xsi:type ne sont pas ignorés. booléen
wsdl-strict-soap-version Non Indique si la liaison SOAP doit être strictement suivie dans le WSDL. Si cette option est activée, seuls les messages liés à SOAP 1.2 apparaissent dans les enveloppes SOAP 1.2 et seuls les messages liés à SOAP 1.1 apparaissent dans les enveloppes SOAP 1.1. Par défaut, la liaison SOAP stricte est désactivée. booléen
xacml-debug Non Indique si les stratégies XACML doivent être compilées avec des informations de débogage. Notez que les messages de débogage XACML sont également contrôlés par l'événement du journal dans la catégorie XACML. Utilisez le niveau de journalisation 'debug' pour afficher les messages de débogage XACML complets. Par défaut, les stratégies XACML ne sont pas compilées avec les informations de débogage. booléen
allow-xop-include Non Indique si le schéma ou le document WSDL accepte les messages dans lesquels le contenu binaire codé en base64 a été optimisé conformément aux spécifications MTOM/XOP. L'optimisation binaire XOP remplace les données binaires base64-encoded par un élément de référence xop:Include qui fait référence aux données binaires non codées situées dans une pièce jointe. Par défaut, les messages optimisés MTOM/XOP sont désactivés.
  • Lorsqu'elles sont désactivées, ces messages optimisés sont rejetés lors de la validation du formulaire optimisé. Le rejet se produit car le schéma spécifie un type simple qui accepte les données base64-encoded , telles que xs:base64Binary ou xs:string, mais le message contient un élément xop:Include à la place.
  • Lorsqu'il est activé, un élément xop:Include peut éventuellement apparaître à la place du contenu pour tout type simple de schéma XML qui valide les données binaires base64-encoded . L'élément xop:Include lui-même sera validé en fonction du schéma intégré dans store:///schemas/xop.xsd.
 booléen

Vous pouvez également appliquer une stratégie validate à l'aide de l'éditeur d'assemblage API Designer pour ajouter une stratégie intégrée à l'API. Pour plus d'informations, consultez la section « Validate - DataPower API Gateway » dans la partie consacrée aux stratégies intégrées.

Exemple 1

- validate:
    version: 2.0.0
    title: 'validate, response parameter schema'
    validate-against: response-param

Exemple 2

- validate:
    version: 2.0.0
    title: 'validate, predefined schema'
    validate-against: definition
    definition: '#/definitions/RouteOutput'

Exemple 2

- validate:
    version: 2.0.0
    title: 'validate, JSON and XML schema URLs'
    validate-against: url
    json-schema: 'https://my.json.schema'
    xml-validation-mode: xsd
    xml-schema: 'https://my.xml.schema'