JCMS 8 : les principales nouveautés et les modules associés

1. Alertes et notifications

1.1 Un nouveau système unifié

JCMS et ses modules proposent de nombreuses fonctions de notification et d'alerte : notification sur publication, validation dans les workflow, planification d’un événement, rappel sur une tâche, dépassement de quota, .... On dénombre ainsi une cinquantaine d’alertes différentes.

JCMS 8 rationnalise ces fonctionnalités. Toutes les alertes émises par la plateforme sont désormais gérées de façon homogène et générique. Les alertes sont typées sur trois niveaux avec un code couleur :

• Information (en bleu) : l’utilisateur est informé d’une nouveauté ou d’un changement (p. ex. : nouveau commentaire, nouveau billet de blog, mise à jour d’un contenu suivi, …)
• Action (en orange) : l’utilisateur est informé qu’une action de sa part est attendue (p. ex. : valider d’une étape de workflow, indiquer ses disponibilités pour une planification, …)
• Alerte (en rouge) : l’utilisateur est alerté d’une situation d’urgence (p. ex. : dépassement de quota dans un espace, store ou base de données corrompu, …)

JCMS 8 propose la diffusion de ces alertes sur différents canaux : le mail, le site, la messagerie instantanée (XMPP), le smartphone (via le service Pushover), … Par défaut, les alertes sont envoyées dans les canaux E-Mail et Site.

Les utilisateurs peuvent définir des règles de diffusion des alertes selon leur niveau et leur type. Une même alerte peut être envoyée sur plusieurs canaux. P. ex. l’utilisateur peut décider de recevoir les informations par mail, les actions par mail et sur le site, les alertes sur tous les canaux disponibles.

Lorsque plusieurs règles sont applicables pour une alerte, c'est la règle la plus précise qui est utilisée. Si aucun canal de diffusion n’est indiqué pour un niveau ou un type d'alerte, ces alertes ne seront pas envoyées.

Les alertes sont affichées soit de façon détaillée, soit de façon synthétique selon le type de canal (p. ex. détaillé en mail ou sur le site et synthétique dans la messagerie instantanée).

Les alertes sont personnalisées pour chaque utilisateur. Elles sont composées dans la langue de son profil. Quel que soit son paramétrage, il ne reçoit que celles qui lui sont destinées. Par exemple, s’il avait demandé de recevoir les alertes sur les dépassements de quots disque, et qu’il n’est plus administrateur, alors il ne les recevra pas.

Les e-mails envoyés ont été homogénéisés et enrichis. Ils sont au format HTML. Ils ont un entête dans la couleur de leur type (bleu, orange, rouge). Si l’alerte est émise par un autre utilisateur avec un message (p. ex. recommandation, commentaire, …), la photo de l’émetteur et le message sont clairement distingués du descriptif de l’alerte.

Le canal Site est matérialisé par un compteur coloré qui apparaît dans la Topbar. Le compteur indique le nombre d’alertes non lues. Il est coloré selon le niveau d’alerte le plus élevé dans la liste des alertes non lues (si l’utilisateur a 2 alertes information et 1 alerte action, il sera coloré en orange (type action)).

Le module Pushover fournit un canal de diffusion qui diffuse les alertes sur smartphone en utilisant le service du même nom. Ce canal nécessite l’ouverture d’un compte application sur Pushover (gratuit et limité à 7500 envois par jours) et que les utilisateurs installent sur le smartphone l’application Pushover (payante).

Le système de diffusion est extensible et de nouveaux canaux peuvent aisément être développés et proposés aux utilisateurs.

L'article API de gestion des alertes détaille le fonctionnement des alertes et l'utilisation de cette nouvelle API.

1.2 Des recommandations enrichies

JCMS 8 internalise et enrichi le système de recommandation qui était précédemment fourni par le module ESN. Les recommandations exploitent le nouveau framework d’alertes et il est possible de typer chaque recommandation (information, action, alerte). Les destinataires reçoivent ainsi les recommandations par les canaux les mieux adaptés et savent rapidement le niveau d’urgence qu’ils doivent appliqués.

L’alerte qui indique l’arrivée d’une nouvelle recommandation affiche l’émetteur et la liste des destinataires. L’utilisateur connaît ainsi immédiatement les autres membres impliqués sur cette recommandation.

Les recommandations sont archivées. Depuis la Topbar, l’utilisateur a accès à l’ensemble de recommandation envoyées et reçues. En allant sur un contenu, l’utilisateur retrouve les recommandations qu’il a émis et reçu sur ce contenu.

Les recommandations sont aussi couplées au suivi des lecteurs. Lorsque celui-ci est actif sur un contenu, l’utilisateur connaît les membres destinataires qui ont accédé au contenu recommandé.

Le suivi des lecteurs a aussi été revu. Il propose une nouvelle interface et pour les documents, il distingue les consultations de la fiche et les téléchargements du fichier.

1.3 De nouvelles interfaces pour les notifications

Depuis de nombreuses versions de JCMS, les notifications permettent aux utilisateurs de se tenir informés des nouvelles contributions. Ils définissent leur centre d’intérêt via des catégories, des types de contenu, ou des espaces et reçoivent les nouveautés au rythme de leur choix.

JCMS 8 rafraichie cette fonctionnalité.

L’interface de paramétrage a été simplifiée. Depuis son profil, dans l’onglet Notification, l’utilisateur a accès à la liste de ses règles de suivi.

L’ajout et l’édition de règle de suivi se fait via un formulaire à étape.

Le mail de notification a aussi été revu. Il est composé en HTML, segmenté par espace et comporte les visuels associés aux publications.

2. Recherche unifiée et instantanée

La recherche est un point fort de l’offre Jalios JCMS. Elle permettait de retrouver des informations aussi bien dans les contenus (articles, billets, fiches,…) que dans les documents (fichiers bureautiques). L’annuaire permet aussi de rechercher dans la base de membre et, lorsque le module ESN est présent, dans les profils riches où chacun peut présenter sa mission, son expertise et ses relations.

JCMS 8 propose désormais une recherche unifiée avec une interface unique pour rechercher dans les contenus, les documents, et les personnes. C’est une option des portlets Recherche, qui est activée par défaut dans la zone de recherche de la Topbar.

Lorsque cette option est activée, les membres, trouvés avec le texte saisi, sont présentés juste après le premier résultat.

La recherche instantanée améliore encore l’efficacité pour l’utilisateur : au fur et à mesure de la saisie de la recherche, une liste de propositions est présentée à l’utilisateur qui accède ainsi directement à l’information recherchée. Les résultats sont répartis en deux groupes : les utilisateurs et les publications.

3. Espaces Collaboratifs

3.1 Espaces Publics / Privés / Secrets

La nouvelle version du module Espaces Collaboratifs propose trois politiques d’accès :

• Espace Public : l’espace est accessible de tous
• Espace Privé : l’espace est visible de tous mais son accès est restreint aux membres inscrits
• Espace Secret : la visibilité de l’espace est restreinte aux membres inscrits

Lorsqu’un utilisateur accède à un espace privé auquel il n’appartient pas, il est redirigé vers une page de présentation de cet espace. Si la politique d’inscription le permet, un bouton pour s’inscrire lui est proposé.

3.2 Espaces hiérarchiques

La nouvelle version du module Espaces Collaboratifs permet d’ajouter des sous-espaces au sein d’un espace. Les sous-espaces peuvent eux-mêmes comporter des sous-espaces. S’il n’y a pas de limite à cette hiérarchie, il est recommandé de ne pas dépasser 3 ou 4 niveaux. Au-delà des problèmes de rendu pourraient apparaître dans certaines interfaces.

Dans l’entête d’un sous-espace un lien amène vers l’espace parent

La création d’un sous-espace se fait, comme pour un espace collaboratif, depuis l’espace parent via le service Mes Espaces. La portlet peut être paramétrée pour présenter une arborescence d’espaces.

Les sous-espaces sont assez autonomes de leur espace parent :

• Les animateurs d’un sous-espace ne sont pas forcément les mêmes que ceux de l’espace parent ;
• Les membres du sous-espace n’appartiennent pas forcement à l’espace parent, et vice-versa ;
• Un sous-espace peut être d’une typologie différente de celle de son espace parent. Par exemple, un espace Communauté peut comporter plusieurs sous espaces Projet ;
• Un sous-espace peut avoir une politique d’accès différente de celle de l’espace parent. On peut ainsi avoir un espace parent public qui comporte des sous-espaces publics, privés ou secrets mais aussi l’inverse, un espace secret qui comporte un sous-espace public.

La recherche peut-être étendue aux sous-espaces ou restreinte à l’espace courant. Cette option peut être configurée sur la portlet et est disponible dans les facettes des résultats de recherche.

3.3 Comptes invités

Un animateur d’espace collaboratif peut inviter des personnes externes à l’organisation (fournisseurs, partenaires, client, …) tout en garantissant la confidentialité des données du site.

• Un invité n’a accès qu’aux espaces collaboratifs dans lesquels il a été invité
• Un invité ne voit que les données (contenu, membre, catégories, …) des espaces auxquels il appartient

Lors de la demande d’ouverture d’un compte invité, une recherche est effectuée pour vérifier si la personne à inviter n’est pas déjà invitée dans d’autres espaces. Si c’est le cas, elle est simplement rattachée à l’espace demandeur, sinon un compte est créé. L’invité reçoit alors un mail l’invitant à se rendre sur le site pour activer son compte. Il est immédiatement redirigé vers son espace d’accueil. Si un invité participe à plusieurs espaces, le menu accueil de la Topbar lui permet de passer d’un espace à l’autre.

Il est aussi possible de transformer un contact en compte invité. Ceci peut se faire soit par le menu contextuel du contact soit en allant sur sa page profil lorsque le module ESN est présent.

Dans la liste des membres d’un espace, un badge apparaît sur les comptes invités.

La fenêtre et la portlet de présentation d’un espace, indique à tous les participants, les invités accueillis dans cet espace.

3.4 Tâches assignées

Le module Gestion de Tâches permet à un utilisateur de gérer des listes de tâches. Placée au sein d'un espace collaboratif, la liste des tâches est partagée entre tous les participants.

Jusqu’à présent, il était possible d’assigner la tâche à une personne. Mais il s'agissait d'une donnée purement informative pour celui qui créé la tâche. La personne affectée n'était pas prévenue et n'avait aucun moyen de connaître la liste des tâches qui lui avaient été assignées.

Les versions 3.1 et 4 du module Gestion de Tâche proposent désormais une gestion plus complète des tâches assignées.

L’affectation d’une tâche se fait comme avant :

• Pour une tâche simple, on crée la tâche et on l’édite pour choisir la personne assignée (le responsable)
• Pour une tâche sur une publication, le formulaire permet dès la saisie de choisir à qui on l’affecte. Notez que vous pouvez créer une tâche sur une publication depuis la page de la publication ou depuis la carte de la publication.

Dès que l’affectation a été faite, le membre concerné reçoit une alerte qui l’informe de cette tâche.

La portlet Tâche assignées liste toutes les tâches qui sont affectées à l’utilisateur. Si elle est placée dans un espace collaboratif, seules les tâches qui lui ont été assignées dans cet espace seront listées. Placée, dans le bureau personnalisé, elle liste toutes les tâches assignées à l’utilisateur. Deux affichages sont possibles : par date d'échéance ou par priorité.

L’utilisateur ne peut ni modifier ni supprimer une tâche qui lui a été affecté. Il peut seulement la fermer ou la ré-ouvrir. Lorsqu’il la ferme l’auteur de la tâche reçoit une alerte.

3.5 Module Favoris

Le module Favoris offre un accès direct depuis la Topbar à tous les favoris de l’utilisateur. Depuis ce menu il peut aussi ajouter/retirer la publication de ses favoris.

Le menu permet aussi d’accéder au gestionnaire de favoris avec lequel l’utilisateur peut réorganiser, éditer et supprimer ses favoris.

3.6 Module WebEx

Cisco WebEx est une des principales solutions de communication unifiée. Elle permet d’organiser des réunions virtuelles, avec échanges audio/vidéo, de partage son écran, …

Le module WebEx permet aux organisations utilisant ce service de l’intégrer dans JCMS (sous réserve qu’il dispose d’une licence WebEx le permettant). Une fois le module configuré, les utilisateurs planifient leur réunions WebEx depuis JCMS. Pour cela, ils peuvent utiliser le menu Publier ou le faire depuis la portlet Calendrier. Le formulaire d’ajout est très similaire à celui d’ajout d’un événement.

Les réunions WebEx créées apparaissent dans l’agenda partagé comme les autres événements. Les réunions peuvent comporter des participants membres du site et des personnes externes. Les membres sont prévenus par le système d’alerte de JCMS 8. Les personnes externes reçoivent un mail.

Le gabarit d’affichage d’une réunion WebEx indique dans combien de temps la réunion commencera. L’auteur de la réunion, qui en est l’organisateur, dispose d’un bouton pour lancer à tout moment la réunion. Ce bouton déclenche l’application locale WebEx.

Lorsque la réunion a démarré, l’information figure sur le gabarit d’affichage et les participants peuvent la rejoindre. Une fois la réunion terminée, l’organisateur peut récupérer l’historique de la réunion (qui a participé, sur quelle période, …) Il peut aussi déposer la vidéo de la réunion qu’il obtient depuis l’application WebEx.

4. Gestion Documentaire

4.1 Copie de travail des documents

Jusqu’à présent, contrairement à tous les autres types de publication, il n'était pas possible de faire une copie de travail d'un document.

JCMS 8 comble ce manque et permet de faire des copies de travail des documents avec les contraintes suivantes :

• Les prérequis communs aux conditions de création d'une copie de travail doivent être respectés :
  • Seuls les contenus du store peuvent avoir une copie de travail
  • La copie de travail n'est proposée que sur les documents associés à un Workflow
  • L'état initial du Workflow ne doit pas être un état visible (le "Workflow des documents" ne permet donc pas de faire une copie de travail)
  • Le document doit être dans un état visible
  • Le document ne doit pas être une copie de travail
• Deux prérequis supplémentaire sont ajoutés
  • L'espace de travail dans lequel on fait la copie de travail ne doit pas être en dépassement de quota disque
  • La copie de travail ne doit pas engendrer un dépassement du quota disque de l'espace

Lorsqu’une copie de travail d’un document est créée, le fichier associé est dupliqué. Il peut ainsi être mis à jour sans que le document original ne soit affecté.

Lorsque la copie est fusionnée avec son original, le document référence le fichier de la copie de travail. En conséquence, les références par lien (champs Wysiwyg, images dans les champs Wiki) deviennent invalides.

Les copies de travail ne sont pas visibles par la navigation WebDAV.

Les modules suivants ont été mis à jour pour prendre en compte les copies de travail :

• Module Explorer : Lorsque la portlet Explorer est configurée pour afficher les publications dans les états non visibles, les copies de travail apparaissent avec un badge dédié.
• Add-in Microsoft Office : Les copies de travail peuvent être éditées avec l’add-in. Les copies de travail sont présentées avec un badge dans les différentes interfaces de l’add-in (navigation, recherche, mes documents).

Enfin, les documents peuvent aussi être dupliqués comme les autres types de contenu.

4.2 Choix du fichier PDF

Avec le module conversion PDF, un PDF est automatiquement généré à chaque dépôt de document bureautique (MS Office, Open Office, Libre Office). La conversion est réalisée par Libre Office. Pour certains document MS Office, le PDF produit n’est pas fidèle au document original (mise en page, type et chasse des polices, placement de certains objets, …). Ceci peut être gênant sur certains documents pour lesquels la mise en forme est importante. Par ailleurs, il peut être utile d’associer un PDF à des documents qui ne sont pas traité par le module de conversion PDF (e.g. fichiers Photoshop, Visio, CAO, …)

JCMS 8 permet d’associer manuellement un PDF à tout document (sauf à un PDF). Via le menu contextuel du document, il suffit de sélectionner « Déposer un PDF… » et de choisir le fichier dans la fenêtre modale qui s’ouvre.

Les modules Générateur d’aperçu et Visionneuse de document se baseront sur ce fichier PDF pour produire leur fichier.

4.3 Nouveaux formats de document (Visio, SVG et EPub)

Visio

JCMS 8 reconnaît les documents Microsoft Visio (*.vsd) et affiche la visionneuse Visio lorsqu’ils sont présentés dans la vue détaillée du document (uniquement sous Internet Explorer).

Les dimensions par défaut de la zone d’affichage (100%, 600) peuvent être configurées avec les propriétés :

• media.template.default.application/x-visio.width
• media.template.default.application/x-visio.height

SVG

JCMS 8 reconnaît les fichiers graphique au format SVG (images et animations) et les affiche lorsqu’ils sont présentés dans la vue détaillée du document.

Les dimensions par défaut de la zone d’affichage (100%, 600) peuvent être configurées avec les propriétés :

• media.template.default.image/svg-xml.width
• media.template.default.image/svg-xml.height

EPUB

Enfin, JCMS 8 reconnaît les fichiers au format EPUB. Il s’agit de l’un des formats les plus populaires pour les livres électroniques. Il n’existe pas de visionneuse intégrée dans la page mais l’extension Firefox EPUBReader permet de les ouvrir.

4.4 Module Microsoft Office

Le module Microsoft Office s’enrichi d’une fonction de création de document. Celle-ci apparaît dans le menu Publier de la Topbar et dans la portlet Explorateur. La création est contextuelle à l’endroit où elle est déclenchée :

• depuis le menu Publier, elle a lieu dans l’espace courant
• depuis la portlet Explorateur, elle a lieu dans l’espace courant et dans la catégorie sélectionnée

Dans la fenêtre modale de création de document, l’utilisateur renseigne le titre et le type de document à créer (Word, Excel, PowerPoint). Les types proposés sont paramétrés dans le module. Il est ainsi possible de proposer les types Office 2007 (docx, xlsx et pptx) et les types Office 2003 (doc, xls et ppt).

A l’étape 2, l’utilisateur sélectionne un modèle de document. Les modèles sont des documents catégorisés dans une branche de catégories qui doit être déclarée dans les propriétés du module. Plusieurs branches de catégories peuvent être proposées.

Les modèles sont proposés en fonction du type de document choisi à l’étape 1. Par exemple, si on a choisi un document Word 2007 alors on peut choisir des modèles Word 2007 et Word 2003, si on a choisi un document Word 2003, on ne proposera que des modèles Word 2003.

A l’étape 3, l’utilisateur peut préciser les métadonnées (description, droits, catégories, …). Lorsqu’il clique sur Terminer, le document est créé à partir du modèle sélectionné et le document est ouvert dans l’application Office correspondante.

4.5 Module CMIS

CMIS (Content Management Interoperability System) est un standard ouvert d’interopérabilité entre des systèmes de gestion de contenu. CMIS étant très orienté autour du document, ce standard est essentiellement utilisé pour faire inter opérer des systèmes de GED.

Le module CMIS fournit un accès aux GED exposant le contenu en CMIS. Les GED peuvent enrichir le format CMIS, aussi le module CMIS peut être complété d’un module dédié à la GED Alfresco et d’un autre dédié à celle de MS SharePoint. Ces modules complètent les fonctionnalités de base offertes par CMIS.

Le module CMIS permet de naviguer dans des GED, d’y rechercher, déposer, éditer, verrouiller, supprimer des documents.

Le module CMIS peut gérer plusieurs entrepôts de GED. Depuis l’espace d’administration, un lien permet d’accéder au gestionnaire des entrepôts.

Lors de la création d’un entrepôt, il faut indiquer le type d’entrepôt (CMIS générique, Alfresco, SharePoint) et l’URL d’accès. Puis il est nécessaire de s’authentifier pour choisir l’arborescence à utiliser.

Une fois l’entrepôt créé, il peut être utilisé dans la portlet Explorateur CMIS. Celle-ci est assez proche de la portlet Explorateur de JCMS. La colonne de gauche permet de naviguer dans l’arborescence de répertoires de l’entrepôt. La zone centrale affiche les fichiers contenus dans le répertoire sélectionné. Sur les répertoires et sur les fichiers, un menu contextuel permet de déclencher des actions. Il est ainsi possible de créer/modifier/supprimer des répertoires, de déposer des fichiers, de les supprimer, de les rechercher, de modifier leur propriété, de créer une copie de travail, …

Il est aussi possible de créer une référence dans JCMS sur un fichier de l’entrepôt CMIS. Pour cela deux solutions sont proposées. Depuis l’explorateur, le menu contextuel permet de créer une référence qui est matérialisée par un contenu JCMS. Ce contenu peut donc être utilisé comme tout autre contenu et a les même propriétés (lien, recherche, droits, …) Lorsqu’on y accède on affiche le fichier correspondant de la GED.

L’autre façon de référencer un fichier de la GED est de l’insérer dans un champ Wiki. Depuis la barre d’icône, on ouvre l’explorateur CMIS et on sélectionne le fichier à insérer.

La portlet Requête CMIS est similaire à la portlet Requête / Itération de JCMS. Elle liste les fichiers d’un entrepôt CMIS selon une requête CMIS donnée.

4.6 Module Google Docs

Le service Google Docs est un constituant du service Google Drive. Il permet de coéditer des documents de façon synchrone (tous les utilisateurs voient les changements en temps réel). Les documents sont de différents types : document texte, feuille de calcul, présentation et dessin. Actuellement, ce service est gratuit. Il suffit de disposer d’un compte Google pour y avoir accès.

Le module Google Docs fournit une intégration fine de ce service avec JCMS.

L’ergonomie de création est très similaire à la création d’un document avec le module Microsoft Office.

Depuis JCMS, l’utilisateur déclenche la création d’un nouveau document Google Docs. Cela peut se faire :

• Depuis le menu Publier
• Depuis la portlet Explorateur
• Depuis la portlet GoogleDocs

Dans la fenêtre modale de création de Google Docs, l’utilisateur renseigne le titre et le type de document à créer (Document, Feuille de calcul, Présentation, Dessin). Il peut aussi choisir de démarrer à partir d’un document présent sur son poste.

Des modèles de documents peuvent être proposés. Il s’agit de document JCMS classés sous des branches de catégories qui doivent être déclarées dans les propriétés du module.

A l’étape 3, l’utilisateur choisit les autres personnes qui participeront à l’édition de ce document, aux commentaires ou simplement à sa consultation.

Une fois le Google Document créé, l’utilisateur est redirigé sur la page du document. Les participants reçoivent une alerte (de type Action) leur indiquant qu’ils sont invités à éditer ou commenter le document.

Dans JCMS, un Google Document est représenté par un document JCMS classique auxquels sont attachées des informations spécifiques à Google Docs. Toutes les caractéristiques d’un document JCMS s’applique (affichage, droits, …). Si le membre qui consulte la page participe à l’édition du document, l’interface intègre l’éditeur Google Doc.

Si le membre n’a pas été invité à l’édition Google Docs, il voit l’interface classique d’un document JCMS. Une boîte lui indique qu’il s’agit d’un document Google Docs et lui permet de demander à rejoindre la coédition (qui devra être validée par l’auteur du document).

A tout moment, l’auteur du document (ainsi que les administrateurs) peuvent récupérer une copie locale du document en cours d’édition. Ceci met à jour le fichier attaché au document. Une fois la rédaction terminée, l’auteur peut arrêter la coédition et récupérer la dernière version du document.

Le module propose deux modes de stockage des documents Google Docs :

• Compte centralisé (mode recommandé) : tous les documents Google Docs sont créés dans un compte Google dédié à l’organisation. Avec ce mode, le module n’a pas besoin d’accéder en écriture aux comptes Google Docs des utilisateurs (l’accès en lecture est demandé pour des raisons techniques liées à l’API Google Docs mais non utilisé). Ce mode a aussi l’avantage de garantir à l’organisation la pérennité des documents en cours d’édition lors du départ d’un collaborateur.
• Comptes décentralisés : les documents Google Docs sont créés dans le compte Google Drive de chaque utilisateur. Ce mode est plus simple à mettre en place mais requiert que les utilisateurs acceptent que le module Google Docs ait accès en lecture/écriture à leur compte Google Drive.

La portlet Google Docs liste tous les documents Google Docs en cours d’édition. Utilisée dans le bureau personnalisé, elle liste les documents de l’utilisateur. Lorsqu’elle est placée dans un espace collaboratif, elle liste tous les documents de l’espace.

Enfin, les administrateurs fonctionnels disposent d’un tableau bord listant tous les documents Google Docs en cours d’édition dans leur espace.

4.7 Module Crocodoc

Crocodoc est un service payant d’affichage et d’annotation de document bureautique. Le module Crocodoc intègre finement ce service au sein de JCMS.

Une fois le module configuré, l’utilisateur peut déclencher les annotations Crocodoc sur les documents de type MS Office, MS PowerPoint et PDF. Pour cela il indique les personnes qu’il souhaite inviter à annoter le document. La tarification du service Crocodoc se basant sur les dépôts de document, une ACL JCMS est requise pour ouvrir les annotations sur un document (i.e. de déposer le document dans le cloud de Crocodoc).

La visionneuse JCMS est alors remplacée par la visionneuse Crocodoc. Les participants reçoivent une alerte (de type Action) leur indiquant qu’ils sont invités à annoter le document. Ils peuvent annoter le document directement dans la page d’affichage ou basculer en mode plein écran pour plus de confort.

A tout moment, le gestionnaire des annotations peut historiser les annotations. Cela consiste à créer un document PDF contenant les annotations. Ce document est lié au document annoté. Toutes les versions historisées sont listées dans la boîte « Historique des annotations ».

La boîte « Suivi des annotations » permet de savoir rapidement les participants qui ont terminé leurs annotations. Un lien permet de relancer ceux qui n’ont pas terminé.

En tant qu’Administrateur, il est possible d’obtenir des statistiques détaillées sur les documents JCMS qui ont été annotés avec Crocodoc : qui a démarré les annotations, quand, le nombre de documents annotés par mois.

4.8 Module Cryptage des documents

Comme son nom l’indique, le module Cryptage des documents crypte les documents qu’on lui soumet. L’objectif de ce module est de protéger les documents qui sont enregistrés sur le serveur. Cependant, ce module reposant sur un système de cryptage symétrique avec une clé aussi présente sur le serveur, il n’est pas infaillible. Il protège contrôle le vol de documents par copie mais si l’attaquant vole aussi la clé il peut arriver à décrypter les documents. Pour plus de sécurité, il est recommandé de déporter les documents sur un volume accessible à l’application JCMS mais restreints à des exploitants accrédités.

Le cryptage peut se faire à la demande lors d’un dépôt, sur un document déjà déposé ou systématiquement sur tous les documents d’un espace de travail donné.

Le cryptage est réalisé côté serveur. De même le décryptage est réalisé sur le serveur avant l’envoi du document. Il convient donc de mettre en place une connexion sécurisé HTTPS entre le client et le serveur.

Enfin, les documents cryptés subissent plusieurs restrictions fonctionnelles :

• Le contenu du document n’est pas indexé
• Les documents cryptés ne bénéficient pas de la conversion PDF ni de la visionneuse
• Aucune miniature n’est générée
• Ils ne peuvent pas être édités (par WebDAV, par l’add-in MS-Office ou par Google Docs)
• Ils ne peuvent pas être annotés par le module Crocodoc

5. Réseau Social d’Entreprise (ESN)

5.1 J’aime !

JCMS 8 propose une fonction de vote sur le contenu dans le même principe que celle que l’on retrouve sur les réseaux sociaux Facebook ou Google Plus. Le but de cette fonctionnalité est de faire remonter les contenus les plus populaires.

Lorsqu’il est activé, le vote est disponible en bas de tout contenu. Il est matérialisé par un pouce levé gris puis vert une fois que l’utilisateur a voté.

Le vote est aussi disponible depuis la portlet Activité des membres (fournie par le module ESN) et dans chaque commentaire.

Le vote permet de savoir rapidement qui a apprécié un contenu mais aussi de remonter les contenus les plus populaires. Il peut ainsi être utilisé comme critère de tri dans les Portlet requête/itération. Afin d’obtenir des résultats pertinents, il est recommandé de le coupler avec une recherche limitée dans le temps (p. ex. les contenus publiés dans les 30 derniers jours).

5.2 Module ActivityStreams

Le format ActivityStreams standardise la représentation d’un flux d’activité, sous une forme très simple. Chaque activité est composée d’un acteur, d’un verbe, d’un objet et d’une cible. Par exemple : Marie (acteur) a publié (verbe) un document (objet) dans l’espace marketing (cible).

ActivityStreams utilise le format de représentation JSON.

Le module ActivityStreams collecte l’activité d’un site JCMS, le stocke dans la base de données et peut ensuite le restituer sous forme d’un flux JSON. L’activité concerne non seulement la contribution, mais aussi la consultation et les connexions. Afin de garantir la confidentialité, le flux peut être totalement anonymisé (titre de publication, nom des auteurs, …)

Le module fournit aussi la portlet ActivityStreams qui agrège et affiche des flux ActivityStreams externe.

5.3 Module Lecko RSE Analytics

Lecko RSE Analytics est un service SaaS de la société Lecko. Cet outil mesure les évolutions vers des pratiques collaboratives et sociales :

• Caractérisation des espaces (projet, communauté de partage, …)
• Suivi de l’adoption
• Suivi de l’engagement

Lecko RSE Analytics effectue ses analyses à partir des flux d'activité de la plateforme au format ActivityStreams. Une fois le module en place, JCMS envoie tous les jours à heure régulière le flux ActivityStreams de la veille. Afin de garantir la confidentialité des données, ce flux est totalement anonymisé.

6. JCMS Analytics

L'analyse de l'usage d'un site est un point important pour savoir si le site répond aux attentes de ses utilisateurs. Depuis de nombreuses versions, JCMS propose un outil d’analyse statistique des accès. Cependant cet outil n’était plus en adéquation avec les besoins actuels.

6.1 De nouvelles métriques

JCMS 8 remplace l’ancien outil d’analyse des accès par un outil d’analyse des usages. Celui-ci produit des métriques sur les différents pans fonctionnels de JCMS :

1. Consultation : visite, téléchargement, contenu les plus consultés, …
2. Recherche : taux de recherche, mots les plus recherchés, …
3. Contribution : évolution du nombre de contenu, de document, types les plus utilisés, …
4. Utilisateurs : évolution du nombre d’utilisateurs, répartition selon le type (membre, contact, invités, …)
5. Exploitation : évolution de l’espace disque, des espaces de travail, …
6. Technique : taux de requête, temps moyen de réponse, navigateurs et système d’exploitation utilisés, …

L’analyse des usages est extensible. A l’instar des modules Espaces Collaboratifs et ESN, des modules peuvent ajouter leur propres métriques :

1. Espaces collaboratifs : répartition par typologie, politique d’accès, membre, taux de contribution, …
2. Réseau social (ESN) : évolution de l’activité, répartition par type d’activité, taux de relation, de complétude des profils, de microblogging, …

6.2 Une nouvelle interface

L’interface de l’analyse des usages est accessible depuis l’espace d’administration, depuis l’administration d’un espace de travail et directement en front-office pour les espaces collaboratifs. L’interface permet de choisir la période analysée et, pour l’analyse générale, l’espace. Les métriques sont organisées en onglet (Consultation, Recherche, Contribution, ...) Les graphiques sont désormais produits en HTML 5 et sont interactifs (choix des séries affichées, mise en avant d’une série, affichage de la valeur d’un point).

Une interface de gestion permet de relancer une analyse sur une période donnée (ceci est particulièrement utile lors de la mise en place de nouvelles métriques).

6.3 Une nouvelle architecture

Le système de calcul a été entièrement repensé pour être plus performant et plus simple à mettre en place. Toutes les requêtes sont historisées quotidiennement dans un fichier JSON. Lorsque le site est composé de plusieurs réplicas, chaque réplica historise ses propres requêtes. Ces fichiers sont assez proches des anciens fichiers statistiques en XML. Un convertisseur est disponible pour transformer les anciens fichiers XML en JSON.

Tous les jours, à une heure régulière (par défaut 00:30) une consolidation est lancée. Chaque réplica reprend la collecte les requêtes de la veille, calcul et enregistre pour chaque métrique un rapport quotidien dans la base de données. En plus de l’analyse de la collecte certaines métriques sont calculées à partir des clichés instantanés des données (p. ex. répartition des espaces collaboratifs, le taux de complétude de profil ESN).

La base de données contient la consolidation quotidienne de tous les réplicas. Lorsqu’un utilisateur consulte l’analyse des usages, JCMS Analytics recherche et agrège les rapports quotidiens de la période demandée et produit les rendus graphiques pour chaque métrique.

7. Administration

7.1 Import des membres

L’import des membres permet d’alimenter la base des membres JCMS (en objet Member). L’administrateur fournit un fichier CSV qui représente les comptes utilisateurs à importer. Un modèle de fichier CSV est fourni à l’étape 1 du formulaire d’import. Ce fichier décrit l’ordre des colonnes contenant les informations sur les membres (nom, prénom, e-mail, …).

A l’étape 2, une vérification du contenu du fichier est réalisée. Le système supporte des imports incrémentaux : si des membres ont déjà été importés durant un précédent import, leur compte sera simplement mis à jour. Durant cette étape, c’est l’e-mail qui sert de clé pour retrouver les membres.

Il est possible d’ajouter des étapes pour associer les futurs membres à des espaces :

• Une étape peut être ajoutée pour proposer les groupes des espaces se trouvant sous une certaine catégorie (définie en propriété).
• Si le module Espaces Collaboratifs est présent, une étape du même nom est ajoutée qui permet d’associer ces membres à des groupes d’espaces collaboratifs.

Après l’import, les membres nouvellement créés reçoivent un e-mail les invitant à activer leur compte.

7.2 Add-Pack

Le contrôle des add-pack a évolué. Les comptes désactivés et les contacts ne sont désormais plus comptés dans le calcul des limites sur les Member et les DB Member.

Des seuils d’alertes sont désormais définis sur chaque limite portant sur les données. Les administrateurs reçoivent une alerte à chaque fois qu’un seuil est franchi. Le seuil est représenté par un pourcentage. Si le seuil n'est pas défini, il est par défaut à 100%. Les seuils sont définis dans les propriétés suivantes :

channel.add-pack.threshold.Workspace:          100
channel.add-pack.threshold.CollaborativeSpace: 90
channel.add-pack.threshold.Member:            90
channel.add-pack.threshold.DBMember:          80
channel.add-pack.threshold.DBFileDocument:   80

 

Le seuil pouvant être dépassé voire franchis plusieurs fois, une alerte n’est émise que si c’est la première fois ou que si la dernière alerte date de plus de 24 heures (propriété channel.add-pack.threshold.alert-freq)

Lorsqu’un add-pack a une date d’expiration, des alertes sont désormais envoyées aux administrateurs pour les prévenir de l’échéance de l’expiration.

Par défaut, les alertes sont émises :

• 30 jours avant l'échéance
• 15 jours avant l'échéance
• Puis tous les jours avant l'échéance
• Une fois le add-pack expiré

Le contrôle est fait tous les jours à heure régulière (10h00).

Tout ceci est défini par les propriétés suivantes :

channel.add-pack.expiration.schedule: 00 10 * * * *
channel.add-pack.expiration.reminders: 1 2 3 4 5 6 7 8 9 10 15 30

7.3 Multi-LDAP

JCMS 8 permet d’authentifier un membre et de récupérer ses informations à partir de plusieurs annuaires LDAP.

Des critères doivent néanmoins être respectés pour activer cette fonctionnalité :

• Information discriminante pour la sélection de l’annuaire
  • Identifiant bas niveau (DOMAIN\sAMAccountName)
  • E-mail (marie.durant@acme.org)
  • userPrincipalName (durant@acme.local)
• Schéma identique entre tous les annuaires

L’article Configuration et fonctionnement du LDAP dans JCMS sera bientôt mis à jour pour présenter le multi-LDAP.

7.4 Opérations en masse sur les données en base

Avec JCMS 8, la fonction « panier » peut opérer sur des données en base (Publication et Membre) comme sur celle du store. La volumétrie en base pouvant être importante, il convient de faire attention à la quantité de données que l’on déverse dans le panier. Un traitement sur un panier volumineux (plusieurs dizaine de milliers d’objets) peut affecter les performances du site.

7.5 Module Waffle (Kerberos)

Le module Waffle permet de réaliser une authentification sur JCMS via NTLM / Kerberos.

Ce module ne fonctionne que sur les architectures Windows. Pour plus de détails, reportez-vous à la documentation interne du module.

7.6 Localisation en 10 langues

A partir de JCMS 8 SP1, JCMS et tous les modules existants (sauf certains modules techniques) sont désormais localisés en 10 langues :

1. Anglais
2. Français
3. Allemand
4. Espagnol
5. Italien
6. Portugais
7. Japonais
8. Coréen
9. Chinois simplifié
10. Chinois traditionnel

L’usage du chinois traditionnel nécessite de fonctionner sur un environnement Java 1.7.

Exemples d’interfaces localisées :

La fenêtre d’authentification a aussi été retravaillée afin de pouvoir choisir la langue d’affichage.

8. Développement

8.1 Frameworks CSS et JavaScript

Une grande refonte a été opérée sur l’ensemble du code JavaScript et CSS de JCMS 8.

La plupart des composants graphiques (fenêtres modales, menus contextuels, ttCards, auto-completion, onglets, …) reposent désormais les composants Bootstrap 2.2.

En conséquence, toutes les pages de JCMS 8 utilisent la déclaration de DOCTYPE HTML5.

JCMS 8 utilise aussi le framework Modernizr qui détecte les capacités HTML 5 et CSS3 du navigateur.

Le framework Ajax-Refresh a été enrichi. Il utilise les nouveaux attributs data-* de HTML 5.

Côté JavaScript, JCMS 8 repose maintenant en grande partie sur le framework jQuery 1.8. Les bibliothèques Scriptaculous et LivePipe ont été retirées. Prototype est encore présent pour préserver la compatibilité sur certains composants qui n’ont pas encore été migrés. Il sera retiré progressivement avec les prochaines versions de maintenance de JCMS 8.

JCMS 8 introduit le ToggleManager. Il s’agit d’un composant JavaScript qui permet de limiter et remplacer les développements JavaScript par des classes CSS. Les actions écoutées peuvent par exemple, faire apparaître un bloc, ajouter un item dans une liste, cocher toutes les cases à cocher d’un formulaire.

Exemple :

<a href="https://community.jalios.com/jcms/jx_75003/en/jcms-8-les-principales-nouveautes-et-les-modules-associes#" data-jalios-action="toggle:hide" data-jalios-target="#secret-cave">Sésame, ouvres-toi !</a>
<div id="secret-cave" class="hide">Soyez les bienvenus…</div>

Un article détaillera prochainement toutes ces nouveautés.

8.2 Support des tablettes

Avec l’utilisation des composants Bootstrap, le support des tablettes a été amélioré. Les formulaires en modale fonctionnent beaucoup mieux ainsi que les fonctions d’autocompletion.

L’organisation des menus de la Topbar a été revue et est «responsive ». C’est-à-dire que son contenu s’adapte en fonction de la dimension de l’écran.

8.3 StoreMerge

Avec le script deploy.sh, le StoreMerge est le composant coeur du système de déploiement de JCMS. JCMS 7.1 a nettement amélioré le StoreMerge, notamment dans la gestion des conflits. Néanmoins, jusqu’à présent, la résolution des conflits nécessitait encore un traitement manuel.

La nouvelle version du StoreMerge fourni avec JCMS 8 intègre un système de résolution automatique des conflits. Cette résolution se base sur un jeu de règles que l’on définit en amont et en aval de l’opération de fusion.

Dans cette version, les 2 stores à fusionner ne sont plus typés (store courant, store de développement, store de référence, ...). On parle désormais simplement du store 1, du store 2 et du store fusionné.

Le StoreMerge peut être lancé avec :

1. un fichier de règles générales de résolution de conflits (p.ex. ignorer les conflits sur l'attribut opAuthor, ignorer l'ordre sur l'attribut skins des portlets, ... )
2. un fichier de règles spécifiques aux conflits non résolus par les règles générales de résolution

Lorsque le StoreMerge est lancé, différents cas se présentent :

• Il n'y a aucun conflit détecté
  • La fusion a lieu
• L'application de ces règles (générales et spécifiques) résout tous les conflits
  • La fusion a lieu
  • On indique les résolutions effectuées
  • Les éventuelles nouvelles opérations consécutives à la résolution des conflits sont ajoutées au store fusionné
• L'application de ces règles ne résout pas tous les conflits
  • La fusion n'a pas lieu
  • La liste des conflits est indiquée
  • Si la préparation du fichier de résolution spécifique a été demandée, il est alimenté avec des règles par défaut pour chaque conflit détecté

Ainsi la fusion peut être préparée sur la plateforme de recette / pré-production. Le fichier des règles et le fichier de résolution sont fournis à l’opérateur ou au script devant effectuer la fusion en production.

Pour plus de détails, consultez l'article StoreMerge - Guide de l’utilisateur.

8.4 Inspecteur de données

JCMS 7.1 avait introduit une interface pour éditer ou afficher rapidement une donnée dont on connaît l’identifiant. JCMS 8 enrichit cette fonctionnalité en proposant d’inspecter une données à partir de son identifiant.

L'inspecteur de données est accessible via la zone développement du back-office, le nouveau menu du module DevTools et depuis tous les menu contextuels sur les données (Publication, Portlet, Membre et Catégorie).

L’inspecteur de données affiche différents types d’informations sur :

• Le type (classe, mode de stockage, …)
• Les attributs (les champs)
• Les extraInfo
• Les extraData et extraDBData
• Les identifiants virtuels

Pour les attributs, au-delà des attributs hérités de la classe Data (id, cdate, mdate, author), on affiche les principaux attributs des classes Member, Group, Category, Workspace et Publication.

8.5 Modules

8.5.1 Gestionnaire de modules

Dans JCMS 8 SP1, le gestionnaire des modules a été revu. L’édition des propriétés est mise en avant.

La documentation des modules Jalios n’est plus dans le module mais sur la fiche du module (l’URL est indiquée dans l’interface de gestion du module). Cependant, si une documentation est présente dans le module, elle continuera d’être affichée dans l’interface de gestion du module.

8.5.2 Module Principal

JCMS 8 SP1 introduit la notion de module principal. Toute webapp JCMS peut déclarer un et un seul module principal.

Le module principal offre des garanties spécifiques à la webapp lors du démarrage de JCMS et sur la surcharge des propriétés.

Il est recommandé de toujours déclarer un module de site pour une webapp JCMS.

Déclaration d’un module principal

La déclaration se fait par la propriété channel.main-plugin :

Exemple :

channel.main-plugin: AcmePlugin

Cette propriété doit être déclarée dans le fichier custom.prop.

L'interface de gestion des modules met en avant le module principal lorsqu'il a été déclaré.

Le module principal est aussi indiqué dans la ressource donnant l’état du site (/rest/admin/status ou admin/statusXml.jsp) avec l’attribute mainPlugin sur la balise plugin.

Contrôles au démarrage de JCMS

Au démarrage, JCMS vérifie si un module principal a été déclaré. si c'est le cas, alors il effectue un ensemble de vérifications :

• Le module principal doit exister ;
• Le module principal doit être initialisé ;
• Le module principal doit être démarré ;
• Le module principal doit avoir démarré sans avertissement ;
• Chaque dépendance (et sous dépendance) du module principal doit avoir démarrée sans avertissement.

Si l'une de ces conditions n'est pas respectée, le démarrage de JCMS est interrompu.

Il est possible de désactiver ces vérifications en positionnant la propriété channel.main-plugin.check-at-startup est à false.

Surcharge des propriétés

L'objectif est de pouvoir livrer en production des propriétés sans avoir à faire des opérations dans le fichier custom.prop.

Au démarrage de JCMS, les propriétés du module principal sont chargées en dernier afin de surcharger toutes les autres propriétés (y compris celles déclarées dans custom.prop).

Dans l'éditeur de propriétés, les propriétés surchargées par le module principal ne sont plus éditable (car la valeur saisie ne serait pas pris en compte). De même à l'enregistrement, ces propriétés ne sont pas enregistrées dans le fichier custom.prop.

8.5.3 Suppression du fichier webapp.prop

Le fichier webapp.prop n’est plus livré avec JCMS. Si il est présent il est chargé mais avec une trace d’avertissement. Il est fortement recommandé de ne plus utiliser ce fichier et de déplacer les propriétés qui s’y trouvaient dans le fichier de propriétés de module principal.

En raison de la suppression du fichier webapp.prop dans JCMS 8.0 SP1, l'application des Jumbo Patch nécessite la dernière version des Jumbo Patch Tools diffusé en même temps que JCMS 8.0 SP1.

8.5.4 Packaging des classes Java des modules

JCMS 8 SP1 permet de déclarer dans le fichier plugin.xml les packages de classes Java au lieu de chaque classe Java à packager.

Exemple :

<java-classes>
  <java package="com.jalios.jcmsplugin.acmeplugin" />
</java-classes>

8.6 Portlet Requête / Itération

Gabarit Carousel

La portlet Requête / Itération propose un nouveau gabarit Carrousel, basé sur le carrousel de Bootstrap. Chaque résultat est présenté avec sa « dataImage » et son titre avec un lien amenant sur l’affichage détaillé de la donnée.

Affinement

Il est désormais possible de paramétrer une portlet Requête/Itération pour qu’elle effectue un affinement sur catégorie même si l'option Recherche en base de données a été cochée. Ceci est néanmoins possible uniquement dans le cas où la requête ne comporte aucun critère sur catégorie.

8.7 Le tag <jalios:dataicon>

JCMS 8 propose une nouvelle API pour obtenir de façon homogène l’icône d’une donnée. Le nouveau tag <jalios:dataicon> affiche l’icône d’une donnée.

Pour le cas simple, la déclaration des icônes se fait via des propriétés de la forme types.NomDuType.icon.

Exemple :

types.SocialIdea.icon:       plugins/SocialConversationPlugin/images/icons/idea.gif
types.SocialQuestion.icon:   plugins/SocialConversationPlugin/images/icons/question.gif
types.SocialTopic.icon:      plugins/SocialConversationPlugin/images/icons/topic.gif
types.SocialAnswer.icon:     plugins/SocialConversationPlugin/images/icons/answer.gif

Si le choix de l’icône est lié à certaines conditions, il suffit alors de surcharger les méthodes de la classe Data :

• getDataIcon()
• getDataIconAlt()
• getDataIconTitle()

8.8 Le tag <jalios:memberphoto>

A partir de JCMS 8 SP1, le tag <jalios:memberphoto> remplace l’utilisation de doMemberPhoto.jspf pour l'affichage la photo d’un membre.

Exemples :

<jalios:memberphoto member="<%= mbr %>" size="<%= PhotoSize.TINY %>" />
<jalios:memberphoto member="<%= mbr %>" size="<%= PhotoSize.LARGE %>" css="animated shake" htmlAttributes="style='border:1px solid red'"/>

Le tableau ci-dessous répertorie la liste des attributs pouvant être utilisés sur ce tag :

 

Par défaut, le rendu HTML de l'affichage de la photo du membre est réalisé par la JSP /jcore/memberPhotoTemplate.jsp.

Il est possible de surcharger cette JSP. Pour cela vous pouvez soit :

• Surcharger la propriété jcms.resource.member-photo en lui attribuant comme valeur le chemin vers le nouveau modèle JSP. Ceci surchargera de manière globale tous les appels au tag <jalios:memberphoto>.
• Ajouter l’attribut templateProperty sur le tag <jalios:memberphoto> pour surcharger ponctuellement le gabarit d'affichage. La valeur de cet attribut doit être soit une propriété soit le chemin de la JSP.

Dans cette JSP, vous pouvez accéder aux attributs suivants :

// Le membre
Member photoMember = (Member)request.getAttribute(MemberPhotoTag.MEMBER_PHOTO_MEMBER_ATTR);

// La taille de la photo définie dans l’attribut size
PhotoSize mbrPhotoSize = (PhotoSize)request.getAttribute(MemberPhotoTag.MEMBER_PHOTO_SIZE_ATTR);

// Les classes CSS définies dans l’attributs css
String css = (String)request.getAttribute(MemberPhotoTag.CSS_ATTR);

// Les attributs HTML additionnels définis dans l’attribut htmlAttributes
String htmlAttributes = (String)request.getAttribute(MemberPhotoTag.HTML_ATTRIBUTES_ATTR);

// L’objet Data définis dans l’attribut linkData
Data linkData = (Data)request.getAttribute(MemberPhotoTag.LINKDATA_ATTR);

 

8.9 Widget Member Chooser

Des classes CSS permettent de filtrer quels types de membres seront proposés :

• jstoreOnly : uniquement les Member
• adminOnly : uniquement les administrateurs
• workerOnly : uniquement les contributeurs
• accountOnly : uniquement les comptes utilisateurs
• contactOnly : uniquement les contacts

Exemple :

<jalios:widget 
                editor          ='<%= AbstractWidget.UI_EDITOR_MEMBERCHOOSER %>'
                widgetName      ='<%= "members" %>'
                widgetAddCount  ='<%= 1 %>' 
                keyword         ='<%= true %>'
                css             ='jstoreOnly accountOnly'
/>

8.10 Module DevTools

Le module DevTools fournit un nouveau menu qui s’insère dans la Topbar qui propose la plupart des actions de développement (inspecteur de donnée, affichage des targets, compilation LESS, rechargement des propriétés de langue, …) ainsi que les liens vers les différentes pages de documentations (Javadoc, CSS, JavaScript, OpenAPI, …)

8.11 Certifications

JCMS 8 SP1 est officiellement certifié et supporté sur le serveur d’application Apache Tomcat 7.

JCMS 8 SP1 apporte également la certification de Java 1.7.

Cependant JCMS reste compatible avec Java 1.6, à l’exception de l’usage du chinois traditionnel qui nécessite Java 1.7.

Consultez le manuel d’installation et d’exploitation pour les détails sur les versions recommandées.

8.12 JADE

JADE (JAlios Delivery Engine) est une plateforme d’intégration continue. Elle se matérialise par une machine virtuelle prête à l’emploi contenant différents outils : serveur SVN, serveur d’intégration continue (Jenkins) et scripts d’exploitation.

JADE est accompagnée d’un guide méthodologique pour la mise en place rapide de projets JCMS.

JADE sera diffusée prochainement.