darkBlog

Disposer de deux serveurs Sametime dans deux organisations différentes, c'est bien, mais les connecter ensemble pour permettre aux utilisateurs de l'un de communiquer avec ceux de l'autre, c'est encore bien mieux. Et (curieusement ?), c'est quelque chose d'assez simple à mettre en oeuvre¹, et qui est très bien détaillée dans les deux articles suivants : How to enable communication between multiple Lotus Sametime servers et Getting two Sametime servers in the same community.

Ce que ces deux articles ne précisent pas toutefois, c'est qu'outre le fait que ces deux serveurs doivent partager le même annuaire, la connexion à ces annuaires doit être de même nature. Plus clairement : si vos deux serveurs Sametime pointent vers le même annuaire, mais que l'un utilise une connexion native à l'annuaire Domino, et que l'autre accède à l'annuaire Domino via LDAP, la connexion entre les deux serveurs ne fonctionnera pas. Et cela est aisément compréhensible ; respectivement l'un verra CN=Obiwan Kenobi/O=Ordre Jedi quand l'autre verra CN=Obiwan Kenobi,O=Ordre Jedi. Evident ? Peut-être, mais pas tant que ça quand on est dans le vif du sujet. La solution est bien évidemment de paramétrer les serveurs Sametime pour qu'ils utilisent le même protocole pour accéder à l'annuaire (et à ce sujet, je conseille vivement LDAP plutôt que les connexions natives à l'annuaire Domino).

1 : en dehors des problématiques liées au réseau si les organisations ne sont pas en LAN : autorisation des IP, ports, reverse proxy, DMZ, etc.

Déjà évoqué dans le second billet traitant du développement de portlets avec Jetspeed et Eclipse, les informations que l'on retrouve dans WebSphere Portal à l'issue du déploiement d'un portlet JSR 168 proviennent du descripteur de déploiement portlet.xml dudit portlet. Cela dit, comme ce fichier peut se montrer plutôt verbeux, et que sa représentation XMLAccess l'est encore davantage, difficile de déterminer le rôle et l'impact précis de chacune des données du descripteur de déploiement.

C'est pourquoi je me suis livré à une petite expérience visant précisément à lever le voile sur cette zone d'ombre. En ressort que peu d'informations sont réellement utilisées, mais qu'elles sont essentielles et qu'il convient de les manipuler avec précaution (j'y reviendrai plus loin). Voici deux extraits de ces fichiers, volontairement épurés :

Descripteur de déploiement du portlet :

<portlet-app id="FOO">
    <portlet>
        <portlet-name>BAR</portlet-name>
        <portlet-info>
            <title>PLOP</title>
        </portlet-info>
    </portlet>
</portlet-app>

Puis l'export XMLAccess du portlet :

<web-app uid="FOO.webmod">
    <servlet referenceid="BAR.servlet">
    <portlet-app name="FOO" uid="FOO">
        <localedata locale="fr">
            <title>FOO</title>
        </localedata>
        <portlet name="BAR">
            <localedata locale="fr">
                <title>PLOP</title>
            </localedata>
        </portlet>
    </portlet-app>
</web-app>

Il apparaît que les deux données majeures sont la balise portlet-name ainsi que l'attribut id de la balise portlet-app : à elles seules, elles déterminent les données vitales du portlet déployé dans WPS.

Pourquoi tout ceci est important et que je vous bassine avec ? Parce qu'une mauvaise manipulation, même motivée par de très bonnes intentions, peut avoir des conséquences dramatiques. Un exemple ? Imaginez que pour une quelconque histoire de suivi de conventions de nommage (ce qui est tout à votre honneur), vous décidiez de modifier la balise portlet-name du descripteur de déploiement. Redéployez votre module web, et vous perdez tous les portlets issus du module dans votre portail¹.

Bug de WPS ? Non, en réalité, la modification du portlet-name a entrainé des modifications de la servlet sous-jascente ; en effet celle-ci se voit attribuée un nouveau referenceid (celui-ci étant basé sur la valeur du portlet-name), et du coup, d'un nouvel objectid, WPS devant considérer que la servlet a changé (et ça semble compréhensible, le referenceid étant le seul attribut utilisé pour l'opération de lookup). Et vos portlets existants, liés à cette servlet par l'attribut servletref, disparaissent soudainement de la surface de votre portail. Oui, c'est sournois, mais ça peut arriver, et très facilement. Les exports XMLAccess sont formels.

Que retenir de tout ceci ? Que le portlet-name comme l'attribut id de la balise portlet-app sont les données les plus importantes du descripteur de déploiement, et qu'une fois un module déployé, mieux vaut ne jamais toucher à ces valeurs.

1 : c'est du vécu. Et ce comportement est reproductible avec WPS 5.1 et 6