Integration Gateway en production : App Events, routes Camel et erreurs qui ne se perdent pas

Ce que change vraiment Integration Gateway par rapport aux intégrations embarquées dans PolicyCenter — et le détail qui fait la différence en exploitation : rendre l'erreur fonctionnelle visible pour le métier.

La documentation Guidewire explique bien ce qu'est Integration Gateway : un conteneur d'intégration externe à l'application, bâti sur Apache Camel. Ce qu'elle explique moins, c'est ce que ça change concrètement quand on livre des flux sur un programme PolicyCenter — et où se situent les vrais points durs.

Le problème : la logique d'intégration dans le cœur assurantiel

Historiquement, une intégration PolicyCenter vit dans l'application : du Gosu, des plugins, des appels sortants déclenchés depuis le modèle métier. Ça fonctionne, et c'est exactement pour ça que la dette s'accumule. Trois conséquences reviennent systématiquement :

Le cycle de vie de l'intégration est couplé à celui du cœur : changer un mapping vers le CRM impose de redéployer PolicyCenter.
La compétence requise se rétrécit : il faut du Gosu pour toucher à un flux qui, sur le fond, est un appel REST.
La frontière fonctionnelle se brouille : la règle métier et la plomberie technique cohabitent dans le même code.

Ce que change Integration Gateway

Integration Gateway sort cette logique du cœur applicatif et la place dans un conteneur léger, séparé, où les flux s'écrivent en routes Apache Camel. Le déplacement paraît modeste. Il ne l'est pas : il redéfinit qui peut travailler sur quoi, et à quel rythme.

Les flux se déploient indépendamment du cœur assurantiel.
Les connecteurs REST et SOAP vers les systèmes aval — paiement, CRM, gestion documentaire — deviennent du code d'intégration ordinaire, avec les outils et les réflexes correspondants.
Le mapping bidirectionnel entre le modèle Guidewire et des modèles externes hétérogènes devient une responsabilité explicite, localisée, testable.

App Events : capter l'événement métier, pas la mutation technique

C'est le point de bascule de la conception. Une intégration naïve écoute des changements de données. Une intégration durable écoute des événements métier : émission de police, avenant, résiliation. Les App Events donnent exactement ce vocabulaire.

La différence se paie plus tard. Un flux branché sur « la table a changé » casse à la première refonte du modèle. Un flux branché sur « une police a été émise » survit, parce que l'événement métier, lui, ne change pas de sens. C'est aussi le langage que parlent les analystes d'affaires : la modélisation des flux avec eux devient une conversation sur le métier, pas sur des colonnes.

La route Camel : idempotence d'abord

Une fois l'événement capté et publié — via JMS, typiquement — la route fait trois choses : elle se protège des doublons, elle transforme, elle traite l'échec. Dans cet ordre d'importance. La messagerie garantit la livraison, pas l'unicité : sans consommateur idempotent, un rejeu crée un doublon dans le système aval, et un doublon dans un CRM ou une plateforme de paiement se paie en appels clients.

from("direct:policyIssued")
    .idempotentConsumer(header("eventId"), idempotentRepository)
    .transform().method(policyMapper, "toCrmContract")
    .doTry()
        .to("rest:post:/contracts")
    .doCatch(HttpOperationFailedException.class)
        .to("direct:functionalError")
    .end();

Forme générique d'une route — illustration, pas du code de production.

L'erreur fonctionnelle est le vrai sujet

L'erreur technique est facile : le système aval répond 500, on rejoue, on alerte l'exploitation. L'erreur fonctionnelle est le cas difficile — le système aval répond correctement « je refuse », parce que la donnée ne lui convient pas. Rien n'est cassé techniquement. Personne n'est réveillé. Et le dossier reste en travers, invisible, jusqu'à ce qu'un client appelle.

La réponse qui marche n'est pas une alerte de plus dans un canal que personne ne lit. C'est de transformer l'échec en travail assigné, là où travaillent les gens concernés : dans PolicyCenter, via les activity patterns. Une intégration qui échoue fonctionnellement crée une activité de suivi sur le dossier, avec un responsable.

Une erreur d'intégration qui n'atterrit dans la file de personne n'est pas une erreur détectée : c'est une erreur différée.

C'est le changement qui, en exploitation, fait la plus grosse différence — et il ne coûte presque rien : de la configuration XML, pas du code.

Ce que je vérifierais avant la mise en production

1. Chaque route est-elle idempotente sur l'identifiant d'événement, et non sur un identifiant métier réutilisable ?
2. Un échec fonctionnel produit-il une tâche assignée à quelqu'un, ou seulement une ligne de log ?
3. Les analystes d'affaires savent-ils lire la cartographie des App Events sans lire le code ?
4. Les jeux de données QA couvrent-ils les avenants et les résiliations, pas seulement l'émission — le chemin nominal est celui qui casse le moins ?
5. Les logs Integration Gateway permettent-ils de rejouer un cas précis, ou seulement de constater qu'il a échoué ?

En résumé

Integration Gateway déplace la logique d'intégration hors du cœur assurantiel : c'est un gain de découplage réel. Mais l'essentiel de la qualité d'une intégration d'assurance ne se joue pas dans le chemin nominal — il se joue dans la façon dont l'échec revient à un humain capable d'agir.