Posts Tagged 'portail'

Livre « Le poste de travail Web »

Le groupe SQLI annonce la sortie de son dernier livre co-écrit par les équipes de SQLI Consulting et SQLI Agency.
Cet ouvrage a pour ambition de traiter à la fois les concepts de poste de travail, de situation de travail ou d’activité interactive et les aspects pratiques de la mise en oeuvre au travers de retours d’expérience et de recommandations. Il aborde également des questions techniques et ergonomiques que soulève inévitablement la mise en oeuvre d’un portail.

Un nouveau type de plugin pour Liferay 5

Une des nouveautés de liferay 5 est l’ajout d’un nouveau type de plugin, nommé hook, dans le Plugin SDK. Il impacte fortement la façon de customiser liferay car il permet de changer le comportement et l’interface de liferay de manière plus intelligente.

Je n’entre pas dans le détail de création d’un plugin hook. Vous pouvez le voir en détail dans le wiki de Liferay. Dans ce billet je voudrais donner mon opinion et formuler quelques souhaits d’évolution pour les futures versions.

D’abord j’apprécie beaucoup l’idée de séparer toutes les customisations dans un war de type plugin. Cela donne la souplesse et le dynamisme pour les SI qui veulent customiser Liferay par rapport à leur besoin métier. Pour rappel, auparavant si l’on voulait customiser Liferay, la méthode la plus utilisée était d’utiliser l’environnement EXT fourni par Liferay. Mais EXT ne peut pas fournir un livrable séparé, les parties customisées sont déployées de facon manuelle ou semi automatique via les scripts ant. Les customisations notamment dans la couche présentation (les pages jsp) sont mélangées avec les sources originales de liferay et il n’existe pas donc de moyen simple pour les enlever. On doit supprimer le war customisé et redéployer le war original. On peut maintenant regrouper toutes les customisations dans un war, que l’on peut facilement déployer et retirer à la montée de version.

Voyons de quoi le plugin hook est capable. Il permet d’« accrocher » les modifications dans liferay. Plus précisément, il permet

  • de surcharger une partie des propriétés de la configuration de liferay (portal.properties). Parmi ces propriétés on peut trouver celles qui permettent d’intercepter le système d’événement et la gestion de l’écouteur autour des modèles métiers.
  • de surcharger, ajouter la traduction
  • de surcharger les pages jsp de liferay

Quelles sont les utilisations du plugin hook ?
L’usage principal est bien sur pour customiser le comportement et l’interface de Liferay via les différentes surcharges listées ci-dessus. L’usage alternatif est de créer un plugin hook qui initialise certaines données dans Liferay. C’est très utile pour faire une démo. Un bon exemple: dans le bundle tomcat-liferay fourni sur le site de Liferay, on peut trouver le hook sevencogs qui sert à initialiser les données de la communauté exemple nommé SevenCog.

L’apparition du plugin hook dans va-t-il entrainer la fin de l’environnement EXT ?
Personnellement, je n’y crois pas. Il faut distinguer les rôles des 2 projets de Liferay Plugin SDK et EXT. EXT sert à étendre le fonctionnement interne de Liferay ainsi qu’à le customiser. Plugin SDK sert à développer les plugins de Lifray (portlet, thèmes…) et maintenant packager une partie de la customisation. EXT est encore utiliser pour l’ajout des extensions lourdes. Il y a encore des choses qu’on peut faire dans EXT mais pas avec plugin hook. Par exemple, ajouter des nouvelles pages jsps, et des nouvelles actions struts.

Ce sont aussi les fonctionnalités que je souhaite voir dans la prochaine version du projet Plugin SDK. Pour arriver à ce point là, il faut gérer la surcharge à chaud de la configuration de struts (struts-config.xml) qui n’est pas évidente. La logique voudrait alors que Liferay enleve le répertoire ext-web dans projet EXT, comme ce qu’ils ont fait à l’époque pour le répertoire portlets.

Une autre fonctionnalité de hook que je souhaite est la surcharge au niveau de l’instance de portail. Pour l’instant les customisations dans un hook impactent tous les instances portail dans liferay. Si Liferay arrive à les limiter dans le scope d’une instance portail (un genre de portal-companyId.properties par exemple) ce serait idéal, notamment dans les contexte de site en "marque blanche".

Les plugins hook sont donc une évolution majeure de Liferay qui va considérablement faciliter la customisation du portail.

IAM – 3. Un portail d’identités efficient

Voici le troisième article sur le sujet de la Gestion d’identité (ou IAM).

La gestion d’identité est souvent vue comme un thème technique n’intéressant que les administrateurs du Système d’Information. Concentrons-nous sur la partie visible de l’iceberg, celle qui concerne chaque collaborateur.

Recherche sur un collaborateur.

– Bonjour Gérard, vous m’avez appelée ?
– Bonjour Sophie, j’aurai besoin de contacter Olivier, il est malade depuis deux semaines et personne ne sait où il a mis les documents du projet X.
– Bien, je vais regarder.

Dix minutes plus tard …
– J’ai cherché dans l’Intranet et je ne l’ai pas trouvé
– C’est normal, l’Intranet est public et l’information que je vous demande est privée.
– Et je cherche où alors ?
– Dans ses papiers ! Il a bien rempli des papiers en arrivant ici (il y a 15 ans) ?

2 heures plus tard après un aller retour dans le service RH puis un aller retour à la cave dans les archives le numéro a été trouvé.

La construction d’un portail d’identité se fait généralement en deux étapes qui, vous allez le voir, sont nettement insuffisantes.

  1. La première étape consiste à récolter les informations sur les collaborateurs de l’entreprise et à les afficher le plus ergonomiquement possible.
  2. La deuxième étape consiste à créer une page de recherche avec les champs « nom », « prénom », « numéro de téléphone » etc. et un bouton « rechercher ». Si les critères de la recherche sont insuffisants pour obtenir la fiche d’un seul collaborateur, une page intermédiaire permet de sélectionner le collaborateur voulu parmi une liste de choix possibles.

À ce niveau de réflexion, il est évident que les informations d’identité du collaborateur sont celles qui sont visibles par tout le monde. Le portail est une simple application « pages jaunes/pages blanches ».

Centraliser l’information

Les informations privées sont, quant à elles, accessibles à partir d’autres progiciels, applications diverses, référentiels de stockage informatique ou dans des listings papier ou encore dans le dossier de chaque collaborateur.

Cela n’encourage pas l’ensemble des collaborateurs à utiliser le nouveau portail d’identité qui vient d’être implémenté, puisqu’il est incomplet.
Une information décentralisée ne fait pas gagner de temps, au contraire, elle en fait perdre.

Pour gagner en productivité, il est nécessaire de centraliser toutes les informations d’identité. Nous ne nous intéressons pas ici aux problématiques liées au provisioning de référentiels.

Adapter l’information

Intéressons-nous à la possibilité de présenter ces informations confidentielles.

Quelle quantité d’informations confidentielles peut être disponible à partir du portail ? Partons du principe de disposer de toute l’information, confidentielle, privée ou publique à partir du portail.

Comment protéger ces informations confidentielles ? Le portail doit être sécurisé. Une page d’identification permet de vérifier que la personne qui se logue est bien connue du SI et qu’ensuite elle est qui elle prétend être, par la saisie de son mot de passe par exemple. Nous ne nous intéressons pas ici à l’art et la manière de sécuriser l’accès à un portail.

Le portail est protégé. Seules les personnes authentifiées ont accès aux informations d’identité. Sécuriser l’accès est nécessaire, mais pas suffisant, dans notre étude, si on ne gère pas l’identité de la personne connectée. En effet, avant d’afficher une information confidentielle, il faut s’assurer que la personne connectée ait le droit de voir cette information. C’est ce qu’on appelle l’habilitation. Sur quels critères l’information confidentielle doit-elle être affichée ? Et inversement, sur quels critères l’information confidentielle ne doit surtout pas être affichée ? Dans l’ensemble des éléments dits confidentiels, certains le restent pour la personne connectée, d’autres ne le sont plus.

Classifier les individus

Une première idée serait de gérer les droits, pour chaque utilisateur, sur chaque champ affiché, au niveau le plus bas, en positionnant des ACL dans l’annuaire LDAP, par exemple. Cette idée est

  • Passable si le nombre de profils métier différents ou de collaborateurs dans l’entreprise ne dépasse pas 3
  • Compliquée voire même irréalisable si l’entreprise est hétérogène en terme de fonctions et de services.
  • Trop technique.

Un directeur, un commercial, un architecte, une secrétaire, un employé lambda, n’ont pas les mêmes besoins ni les mêmes droits, sinon tout le monde serait directeur. De plus le directeur de l’agence de Lyon a des contraintes différentes de celui de l’agence de Bordeaux…

Une étude peut être faite pour aboutir à une classification claire et précise des employés, mais attention à la maintenance et à l’évolution d’une telle structure sans le bon outil et les bonnes procédures.

Le bon outil

Plusieurs procédés sont envisageables pour implémenter notre portail.
Certains préféreront le développer de A jusqu’à Z. D’autres choisiront d’utiliser un outil de gestion de contenu d’identité. Pour ma part, je suis partisan de ne pas refaire le monde à chaque fois.
Parfois, investir dans un outil de gestion de contenu d’identité est la bonne solution, en termes de rapidité d’élaboration, d’administration, de maintenance et d’évolutivité.

Le bon référentiel

Nous n’avons pas encore discuté des référentiels de données. Nous avons vu qu’il fallait centraliser l’information. Notre portail présente cette information à partir d’un point d’accès unique. Mais faut-il aller plus loin et la centraliser physiquement en un seul référentiel ? Encore une fois, cela dépend du contexte et n’est pas toujours envisageable.
Dans la majorité des cas, avoir un référentiel central est une bonne solution, cela optimise la recherche d’informations, à partir du moment où un outil permet de gérer la synchronisation avec les autres référentiels.

En profiter pour gérer son SI

Nous avons discuté de l’utilité de présenter l’information d’identité à partir d’un portail, accessible dans l’Intranet par exemple. Ce portail est sécurisé et l’information est pertinente. Nous avons tous les éléments réunis pour étendre ses fonctionnalités et offrir des interfaces de gestion de l’identité.

Ajouter, modifier, supprimer sont des actions qui se font régulièrement et plusieurs fois par jour si l’entreprise est importante. Elles sont souvent réservées à une élite technique du SI qui finit par faire de la saisie administrative pour faire vivre le portail.

L’administration centralisée d’un portail est une fonctionnalité intéressante qui fera l’objet d’un autre article dans notre blog.

En résumé

Aujourd’hui il est parfaitement envisageable d’avoir une information et une administration centralisée de son SI. La productivité des collaborateurs sera nettement améliorée. L’administration du SI sera grandement facilitée et rapidement apparaîtra une réduction de coût de production et d’exploitation.

Dans certains cas, centraliser l’information correspond à la réunir physiquement, dans d’autres cas cela signifie la présenter en une unique interface IHM. La règle absolue n’existe pas, mais seule une étude approfondie permettra d’être certain de choisir la bonne solution.

Centraliser l’information est nécessaire mais pas suffisant. Nous l’avons vu, il faut présenter une information utile et pertinente en fonction de l’utilisateur connecté. L’idée qu’il y a derrière une gestion des identités et des accès, n’est pas de sécuriser pour interdire mais sécuriser pour présenter l’information utile sur l’identité d’une personne.
De plus, outre la sécurité, le besoin d’information est différent selon le profil de l’utilisateur qui fait la recherche. Ce qui est important c’est que l’information soit trouvée rapidement.

Implémenter un portail d’identité efficient permet de gagner

  • en sécurité
    • Toutes les recherches passent par une interface centralisée dont l’accès est sécurise.
    • Le demandeur est bien identifié, authentifier et habilité. Il est connu par son profil métier.
  • en productivité
    • Les recherches d’identité passent par une IHM unique.
    • Les recherches sont plus performantes car seule l’information utile au profil métier de la personne qui fait la recherche est présentée.
  • en retour sur investissement
    • Le temps perdu à rechercher l’information dans plusieurs référentiels est supprimé.
    • Toute l’information utile est présente à un seul endroit et donc accessible.

Thierry ALBAIN

Kickoff Sun, portlets 2 et EJB 3.1

Enorme: c’est la première impression que l’on a en entrant dans le Moscone Center de San Francisco. 10 000 personnes s’agitent et font la queue pour assister au kickoff de Sun, introduit par un show de danseurs ponctué d’un lancer de T-Shirt à la catapulte par James Gosling…

Tout la session a tourné autour de Java+You, et Rich Green s’est évertué à démontrer que java était partout (mobiles, PS3…), et que les utilisateurs tiraient la technologie, même en entreprise. Un exemple avec Kindle, le livre numérique d’Amazon, a presque marché. Si Java est partout, c’est aussi parce que JavaFX permet d’unifier la programmation et le déploiement sur tout type de terminaux : un exemple avec une application dans un browser que l’on glisse et dépose sur le bureau, puis que l’on visualise sur un mobile était très explicite. La refonte de Glassfish pour la V3 est sa modularité a aussi été mise en avant, avec un noyau de 98k qui démarre en moins d’une seconde. Le projet Hydrazine a enfin été abordé, comme un moyen de fédérer, découvrir et déployer des services « on the cloud », un peu comme Microsoft Live Mesh. Malgré le peu de détail donné, je pense que ce projet peut rapidement prendre de l’importance. Enfin, Neil Young (pour les plus jeunes : un rocker emblématique qui a commencé en 1963) est venu louer les mérites de Java embarqué dans un Blu Ray sur une PS3 : grâce à cette technologie, il peut enfin mettre à disposition l’intégralité de ses archives et de ses morceaux en 192/24 tout en ne sacrifiant pas l’interactivité. On peut écouter un morceau, et pendant ce temps parcourir les images d’archives.

Beaucoup moins rock, j’ai enchaîné sur la présentation par Stefan Hepper, d’IBM, des portlets 2(.0…) / JSR-286 dont on a déjà parlé ici. Il a très logiquement mis l’accent sur la coordination de portlets, et leur communication à l’aide d’events que chacune produit ou consomme. Un exposé intéressant, car il montrait bien les possibilités / dangers qui s’offrent maintenant lors de la création d’une application composite : il faut penser autrement la navigation interne à la portlet, et l’on peut maintenant vraiment avoir des cinématiques très complexes. Plusieurs points ont aussi été abordés, et notamment tout le travail pour enlever certaines restrictions que l’on avait en portlet 1 (Portlet filters, manipulation des headers…) et améliorer le comportement général (cache, AJAX…) et l’alignement de la norme sur JSF et WSRP pour l’exposition distante.


J’ai ensuite assisté à une présentation de l’état d’avancement des EJB 3.1 très intéressante, car allant dans deux directions : toujours l’amélioration de la facilité d’utilisation qui était le seul but des EJB 3.0, mais maintenant aussi l’ajout de nouvelles fonctionnalités : l’EJB singleton, et des timers basés sur le principe de cron, appels asynchrones locaux. La simplification porte sur le déploiement intégré dans un war, l’interface business locale optionnelle, un sous ensemble EJB Lite facilement embarquable. Un travail en cours, très intéressant, qui touche des domaines sensibles comme les profiles.

Portlet 2.0 : enfin finalisée !

Depuis le 3 mars dernier, la spécification JSR 286 est passée au stade Final Approval Ballot, ou plus clairement, la spécification Portlet 2.0 est enfin officielle. Il est vrai qu’on l’attendait depuis longtemps (commencée en novembre 2005, elle était initialement prévue pour mai 2007). Les insuffisances de la première spécification (JSR 168) commençaient grandement à se faire sentir, avec la prolifération de surcouches hétérogènes pour y pallier.


Mises à jour Twitter

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64,072 hits