Comment superviser les flux entre applications ?

Les flux de données s’accélèrent dans les Systèmes d’Information. Tout le monde veut faire du business avec ses nouvelles API.

Mais à chaque fois que c’est en ligne, on m’interroge: Comment puis-je vérifier que tout fonctionne ? Comment mes équipes métier peuvent suivre les appels ? Est-ce que mes flux restent bloqués ? Comment les erreurs remontent-elles ? Que faut-il suivre ? Existe-il des bonnes pratiques ? Est-ce que mon équipe IT de développement des flux va être submergé par le support ? Quels sont les outils disponibles ? Existe-t-il des standards ? etc.

Je vous propose ma vision à ce sujet passionnant mais très mal outillé par les éditeurs traditionnels. La question est réduite à son plus simple appareil:

Comment superviser les flux entre applications ?

dixit tous LES DSI.

La réponse nécessite de prendre un peu de recul.

Lire la suite “Comment superviser les flux entre applications ?”

Présentation rapide de Apigee-X

Google Apigee-X est la nouvelle version de la solution de management des API de Google. Il s’agit de la version nommée “hybrid”.

Voici les notions principales pour réaliser des API dans Apigee-X.

Développement d’API

API = Proxy

APIgee propose la gestion de “proxies” qui regroupent les comportements des opérations d’un contrat OpenAPI ou Swagger.

Lire la suite “Présentation rapide de Apigee-X”

CI/CD avec l’API Management Azure

Objectifs

L’intégration continue (CI) et le déploiement continue (CD) sont des pratiques indispensables aujourd’hui. Tant pour construire, déployer ou encore configurer une plateforme. Elles sont progressivement absorbées par les pratiques DevOps. Ces pratiques CICD ont pour principaux objectifs de:

  • automatiser le build des artefacts,
  • automatiser le déploiement de ces artefacts vers des environnements cibles.

Dans le cas de l’API Management pour Azure, il est nécessaire de déployer les éléments suivants:

  • les API et leurs contrats respectifs,
  • les Policies, stratégies ou traitements internes,
  • les BackEnds, cibles des API,
  • les NamesValues, ou tables de références externes.

Une version d’une API est alors la combinaison de tous ces éléments. C’est leur combinaison qui est le résultat d’un déploiement vers une plateforme de Recette ou de Production, par exemple.

Chaque API possède son propre cycle de vie. Les étapes de construction, de validation et de déploiement sont temporellement décorrélées les unes des autres API. Au quotidien, chaque API doit être gérée de manière unitaire.

Contextualisation ou Variabilisation

L’automatisation est un point important mais il s’accompagne systématiquement par la capacité à déployer dans plusieurs environnements. Pour cela, il est nécessaire d’intégrer des variables externes aux scripts CI/CD. Un livrable d’un environnement n’est donc pas égal à celui d’un autre.

Diffusion d’une API versionnée dans les environnements cibles.

Avec quels outils ?

Microsoft propose plusieurs outils, complémentaires ou non, pour supporter ces actions. La richesse et la multiplicité des solutions n’aide pas toujours…

Cet article détaille le résultat de mes travaux qui ont pour objectifs de mettre en place un socle de CI/CD complet et efficace pour l’ API Management Azure.

Lire la suite “CI/CD avec l’API Management Azure”

Exemple d’ API avec WSO2 ESB

Je profite d’une expérience récente pour vous montrer, dans un cas pratique, les qualités de la solution ESB de WSO2. Pour le situer dans les produits de WSO2, ce bus est le coeur de l’ Enterprise Integration (Intermédiations de Systèmes) et de l’ API Management (Plateforme de partage d’API). En quelques mots, ce bus est spécialisé dans les intermédiations de services HTTP.

L’exemple que je vous propose est assez simple et est pour moi représentatif. Vous allez, je n’en doute pas, constater la lisibilité et la clarté des médiations réalisées avec cet ESB.

Le sujet que je vous propose est une API “utilisateur”. Elle présente des profils d’ utilisateurs. Elle puise ses données dans un annuaire Active Directory de Microsoft. Je ne m’attarde ici qu’à la médiation en tant que telle. Les outils WSO2 EI ou API Management portent d’autres fonctionnalités que je détaille pas dans cet article.

La conception de la route tient en 4 étapes:

  1. initialisation de la connexion LDAP,
  2. préparation de la requête,
  3. construction de la réponse.
  4. optionnel: la gestion d’erreurs.

Je vais dans la suite de cet article commenter cette API par étape, par bloc de code. Cela permettra de bien commenter chaque partie.

Lire la suite “Exemple d’ API avec WSO2 ESB”

API Days Paris 2018

Les 30 et 31 janvier, j’ai eu le plaisir de me plonger 2 jours dans les API au cœur de Paris, à la cité internationale universitaire. Il s’agissait du séminaire APIDays. Je venais y chercher des retours d’expérience, des approches pertinentes et des méthodes efficaces.

Avant de vous faire une synthèse de ces journées, je tiens à féliciter Mehdi Medjaoui pour la qualité de son organisation. C’était réussi. Bravo !

Aux APIDays,  je me suis focalisé sur les tracks Digital transformation et GDPR & Data Governance.

Lire la suite “API Days Paris 2018”

Gravitee sur OpenShift

Voici ma très courte procédure d’installation de la solution d’API Management Gravitee.io sur Openshift. Du simple et rapide comme j’aime 🙂 .

Objectif

Gravitee se compose de 2 DB: ElasticSearch et MongoDB ainsi que 3 modules: UI, API et Gateway.

Je souhaite avoir un environnement simple et bien compartimenté pour mes futurs projets d’API Gravitee, quelque chose comme ceci:

Lire la suite “Gravitee sur OpenShift”

SOA sans ESB

esbUn de mes clients m’a récemment poussé cette vidéo de Martin Fowler et Jim Webber sur une présentation acide sur la SOA et son outillage. Je vous partage ma vision.

En résumé, Martin et Jim attaquent là où ça fait mal: au niveau de l’agilité des processus de construction des intermédiations et sur la complexité des outils. Leur constat est (était?) le suivant:

Middleware propriétaire Technologies Web Centriques
– Non performant
– Coûteux
– Risqué
– Echelle de l’entreprise
– Spécialisé
– Intégration est une activité à part en tiers
– Design évolutif
– Delivry continue
– Pas couteux
– Incrémental
– Croix avec internet
– Intégration contrôlée par le consommateur

En un mot, ils préconisent la mise en oeuvre d’une démarche de services sans ESB car ils portent une complexité trop importante à contrario de l’approche Web. A ce propos, est-ce l’origine de la vague d’API Management actuelle ?

Bref, je comprends complètement leurs critiques. Pour être franc, j’ai moi-même connu des mastodontes tant sur leurs besoins en ressources matérielles que sur leur incapacité à évoluer. Mais…

Lire la suite “SOA sans ESB”

Transformation plus agile du Système d’Information

ConferenceLors de la mise en œuvre d’une démarche SOA outillé, je fais souvent le constat que l’interconnexion est assez coûteuse en effort humain. Il faut beaucoup communiquer pour clarifier les mécanismes envisageables, identifier les contraintes, définir les capacités du système, mettre en corrélation avec les patterns existants, etc. tout ceci avec de nombreux interlocuteurs : les chefs de projets, les architectes logiciels, les architectes systèmes, les architectes SOA et les urbanistes. Malgré tous ces efforts et après d’âpre discussions, le propriétaire du système craint alors des impacts sur ses flux existants et veut donc, tout naturellement, minimiser l’impact de ces nouveautés.

Derrière ce constat se cachent 2 problématiques :

  1. le manque de confiance dans la gestion du changement
  2. le manque de contrôle vis-à-vis de cet usage imposé.

Ce constat est exaspérant car il est consommateur d’une énergie folle. Il faut constamment se réunir et se synchroniser pour expliciter les besoins, décrire les données transférées, demander l’exécution d’un service (ensemble de règles) et faire correspondre avec les patterns et les outils d’interconnexions existants. Petit ou gros changements, l’effort humain pour faire aboutir ces besoins est majeur.

Les parties techniques sont souvent les plus simples. Il convient de mettre en place des mécanismes spécialisés portés par le Bus d’entreprise 9 fois sur 10. Voici quelques exemples:

  • Les connecteurs ABAP ou IDOC SAP
  • Les pooling et CDC (Change Data Capture) des bases de données
  • Les API d’accès aux couches natives
  • Exposition de règles par des Web Services

Pour chaque système, une série d’interconnexions est définie, prototypée puis validée.

Bref, chaque système subit l’évolution de son écosystème. En fonction des demandes externes, transverses ou globales, des interfaces supplémentaires sont ajoutées au fur et à mesure.

Lire la suite “Transformation plus agile du Système d’Information”

L’API Management, fruit de l’économie collaborative

confusionC’est en sortant d’une réunion pénible avec une équipe marketing que j’ai eu envie d’écrire cet article. “Ouvrir le Système d’information aux nouvelles opportunités” qu’ils disent. Mais en posant sur la table un flou d’expression de besoin, je dirai même un flou opaque, nous n’avons abouti à rien… Bref, à par Ubber et son modèle économique, c’est pas très clair. Je vous propose donc de rembobiner la problématique et de repartir sur des bases saines (et moi avec vous).

 
Je ne vous cache pas que de nombreux mots clés ont été échangés durant cette réunion (et les précédentes): API, API Management, développeurs affiliés, etc. Mais comme le disait un auteur inconnu:

Comprendre la solution, c’est bien. Comprendre le besoin, c’est essentiel.

Les exemples de réussites commerciales comme Ubber, BlaBlaCar ou AirB&B font envie à nos dirigeants d’entreprise. On nous le martèle à longueur de journée. Autre exemple, la vague des fintech bouleverse les banques habituées à, disons, une concurrence plus tranquille.

Lire la suite “L’API Management, fruit de l’économie collaborative”