Flux
The Portlane flux model — ingress, routing, transform, and egress
A flux describes the journey of an enveloppe from a source system to a target system. Each flux is authored as code — a small declarative identity card plus a pure Python transform — versioned in your own git repository (portlane-flux). The Espace client "Flux" download is an empty repository scaffold to initialize that project — not a second runtime.
The four steps
| Step | Moteur | Purpose |
|---|---|---|
| Ingress | listener (webhooks) or pooling (scheduled pull) | Receive or fetch data from a source system |
| Routing | broker | Normalize the event and route it toward the right flux |
| Transform | worker | Apply your business logic — mapping, enrichment, business rules |
| Egress | distribute | Push the transformed enveloppe to the target system |
Authoring a flux
You declare a flux with two artifacts, reviewed like any code change:
- An identity card (YAML) — source, routing, target, and which transform to apply.
- A pure Python transform — no network calls, no database access, just data in and data out.
Publishing a flux synchronizes the card into the platform's routing configuration; the transform ships inside a versioned container image. Both move together on every deploy.
Typical patterns
Extract–transform–load (ETL) — Pull from a source system on a schedule, normalize in a transform, push to a warehouse or API.
Event-driven sync — React to a webhook, apply business rules, deliver to one or more downstream systems.
Versioning and rollback
Flux cards and transforms are versioned in git and deployed through your CI. Rolling back means redeploying a previous, already-tested image — no manual reconfiguration.
What this doc does not cover
This page describes the generic flux model. The flux actually configured in your instance are shown live in the Tour de contrôle, not written here.