Conseils et astuces pour l'utilisation de WSRP avec le portail
Voici quelques conseils et astuces relatifs à l'utilisation de WSRP avec HCL Digital Experience.
Consommation de portlets distants avec votre portail
- com.ibm.ws.websvcs.useMultipleSetCookie = true
- Cette propriété permet d'activer le consommateur WSRP pour le traitement de plusieurs en-têtes Set-Cookie contenus dans une réponse WSRP.
Pour définir cette propriété JVM, utilisez WebSphere® Integrated Solutions Console. Une fois que vous avez défini cette propriété JVM, redémarrez votre serveur de portail.
Consommation de portlets distants à partir d'HCL WSRP Producer for WebSphere® Application Server
Si vous utilisez HCL version 8.5 pour consommer des portlets distants à partir d'un produit HCL WSRP Producer for WebSphere® Application Server que vous possédez, utilisez la mise à jour de ce système datant de juillet 2015. Si la version de producteur dont vous disposez est antérieure, mettez à jour le producteur vers la mise à jour de juillet 2015.
La consommation de portlets distants à partir d'une version antérieure d'HCL WSRP Producer for WebSphere® Application Server peut ne pas fonctionner correctement dans des environnements et des scénarios individuels.
Enregistrement
WSRP Producer for HCL Digital Experience ne prend pas en charge l'interface d'enregistrement WSRP.
Portlets distants sur des pages non authentifiées
Si vous ajoutez des portlets distants à des pages non authentifiées pour lesquelles les sessions publiques sont désactivées, les conséquences sont les suivantes :
- Les données de session sont perdues pour chaque requête.
- Une requête supplémentaire est soumise au Producteur pour établir une session.
Si vous ajoutez des portlets distants à des pages non authentifiées, activez les sessions publiques. Vous bénéficierez ainsi pleinement des performances du portail et évitez les comportements imprévus résultant de la perte des données de session.
Affichage des URL pour les formulaires
La soumission de données à un portlet via des formulaires est désignée par le terme action, dans la mesure où cette demande modifie l'état du portlet. WSRP applique strictement la séparation des demandes action et render en fonction de la sémantique correspondante. Il empêche la soumission de données de formulaire via des demandes render. Par conséquent, les portlets qui utilisent des URL render pour soumettre des données de formulaire ne fonctionnent pas à distance.
Les portlets ne peuvent pas utiliser les fonctions internes de portail
Avec le WSRP, vous ne pouvez pas utiliser les fonctions internes du portail dans des portlets, par exemple les objets machine ou les balises machine. Les portlets utilisant ces fonctions internes ne fonctionnent pas à distance, dans la mesure où le WSRP ne fournit pas l'infrastructure requise pour l'utilisation des fonctions internes de portail par les portlets.
Compatibilité des portlets avec WSRP
- Certains portlets fournis avec HCL ne peuvent pas être fournis en tant que services WSRP.
- Des concepts et fonctions supplémentaires et plus avancés HCL ne figurent pas encore dans le standard WSRP. Ce groupe inclut tous les portlets d'administration de portail, les portlets de recherche de portail, Gestion de la recherche et Centre de recherche, ainsi que certains autres portlets qui sont fournis avec le portail.
- Si des portlets contiennent des URL vers d'autres ressources, les URL doivent être codées en fonction de la spécification des portlets Java pour qu'ils fonctionnent avec WSRP.
- Vous pouvez disposer de portlets qui gèrent des ressources ou permettent d'accéder à des ressources, telles que des images, des fichiers CSS, des fichiers JavaScript ou des servlets fournis avec le portlet. Pour travailler dans un environnement distribué tel que WSRP, ces portlets doivent gérer les URL correctement. L'environnement d'exécution du Producteur WSRP HCL se connecte au code de génération d'URL utilisé par les API JPS (Java Portlet Specification). Dans ce cas, le portail peut générer des URL compatibles avec WSRP pour permettre aux ressources d'être transmises par proxy par le serveur du Consommateur WSRP. Par conséquent, les URL dans le navigateur peut pointer vers un proxy de ressources fourni par le Consommateur WSRP qui achemine la demande vers la ressource appropriée, fournie par l'hôte du Producteur WSRP. Par exemple, des portlets peuvent contenir des adresses URL qui incluent des fichiers CSS ou JavaScript et vous souhaitez fournir ces portlets par WSRP. Dans ce cas, vous devez veiller à ce que les URL pointent vers les emplacements corrects en les codant conformément à la spécification de portlet Java. Si vous ne codez pas les URL en utilisant les appels API JPS, les portlets en fonctionnent pas correctement. Remarque : L'implémentation de proxy de ressource HCL prend également en charge le traitement des URL relatives. Exemple : une URL pointe vers un fichier CSS et elle est codée en utilisant l'API JSP (Java Portlet Specification). Le fichier CSS contient à son tour des liens relatif vers d'autres ressources, telles que des images. Dans ce cas, les demandes pour ces images sont également acheminées et gérées via le proxy de ressources du Consommateur WSRP.
WSRP ne prend pas en charge la configuration côté Consommateur des portlets distants qui ne prennent pas en charge la configuration partagée.
La configuration du mode de portlet edit_defaults_compatibility n'est pas prise en charge pour les portlets exploités à l'aide de WSRP.
L'interface SPI PUMA n'est pas utilisable avec WSRP.
La SPI PUMA ne peut pas être utilisé avec les portlets distants.
Les portlets Nuage d'étiquettes, Centre d'étiquettes et Liste des résultats ne prennent pas en charge WSRP
Les portlets Nuage d'étiquette et Centre d'étiquettes ainsi que le portlet Liste des résultats ne prennent pas en charge WSRP. Par conséquent, un portail Producteur ne peut pas fournir ces portlets en tant que services Web distants ou un portail Consommateur ne peut pas les utiliser afin que ses utilisateurs puissent les exploiter.