Infotel, fier d’être partenaire technologique de Datastax

Pourquoi ce partenariat ?

1. Infotel a récemment lancé son plan stratégique appelé « Plan Performance 2016 » dans lequel le Groupe a pour objectif d’accompagner ses clients dans leur stratégie Big Data. Ce partenariat permet à Infotel de compléter son expertise dans la gestion des grandes bases de données et élargir sa maîtrise de l’écosystème Big Data dans lequel Datastax joue un rôle majeur.


2. Pour Datastax, ce partenariat met à disposition de ses clients l’expérience d’intégrateur d’Infotel déjà impliqué dans de nombreux développements autour des systèmes distribués et des grandes bases de données. Infotel participe à la migration des grands comptes vers le NoSQL, en France comme à l’international.


Quelle est la valeur ajoutée pour les clients d’Infotel ?

Infotel fournit à ses clients un support adapté à leurs besoins pour intégrer les nouveaux outils du NoSQL, comme Cassandra, dans leur SI. Les capacités de Cassandra pour l’écriture rapide de quantités massives d’informations en font en effet une des bases de données majeures de la tendance NoSQL. Distribuée par Datastax, elle représente un outil de choix lorsque l’on cherche une base de données scalable sans single point of failure. Appartenant à la famille des bases de données colonnes, elle constitue une véritable alternative face à d’autres systèmes de stockage structurés.

Interface OpsCenter permettant la supervision de clusters Cassandra


Infotel complète son panel de technologies mises en œuvre sur ses plateaux et vous accompagne grâce à ce partenariat. Avec Infotel, vous pouvez fournir à vos équipes projet le support Datastax dont elles ont besoin pendant les cycles de développement et jusqu’à la mise en production de vos applications.


Vous souhaitez en savoir plus ?

N’hésitez pas à nous contacter : ingenierie.technique@infotel.com



Retour sur DevoxxFR 2015 CDI

Cette année encore, de nombreux Infoteliens ont participé au Devoxx France qui s’est tenu pendant 3 jours du 8 au 10 juin au Palais des Congrès de Paris.

François NASSOY nous fait un retour sur CDI

Introduction

Contexts and Dependancy Injection (CDI) est une spécification (JSR 299) de JAVA EE qui défini une interface de programmation pour la gestion des injections des dépendances.
Le mot d’ordre de CDI pourrait être : Avec CDI, on injecte tout dans tout!
Les principaux services offerts par CDI sont :

  • Contexte : la capacité à lier le cycle de vie et les intérractions des composants stateful ou l’ensemble des contextes est extensible.
  • L’injection de dépendance: La capacité d’injecter des componants de manière typée et de choisir le spectre d’utilisation (developpement / deploiement)

CDI offre aussi, un certain nombre de services complémentaires :

  • L’intégration de l’Expression Language (EL) permettant à tous les objets contextuels d’être utilisés directement dans les pages JSF et/ou JSP.
  • La capacité de décorer les objects injectés
  • La capacité d’associer des interceptors avec des components en utilisant typesafe interceptor bindings
  • Un modèle de notification d’evénement
  • L’ajout d’un nouveau Scope au trois classiques (request, session and application) : scope conversation
  • Une SPI permettant une intégration propre de CDI aux conteneurs tiers

Premier pas avec CDI

Injection de dépendance

L’injection avec CDI est tres simple. En effet, pour injecter un bean, il suffit d’annoter une classe, un attribut de classe, ou une méthode (setter, constructeur) avec l’annotation @Inject.

Injection d’un DAO :

  • Sur l’attribut

    @inject
    private MyClassDao myClassDao
  • Sur le setter

    private MyClassDao myClassyDao
    @inject
    public void setMyClassDao(MyClassDao myClassDao){
    return myClassDao;
    }
  • Sur le constructeur

    private MyClassDao myClassyDao;
    @inject
    public MyClass(MyClassDao myClassDao){<br />
    this.myClassDao = myClassDao;
    }

Qualifier

Il est tres frequent qu’un bean posséde plusieurs implémentations. L’injection d’un tel bean via @inject provoque une erreur d’ambiguité. En effet, qu’elle implémentation utiliser ?
Pour pallier se problème, CDI propose les Qualifier. L’idée est que chaque implémentation soit qualifié, ie. nommé, et qu’à l’injection du bean soit spécifié quelle implémentation doit être utilisée.
Pour mettre en place cela, il faut :

  • Créer autant d’annotation que de Qualifieur annonter @Qualifier
  • Annonter les implémentations avec le Qualifier @NomQualifier
  • Ajouter lors de l’injection le Qualifier : @inject @NomQualifier
  • Création des annotations
    @Qualifier
    @Retention(RUNTIME)
    @Target({FIELD, TYPE, METHOD, PARAMETER})
    public @interface MyFirstImplDao {
    }
     
    @Qualifier
    @Retention(RUNTIME)
    @Target({FIELD, TYPE, METHOD, PARAMETER})
    public @interface MySecondImplDao {
    }
  • Annotation des implémentations

    @myFirstImplDao
    public class MyFirstImplDaoImpl implements MyClassDao {...}
     
    @mySecondImplDao
    public class MySecondImplDaoImpl implements MyClassDao {...}
  • Injection

    @inject @mySecondImplDao
    private myClassDao;

CDI defini un Qualifier par defaut via l’annotation @Default, permettant ainsi de ne pas devoir préciser le qualifier lors de l’injection.

  • L’injection
    @inject
    private myClassDao;
  • Equivaut à l’injection

    @inject @Default
    private myClassDao;

Produces

Toutes applications JAVA, ou presque, utilisent des librairies externes (log4j, Hibernate, etc.). CDI permet nativement d’inject des beans de librairie externe du moment qu’elles soient elles même des librairies CDI.

La différence entre une librairie CDI et une librairie non CDI est la présence ou non d’un fichier, beans.xml, dans l’archive. La librairie CDI devant posséder ce fichier.

CDI propose un mecanisme pour résoudre le problème d’injection de bean d’une librairie non CDI. Ce mécanisme consiste à rendre injectable un bean d’une librairie tiers en utilisant les Producer CDI, annotation @Produces. Ces produers ont pour but de de créer des objects injectables qui peuvent être de types primitifs, des beans ou encore des ressources telles qu’un entityManager, une connection JMS, etc.

Pour rendre un élement (méthode, attribut, beans, ..) injectable, il suffit de le nommer via un Qualifier et de l’annonter via @Produces.

  • Injection d’un type primitif qui ne varie pas au Runtime
    public ClassA {
    private int myNumber = 10;
     
    @Produces @MyNumber
    int getMyNumber() {
    Return myNumber;
    } 
    }
    Public ClassB {
    @Inject @MyNumber
    Int myNumber;
    }

    le ClassB.myNumber est directement initialisée via ClassA.getMyNumber() à 10

  • Injection d’un type primitif qui varie au Runtime
    public ClassA {
    private java.util.Random random = new java.util.Random( System.currentTimeMillis() );
     
    java.util.Random getRandom() {
            return random;
    }
     
    @Produces @Random 
    int next() {
        return getRandom().nextInt(maxNumber);
    }
    }
    public ClassB {
    @Inject @Random
    Instance<Integer> randomInt;
     
    Int myRandom;
     
    void ClassB() {
    myRandom = randomInt.get()
    }
    }

l’injection se fait sur une déclaration d’une instance contextuelle de l’objet, utilisable ensuite via la méthode get().

  • Sans CDI
    public class MyDAO {
    @PersistanceContext(unitName="cdiEM")
    private EntityManager em;
    }
  • Avec CDI
    public class DatabaseProducer() {
    @Produces
    @PersistanceContext(unitName="cdiEM")
    @MyDatabase
    private EntityManager em;
    }
    public class MyDAO {
    @inject
    @MyDatabase
    private EntityManager em;
    }

Injection d’élement d’une librairie externe comme par exemple un Logger :

  • Sans CDI
    public class MyClass {
    private static final Logger LOG = Logger.getLogger(MyClass.class);
    }
  • Avec CDI
    public class LoggerProducer() {
    @Produces
    public Logger produceLogger(InjectionPoint injectionPoint) {  
    return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName());  
    }
    public class MyClass {
    @Inject
    private static final Logger LOG;
    }

    La méthode du producer à comme paramétre un injectionPoint, permettant entre autre, de récupérer les informatiosn sur le nom de la classe où l’élement est injecté.

Nommage EL

CDI permet de donner un nom EL (Expression Language) aux beans, via l’annotation @Named, afin qu’ils soient accessibles dans les pages JSF.

  • @Named
    public class MyBean {...}
  • Équivaut
    @Named(myBean)
    public class MyBean {...}
  • Et s’utilise ainsi dans les pages JSF
    <h:outputLabel value="#{myBean.oneMethod}" />

Alternative

CDI propose une autre fonctionnalité tres interressante, la possibilité de définir une implémentation alternative à un bean.

Un bean peut avoir plusieurs implémentations utilisées à des fins différentes et positionnées lors des developpements par injection via leurs qualifiers. CDI propose de définir des implémentations qui pourront être choisies directement au moment du deploiement permettant ainsi de changer une implémentation sans modification de code.

  • Gérer une logique métier spécifique au client determinée au runtime
  • Spécifier des beans qui sont valides suivant des scénarios de deploiement spécifiques
  • Créer des versions MOCK des beans

Pour créer une alternative, il faut :

  • créer une implémentation
  • annoter la classe avec @alternative
  • definir les qualifiers impactés par l’alternative
  • déclarer l’alternative dans le beans.xml
  • Dao bean avec trois implémentations
    @myFirstImplDao
    public class MyFirstImplDaoImpl implements MyClassDao {...}
    @mySecondImplDao
    public class MySecondImplDaoImpl implements MyClassDao {...}
    @mytThirdImplDao
    public class MythirdImplDaoImpl implements MyClassDao {...}
  • Création de l’alternative
    @alternative
    public mockDAO impléments MyClassDao {}
    Ajout des qualifier devant être remplacer par l’alternative (1 ou plusieurs)
    @alternative
    @myFirstImplDao
    @mySecondImplDao
    public MockMyClassDAO impléments MyClassDao {}
  • L’injection des implémentations ne change pas
     
    @inject @mySecondImplDao
    private myClassDao;

    à ce stade, c’est toujours l’implémentation MySecondImplDao qui sera utilisée

  • Activation de l’alternative dans le beans.xml
    <alternatives>
       <class>fr.exemple.alternative.MockMyClassDAO</class>
    </alternatives>

    à partir de cette instant, c’est l’implémentation alternative, ici le mock, qui sera utilisé en lieu et place des implémentations MyFirstImplDao et MySecondImplDao.
    L’alternative ne portant pas le qualifier de l’implémentation MyThirdImplDao, les injections liés à cette implémentation ne seront pas impactées par l’alternative. Ce sera toujours l’implémentation MyThirImplDao qui sera utilisée.

Event

CDI offre aussi la possibilité aux beans de produire et de consommer des evénements (events). Ce mécansime permet une interaction entre beans via un couplage asynchrone sans utiliser JSM. Il permet aussi de synchroniser et capter les changements d’état de bean stateful.

Un évement est matérialisé soit par un event objet soit par un playload et est qualifié via un ou plusiuers event qualifiers. Ces qualifiers permettent de determiner les events à produire ou à observer pour un bean donné.

    Le principe est simple :

  • mise en place d’un event à observer
    • création d’un qualifier pour l’event
    • création de l’event
    • création de la(des) méthode(s) déclanchant l’event
  • mise en place des observer
    • création de la(des) méthode(s) écoutant l’event
  • Qualification de l’event
    @Qualifier
    @Target({FIELD, PARAMETER})
    @Retention(RUNTIME)
    public @interface Updated {}
  • Création de l’event
    @Inject @Updated 
    Event<User> userEvent;
  • Création de la méthode déclanchant l’event
    public void myMethod(Event<User> userEvent) {
       ...
       userEvent.fire(user);}
  • Création d’un observateur quelque soit le qualifier de l’event
    public void onAnyUserEvent(@Observes User user) {}

    méthode déclanchée pour tout event de type userEvent

  • Création d’un observateur pour un events spécifique
    public void afterUserUpdate(@Observes @Updated User user) {...}

    méthode déclanchée pour les event qualifiés @Updated

Conclusion

Bien que cet article ne presente qu’un bref appercu des possibilités de l’API CDI, il transparait assez clairement que CDI apporte un vrai plus à JAVA EE6, de part sa facilité d’utilisation et ses nombreuses fonctionnalités. CDI est une remise en cause de la façon de traiter l’injection de dépendances et les AOP. Il simplifie, il réduit, il se débarrasse de l’héritage, des idées dépassées.

Dans le domain des injections de dépences, des AOP, etc., une API revient reguliérement, Spring. Bien que à mon sens Spring ait encore une longueur d’avance sur CDI, CDI ne démerite pas, loin de là même. Il offre une tres bonne altérnative voir un complément. En effet, des mécanismes permettent d’intégrer les deux API.



SAP HANA (sur Amazon Web Services), l’in-memory pour booster l’analytique.

Nous vous proposons de parcourir les caractéristiques de HANA la base in-memory colonne développée par SAP, et vous inviter à connaître la solution au travers de l’offre de Amazon Web Services qui offre un terrain de jeu parfait pour un POC.

HANA : Une base colonne en mémoire

Avec l’avènement des nouvelles architectures matérielles vers 2005 ( CPU plus nombreux et plus rapides, RAM dépassant le TB ), les bases colonnes ont trouvé un support leur permettant de se développer industriellement. A ce jour, outre HANA, on peut citer Vertica ( HP ) ou Oracle ( option in-memory ) comme alternatives sur une machine Unix/Linux. Mais plus généralement, tous les grands éditeurs possèdent une option colonne dans leur catalogue et il est frappant d’observer qu’il n’existe pas (encore ?) de bases colonnes open source disponibles du type Cassandra ou Couchbase !

Les bases in-memory colonnes ont pour but d’optimiser l’OLAP, c’est-à-dire l’analytique en direct. Pour ce faire, elles se reposent sur les principales caractéristiques suivantes :

  • Un taux de compression de 10 ou plus sur les colonnes :

    En effet, l’entropie est beaucoup plus faible sur une colonne que sur une ligne, les données se « ressemblant » plus. Ainsi, des algorithmes de compression moins consommateurs en CPU ( RLE, bit-vector, dictionnary, … ) ont pu être mis en oeuvre pour profiter de cette faible entropie.
  • Une nouvelle localisation des données :

    Au démarrage de l’instance, les données sont chargées en RAM. Puis, la vectorisation des colonnes permet à ces dernières de résider dans les caches du processeur, d’où une accélération supplémentaire en terme d’accès à la donnée.
  • Une parallélisation accrue :

    Au niveau des processeurs, la technologie SIMD ( SingleInstructionMultipleData ) permet d’effectuer des opérations binaires entre les vecteurs.

HANA propose d’aller plus loin en se positionnant comme une base pouvant également gérer l’OLTP, un choix différent d’Oracle qui propose le mode colonne en complément du mode ligne.

Pour ce faire, SAP a introduit un concept de merge delta permettant de gérer les mises à jour unitaires et en masse. Pour les mises à jour unitaires, la zone delta est en mode ligne. Les données sont ensuite déversées dans la zone réservée aux mises à jour de masse, zone en mode colonne non optimisée. Enfin, les données rejoignent la zone principale de manière asynchrone. Sur ce point, l’éditeur doit encore faire ses preuves, la plupart des cas d’utilisation publiés étant relatifs à la BI.

Quel impact sur le développement ?

Le développement des requêtes se fait en SQL et les procédures stockées sont écrites en SQL Script. La grammaire SQL est déjà bien étoffée ( lien : http://help.sap.com/hana_appliance => SAP HANA SQL and System Views Reference). En revanche, le langa
ge SQL Script (SAP HANA SQLScript Reference ) est principalement dédié au traitement OLAP, en particulier les fonctions qui ne sont utilisables que pour les lectures afin de les paralléliser au mieux. Les procédures, quant à elles, permettent d’encapsuler les requêtes SQL de toute nature, mais il est encore pénalisant de gérer les transactions ( commit & rollback non autorisés ) au sein d’elles.


De plus, SAP met en avant un modèle analytique basé sur des attribute view ( dimensions ), des analytical view ( tables de fait ) et des calculation views ( calculs sur les tables de fait ) permettant de concevoir un modèle en étoile dans un contexte colonne. Les calculation views se basent sur des CE-Build In fonctions ou des requêtes SQL de lecture. Il existe aussi un outil de conception entièrement graphique qui permet de mettre en oeuvre ce modèle analytique.


Lancer son instance HANA dans AWS


Afin de promouvoir HANA, SAP propose de s’initier à ce produit via Amazon Web Services (AWS). L’instance HANA peut être déployée à Francfort ou en Virginie du Nord. Petite limite observée à ce jour, Il est préférable de déployer sur l’instance des Etats-Unis, pour surmonter des problèmes de disponibilité (machine non réservée perte de contexte à chaque arrêt / démarrage ). Elle repose sur une machine Linux Suse de type m2.4xlarge ( 8 vcpu, > 60 GB RAM ).


En termes de coût, l’instance HANA est gratuite et l’infrastructure mise à disposition par AWS payante (Remarque : le coût de possession sur ses propres infrastructures n’est pas sur ce modèle). A titre d’exemple, le coût peut être déchiffré de la manière suivante :

$1.080 par heure d’exécution ;
$0.05 par GB au-delà de 30 GB par mois ;
$0.05 pour un million d’IO au-delà de 2 millions d’IO par mois ;
$0.095 par GB ( snapshot ) au-delà de 1 GB par mois ;
Taxes (20 %).


opérationnel en 2 heures

En termes technique, la procédure est décrite à cette adresse : http://scn.sap.com/docs/DOC-28294 et permet d’être opérationnel en 2-3 jours, le temps d’initialiser le compte AWS. Si ce dernier existe déjà, l’installation est faite en quelques heures, le temps de se familiariser avec la version cloud d’HANA.

Bien que relativement simple d’appréhension, la création de l’instance HANA peut vous conduire à recevoir des erreurs délivrées par les web services d’AWS.

Exemple : lors de la configuration du compte AWS, vous pouvez tomber sur cette page:

Dans ce cas, contacter le support disponible sous AWS ; il est très réactif.
Une fois l’installation effectuée, l’instance se pilote via le site HANA Enterprise Cloud/Cloud Appliance Library :
HANA Enterprise Cloud

HANA STUDIO, client basé sur Eclipse, permet de développer, d’administrer et de monitorer l’instance HANA.
HANA Studio

Pour étudier cette solution, j’ai créé quelques tables en mode colonne ( nombre de colonnes variant entre 10 et 50, nombre de lignes variant entre quelques dizaines de milliers et 1 million ). Mon objectif n’était pas de tester des grandes tables ( plus de 1 GB en mode compressé ), mais de vérifier l’efficacité de la compression en mode colonne. Sur ce point, j’ai bien retrouvé des facteurs de 10 ou plus sur les colonnes non uniques.


D’autre part, je souhaitais étudier le SQL Script et ses limites pour la mise à jour. Je vous ai déjà parlé de la non gestion des transactions, mais il faut aussi savoir qu’il ne dispose pas de bulk collect. Si vous souhaitez l’équivalent, il vous faudra par exemple utiliser le mode batch de la couche JDBC. Comme alternative payante, vous pouvez utiliser SLT, un outil de réplication ou Data Services, un outil de chargement des données. Pour le chargement des fichiers, vous disposez aussi d’une commande import gratuite et optimisée ( thread, batch size ).


Enfin, je me suis intéressé à l’optimiseur colonne de HANA afin de mieux comprendre comment il fonctionne en terme de gestion des jointures ( jointure à 1 ou n colonnes ), d’utilisation des colonnes, de calculs d’agrégat. Pour ce faire, un outil indispensable : SAP HANA Plan Viz. Pour information, Hana dispose aussi d’un optimiseur ligne pour les tables en mode ligne et d’un optimiseur en mode OLAP pour le modèle analytique.

Changer de technologie c’est changer de paradigme

Avant de se lancer dans le grand bain, il faut appréhender ce nouveau type de solution en changeant de paradigme : le mode ligne n’est plus applicable ; il faut comprendre comment les opérations de lecture et d’écriture sont repensées et construire son modèle de données selon ces particularités. Un simple exemple très explicite: les index sont la plupart du temps inutiles en mode colonne.
Enfin, je vous conseille de lire ce post : http://scn.sap.com/community/hana-in-memory/blog/2013/12/29/6-golden-rules-for-new-sap-hana-developers.

Pour en savoir plus sur les bases colonnes et HANA :

  • Column-Oriented Database Systems : S.Harizopoulos, D.Abadi, P.Boncz [ VLDB 2009 Tutorial ];
  • The Design and Implementation of Modern Column-Oriented Database Systems: D.Abadi, P.Boncz, S.Harizopoulos, S.Idreos [ Foundations and Trends in Databases, 2012 ];
  • Building Advanced Data Model with SAP HANA: W.Steyn [ 2011 ];
  • Best-practices-for-sap hana data load: http://scn.sap.com/community/hana-in-memory/blog/2013/04/08/best-practices-for-sap-hana-data-load.

    • Stéphane NOTTER, Expert Architecture des données.



Premier pas dans l’internet des objets avec les Beacons

Nous voulons partager avec vous notre projet Beacon tout juste sorti par notre équipe Innovation.

L’idée est de pouvoir accompagner nos clients dans leurs projets disruptifs et force est de constater que l’Internet des Objets (IoT) est au cœur des enjeux du moment. L’annonce de Google concernant le ‘Web Physique’ (https://github.com/google/physical-web/blob/master/documentation/introduction.md ) ne va pas démentir cette observation.


Toujours plus contextualisée et personnalisée, l’information va vivre au contact des balises Beacons, tags NFC ou autre. Notre projet est de démontrer le potentiel de ces technologies en associant une application mobile avec une solution Web qui officie à la fois comme pilote des fonctions contextualisées et réceptacle du flot de données généré (…Big Data, le mot est lâché).


Fonctionnement schématique de la solution

Fonctionnement schématique de la solution



Première étape, l’acquisition de la balise et sa configuration.

On trouve des sites qui offrent des packages prêts à l’emploi, il faut ensuite associer paramétrer les quelques informations qui seront émises par notre balise.

  • UUID : c’est l’identifiant unique de notre balise, modifiable et donc personnalisable
  • Major : un des paramètres modifiables; on pourra y associer par exemple un numéro de magasin
  • Minor : autre paramètre, qu’on peut penser comme une précision apportée à un ensemble de balises reliées par la valeur d’un ‘Major’, comme le rayon d’un magasin
Balises utilisées pour le projet d'Infotel

Deuxième étape, créer l’application qui va capter le signal et prendre la décision appropriée :

Prérequis, il faut que votre téléphone embarque la prise en charge du BlueTooth Low Energy, qui est aujourd’hui disponible pour les smartphone sous iOS, Android 4.3 et Windows 8.
Une fois maîtrisée la détection du signal, on crée différentes interactions, différenciées selon que l’application est en veille ou en premier plan.

Capture Alerte iBeacon Catpure notification présence iBeacon
Envoyer une alerte ou un message associé à la proximité d’une balise Lorsque l’application est en veille, les notifications sont possibles, de manière plus ou moins intrusive.
Pour une interaction plus riche, on propose l’affichage d’un contenu HTML qui est fourni par notre serveur, mais on pourrait également constituer un message si l’application mobile embarque la logique (catalogue de produit embarqué, envois de messages en mode chat).

Voici le périmètre de notre solution :

  • Créer une application qui capte les signaux des Beacons,
  • Dans une approche connectée, envoyer au serveur les informations techniques de la balise associée à son identifiant,
  • Recevoir en retour l’action à déclencher qui se peut prendre une des valeurs suivantes :
    Aucune action : nous voulons simplement enregistrer le passage de notre usager,
    Réveil de l’application,
    Affichage d’une notification,
    Affichage d’un contenu Web (dans une WebView).
  • Filtrer les événements pour ne pas prendre en compte les signaux qui ne sont pas directement liés à notre parc de balises,
  • Afficher un sémaphore de présence de balises.


Par ailleurs, nous avons ajouté quelques fonctionnalités pour l’administration du parc : historique des signaux captés, débogage avec visualisation des informations techniques, configuration, et comportement par défaut au travers de ‘bouchons’ pour simuler une connexion à notre serveur.


Troisième étape, piloter son parc.


Il faut ensuite associer du contenu et des comportements à chaque balise, ce que nous faisons dans notre application centrale. En voici quelques captures d’écran représentatives.

Paramétrage d'une balise

Paramétrage d'une balise et association d'actions

création d'une action

Création d'une action type

Création d'une action générique

Visualisation d'une événement lié à une balise



Quatrième étape, analyser et améliorer.


Pour faire vivre la donnée et comprendre les comportements relevés par nos balises, rien de mieux que d’utiliser la masse d’information correspondant aux événements en les déversant dans ElasticSearch (par exemple).

On crée ainsi des tableaux de bord dans lesquels on décline les différentes actions, avec une visualisation temporelle.

On peut ensuite se pencher sur une classification et une analyse plus poussée.



Infotel partenaire d’Elasticsearch

Infotel est fier de vous annoncer son nouveau partenariat technologique avec Elasticsearch, effectif depuis le 12 mai 2014.




Logo Elasticsearch

Pourquoi ce partenariat ?

1.

Pour Infotel, il permet de développer son expertise reconnue dans la mise en œuvre de d’approches innovantes pour lesquelles Elasticsearch joue les premiers rôles.

2.

Pour Elasticsearch, il offre à ses clients la qualité de son support en l’accompagnant de l’expertise d’Infotel qui opère au cœur des systèmes d’informations complexes (Banque, Industrie Automobile, Assurance, Services…).


Infotel développe au cœur du métier de ses clients des solutions qui s’appuient sur les formidables capacités d’Elasticsearch à indexer et valoriser de très grandes quantités de données. Que ce soit de la donnée en texte libre (Documents, facture, Mails, tweets, forums..), des logs techniques, des logs applicatifs ou bien de la donnée statistique, la liberté offerte par Elasticsearch en fait un choix de premier ordre pour construire sa solution BigData.

Portail avec Elasticsearch

Exemple : Solution d'exploration documentaire motorisée par Elasticsearch




De plus, Infotel poursuit la montée en compétences de ses collaborateurs sur les technologies Big Data pour vous permettre d’accéder à un savoir-faire reconnu et en ligne avec votre stratégie IT. Vous pouvez désormais le compléter avec le support Elasticsearch dont vous avez besoin, lors de vos développements ou votre passage en production.


Vous voulez en savoir-plus ?
N’hésitez pas à nous contacter : ingenierie.technique@infotel.com