darkBlog

Vous l'avez peut-être remarqué, étrangement, il n'y a pas d'instruction Exit while en LotusScript (du moins avec Domino 7), permattant de sortir d'une boucle While ... Wend. Une solution simple à ce problème est d'utiliser une boucle Do While ... Loop à la place puis l'instruction Exit do. J'aime quand un plan se déroule sans accroc.

Je ne sais pas si vous vous rappelez, mais il y a quelques mois, je me suis fendu d'un billet particulièrement assassin sur Lotus Sametime 7.0, dans lequel je relatais les nombreux déboires que nous avons rencontré lors de la migration de Sametime 6.5.1 en 7.0. Pour le coup, je gardais une image fondamentalement négative du produit.

Cet été, je me suis déplacé dans la filliale américaine d'un de nos clients pour établir une connexion entre les serveurs Sametime américain et européen (ce dont je viens de parler quelques lignes plus bas). Figurez-vous que j'ai été très surpris, en discutant avec les administrateurs locaux, d'apprendre que ceux-ci n'ont jamais rencontré le moindre problème avec le produit. Celui-ci tourne sur iSeries, alors que l'européen (celui sur lequel je suis intervenu pour la migration) tourne sur Windows 2003.

Lors de l'opération de rapprochement des deux serveurs, il est apparu que cela ne fonctionnait pas car les serveurs n'utilisaient pas la même nature de connexion vers l'annuaire. Je me suis alors orienté vers l'infocenter de Sametime en quête de la procédure de changement de type de connexion. Et j'ai été frappé par l'étape suivante : Copy and rename the .DLL files, edit the Notes.ini file, or edit the Sametime.ini file. En substance, pour mener à bien cette opération, sur Windows, il est nécessaire de renommer tout un tas de DLL ainsi que d'écraser d'autres fichiers plus ou moins obscurs, alors que sur les autres systèmes, il suffit de modifier un simple paramètre dans le fichier sametime.ini (DirectoryType=LDAP).

Et a bien y réfléchir à posteriori, tous les problèmes que nous avons recontré lors de la migration sont propres à Windows : crash de la tâche HTTP avec la JVM de Domino 7.0.2, services qui ne démarrent pas quand Sametime est lancé depuis Remote Desktop, les meetings qui peuvent ne pas fonctionner quand le processeur utilise l'hyperthreading, le partage d'écran qui nécessite plus de 256 couleurs, etc. Je crois que ça en dit long sur la stabilité de Lotus Sametime sur Windows. J'avais conclu par "C'est bien dommage, car Sametime est un beau produit quand il marche.". Aujourd'hui, je suis convaincu que Lotus Sametime est un beau produit, et qu'il marche très bien. Mais par sur Windows.

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