Architecture

Portlane moteurs step by step: APIM, ingress, broker, worker, distribute, supervision, on your infrastructure

Most integration platforms sell you a studio far from your servers and a subscription that comes back every year. Portlane is the opposite: Docker moteurs you install (Cœur), a Postgres that acts as both enveloppe bus and memory, and a chain you can read without opening a vendor console. Commercial model: Licence à vie on devis.

Each moteur has one job. It reads a queue, does the work, writes the result. Nothing important lives only in memory. A link can fail and the enveloppe remains. What follows is the path in order.

Cluster of Docker moteurs on an on-prem server — *runtime* · The Cœur runs on your server or VM. No vendor cloud sits between you and your payloads.

The path, step by step

Seven moteurs, one fixed order. Each does one thing. The next picks up where the previous left off.

01 · apim · Entry perimeter

You hold the door before data enters the chain. Who can send, under which rules, what crosses the line: your call. No hidden filter at the vendor.

APIM gateway filtering inbound requests before the listener — *apim* · The public edge: auth and rate limits at your perimeter, then hand-off to the listener.

02 · listener · Ingress (push)

When a partner or system sends you data, the listener takes charge right away. It is traced, stored, rejouable. That is the difference between an informal exchange and a flux you can defend in an audit.

Canonical enveloppe in transit between two moteurs — *enveloppe* · One enveloppe shape once past the edge.

03 · pooling · Ingress (pull)

Not every system pushes its data. Pooling fetches on schedule (CRM, ERP, business API) and hands off to the listener, which creates the canonical enveloppe. One circuit after that, not two parallel chains.

PostgreSQL data bus connected to surrounding Docker moteurs — *central bus* · Data-plane moteurs read and write Postgres queues. They do not call each other directly.

04 · broker · Routing

The broker sorts: which business flux, which queue, which treatment next. One source can feed several paths without rewiring. This is not business logic, not a visual studio. It is routing you can read and verify.

Central routing node directing flux toward distinct business queues — *routing* · The broker fans work onto the right queues without rewiring the moteurs.

05 · worker · Transform

Your business rules run here: mapping, enrichment, validation. The code lives in your Flux repository (portlane-flux), goes through review like the rest of the estate, deploys when you decide. Not proprietary configuration only a vendor integrator can reopen.

Python worker transforming raw input data into structured output — *transform* · Versioned Python your team can review, not opaque vendor config.

06 · distribute · Delivery

The result goes where your Organisation expects it: business tool, partner, pivot database. The flux ends inside your perimeter. It does not pass through a vendor cloud to exit.

Linear chain of Docker moteurs linked by enveloppes — *chain* · After ingress: broker, worker, distribute. Each link is independent and restartable.

07 · supervision · Tour de contrôle

The Tour de contrôle shows what is running, what failed, and what can receive a rejeu. On your instance, not ours. You keep operational visibility and recovery in hand, without a vendor ticket.

Tour de contrôle overlooking moteur topology and Postgres — *Tour de contrôle* · Supervision on your instance: moteur status, enveloppe path, rejeu when something fails.

Message envelope replayed after failure along the engine chain — *replay* · A failed enveloppe takes the path again. Recovery stays on your instance.

Event queue feeding an observability supervision panel — *observability* · Runtime events feed the Tour de contrôle. You see what ran, not a marketing dashboard.

From source system to target

Three zones, one direction. Moteurs in the middle do the work. Central memory carries the trace of each enveloppe.

01 · Sources

Where data is born: a partner that sends, a system you query, a business event. APIM holds the door. The listener creates the enveloppe (direct push, or handed off by pooling).

02 · Moteurs

Routing, transform, delivery. Each step picks up work already started. A link restarts, the enveloppe is not lost.

03 · Targets

Where your Organisation consumes the result: business tool, partner, reference system. Data stays with you.

What the path guarantees

at-least-once · An enveloppe does not vanish into the void. It waits in a queue until processed.
idempotent · Reprocessing the same enveloppe does not corrupt the target. The contract is designed for that.
rejouable · A failure receives a rejeu from the Tour de contrôle, on your instance, with an audit trail.