Présentation des conventions de protocole de gestion XML et NETCONF
Une application client doit respecter les conventions de protocole de gestion XML et NETCONF des protocoles de gestion XML. Chaque demande d’application client doit être un document XML bien formé. autrement dit, il doit se délérer aux règles qui sont définies dans les définitions de type de document (DTD) NETCONF et XML de Junos pour le type d’informations encodées dans la requête. L’application client doit émettre des étiquettes dans l’ordre requis et uniquement dans les contextes juridiques. Les applications conformes sont plus faciles à gérer en cas de modification du protocole Junos OS NETCONF.
De même, chaque réponse du serveur NETCONF constitue un document XML bien formé (le serveur NETCONF défie les conventions XML et NETCONF).
Les sections suivantes décrivent les conventions de protocole de gestion XML NETCONF:
Éléments de balise de demande et de réponse
Un élément de balise de demande est généré par une application client pour demander des informations sur l’état ou la configuration actuel d’un équipement, ou pour modifier la configuration. Un élément de balise de demande correspond à une commande CLI opération ou de configuration. Cela ne peut se produire qu’au sein <rpc> d’une balise. Pour plus d’informations <rpc> sur l’élément, consultez la requête Envoyer des requêtes au serveur NETCONF.
Un élément de balise de réponse représente la réponse du serveur NETCONF à un élément de balise de demande et ne se produit qu’au sein d’une <rpc-reply> balise. Pour plus d’informations <rpc-reply> sur l’élément, consultez le site Parse the NETCONF Server Response.
L’exemple suivant représente un échange au cours duquel une application client émet le tag de demande avec l’indicateur et le serveur NETCONF renvoie l’élément <get-interface-information> <extensive/> de balise de <interface-information> réponse.
Client Application
<rpc>
<get-interface-information>
<extensive/>
</get-interface-information>
</rpc>
]]>]]>
Serveur NETCONF
<rpc-reply xmlns="URN" xmlns:junos="URL">
<interface-information xmlns="URL">
<!-- children of <interface-information> -->
</interface-information>
</rpc-reply>
]]>]]>
Cet exemple, comme tous les autres dans ce guide, montre chaque élément de balise sur une ligne distincte, dans les flux de balises émis par l’application client et le serveur NETCONF. En pratique, une application client n’a pas besoin d’inclure de nouveaux caractères de ligne entre les éléments de la balise, car le serveur écarte automatiquement cet espace blanc. Pour en savoir plus, consultez Espaces, nouveaux caractères et autres espaces blancs.
Pour plus d’informations sur les attributs de la balise d’ouverture, consultez Parse la réponse au serveur <rpc-reply> NETCONF. Pour plus d’informations sur l’attribut de la balise ouvrante, consultez la requête d’informations opérationnelles xmlns <interface-information> utilisation de NETCONF. Pour plus d’informations sur la ]]>]]> séquence de caractères, consultez « Generate Well-Formed XML Documents» (Générer des documents XML bien formés).
Éléments de balise pour enfants d’un élément de balise de demande
Certains éléments de la balise de demande contiennent des éléments de balises pour enfants. Pour les demandes de configuration, chaque élément de balise d’enfant représente un élément de configuration (niveau hiérarchique ou objet de configuration). Pour les requêtes opérationnelles, chaque élément de balise pour enfants représente l’une des options que vous fournissez sur la ligne de commande lors de l’émission de la CLI de commande équivalente.
Certaines demandes ont des éléments de balise enfants obligatoires. Pour réussir la demande, une application client doit émettre la balise obligatoire dans l’ouverture et la fermeture du tag de la balise de demande. Si l’un des enfants est lui-même des éléments de balise de conteneur, la balise d’ouverture de chaque tag doit se produire avant l’un des éléments de la balise qu’il contient, et la balise de clôture doit se produire avant l’ouverture de la balise pour un autre élément de balise au niveau de la hiérarchie.
Dans la plupart des cas, l’application client peut émettre des enfants au même niveau, n’importe quel ordre, au sein d’un container. L’exception importante est un élément de configuration qui dispose d’un élément de balise d’identification, qui distingue l’élément de configuration des autres éléments de son type. L’élément de la balise d’identification doit être le premier élément de balise pour enfants dans l’élément de balise de conteneur. Le plus souvent, l’élément de balise d’identification spécifie le nom de l’élément de configuration et s’appelle <name> . Pour plus d’informations, consultez la fonction Mapping for Objects That Have An Identifier.
Éléments de balise pour enfants d’un élément de balise de réponse
Les éléments de balise d’enfant d’un élément de balise de réponse représentent les éléments de données individuels renvoyés par le serveur NETCONF pour une demande particulière. Les enfants peuvent être des éléments de balise individuels (balises vides ou triples de l’élément de balise) ou des éléments de balise de conteneur qui joint leurs propres éléments de balise d’enfant. Pour certains éléments de balise de conteneur, le serveur NETCONF renvoie les enfants par ordre alphabétique. Pour d’autres éléments, les enfants apparaissent dans l’ordre dans lequel ils ont été créés dans la configuration.
L’ensemble d’éléments de balise pour enfants qui peuvent se produire en réponse ou au sein d’un élément de balise de conteneur est sujet à changer dans les version ultérieures de l’API XML Junos. Les applications client ne doivent pas se reposer sur la présence ou l’absence d’un élément de balise particulier dans le résultat du serveur NETCONF, ni sur la commande d’éléments de balises enfant au sein d’un élément de balise de réponse. Pour une utilisation plus robuste, inclure la logique dans l’application client qui gère au mieux l’absence d’éléments de balise attendus ou la présence de éléments imprévus.
Espaces, nouveaux caractères et autres espaces blancs
Comme dictée par la spécification XML, le serveur NETCONF ignore l’espace blanc (espaces, onglets, caractères nouvelle ligne et autres caractères représentant l’espace blanc) qui se produit entre les éléments de balise du flux de balises générés par l’application client. Les applications client peuvent inclure un espace blanc entre les tags, mais pas nécessairement. Toutefois, elles ne doivent pas insérer d’espace blanc dans une balise ouvrante ou fermant. S’ils incluent un espace blanc dans le contenu d’un élément de balise qu’ils soumettent sous la forme d’une modification à la configuration du candidat, le serveur NETCONF conserve l’espace blanc dans la base de données de configuration.
Dans ses réponses, le serveur NETCONF inclut un espace blanc entre les éléments de la balise afin d’améliorer la lecture des réponses enregistrées dans un fichier: il utilise des caractères nouveaux pour placer chaque tag sur sa propre ligne, et des espaces pour indentifier les éléments de balises enfant à droite par rapport à leurs parents. Une application client peut ignorer ou écarter l’espace blanc, notamment si elle ne stocke pas les réponses pour être ensuite réentassée par les utilisateurs humains. Toutefois, elle ne doit pas dépendre de la présence ou de l’absence d’espace blanc à un emplacement particulier lors de l’utilisation du flux de balises.
Pour plus d’informations sur l’espace blanc dans les documents XML, consultez la spécification XML du World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, à http://www.w3.org/TR/REC-xml/ .
Commentaires XML
Les applications client et le serveur NETCONF peuvent insérer des commentaires XML à tout moment entre les éléments de balise du flux de balise qu’ils génèrent, mais pas au sein des éléments de balise. Les applications client doivent gérer les commentaires en sortie depuis le serveur NETCONF avec élégance, mais ne doivent pas dépendre de leur contenu. Les applications client ne peuvent pas non plus utiliser les commentaires pour transmettre des informations au serveur NETCONF, car le serveur rejette automatiquement tout commentaire qu’il reçoit.
Les commentaires XML sont inclus dans les chaînes et ne peuvent contenir <!-- --> la chaîne -- (deux traits d’union). Pour plus d’informations sur les commentaires, consultez la spécification XML à l’http://www.w3.org/TR/REC-xml/ .
Voici un exemple de commentaire XML:
<!-- This is a comment. Please ignore it. -->
Références d’entités prédéfines
Selon la convention XML, il existe deux contextes dans lesquels certains caractères ne peuvent pas apparaître dans leur forme régulière:
Dans la chaîne qui s’affiche entre l’ouverture et la fermeture des balises (le contenu de l’élément de la balise)
Dans la valeur de chaîne attribuée à un attribut d’une balise ouvrante
Lorsqu’elles inséquisent un caractère désamorcé dans l’un ou l’autre contexte, les applications client doivent remplacer la référence équivalente de l’entité prédéfini, c’est-à-dire une chaîne de caractères représentant le caractère dévolré. Étant donné que le serveur NETCONF utilise les mêmes références d’entité prédéfinissent dans ses éléments de balise de réponse, l’application client doit être en mesure de les convertir en caractères réels lors du traitement des éléments de la balise de réponse.
Le Tableau 1 résume le mappage entre les caractères désinvolqués et les références d’entités prédéfines pour les chaînes qui apparaissent entre les balises d’ouverture et de fermeture d’un élément de balise.
Caractère non-dévolé |
Référence prédéfinée des entités |
|---|---|
& (et) |
et |
>(supérieur au signe) |
> |
< (moins que signe) |
< |
Le tableau 2 résume le mappage entre les caractères désinvolqués et les références d’entités prédéfines pour les valeurs d’attributs.
Caractère non-dévolé |
Référence prédéfinée des entités |
|---|---|
& (et) |
et |
« (apostrophe) |
' |
>(supérieur au signe) |
> |
< (moins que signe) |
< |
« (guillemet) |
" |
Par exemple, imaginons que la chaîne suivante est la valeur contenue par le <condition> tag:
if (a<b && b>c) return "Peer’s not responding"
Le tag apparaît sur deux lignes pour une plus haute <condition> compatibilité:
<condition>if (a<b && b>c) return "Peer’s not \
responding"</condition>
De même, si la valeur de l’attribut du tag est , la balise <example> d’ouverture heading ressemble Peer’s "age" <> 40 à celle-ci:
<example heading="Peer's "age" <> 40">