lumnik. / scénarios Tous les scénarios · English

Les listes d'un formulaire de sinistre viennent du CRM sans exposer son GraphQL

Objectif Alimenter les listes d'un formulaire depuis un CRM GraphQL sans que le navigateur dépende du schéma du CRM.

Le type et le sous-type de sinistre vivent dans un CRM qui parle GraphQL. lumnik l'ingère page par page et en fait une entité canonique.

insurance-case-options.json
[
  {"id":"AUTO-COLLISION","typeCode":"AUTO","typeLabel":"Automobile","subtypeCode":"COLLISION","subtypeLabel":"Collision","typeOrder":10,"subtypeOrder":10,"active":true},
  {"id":"AUTO-GLASS","typeCode":"AUTO","typeLabel":"Automobile","subtypeCode":"GLASS_BREAKAGE","subtypeLabel":"Bris de glace","typeOrder":10,"subtypeOrder":20,"active":true},
  {"id":"AUTO-THEFT","typeCode":"AUTO","typeLabel":"Automobile","subtypeCode":"THEFT","subtypeLabel":"Vol du véhicule","typeOrder":10,"subtypeOrder":30,"active":true},
  {"id":"HOME-WATER","typeCode":"HOME","typeLabel":"Habitation","subtypeCode":"WATER_DAMAGE","subtypeLabel":"Dégât des eaux","typeOrder":20,"subtypeOrder":10,"active":true},
  {"id":"HOME-FIRE","typeCode":"HOME","typeLabel":"Habitation","subtypeCode":"FIRE","subtypeLabel":"Incendie","typeOrder":20,"subtypeOrder":20,"active":true},
  {"id":"HOME-BURGLARY","typeCode":"HOME","typeLabel":"Habitation","subtypeCode":"BURGLARY","subtypeLabel":"Cambriolage","typeOrder":20,"subtypeOrder":30,"active":true},
  {"id":"HEALTH-HOSPITAL","typeCode":"HEALTH","typeLabel":"Santé","subtypeCode":"HOSPITALISATION","subtypeLabel":"Hospitalisation","typeOrder":30,"subtypeOrder":10,"active":true},
  {"id":"HEALTH-DENTAL","typeCode":"HEALTH","typeLabel":"Santé","subtypeCode":"DENTAL_CARE","subtypeLabel":"Soins dentaires","typeOrder":30,"subtypeOrder":20,"active":true},
  {"id":"HOME-OLD-STORM","typeCode":"HOME","typeLabel":"Habitation","subtypeCode":"OLD_STORM_CODE","subtypeLabel":"Ancien code tempête","typeOrder":20,"subtypeOrder":90,"active":false}
]
manifests/20-insurance-case-option.yaml
kind: Entityname: ScenarioInsuranceCaseOptionBdescription: "An insurance claim type and subtype pair curated by the CRM."match: [option_id]scopes: [insurance]columns:  type_code:    label: "Claim type code"  type_label:    label: "Claim type"  subtype_code:    label: "Claim subtype code"  subtype_label:    label: "Claim subtype"  active:    label: "Available"sources:  - table: scenario_insurance_case_option_b    map:      option_id: option_id      type_code: type_code      type_label: type_label      subtype_code: subtype_code      subtype_label: subtype_label      type_order: type_order      subtype_order: subtype_order      active: active
GET /form-options/claim-types
AUTO Automobile · HOME Habitation · HEALTH Santé
… /AUTO/sub-types
COLLISION Collision · GLASS_BREAKAGE Bris de glace · THEFT Vol du véhicule
… /HOME/sub-types
WATER_DAMAGE Dégât des eaux · FIRE Incendie · BURGLARY Cambriolage

preuves: replay.log, 50-claim-types.json, 51-auto-subtypes.json, 52-home-subtypes.json, 53-unknown-type.json · transform v1

… /UNKNOWN/sub-types
404 · claim type not found

preuves: replay.log, 50-claim-types.json, 51-auto-subtypes.json, 52-home-subtypes.json, 53-unknown-type.json · transform v1

Limites

  • Le CRM est synthétique, mais parle les vraies formes de requête et de réponse Relay du connecteur GraphQL de lumnik.
  • Le BFF est de taille démonstration: il appelle lm à chaque requête. Un BFF de production appellerait l'API du hub avec sa propre identité et mettrait ces listes en cache.
  • Le BFF ne fait que lire; créer le dossier de sinistre dans le CRM sort du scénario.
  • La règle est active == true; dates d'effet, libellés par langue et éligibilité par produit seraient d'autres règles métier.
  • Données synthétiques.

Assurance · formulaire

Un formulaire de sinistre a deux listes.

Le type, puis le sous-type.

Les deux vivent dans un CRM qui parle GraphQL.

CRM synthétique

Le problème

Le schéma du CRM devient le contrat du navigateur.

  • Le front appelle le GraphQL du CRM.
  • Chaque changement du CRM casse le formulaire.
  • Un code retiré peut rester proposé.

Rien n'est modifié

Le CRM garde son GraphQL.

  • lumnik le lit page par page.
  • Une entité porte des noms stables.
  • Le formulaire lit du JSON REST.

Ce qu'il a fallu écrire

kind: graphql
query: |
  query InsuranceCaseOptions($after: String) {

GraphQL est une forme de requête, pas un connecteur.

Le scénario complet tient en 2 fichiers de déclaration, 78 lignes.

Ce que voit l'assuré

Automobile: trois sous-types.

  • Collision.
  • Bris de glace.
  • Vol du véhicule.

Réponse réelle du BFF, rejeu du 3 novembre 2026.

Une liste remplacée

Habitation remplace la liste.

  • Dégât des eaux, incendie, cambriolage.
  • Collision n'y reste jamais.
  • Le code retiré n'est pas proposé.

La limite

Le BFF est de taille démonstration.

  • Il appelle lm à chaque requête.
  • En production: l'API du hub et un cache.
  • Créer le sinistre dans le CRM sort du scénario.

Essayer

Le scénario se rejoue de bout en bout.

CRM GraphQL, entité, BFF: chaque étape est publiée avec sa sortie.

Ce scénario tourne sur lumnik Open, gratuit et open source.

Essayer lumnik Open →