Oyez l'histoire des chevaliers du Web, et venez découvrir avec nous les mythes et légendes de ce continent nouveau …

La 3e édition de Sud Web s'est déroulée le week-end dernier, à Avignon, au Palais des Papes dans la salle du Conclave, lieu mythique et magique s'il en est. Cet événement voue son existence à promouvoir le web dans tous ses états, en privilégiant les échanges sous la forme de retours d'expériences entre participants et en s'intéressant aux aspects sociétaux de nos professions de développeurs, designers, décideurs…

Comme d'habitude, nous y étions. Petit retour sur deux jours au coeur de l'écosystème du Web…

Clever Age envoie ses Chevaliers

Comme lors des précédentes éditions, nous avons eu la chance de voir des consultants de Clever Age sélectionnés en tant qu'orateurs.

Mehdi Kabab présentait « Sass et Compass ont embelli mon quotidien », conférence au cours de laquelle il a pu offrir une vision large de ces outils.

Matthias Dugué animait l'élaboratoire « Boutez les ignominieuses fonctions anonymes hors de vos jQuery », axé autour de la conception et de l'architecture de plugins jQuery.

Nous avions également la chance de retrouver sur place Olivier de Villardi, chef de projet web à la MACSF, client historique de Clever Age. Il ouvrait la journée de conférences avec le sujet « le client : ce gentil méchant », mettant en lumières les échanges client / prestataire, et comment les améliorer au quotidien.

Ces fiers chevaliers, accompagnés de moult palefreniers dans leurs valises, ont donc contribué au nouveau succès de cette édition.

Sud Web, une quête chaque année renouvelée

Globalement nous avons constaté quelques mouvements de fond, notamment dans l'industrialisation de l'outillage (on a parlé de git autant qu'on a réfléchi au design du code) ainsi que dans l'intégration de plus en plus importante de l'expérience utilisateur (UX) et du responsive web design, ce qui nous conforte dans nos axes de travail !

L'une des caractéristiques majeures de Sud Web, c'est qu'il s'agit d'une conférence itinérante : elle change de ville chaque année. De cette façon, elle vient d'elle-même à la rencontre du public. Cette année encore, nous étions nombreux, dont une bonne proportion de nouveaux visages. C'est là le signe du renouvellement constant du public, et c'est bien là ce qui fait la qualité de cet événement : des échanges faciles et humains entre les orateurs, les participants, les organisateurs.

L'édition de cette année n'aura pas démérité, de belles rencontres ont eu lieu. L'occasion de renforcer encore le tissu de cette formidable communauté au sein de laquelle nous œuvrons chaque jour.

La présence Web d'une marque (une entreprise ou un produit) est de plus en plus « protéiforme » : sites Web/Mobile/Tablette, sites e-Commerce, moteurs de recherche, blogs, réseaux sociaux, comparateurs, sites d'affiliation … Outre cette explosion des canaux digitaux, la complexité technique croissante des dispositifs nécessite d'industrialiser leur surveillance : performances, sécurité, compatibilité multi-devices … pour garantir à ses utilisateurs une expérience de qualité. Les « listening platforms » sont là pour répondre à ce besoin et identifier où sont les réels axes de progrès pour votre marque.

La multiplication des canaux digitaux, la gestion de la relation client de plus en plus bidirectionnelle, la complexité croissante du développement web … imposent aux entreprises de dépasser le pilotage manuel qu'elles ont pu mettre en place jusqu'alors. L'enjeu principal consiste maintenant à monitorer automatiquement des dispositifs multi-canaux, mais aussi de lever des alertes le cas échéant, et d'assister les managers dans l'arbitrage de leurs décisions. Un certain nombre d'outils d'audit existent déjà, on peut donc se demander à quoi servent les plateformes d'écoute (ou listening platforms).

La différence principale tient dans les mécanismes : les audits sont souvent manuels, prennent en compte une partie seulement de ce qu'on veut monitorer, là où les plateformes d'écoute s'inscrivent dans l'automatisation et la durée, ce qui permet aisément de suivre aussi bien les tendances que d'identifier rapidement les points susceptibles d'être améliorés. Ces plateformes apportent également la possibilité de se « benchmarker » par rapport à la concurrence.

Qu'est-ce qu'on peut (doit) écouter ?

Nous avons regroupé en 3 axes (Visibilité, Protection, Qualité) ce que les plate-formes d'écoute savent écouter, historiser, comparer … En l'état actuel du marché, la plupart des plate-formes se concentrent sur un axe, voire un sous-axe. Pour éviter ce traitement en silos, Steerious (projet Clever Age) a pour objectif d'apporter une vision consolidée de ces 3 axes (pour en savoir plus). Nous développerons dans un prochain article le positionnement des principales listening plateforms par rapport à notre découpage fonctionnel du besoin métier.

Axe Visibilité : C'est l'axe qui intéresse en priorité les responsables marketing et communication. Il mesure la visibilité et la réputation de la marque sur le Web. Cet axe couvre :

• l'analyse de la présence sur les moteurs de recherches (SEO/SEM : suivi du degré et de la qualité de la présence de la marque sur des requêtes identifiées en référencement naturel / payant)
• et tout ce qui englobe la mesure de réputation numérique :
  • le monitoring dans les médias sociau,x mais aussi les blogs, et les médias traditionnels, qui conservent un pouvoir d'influence à ne pas oublier derrière l'arbre des réseaux sociaux ;
  • l'identification d'influenceurs

Axe Protection : C'est l'axe qui intéresse en priorité les responsables juridiques et commerciaux. Il permet de contrer les attaques de ses concurrents et de détecter au plus vite les opportunistes qui tentent de détourner à leur profit l'aura de la marque. Cet axe couvre :

• la détection de toutes les formes d'usurpation d'identité : cybersquatting, typosquatting, faux profils dans les réseaux sociaux ...
• l'identification de détournement de l'usage de la marque dans les régies publicitaires Google Adwords, Facebook Ads ...
• la détection de copie ou de détournement de contenus
• la détection de référencement naturel polluant

Axe Qualité : C'est l'axe qui intéresse théoriquement tout le monde lorsque le niveau de maturité des équipes est élevé. Cet axe est crucial puisque qu'il a un impact sur les 2 autres : pas de référencement naturel de qualité sans respect des standards, pas de protection sans contrôle de ses failles de sécurité ... Cet axe couvre :

• le suivi de la conformité de son dispositif permettant d'assurer un référencement naturel optimum : respect des standards, présence dans les graphes sociaux ...
• le suivi de la performance (WebPerf) de ses sites depuis l'ensemble des zones géographiques visées par la marque
• le contrôle de la conformité à des référentiels de qualité adaptés à sa cible type Opquast, RGAA …
• la vérification continue de la sécurité des dispositifs en place

Une opportunité pour fédérer les équipes autour du Digital

Dans le monde offline, un fonctionnement des équipes très "haché" est courant. Prenons le cas du mailing papier : Un annonceur va solliciter une agence qui va concevoir la campagne et produire le livrable. Un imprimeur va assurer le tirage alors qu'un routeur va se charger de la mise sous pli et de la remise aux services postaux concernés. Une autre agence va éventuellement tenter de mesurer le retour de cette campagne par sondage des destinataires.

Dans le monde online, ce découpage en silos est impossible tellement les canaux se nourrissent les uns les autres et le besoin de réactivité est fort. Nous constatons que la mise en place d'une stratégie d'écoute impliquant l'ensemble des acteurs du digital est une opportunité pour fédérer les équipes autour d'une ambition commune. Le premier bénéfice à attendre de ce type de projet est de rapprocher les lignes et de converger vers un but qu'il devient nécessaire de formaliser (la réponse au pourquoi d'une présence sur le Web).

La plate-forme d'écoute doit être la tour de contrôle de la présence Web pour une marque. Elle doit être également le point de départ pour la priorisation des actions des différents départements et le suivi des tâches de chacun. Sans cette discipline, les organisations continueront à disperser leur forces au gré des modes (un jour Facebook, demain la WebTV …) sans que la marque progresse véritablement dans cet univers hyper exigeant, ultra-concurrentiel et sans foi ni loi.

Play Framework et Elasticsearch sont deux outils récents très populaires. Afin d'intégrer facilement ces deux outils, nous utilisons dans nos projets un module pour Play Framework 2 que nous avons développé. Voyons ensemble comment fonctionne ce module.

Historique

Lors de différents projets développés sous Play Framework 2, nous avons eu besoin d'intégrer Elasticsearch. Aucun module n'existait permettant de rendre cette intégration simple, nous avons donc décidé de bâtir le notre.

Tout d'abord développé dans un dépôt privé, après quelques itérations nous avons obtenu un module suffisamment stable pour être utilisé par d'autres personnes et nous l'avons donc mis à disposition sous licence MIT sur le compte Github de Clever Age.

Dernièrement, une API dédiée à Scala a été mise en place autour de l'API initiale du module. Nous allons présenter dans cet article les grands principes de fonctionnement de ce module.

Que fait le module ?

Ce module permet d'utiliser Elasticsearch soit :

• en mode local : pour embarquer un serveur Elasticsearch ( très utile pour les tests )
• en mode client : pour se connecter à un ( ou plusieurs ) noeuds Elasticsearch

Lors du démarrage de l'application Play, le module va instancier un “Client” qui permettra ensuite d'intérargir avec Elasticsearch.

On peut ensuite créer un (ou plusieurs) Index(s), Type(s) dont on peut initialiser les “settings” et les “mappings” si besoin.

Le module permet d'effectuer des opérations d'indexation, de lecture et de suppression sur un “Index”/“Type” donné.

Il permet principalement d'effectuer des recherches avec la possibilité de lui demander des facettes. Nous avons également mis en place des méthodes pour faciliter l'utilisation des “Percolator”.

Installation

Comme tout module Play, il suffit de déclarer la dépendance dans le fichier Build.scala pour pouvoir récupérer et utiliser le module. Il est actuellement publié sur le dépôt communautaire de SBT, il faut donc également déclarer ce dépôt. Voici donc les dépendances à déclarer :

1. import sbt._
2. import Keys._
3. import play.Project._
4. object ApplicationBuild extends Build {
5. val appName = "elasticsearch-sample"
6. val appVersion = "1.0-SNAPSHOT"
7. val appDependencies = Seq(
8. // Add your project dependencies here,
9. "com.clever-age" % "play2-elasticsearch" % "0.5.3"
10. )
11. val main = play.Project(appName, appVersion, appDependencies).settings(
12. // Add your own project settings here
13. resolvers += Resolver.url("play-plugin-releases", new URL("http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/"))(Resolver.ivyStylePatterns),
14. resolvers += Resolver.url("play-plugin-snapshots", new URL("http://repo.scala-sbt.org/scalasbt/sbt-plugin-snapshots/"))(Resolver.ivyStylePatterns)
15. )
16. }

Télécharger

Activation

Il faut ensuite activer le module en le définissant dans le fichier “conf/play.plugins”

11000:com.github.cleverage.elasticsearch.plugin.IndexPlugin

Configuration

Une fois la dépendance récupérée, différentes options peuvent être ajoutées dans le fichier application.conf ou dans un fichier de configuration dédié inclus dans ce dernier.

1. elasticsearch {
2. # permet d'utiliser elasticsearch de manière "embarquée" à l'application
3. local: true
4. # liste des Node elasticsearch auxquels se connecter
5. client: "127.0.0.1:9300,127.0.0.1:9301"
6. # cluster.name elasticsearch auquel se connecter
7. cluster.name: "elasticsearch"
8. index {
9. # le(s) nom(s) d'index qui sera(ont) utilisé(s) dans l'application
10. name: play2-elasticsearch,log
11. # pattern définissant les classes "indexables"
12. clazzs: "indexing.*"
13. # mapping elasticsearch qui seront appliqué au démarrage de l'application
14. mappings: {
15. # la clé est le "type" elasticsearch et la valeur est le mapping
16. "indexTest": "{\"indexTest\":{\"properties\":{\"category\":{\"type\":\"string\",\"analyzer\":\"keyword\"}}}}"
17. }
18. # activation du log des requêtes (logs effectués au niveau "DEBUG")
19. show_request: true,
20. }
21. # paramètres additionnels qui seront appliqués sur l'index au démarrage
22. play2-elasticsearch.settings: "{ analysis: { analyzer: { team_name_analyzer: { type: \"custom\", tokenizer: \"standard\" } } } }"
23. }

Télécharger Java

En Java, pour indexer et requêter Elasticsearch, il faut définir une classe qui correspond aux données que vous souhaitez indexer. Cette classe doit hériter de la classe "Index" définie dans le module et définir les méthodes toIndex() et fromIndex().

On définit le "type" Elasticsearch à l'aide de l'annotation @IndexType(). Optionnellement, on peut spécifier l'index utilisé à l'aide de l'annotation @IndexName (par défaut, le premier défini dans la configuration sera utilisé).

Ex :

1. @IndexType(name = "indexTest")
2. public class IndexTest extends Index {
3. public String name;
4. // Finder used to request ElasticSearch
5. public static Finder<IndexTest> find = new Finder<IndexTest>(IndexTest.class);
6. @Override
7. public Map toIndex() {
8. Map<String, Object> map = new HashMap<String, Object>();
9. map.put("name", name);
10. return map;
11. }
12. @Override
13. public Indexable fromIndex(Map map) {
14. this.name = (String) map.get("name");
15. return this;
16. }
17. }

Télécharger

Lors de la création du Finder, il est possible également de cibler un index spécifique. Ex : new Finder(IndexTest.class, "log");

Il est alors possible d'indexer et de requêter elasticsearch comme ceci :

1. IndexTest indexTest = new IndexTest();
2. indexTest.name = "hello World";
3. indexTest.index();
4. IndexTest byId = IndexTest.find.byId("1");
5. IndexResults<IndexTest> all = IndexTest.find.all();
6. IndexQuery<IndexTest> indexQuery = IndexTest.find.query();
7. indexQuery.setBuilder(QueryBuilders.queryString("hello"));
8. IndexResults<IndexTest> results = IndexTest.find.search(indexQuery);

Télécharger

Toutes les possibilités offertes par l'API Elasticsearch peuvent être passés à l'object IndexQuery, ainsi que les FacetBuilder et SortBuilder.

Si vous souhaitez appliquer un mapping particulier sur un type donnée, il est possible de le faire à l'aide de l'annotation @IndexMapping. Ex :

1. @IndexType(name = "team")
2. @IndexMapping(value = "{ players : { properties : { players : { type : \"nested\" }, name : { type : \"string\", analyzer : \"team_name_analyzer\" } } } }")
3. public class Team extends Index {
4. public String name;
5. public Date dateCreate;
6. public String level;
7. public Country country;
8. public List<Player> players = new ArrayList<Player>();
9. // Finder used to request ElasticSearch
10. public static Finder<Team> find = new Finder<Team>(Team.class);

Télécharger Scala

Pour utiliser le module en profitant pleinement de Scala, il est possible d'utiliser l'API définie dans le module ScalaHelpers. Les principes sont à peu près les mêmes, mais il est possible d'utiliser des case class pour définir les objets à indexer et les résultats de recherche seront accessible sous forme de collections Scala permettant d'utiliser toutes les méthodes associées (map(), filter(), …).

Il vous faut donc tout d'abord créer une case class qui devra étendre le trait ScalaHelpers.Indexable :

1. case class IndexableTest(id: String, name: String, category: String) extends Indexable

Associé à cette classe, un object qui étend le trait ScalaHelpers.IndexableManager[T] permettra d'intéragir avec Elasticsearch. :

1. object IndexableTestManager extends IndexableManager[IndexableTest] {
2. import play.api.libs.json._
3. // Obligatoire : le type Elasticsearch à utiliser
4. val indexType = "indexableTest"
5. // Optionnel : le nom de l'index si on ne veut pas utiliser le premier déclarer dans la conf
6. // val index = "log"
7. val reads: Reads[IndexableTest] = Json.reads[IndexableTest]
8. val writes: Writes[IndexableTest] = Json.writes[IndexableTest]
9. }

Télécharger

Ce singleton doit définir des parsers JSON (Reads et Writes). Dans le cas classique, l'utilisation des macros Json.reads[T] & Json.writes[T] feront tout ce qu'il faut. Si un formattage JSON particulier est nécessaire, il faudra les définir manuellement.

Une fois ces éléments définis, il est possible d'intéragir avec l'index de cette manière :

1. IndexableTestManager.index(IndexableTest("1", "first name", "cateogory A"))
2. assert(IndexableTestManager.get("1") == IndexableTest("1", "first name", "cateogory A")
3. val indexQuery = IndexQuery[IndexableTest]().withBuilder(QueryBuilders.matchQuery("name", "first"))
4. //.withSize(...)
5. //.withFrom(...)
6. //.addFacet(...)
7. //.addSort(...)
8. val queryResults: IndexResults[IndexableTest] = IndexableTestManager.search(indexQuery)
9. println(queryResults.results.map(_.name).mkString(",")) val count = queryResults.totalCount
10. IndexableTestManager.delete("1")

Télécharger Asynchrone

Toutes les actions (indexation, recherche,...) peuvent être éxécutées de manière non-bloquante. Les différentes API retournent alors des "Futures". Il est alors possible de les utiliser dans des actions de controlleurs non-bloquantes. C'est le cas pour l'API Java et l'API Scala, il suffit d'utiliser les méthodes suffixés par "Async".

Ex en Scala :

1. object Application extends Controller {
2. def async = Action {
3. IndexTestManager.index(IndexTest("1", "Here is the first name", "First category"))
4. IndexTestManager.index(IndexTest("2", "Then comes the second name", "First category"))
5. IndexTestManager.index(IndexTest("3", "Here is the third name", "Second category"))
6. IndexTestManager.index(IndexTest("4", "Finnaly is the fourth name", "Second category"))
7. IndexTestManager.refresh()
8. val indexQuery = IndexTestManager.query
9. .withBuilder(QueryBuilders.matchQuery("name", "Here"))
10. val indexQuery2 = IndexTestManager.query
11. .withBuilder(QueryBuilders.matchQuery("name", "third"))
12. // Combining futures
13. val l: Future[(IndexResults[IndexTest], IndexResults[IndexTest])] = for {
14. result1 <- IndexTestManager.searchAsync(indexQuery)
15. result2 <- IndexTestManager.searchAsync(indexQuery2)
16. } yield (result1, result2)
17. Async {
18. l.map { case (r1, r2) =>
19. Ok(r1.totalCount + " - " + r2.totalCount)
20. }
21. }
22. }
23. }

Télécharger Conclusion

Si vous avez besoin d'intégrer facilement Elasticsearch dans votre projet Playframework, n'hésitez pas à tester ce module. Vous le trouverez sur notre dépôt Github - Les tests sont éxécutés automatiquement à l'aide de Travis-CI.

Les futures versions devraient proposer les améliorations suivantes :

• Gestion des documents Parent/Child de manière simple
• Développement d'une application d'exemple permettant d'illustrer les différentes fonctionnalités
• Amélioration de la documentation

Toutes les remontées et les Pull Requests sont les bienvenues !