Fiche produit — Supply Service Registry
Repère de lecture
Public cible
Architecte, Développeur, Delivery
Temps de lecture
3 min
Usage
Relier les concepts FLOW aux produits, patterns et responsabilités cible
Intention
Le Supply Service Registry référence les services Supply que FLOW peut mobiliser.
Il décrit les APIs, événements, SLA, conditions d'appel, contraintes et responsabilités des services d'exécution.
Il permet aux Cases de dialoguer avec Supply sans connaître directement toutes les implémentations locales.
Il doit aller plus loin qu'un simple catalogue technique d'APIs : il doit porter les engagements opérationnels de service du monde réel, afin que les promesses FLOW restent compatibles avec ce que Supply peut réellement tenir.
FLOW ne doit pas connaître toute l'exécution en détail.
Il doit connaître les services Supply mobilisables et leurs contrats.
Responsabilités portées
- Référencer les services Supply consommables.
- Décrire leurs contrats d'interface.
- Documenter SLA, contraintes, périmètres et conditions d'appel.
- Clarifier les événements attendus en retour.
- Supporter la réintégration de services existants : C-LOG, CBS, WMS, transporteurs, outils fournisseurs.
Ce que le produit ne porte pas
- L'exécution physique des opérations.
- Le monitoring technique complet des systèmes externes.
- Les règles métier internes des systèmes Supply.
- La gouvernance contractuelle juridique avec les partenaires.
Consommateurs et contributeurs
| Acteur | Usage attendu |
|---|---|
| Cases | Identifier et appeler un service Supply. |
| Supply / C-LOG / CBS / WMS | Publier leurs capacités et contrats. |
| Architecture / intégration | Gouverner les interfaces et contrats. |
| Observabilité | Suivre disponibilité, SLA et incidents. |
Informations clés
| Information | Nature | Statut probable |
|---|---|---|
| Service Supply | Objet métier / Nomenclature | Source de référence FLOW ou projection Supply |
| API exposée | Nomenclature / Document | Source de référence FLOW |
| SLA | Policy | Source de référence ou projection |
| Contrat d'événement | Document / Policy | Source de référence FLOW |
| Éligibilité service | Policy | Source de référence ou projection |
| Statut de service | Fact | Projection |
Capacités à instruire
- Déclarer un service Supply.
- Décrire ses interfaces.
- Décrire les événements qu'il publie ou consomme.
- Décrire ses SLA et conditions d'appel.
- Rechercher un service éligible.
- Versionner un contrat de service.
- Suivre les dépendances entre Case et service Supply.
Interfaces à instruire
- API de consultation registry.
- API de publication / modification contrôlée de service.
- Événements publiés : SupplyServiceRegistered, SupplyServiceUpdated, SupplyContractChanged.
- Événements consommés : service unavailable, SLA degraded, contract updated.
Premiers epics backlog
- Définir le modèle minimal d'un service Supply.
- Référencer les premiers services candidats : C-LOG, CBS, WMS, transport.
- Définir les métadonnées d'API et d'événements.
- Définir les SLA et contraintes minimales.
- Exposer la recherche de services éligibles.
- Gérer le versioning des contrats.
- Définir le processus d'onboarding d'un service existant.
- Connecter le registry au Case Management.
- Mettre en place une première lecture d'observabilité.
- Définir les critères conserver / encapsuler / remplacer.
Questions ouvertes
- Le registry est-il un produit FLOW autonome ou une partie du Fulfillment Network ?
- Qui maintient les contrats : FLOW, Supply, architecture, intégration ?
- Les usines BRD et leurs lead times doivent-ils être modélisés comme services Supply, comme capacités de fabrication ou comme projections issues d'un référentiel spécialisé ?
- Quels services doivent être obligatoirement event-driven ?
- Quels systèmes existants ne peuvent pas être réintégrés sans évolution technique ?