Dossier réalisé en
partenariat avec Dreamsoft
Origine
et évolution de la solution
Fondé
en janvier 1998, Sunopsis se positionne à l'origine
sur le marché de l'ETL (Extract, Transformation
and Loading) en jouant notamment la carte des standards
Java. En 2001, à l'heure où les plates-formes
EAI s'imposent dans le paysage de l'intégration
logicielle, l'éditeur affiche à son tour
des ambitions dans ce domaine, jouant sur un angle d'attaque
du marché cohérent avec sa technologie.
A savoir celui de "l'intégration par les
données", par opposition aux pure players
de l'EAI, qui se veulent plus centrés sur l'intégration
par les processus.
La plate-forme de Sunopsis
appartient donc à ces solutions que l'on classe
habituellement dans la catégorie (plus ou moins
bien nommée) des "EAI tactiques". Au-delà
des débats théoriques (voire sémantique),
un fait s'impose : la solution de Sunopsis répond
à des besoins d'intégration d'applications
- même si cette intégration est très
orientée données comme nous allons le
voir. A ce titre, elle trouve sa place dans ce panorama
2003 de l'EAI. D'autant qu'il serait dommage de ne pas
s'arrêter sur l'un des rares acteurs français
de ce secteur. Français mais en voie d'expansion
à l'international puisque Sunopsis, adossé
à un porte-feuille d'environ 200 clients, a ouvert
deux filiales, à Boston et à Singapour,
l'année dernière.
Principes
et structure de l'offre
Parce qu'elle
est centrée sur l'intégration des données,
la solution de Sunopsis oblige à abandonner les
schémas habituellement utilisés pour analyser
et structurer une plate-forme d'EAI traditionnelle.
Il n'est en effet point question ici de serveur d'intégration
ou de broker. La logique est tout autre : au lieu d'exploiter
un moteur d'intégration au sein duquel s'opèrent
les opérations de transformation et de routage,
Sunopsis v3 (la version que nous avons évaluée)
s'appuie sur les capacités de traitement des
applications source et cible.
Le concept clef à
saisir ici est celui d'espace de travail. Quand un traitement
est élaboré à travers Sunopsis,
le développeur précise l'espace de travail
dans lequel il va s'exécuter. Cet espace peut
être réservé dans l'espace de l'application
source, de l'application cible ou éventuellement
dans le "Memory Engine" de la solution (nous
y reviendrons). Concrètement, des tables temporaires
sont créées dans les applications concernées
(bases de données, progiciels
). Autrement
dit, Sunopsis distribue le traitement des opérations
auprès des applications concernées et
s'appuie à cette fin sur leurs capacités
natives (SQL, PL/SQL, Java, etc.). In fine donc,
tout se termine avec Sunopsis par des traitements SQL.
Conséquence directe (à bien sous-peser)
: les performances des intégrations élaborées
à travers Sunopsis dépendent directement
des performances des applications sources et cibles
et non de celles d'un moteur d'intégration qui
s'interposerait entre ces éléments.
Côté transport,
si, dans l'esprit Sunopsis, les applications initient
et prennent en charge elles-mêmes les échanges
de données, elles peuvent aussi publier leurs
messages dans un MOM - l'éditeur fournira d'ailleurs
prochainement son propre bus (Sunopsis MQ). Pour la
connectique, précisons que la solution s'appuie
sur les standards Java : JDBC en premier lieu, mais
aussi JMS et JCA.
Pour comprendre la structure
de la plate-forme, distinguons les principaux outils
proposés et les composants mis en uvre.
Les
outils
|
Sunopsis
Topology Manager
|
Cet outil est utilisé pour identifier l'architecture
physique, puis logique du système d'information.
Bref, il s'agit ici d'identifier et de référencer
l'ensemble des ressources. C'est aussi à
l'aide du Topology Manager que sont définis
des contextes de développement, de recette,
de production, etc. Il est ensuite très
simple d'indiquer dans quel contexte l'on souhaite
travailler.
|
Sunopsis
Designer
|
Comme
son nom l'indique, le designer est l'outil de
développement principal. Ici, l'essentiel
s'orchestre via des glisser-déposer. Données
sources et données cibles sont glissées
dans une fenêtre afin d'être mises
ensuite en correspondance. Des déclencheurs
sont paramétrés (modification d'une
données, arrivée d'un email, publication
d'un fichier dans un répertoire, arrivée
d'un message dans une queue
), des contrôles
sont définis et les opérations de
mapping (transformation) sont précisées.
Pour chaque traitement, un espace de travail est
nommé.
|
Sunopsis
Security
|
Cet
outil permet d'éditer les habilitations
des différents utilisateurs de la plate-forme.
|
Sunopsis
Designer
|
Comme
son nom l'indique, le designer est l'outil de
développement principal. Ici, l'essentiel
s'orchestre via des glisser-déposer. Données
sources et données cibles sont glissées
dans une fenêtre afin d'être mises
ensuite en correspondance. Des déclencheurs
sont paramétrés (modification d'une
données, arrivée d'un email, publication
d'un fichier dans un répertoire, arrivée
d'un message dans une queue
), des contrôles
sont définis et les opérations de
mapping (transformation) sont précisées.
Pour chaque traitement, un espace de travail est
nommé.
|
Sunopsis
Operator |
Outil
destiné à l'exploitant, ce module
permet à l'opérateur de planifier,
surveiller, et de diagnostiquer les problèmes
d'exécution. |
Les
principaux composants mis en uvre
|
Les
référentiels
|
Sunopsis distingue le référentiel
maître (forcément unique) et les
référentiels de travail, tous hébergés
sur un SGBDR. A titre d'exemple, un agent (voir
ci-après) peut embarquer localement un
référentiel dit de travail afin
de limiter les risques d'une rupture de communication
avec le référentiel maître.
|
Les
modules de connaissance
|
Au nombre
d'une quarantaine, ils s'apparentent à
des méta-modèles de données.
Ces modèlent décrivent la logique
qui permettra de générer ensuite
des scripts dans des langages propres à
chaque application. Les principaux SGBDR et ERP
du marché sont aujourd'hui couverts par
ces modules de connaissance.
|
Les
agents
|
Dans
la philosophie de Sunopsis, les agents doivent
être vus comme des ordonnanceurs. En effet,
ces agents ne véhiculent pas les données
(même si cette possibilité existe)
: ils exécutent des scénarios qui
créent (et suppriment) les espaces de travail
dans les applications concernées au fur
et à mesure des traitements demandés.
Et ce sont les applications qui s'échangent
les données, quelque sorte en direct. A
noter qu'un agent peut faire appel aux scénarios
associés à un autre agent.
|
Le
Memory Engine
|
La plate-forme
dispose de son propre moteur de transformation
Java qui peut donc être exploité
comme un espace de travail intermédiaire
entre les données source et cible, même
si ce n'est pas vraiment l'esprit de la solution.
Ce Memory Engine s'avère notamment utile
quand les applications sources et cibles ne possèdent
pas de capacités de transformation. L'éditeur
indique que l'emploi du Memory Engine est préférable
quand le volume de chaque échange à
traiter est faible car tout s'opère en
mémoire. En revanche, pour de grandes volumétries
(plus de 10 000 lignes par minute), le recours
aux environnement sources et/ou cibles apporte
plus de performances.
|
Le
journal
|
Toutes
les opérations (création d'un espace
de travail, transformation, publication d'un message,
etc.) sont historisées dans un journal,
stocké dans le référentiel
auquel l'agent est connecté en permanence.
|
L'avis
de l'expert
(Mariano Boni, directeur technique de Dreamsoft)
Reconnaissons-le, avec l'outil de Sunopsis la frontière
entre ETL et EAI devient floue. Certes, les puristes
déduiront de l'absence d'un moteur d'intégration que
Sunopsis ne peut figurer aux côtés des offres EAI traditionnelles.
Cependant, dans les faits, la puissance et l'ergonomie
de cet outil d'intégration par les données répond bel
et bien aux enjeux fonctionnels que l'on associe à la
problématique EAI. Les règles d'intégration sont centralisées
dans un référentiel et la plate-forme est suffisamment
riche pour couvrir la plupart des scénarios d'intégration.
Mais "la plupart" seulement : en l'absence de moteur
d'intégration, le champ des possibles est forcément
limité par les fonctions même des applications
impliquées.
Reste la question des processus.
Là où les solutions d'EAI habituelles permettent d'opter
pour une approche Bottom-Up (par les flux techniques)
ou Top-Down (par les processus), Sunopsis impose la
première. L'éditeur, dont nous avons apprécié le discours
clair et direct, revendique d'ailleurs cette approche.
Ces représentants estiment en substance que l'engouement
des éditeurs d'EAI pour le BPM (Business Process Management)
est en décalage avec la réalité du terrain. Un point
de vue que nous nuancerons : certes l'effervescence
autour du BPM est probablement décalée au regard de
la maturité de l'urbanisation des systèmes d'information.
Toutefois, Sunopsis ne devrait pas perdre de vue que
tendre vers le processus représente bien le sens de
l'histoire
|