Types de ressources de portail

Les ressources de portail sont représentées par les balises XML suivantes.

demande

La balise principale de toute requête XML. Cet élément doit toujours apparaître qu'une seule fois et entourer la requête. Vous pouvez l'utiliser pour exporter des données de version de la base de données du portail pour alimenter ultérieurement ces données dans le processus de transfert.

portail

L'élément principal de toute requête XML. Il doit toujours apparaître exactement une fois et prend uniquement en charge les actions locate (localiser) et export (exporter).

global-settings, services-settings

Paramètres des valeurs de configuration globales des portlets et des services spécifiques du portail. Ces éléments prennent uniquement en charge les actions locate et export.

Remarque : Ne modifiez pas les scripts permettant d'exporter et de mettre à jour ces paramètres. Ne modifiez pas manuellement les valeurs présentes dans les scripts XML : cette action pourrait aboutir à une configuration de portail non valide. Pour modifier ces paramètres, utilisez les portlets d'administration appropriés après la mise à jour XML d'une configuration.

langue

Utilisez cette balise pour ajouter des langues à la liste de langues prises en charge définies dans le portail ou en supprimer de la liste. Utilisez l'attribut suivant pour les langues bidirectionnelles.

bidi: Pour les langues bidirectionnelles, attribuez la valeur true à cet attribut.

tâche

Planifie le nettoyage des ressources de portail et l'administration des balises fédérées. Cleanup se réfère à la suppression des pages du portail et de toutes les ressources dépendantes de ces pages qui sont marquées comme destinées à être supprimées. Indiquez une ou plusieurs tâches à exécuter immédiatement ou à des intervalles spécifiés. Les paramètres d'intervalle de planification dayOfMonth et dayOfWeek sont facultatigs et s'excluent mutuellement. Chaque paramètre d'intervalle de planification exige de fournir une valeur pour le paramètre startTime. Si vous désirez lancer une tâche quotidiennement, utilisez seulement le paramètre startTime.

nom

Spécifie la tâche planifiée à exécuter :

com.ibm.portal.datastore.task.ResourceCleanup: Cette tâche nettoie les ressources du portail. Si vous spécifiez cette tâche sans paramètre d'intervalle de planification, le nettoyage des ressources du portail est effectué immédiatement lorsque vous lancez le script XML.
com.ibm.portal.cp.SynchronizationTask: Cette tâche synchronise les données collaboratives comportant des informations de catégorisation de balise fournies par les balises Web Content Manager. Si vous spécifiez cette tâche sans paramètre d'intervalle de planification, le portail effectue immédiatement un nettoyage des ressources lorsque vous lancez le script XML.
com.ibm.portal.services.RefreshIWidgetDefinitionsTask: Cette tâche régénère les définitions d'iWidget stockées dans HCL Portal. La régénération des définitions d'iWidget recharge les fichiers XML de définition d'iWidget et met à jour les clones du portlet iWidget Wrapper avec les nouvelles définitions.
Conseil : Pour appeler cette tâche directement, exécutez la tâche de configuration de portail suivante : refresh-iwidget-definitions. Pour obtenir les instructions correspondantes, voir la rubrique Tâche refresh-iwidget-definitions.
com.ibm.portal.cmis.TransientSlotCleanupTask: Cette tâche supprime les emplacements de coffre de données d'identification temporaires créés par l'assistant des documents fédérés et non utilisés pendant au moins 3 heures.
com.ibm.wps.cp.tagging.federation.taskhandler.FederationTaskHandler: Cette tâche extrait les balises et les données associées en provenance de fournisseurs de balises fédérées. HCL Connections est un exemple de fournisseur de balisage fédéré.
com.ibm.wps.cp.tagging.federation.taskhandler.FederationDeleteTaskHandler: Cette tâche supprime les balises fédérées et les données associées d'HCL Portal. Il est recommandé de démarrer cette tâche lorsque la fédération des tâches n'est plus requise.

dayOfMonth

Si vous désirez effectuer cette tâche mensuellement, spécifiez un nombre compris entre 1 et 31. Si le nombre que vous indiquez est supérieur à celui du dernier jour du mois, le nettoyage est effectué le dernier jour du mois. Par exemple, en spécifiant la valeur 31, la tâche sera réalisée le 31 janvier, le dernier jour de février, le 31 mars, le 30 avril, et ainsi de suite.

dayOfWeek

Si vous désirez effectuer cette tâche sur une base hebdomadaire, spécifiez un nombre compris entre 1 et 7, où 1 correspond à lundi et 7 à dimanche.

startTime

Si vous avez spécifié un intervalle de planification dayOfMonth ou dayOfWeek, vous devez indiquer l'heure à laquelle la tâche doit débuter. Utilisez le format HH:MM pour spécifier une valeur de 0:00 à 23:59. Vous n'avez pas besoin d'inclure des zéros à gauche. Indiquez, par exemple, 4:45. Pour exécuter la tâche quotidiennement, utilisez uniquement ce paramètre ; n'utilisez pas les paramètres dayOfMonth ou dayOfWeek.

L'exemple Task.xml illustre comment planifier le nettoyage des ressources du portail.

Notes :

Lorsque vous supprimez une page avec un ID d'objet, et re-créez la même page à l'aide de l'interface de configuration XML. Si vous utilisez le même ID d'objet, vous pouvez recevoir un message d'erreur. Le message d'erreur indique que l'opération a été annulée parce que ces actions ont créé une valeur de clé en double.
Lorsque vous lancez une tâche de nettoyage, l'interface de configuration XML planifie seulement cette tâche pour son exécution dans IBM® WebSphere® Application Server. Cette action ne signifie pas nécessairement que WebSphere® Application Server exécute la tâche immédiatement. Pour déterminer à quel moment une tâche a débuté ou s'est achevée, vérifiez les messages EJPDE0005I et JPDE0006I dans le journal SystemOut.log du portail. Ces messages confirment l'aboutissement de la tâche. Après avoir obtenu la confirmation de l'exécution de la tâche, vous pouvez lancer le script XML pour recréer une page avec le même ID objet qu'avant sa suppression.

action

Cette balise permet de définir l'action requise. Pour plus d'informations sur les actions, voir la rubrique Actions sur les ressources de portail.

virtual-resource

Les ressources virtuelles dans le sous-système de contrôle d'accès. Les ressources virtuelles sont associées à des définitions de contrôle d'accès, mais ne sont pas représentées par ailleurs dans le portail. La ressource virtuelle PORTLET_APPLICATIONS, par exemple, vous permet de donner aux utilisateurs un accès à tous les portlets installés, mais ne correspond pas à un portlet réel. L'élément virtual resource prend uniquement en charge les actions update (mise à jour) et export (exportation).

user

Les utilisateurs présents dans le référentiel des utilisateurs du portail. Les définitions comprennent leurs propriétés, par exemple la langue préférée de l'utilisateur, ainsi que les paramètres de contrôle d'accès au portail qui s'appliquent aux utilisateurs, par exemple qui est autorisé à les administrer. L'interface de configuration XML permet de définir le mot de passe pour un utilisateur, mais n'exporte pas le mot de passe. L'attribut mot de passe est requis pour créer de nouveaux utilisateurs. Par conséquent, vous ne pouvez pas utiliser directement le fichier de réponse d'une requête d'exportation XML pour créer de nouveaux utilisateurs : il faut d'abord ajouter un attribut mot de passe au fichier XML.

Vous pouvez spécifier l'attribut de nom des utilisateurs et des groupes par un nom distinctif (DN) complet, comme dans l'exemple uid=wpsadmin,cn=users,.... Vous pouvez spécifier l'attribut de nom par un ID abrégé tel qu'il est utilisé pour la connexion au portail, par exemple wpsadmin. Un fichier de réponse XML provenant d'une requête d'exportation de portail contient toujours des noms absolus complets.

En ce qui concerne la balise user, il existe deux cas particuliers dans lesquels vous devez spécifier des attributs particuliers, en fonction de la tâche à effectuer :

Exportation d'utilisateurs et de groupes
Suppression d'utilisateurs et de groupes du portail.

Ces deux cas de figure sont décrits dans les sections suivantes.

Exportation d'utilisateurs et de groupes : une exportation complète du portail ne comprend pas normalement les informations relatives aux utilisateurs et aux groupes ; ces informations ne sont incluses que si vous spécifiez explicitement dans votre requête XML que l'utilisateur doit être exporté. Si vous souhaitez exporter l'ensemble des informations relatives aux utilisateurs et aux groupes, définissez l'indicateur export-users de la balise de requête principale sur true comme suit :

      <request . . . export-users="true" . . .>

Si vous souhaitez exporter des groupes sans inclure les membres, définissez l'indicateur export-users sur la valeur no-member.

Notes :

La recherche d'utilisateurs et de groupes est une tâche qui demande du temps. Elle peut dépasser le délai d'expiration ou retourner plus de résultats que le système ne peut en gérer ou que l'utilisateur ne peut en attendre. Pour éviter ce problème, vous pouvez limiter les recherches d'utilisateurs ou de groupes en définissant un délai d'expiration ou un nombre maximum de résultats.

Les valeurs de certains attributs de la balise user correspondent à des paramètres présents dans les balises parameter incluses. Si vous décrivez les deux dans votre requête d'exportation, mais spécifiez des valeurs différentes pour ces paramètres, la valeur définie par la balise parameter se substitue à celle définie par l'attribut et est exportée en tant qu'attribut. Les valeurs des attributs de la balise user correspondent aux balises parameter incluses comme suit :

Tableau 1. Balise user : attributs correspondants et balises parameter incluses
Attribut	Balise `parameter` avec `name=" "`	Commentaires
`firstname`	`givenName`
`lastname`	`sn`
`nom`	`uid`
`n/a`	`cn`	Il s'agit d'une balise de paramètre obligatoire pour représenter l'attribut LDAP.

Exemple : Vous pouvez définir le prénom d'un utilisateur lors de la création à l'aide de l'attribut firstname ou de la balise parameter avec l'attribut givenName. Si vous utilisez les deux et spécifiez deux noms différents, la valeur spécifiée dans givenName est exportée en tant qu'attribut firstname. Exemple de requête d'exportation XML :


<?xml version="1.0" encoding="UTF-8"?>
<!-- Description of this command file: Create 1 users -->
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_8.5.0.xsd" 
         type="update" create-oids="true">
     <portal action="locate">
         <user action="update" firstname="John_1" password="password" 
               lastname="Miller" name="John's name">
             <description>John Miller</description>
             <parameter name="cn" type="string" update="set">John Miller</parameter> 
             <parameter name="givenName" type="string" update="set">John_2</parameter>
         </user>
     </portal>
</request>

Cette requête définit la valeur John_2 pour l'attribut firstname.

Sur certains serveurs LDAP, où cn fait partie du nom distinctif, vous ne pourrez peut-être pas mettre à jour cn.

Suppression d'utilisateurs et de groupes du portail : Si des utilisateurs ou des groupes du portail sont supprimés du registre d'utilisateurs mais pas de la base de données du portail, ou si des utilisateurs sont mis en sommeil, par exemple, après un trop grand nombre de tentatives avec un mot de passe erroné, vous pouvez exporter ces utilisateurs et ces groupes pour une suppression ultérieure. Vous pouvez les supprimer ultérieurement à l'aide de l'attribut cleanup-users avec la balise request. Pour exporter ces utilisateurs et ces groupes, définissez l'indicateur cleanup-users de la balise de requête principale sur true comme suit :

      <request . . . cleanup-users="true" . . .>

Si vous définissez cette propriété sur true, tous les utilisateurs et les groupes qui ne sont plus présents dans le référentiel d'utilisateurs configuré, par exemple LDAP, sont exportés avec leur ensemble d'actions vers delete. Vous devez également définir l'attribut export-users sur true.

Avant de réimporter le fichier, vous devez examiner et modifier le fichier de résultat et supprimer tous les utilisateurs et les groupes que vous souhaitez conserver dans la base de données du portail. Lors de l'importation XML, tous les utilisateurs et les groupes restant répertoriés dans le fichier sont supprimés de la base de données du portail.

Remarque : Après la suppression de ces entrées avec le script XML modifié, toute la personnalisation est perdue pour les utilisateurs et les groupes supprimés.

Le fichier XML CleanupUsers.xml est un exemple d'exportation d'utilisateurs et de groupes.

groupe

Groupes présents dans la base de données des utilisateurs du portail. Les définitions comprennent les paramètres de contrôle d'accès au portail et les informations relatives aux membres, par exemple quels utilisateurs appartiennent au groupe. Pour plus d'informations sur la gestion des groupes dans XML, consultez l'utilisateur de balise précédent.

balisage

Définition des types de mise à jour prises en charge par les pages du portail.

client

Définition des périphériques clients, de la manière dont ils sont détectés et des mises à jour et caractéristiques qu'ils prennent en charge.

device-class

Définition d'une classe d'unités.

habillage

Décrit l'apparence visuelle, par exemple la bordure des éléments individuels de l'interface utilisateurs ou des portlets sur une page. Il est possible d'attribuer des habillages aux noeuds de contenu et aux composants.

modulaire

Décrit les propriétés de base, par exemple les couleurs et le type de police, de l'apparence de tout un groupe de pages. Les thèmes peuvent restreindre la sélection des habillages possibles sur les pages associées. Les thèmes peuvent être attribués à des noeuds de contenu.

wsrp-producer

wsrp-producer est la définition du Producteur des services Web pour portlets distants (WSRP, Web Services for Remote Portlets) du côté Consommateur. Cette définition permet à un administrateur d'utiliser et d'intégrer les portlets distants fournis par le Producteur WSRP.

Une fois que vous avez intégré un service WSRP, le portail le gère comme un portlet local classique. Vous pouvez par exemple ajouter le portlet à des pages.

web-app

Modules Web correspondant à un fichier WAR déployé. Pour les utiliser dans le portail, vous devez définir une ou plusieurs applications de portlets concrets décrivant des paramètres spécifiques. Dans un descripteur de déploiement portlet.xml, cet élément correspond à la balise portlet-app.

Les modules Web pour portlets conformes à l'API standard ne peuvent contenir qu'une application de portlet, alors que les modules Web pour portlets conformes à l'API HCL peuvent contenir plusieurs applications de portlets. Pour les portlets d'API HCL, l'attribut uid doit correspondre à l'attribut uid défini dans le descripteur de déploiement.

Remarque : Les portlets d'API HCL sont obsolètes depuis la version 7.0 d'HCL Portal, mais sont toujours pris en charge.

Pour les portlets standard, l'attribut uid doit être construit par l'attribut id du sous-élément portlet-app et d'un suffixe .webmod. Si l'attribut id n'est pas défini, l'attribut uid est construit par le nom de fichier WAR et un suffixe .webmod. Exemple :

    <web-app action="update" active="true" removable="true" uid="jsr_bookmarks_id001a.webmod"> 
         . . . . .
    <portlet-app action="update" active="true" uid="jsr_bookmarks_id001a">

Selon l'emplacement du chemin de vos fichiers WAR, les fichiers WAR exportés précédemment peuvent ne pas être trouvés au cours de l'importation XML en raison d'informations de chemin erronées. Pour plus de détails sur l'utilisation de la sous-balise <url> avec la balise <web-app>, voir la rubrique Importation de fichiers WAR.

servlet

Servlets définis dans le module Web. Ils sont créés dans le cadre du déploiement du fichier WAR et ne peuvent pas être créés ou supprimés explicitement ; par conséquent, les actions create (création) et delete (suppression) ne sont pas prises en charge. Dans un descripteur de déploiement portlet.xml standard, cet élément correspond à la balise portlet. Dans un descripteur de déploiement HCL portlet.xml, un servlet est créé pour chaque balise concrete-portlet.

portlet-app

Applications de portlet présentes dans un module Web et contenant des paramètres spécifiques. Les applications et les portlets qu'elles contiennent sont généralement définis dans le fichier WAR du module Web et sont créés par le portail au cours du déploiement. Pour les portlets conformes à l'API HCL, cet élément correspond à la balise concrete-portlet-app du descripteur de déploiement du portlet.

Pour les portlets compatibles standard, l'attribut uid doit correspondre à l'attribut id de l'élément portlet-app défini dans le descripteur de déploiement. Si l'attribut id n'est pas défini dans le descripteur de déploiement, spécifiez le nom du fichier WAR.

Lorsque l'application est utilisée dans un contexte WSRP, les portlets présents dans l'application sont définis à distance et peuvent être intégrés à l'aide de l'interface de configuration XML. Dans ce cas, les applications de portlets doivent définir un attribut groupid.

Une fois que vous avez déployé un fichier WAR localement ou intégré un fichier WAR en tant que service WSRP, vous pouvez aussi créer des applications de portlet supplémentaires (ainsi que les portlets qu'elles contiennent) avec des paramètres différents. Cette action est également appelée copie ou clonage des applications de portlet.

portlet

Les portlets qui peuvent être placés dans une page et contiennent des paramètres spécifiques. Normalement, les portlets sont définis dans le fichier WAR du module Web et créés par le portail au cours du déploiement. Si les portlets qui se trouvent dans le module Web sont utilisés dans un contexte WSRP, ils sont définis à distance et intégrés par l'interface de configuration XML. Dans ce cas, les applications de portlets doivent définir un attribut handle. Un nouvel indicateur, provided (fourni), est créé afin de fournir et de les retirer sur appel distant.

Lorsque vous créez un nouveau portlet dans une application supplémentaire, il doit faire référence à l'un des servlets définis dans le module Web. Dans un descripteur de déploiement portlet.xml, cet élément correspond à la balise concrete-portlet.

Remarque : Si vous rédigez des portlets conformes à l'API standard, vous ne devez pas utiliser la balise parameter pour ajouter des paramètres ; utilisez plutôt la balise preferences.

content-node

Un élément de la hiérarchie de contenu du portail. Le portail prend en charge plusieurs types de noeuds de contenu :

Une page est un noeud de contenu constitué d'éléments de mise en page intégrés et qui affiche les portlets.
Une balise est un noeud de contenu qui sert à organiser la hiérarchie de contenu, mais n'affiche pas les portlets.
Une page statique est un noeud de contenu qui comprend un fichier HTML statique ou un fragment HTML.
Une URL interne est un noeud de contenu qui pointe vers d'autres éléments du portail via une URL de référence.
Une URL externe est un noeud de contenu qui pointe vers une page Web extérieure au portail.

Tous les noeuds de contenu du portail sont organisés de manière hiérarchique ; à la racine de cette hiérarchie se trouve le noeud de contenu spécial wps.content.root. Un nœud de contenu de type page peut être dérivé d'un autre nœud de contenu parent, afin de remplacer partiellement ou de développer la mise en page de son parent. Le portail et le portlet permettant de travailler sur les pages affichent toujours un ensemble comprenant une couche de composition et tous ses ancêtres. Mais l'interface de configuration XML doit gérer chaque couche séparément.

Remarque : Il est recommandé de toujours exporter et remplacer une pile entière de couches de pages et de not utiliser les requêtes XML pour modifier les composants de mise en page individuels ou les couches de pages dérivées. N'essayez pas en particulier de créer manuellement des scripts XML pour la définition des pages dérivées, car la structure de référence est complexe. Utilisez de préférence le portlet de Travail avec les pages pour modifier la mise en page, puis exportez le résultat dans un fichier de réponse XML.

composant

Un composant de mise en page. Le portail prend en charge deux types de composants :

Un conteneur est une ligne ou une colonne qui rassemble les conteneurs enfants.
Un composant de contrôle contient une instance de portlet.

Si vous mettez à jour une page existante à l'aide d'un script XML et que ce script spécifie les composants de la page, l'attribut layout-processing de cette page définit la manière dont ces nouveaux composants interagissent avec la mise en page existante.

portletinstance

Une occurrence individuelle d'un portlet dans une page. L'instance de portlet comprend les données de portlet définies par l'utilisateur à l'aide du mode d'édition du portlet.

Remarque :

Une instance de portlet est toujours contenue dans un composant de type control ; la suppression d'une instance de portlet supprime automatiquement le composant dans lequel le portlet se trouvait.
Les instances de portlets compatibles API de portlet standard ne doivent pas utiliser la balise parameter pour ajouter des paramètres ; elles doivent plutôt utiliser la balise preferences.

Pour le contenu personnalisé, dans lequel seuls des paramètres de portlet, mais pas la structure de page sont modifiés, utilisez les attributs suivants avec la balise portletinstance :

propriétaire: Cet attribut permet de définir le propriétaire de l'instance de portlet.
parentref: Cet attribut permet de définir le parent de l'instance de portlet.

cross-page-wire

Représente un courtier de propriété établissant une connexion entre deux instances de portlet, soit sur la même page, soit sur des pages différentes. Une connexion relie une instance de portlet source à une instance cible, de sorte que les valeurs modifiées dans la source soient propagées vers la cible. Cette balise possède source-pageref et target-pageref comme seuls attributs supplémentaires à la balise de connexion. Lorsque vous exportez une page avec des connexions entre pages actives, la balise cross-page-wire est exportée même en l'absence de référence directe vers ou depuis la page ou la connexion.

Remarque : Une connexion ne peut être créée que si les noeuds finals de connexion des portlets correspondants existent. Les portlets existants non conformes à JSR 168 ou 286 peuvent créer ces noeuds finals via une programmation sur leur premier rendu. Par conséquent, l'interface de configuration XML ne peut pas créer une nouvelle connexion pour ces portlets sauf s'ils ont déjà été rendus. Pour créer cette connexion, affichez tout d'abord la page contenant le portlet à l'aide d'un navigateur Web, puis créez la connexion à l'aide de l'interface de configuration XML.

wire

Représente un courtier de propriété établissant une connexion entre deux instances de portlet sur une page. Une connexion relie une instance de portlet source à une instance cible, de sorte que les valeurs qui changent dans la source sont propagées vers la cible.

Notes :

La balise wire est devenue obsolète avec la version 7.0 d'HCL Portal, car elle prend en charge uniquement une connexion de courtier de propriété entre deux portlets sur la même page. Utilisez la balise cross-page-wire car elle prend en charge une connexion de courtier de propriété entre portlets sur la même page et sur des pages différentes.
Une connexion ne peut être créée que si les noeuds finals de connexion des portlets correspondants existent. Les portlets existants non conformes à JSR 168 ou 286 peuvent créer ces noeuds finals via une programmation sur leur premier rendu. Par conséquent, l'interface de configuration XML ne peut pas créer une nouvelle connexion pour ces portlets sauf s'ils ont déjà été rendus. Pour créer cette connexion, affichez tout d'abord la page contenant le portlet à l'aide d'un navigateur Web, puis créez la connexion à l'aide de l'interface de configuration XML.

credential-segment

Regroupe une collection d'entrées d'identification pour un magasin d'identification central spécifique (le coffre). La configuration des segments d'identification ne peut pas être modifiée après leur création.

credential-slot

Une entrée d'identification unique décrivant les informations requises pour se connecter à une ressource protégée extérieure au portail. L'interface de configuration XML couvre uniquement la définition du logement d'identification. Le droit d'accès réel, par exemple le mot de passe pour une application, est enregistré dans le stock d'informations d'identification dorsal. Il peut être défini ou mis à jour, mais pas exporté à l'aide de l'interface de configuration XML.

Pour plus d'informations sur la définition de données d'identification utilisateur à l'aide de l'interface de configuration XML, reportez-vous à l'exemple de fichier XML UpdateVault.xml fourni avec le portail.

url-mapping-context

Cette balise permet de définir des espaces URL arbitraires mappant vers le contenu de portail.

user-resources

Cette balise permet d'effectuer des exportations ou de supprimer des actions pour des utilisateurs spécifiques.

policy-node

Cette balise permet de définir des espaces URL arbitraires mappant vers le contenu de portail. Lorsque vous utilisez l'interface de configuration XML pour gérer des stratégies, certaines limitations s'appliquent.

application-role

Cette balise permet de définir un rôle composé qui associe plusieurs rôles d'autorisation et qui est spécifique à un ensemble d'utilisateurs.

Les balises et attributs suivants sont réservés à l'usage interne du portail. Si vous les rencontrez dans un script d'exportation XML que vous souhaitez utiliser pour une mise à jour ultérieure, ne modifiez d'aucune façon ces balises ou leur contenu.

action-set: Cette balise est destinée exclusivement à l'usage interne du portail.
category: Cette balise est destinée exclusivement à l'usage interne du portail.
federation-server: Cette balise est destinée exclusivement à l'usage interne du portail.
protected-resource: Cette balise est destinée exclusivement à l'usage interne du portail.
resource-type: Cette balise est destinée exclusivement à l'usage interne du portail.
transformation: Cette balise est destinée exclusivement à l'usage interne du portail.
transformation-app: Cette balise est destinée exclusivement à l'usage interne du portail.
transformationinstance: Cette balise est destinée exclusivement à l'usage interne du portail.
serverref: serverref est un attribut de la balise content-node ; il est destiné exclusivement à l'usage interne du portail.

contenu: Cette balise est destinée exclusivement à l'usage interne du portail.
supported-processing-event: Cette balise est destinée exclusivement à l'usage interne du portail.
supported-publishing-event: Cette balise est destinée exclusivement à l'usage interne du portail.
qname: Cette balise est destinée exclusivement à l'usage interne du portail.
alias: Cette balise est destinée exclusivement à l'usage interne du portail.
class-name: Cette balise est destinée exclusivement à l'usage interne du portail.

Les balises suivantes sont disponibles pour les ressources de portail à des fins de balisage et d'évaluation : tag, rating, custom-resource et category-instance. Pour plus d'informations sur ces balises, reportez-vous à la rubrique Utilisation de l'interface de configuration XML pour administrer les étiquettes et évaluations.

L'interface de configuration XML gère uniquement les ressources du cœur du portail et pas celles des composants supplémentaires, tels que Portal Personalization.