NexusFabricRequest a walkthrough

Enterprise Integration Kernel · Written in Rust

Enterprise integration. Reinvented in Markdown.

An integration platform that connects HTTP, SOAP and gRPC with readable flows. Validate, transform and route messages on infrastructure you control.

What it changes for your team

  • Your support desk answers “where is my message?”

    Support finds a delivery by its correlation ID, sees for each flow how many messages are pending, retrying or dead-lettered, and reads its trace. A sysadmin replays a dead-lettered message under the same ID, and the replay is recorded.

    • Find, Support
    • Queue, Support
    • Trace, Support
    • Replay, Sysadmin
  • One program in place of a stack of products

    The front door, transformation and routing, a persistent queue with retry and dead-letter, and the message journal run in one program.

    An assembled integration tier

    • API gateway
    • Integration runtime
    • Message broker
    • Log store
    • Admin console

    NexusFabric

    • Front door
    • Transformation and routing
    • Persistent queue
    • Message journal
    • Management UI
  • More engines, no cluster to manage

    Start the same program again on the same host. File locks are all that coordinates the copies: no orchestrator, no consensus, no node registry.

    same program, same state directory, file locks

  • Every flow is checked before it takes traffic

    When you publish a flow, the platform checks the shape of its routing block, its name, its transforms and its SOAP version.

    XSLT outside the supported subset is refused at publication, not run some other way.

Four doors, one delivery bracket

The four inbound doors compared: arrival, access gate, delivery bracket, verdict, outcome and channel
Synchronous requestHandover to a queueScheduleThe gRPC door
Arrives byHTTP or SOAP, on the run routeHTTP, on the enqueue routeA six-field schedule in the flow headerA separate port
Access gateThe shared gateAt enqueue timeNot applicable — the trigger is internalThe same as on HTTP
Delivery bracketExecutor::deliver

All four doors enter through the same delivery bracket, the queue at the worker, not at the handover. Deduplication on a key, request-to-response correlation and response memoisation are decided in one place, not rewritten per door.

Verdict

A delivery that arrives by a synchronous request, a schedule tick or a gRPC call leaves a received event and exactly one verdict. The queue does not write this pair: the message waits in the queue’s own write-ahead log until a worker takes it.

Outcome

Where a verdict is written, its nuance is in the outcome column: succeeded, fault_handled or failed.

Channelhttpqueuecrongrpc

The gate is closed by default and runs before the body: an unauthenticated caller causes no body read and no parsing. Which door a delivery came in through is read from a journal column, not from the kind of the event. The gRPC door serves unary methods only.

The pair a delivery leaves in the journal

Illustrative lines, showcase tenant
eventchanneloutcometenantflow
receivedhttpnonemeridianshipment-intake
completedhttpsucceededmeridianshipment-intake
The journal: events filterable by tenant, flow, event kind and outcome, each row expandable to its full fields.The journal: events filterable by tenant, flow, event kind and outcome, each row expandable to its full fields.
The journal of a running installation. The data belongs to the showcase tenant Meridian Logistics (showcase).

How a message travels

401 / 403access_denied413channel, outcomeCallerAccess gateclosed by defaultCeiling, thenthe bodyExecutor::deliverone bracket, four doorsFlow stepsRefusalVerdictJournal401 / 403access_denied413channel, outcomeCallerAccess gateclosed by defaultCeiling, thenthe bodyExecutor::deliverone bracket, four doorsFlow stepsVerdictRefusalJournal
  1. The gate decides before the body

    The request passes the gate before a single byte of body is read. A caller without a credential gets a 401 and learns neither whether the flow exists nor how much body it would have been allowed to send.

  2. The ceiling is resolved, then the body is read up to it

    A message ceiling is resolved per access point: the flow’s own, if it declares one. A body announced over the ceiling gets a 413 before a single byte is read.

  3. Executor::deliver is the one bracket

    All four doors enter Executor::deliver: deduplication, correlation and the memoised response are decided in one place, not rewritten per door.

  4. The steps run in order

    A validate guard refuses at the first rule that is false, a route picks one arm and converges after the guard’s last arm, an ntd fence produces the next document. An unhandled error enters the ## Fault: section, if the flow has one.

  5. One verdict per delivery

    A delivery that exits through the ## Fault: section is not committed as a success: a corrected duplicate runs instead of replaying the memoised fault.

  6. The journal says which door it came in through

    The channel is a column, not a kind of event: http, grpc, queue or cron.

The gate is first, the ceiling second. That is why a caller without a credential announcing a body over the ceiling gets a 401, not a 413: the ceiling is internal installation state and is not disclosed before authentication.
Read this diagram as text
  1. The caller sends the request to a flow route.
  2. The access gate decides first, and it is closed by default. Here a caller without a credential gets a 401 and one whose credential does not cover the flow gets a 403; each refusal leaves an access_denied event.
  3. The message ceiling is resolved, then the body is read up to it. A body over the ceiling stops with a 413 and reaches no step.
  4. Executor::deliver is the bracket all four doors enter through. Deduplication and correlation are decided here.
  5. The flow steps run in order.
  6. The delivery ends in a verdict, exactly one.
  7. A refusal by the gate or by the ceiling goes straight to the journal, without touching the steps.
  8. The journal records the received event, the verdict, the channel the delivery came in on, and the outcome column.

What your team reviews is checked at publication

A flow is a Markdown file: a header, an optional description, then the steps. Your team reviews it like any other change. Publication compiles it.

The flow your team reviews. tests/battery/corpus/meridian/01-shipment-intake.flow.md — the egress step, lines 34-40, is left out.
## Step: check-booking
```validate
$.shipmentId != null    | "shipmentId is required"                    | syntactic
$.hubCode != null       | "hubCode is required"                       | syntactic
$.parcelCount > 0       | "parcelCount must be greater than zero"
$.weightKg > 0          | "weightKg must be greater than zero"
```

…

## Step: acknowledge
response_status: 202
```ntd
{
  "status": "ACCEPTED",
  "shipmentId": "{{ $.echo.shipmentId }}",
  "waybill": "{{ $.echo.waybill }}",
  "hubCode": "{{ $.echo.hubCode }}",
  "parcelCount": {{ $.echo.parcelCount }}
}
```
$ nexus validate flows/01-shipment-intake.flow.md
ok  flows/01-shipment-intake.flow.md
    flow:   shipment-intake
    tenant: meridian
    steps:  3
A flow with an XSLT construct outside the supported subset: refused at publication, not run some other way. tests/battery/corpus/acme/stricate/p10-xslt-necoborabil.flow.md, in full.
---
flowmarkdown_version: 0.1
flow: p10-xslt-necoborabil
tenant: acme
effects: []
---
## Step: x
```xslt
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:apply-templates select="*"/>
  </xsl:template>
  <xsl:template match="*">
    <copiat><xsl:value-of select="."/></copiat>
  </xsl:template>
</xsl:stylesheet>
```
$ nexus validate flows/p10-xslt-necoborabil.flow.md
error: step 'x': this XSLT sheet is outside the subset this platform compiles, and there is no XSLT engine at run time — unsupported XSLT construct <xsl:apply-templates>: recursive template application requires a runtime XSLT engine. Rewrite the step as `ntd`: it expresses the same transformations, and its failures are visible here rather than at the first message. `descendants()` covers `//name` searches, `string()` takes an element's text, and `{{ if }}` / `{{ for }}` cover `xsl:choose` and `xsl:for-each`
error: 1 validation error(s)

What is counted

The figures below describe the shape of the product and are read from the code.

  • 1program to install, patch and back upthe door, transformation, the queue, the journal and the management UI
  • 4doors a delivery arrives throughHTTP, queue, schedule and gRPC, all through one delivery bracket
  • 3roles in the management UISysadmin, Developer and Support, on an enforced boundary
  • 28event kinds in the journalreceipts, verdicts and refusals among them

The platform, by chapter

Licence and version

Version described here
1.30.0
Licence
Commercial, proprietary. No public download and no source code.
Availability
By contract, on request.

Walk through it with the people who wrote it

Bring one integration you run today. We go through the flow, the journal and the management UI with you.

Third-party product names such as Rust are trade marks of their owners.