Logistique et transport

Des partenaires reliés par contrat, des événements qui ne se perdent pas.

Chaque partenaire appelle une API déclarée et s'authentifie par certificat ou clé ; les mises à jour d'expédition partent en événements et en webhooks signés ; les systèmes existants restent derrière, gRPC compris.

Ce que Flexway décide, chez vous

Qui appelle, ce que Flexway décide, ce qui est appelé : chaque trajet est un cas d'usage de votre secteur. En pointillé, ce qui est à venir.

Architecture pour la logistique et le transport : les chargeurs, les transporteurs et les applications de suivi passent par Flexway, dans votre infrastructure. Flexway identifie chaque partenaire par sa clé ou son certificat, publie un statut reçu en HTTP sur le courtier, envoie depuis le courtier des webhooks signés aux systèmes partenaires, traduit REST vers gRPC et tient un budget de délai par opération, devant votre TMS et vos entrepôts, Kafka ou AMQP et vos services gRPC. Un amont appelé qui ne répond pas à temps donne un 504, puis le coupe-circuit s'ouvre.

Chargeurs: Les chargeurs : identifiés par clé d'API ou certificat client lié à un tenant, ils appellent vos TMS et entrepôts par Flexway.
Transporteurs: Les transporteurs : leurs mises à jour reçoivent 202 tout de suite ; le statut est publié sur votre courtier puis livré en webhooks signés.
Apps de suivi: Les applications de suivi : leurs appels REST atteignent vos services gRPC, traduits par descripteurs Protobuf.
Courtier consommé: Un courtier dont Flexway consomme les messages pour les livrer à vos partenaires en webhooks signés.
Clé ou certificat partenaire: Flexway vérifie qui appelle (jeton OIDC, clé d'API ou certificat client) et lit le tenant dans l'identité ; sans identité valide : 401.
Frontière synchrone, asynchrone: Flexway répond 202 tout de suite et publie la suite sur votre courtier : la frontière entre synchrone et asynchrone.
Webhooks signés: Flexway livre vos événements à vos partenaires en webhooks signés et rejouables.
Budget de délai par opération: Chaque opération a son budget de délai, avec coupe-circuit et reprises limitées aux méthodes idempotentes.
REST vers gRPC: Un appel REST est traduit en gRPC par les descripteurs Protobuf : votre service gRPC devient appelable en REST.
TMS et entrepôts: Vos TMS et entrepôts : appelés sous budget de délai et coupe-circuit, avec des reprises sûres.
Kafka, AMQP: Vos courtiers Kafka, AMQP, MQTT et NATS : Flexway y publie sous contrat AsyncAPI, en enveloppe CloudEvents.
Services gRPC: Vos services gRPC : servis en gRPC, en gRPC-Web et en REST traduit par descripteurs Protobuf.
Systèmes partenaires: Les systèmes de vos partenaires : ils reçoivent vos événements en webhooks signés et rejouables.

Ligne : un trajet
Correspondance : décision partagée
Requête
Événement
Refus
Votre infrastructure

Clé ou certificat partenairelié à un tenant
Frontière synchrone, asynchronestatut publié, réponse 202
Webhooks signésrejouables vers les partenaires
Budget de délai par opérationcoupe-circuit, reprises sûres
REST vers gRPCpar descripteurs Protobuf

1Un transporteur envoie un statut de livraison
Ce que Flexway décideLa passerelle publie le statut sur le courtier et répond 202 ; puis, depuis le courtier, le chargeur reçoit un webhook signé.
Ce qui est protégéAucun statut perdu : le webhook se rejoue en cas d'échec.
2Une app de suivi interroge un service gRPC
Ce que Flexway décideLa requête REST est traduite en gRPC par descripteurs Protobuf.
Ce qui est protégéL'existant reste en place, sans réécriture.
3Un partenaire ralentit
Ce que Flexway décideL'amont est appelé mais ne répond pas dans son budget de délai : 504 upstream_timeout ; au-delà du seuil d'échecs, le coupe-circuit s'ouvre (503) ; seules les méthodes idempotentes sont rejouées.
Ce qui est protégéUn partenaire lent ne bloque pas les autres.

Ouvrir ce modèle dans l'éditeur

Ce que le secteur exige

EDI · API partenairesDes API partenaires sous contrat: Seules les opérations déclarées sont servies ; chaque partenaire a sa clé ou son certificat, lié à un tenant.
SuiviDes statuts qui arrivent: La frontière synchrone vers asynchrone est gérée par la passerelle ; les partenaires reçoivent des webhooks signés et rejouables.
Systèmes existantsL'existant derrière, sans réécriture: Traduction REST vers gRPC, reprise d'une configuration de passerelle existante.
ContinuitéUn partenaire lent ne bloque pas les autres: Budget de délai par opération, coupe-circuit, reprises limitées aux méthodes idempotentes.

Comment Flexway y répond

Des API partenaires sous contrat

Clés d'API et mTLS client comme identités de premier planLivré · v0.1.0
Un contrat OpenAPI 3.1 chargé ; ce qui est servi en est déduitLivré · v0.1.0

Des statuts qui arrivent

Médiation de la frontière synchrone vers asynchroneLivré · v1.5.0
Webhooks sortants signés et rejouablesLivré · v1.5.0

L'existant derrière, sans réécriture

Traduction REST vers gRPC par descripteurs ProtobufLivré · v0.2.0
Reprise de la configuration d'une passerelle existante, avec rapport de couvertureLivré · v1.1.0

Un partenaire lent ne bloque pas les autres

Budget de délai par opérationLivré · v0.1.0
Coupe-circuit avec demi-ouvertureLivré · v0.1.0
Reprises limitées aux méthodes idempotentesLivré · v0.1.0

État dans la dernière version publiée de Flexway ; une fonctionnalité n'est marquée livrée qu'avec sa version.

Ce que Flexway ne fait pas

Flexway ne convertit pas les formats EDI : il expose et protège les API qui les remplacent ou les encapsulent.

Parlons de votre passerelle

Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.

Parler à un expert Écrire à Flexwiz

La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.