Documentation

Everything needed to build, run and extend mako — grouped by what you are trying to do.

Start here

Find it by market role

A deployment is scoped to the roles it plays — a role build contains no other arm's code (§ 9 EnWG). makod, marktd, edmd, obsd and agentd are role-neutral and run everywhere; the rest are role-specific.

How the layers fit together

graph TB
    subgraph transport ["Transport"]
        AS4["AS4 / ebMS3<br/>BDEW AS4-Profil"]
        API["API-Webdienste<br/>REST"]
    end
    subgraph format ["Format — generated from BDEW profiles"]
        EDI["edi-energy<br/>parse · validate · build"]
    end
    subgraph domain ["Domain — typed commands and events"]
        ENG["mako-engine<br/>workflows · Fristen · outbox"]
        MODS["mako-gpke · mako-wim<br/>mako-geli-gas · mako-mabis · …"]
    end
    subgraph services ["Services"]
        SVC["makod · marktd · billingd<br/>accountingd · edmd · …"]
    end

    AS4 --> EDI
    API --> ENG
    EDI -->|"typed message"| ENG
    ENG --- MODS
    ENG --> SVC
    SVC -->|"CloudEvents"| SVC

The split is deliberate. The domain layer never sees EDIFACT, and the format layer never knows what a Lieferantenwechsel is — so an annual BDEW release is a codegen run against new profiles rather than a change to process logic.

Sections

• Guide — install, run the demo stack, submit your first message.
• Architecture — the domain model, the workflow engine, ERP integration and the API-Webdienste transition.
• Services — one operator manual per service: endpoints, configuration, emitted events, deployment.
• Reference — EDIFACT parsing, validation, builders, the AS4 profile, process catalogue, and the makotest Python toolkit.
• Regulatory — BNetzA Festlegungen and the full Prüfidentifikator table with the crate and workflow that owns each one.
• Release & compliance — the annual release workflow, schema versioning, and licence inventory.

Common tasks