A Mandant needs no netztransparenz client and no ENTSO-E token. What it
copies is stored on its own audit share, so its views (reBAP forecast,
Fahrplan/Ist costs, calculation, partner contacts) read locally as
before. If the Zentrale is down, the next copy is just late
(
rebap_abruf_fehler, zentrale_partin_fehler).
Market communication stays with each Mandant: answering a partner’s
PARTIN, its APERAK, the partner status in the Marktpartner list, and the
evidence of what a partner sent us (GET /v1/process/market-partners/{key},
received). The Zentrale’s datasheets only fill in contact data:
a partner that sent its datasheet only to another Mandant still has its
desks and addresses known here, for the PARTIN popup, the Korrektur and
Nachfass mails and the LRV recipient.
Which instance is the Zentrale
Any instance can be the Zentrale: the one that holds the netztransparenz client, the ENTSO-E token and a MakoFlow login. This can be one of the Mandanten’ stacks or a stack of its own (the same template, with market routines off). There is no extra service: the Zentrale is the bridge.
The Zentrale always collects for its own BKV and Lieferant MP-IDs too.
Give each Mandant its own report key on the Zentrale (
REPORT_API_KEYS
takes name:secret pairs), so the event log names which Mandant read.
The PARTIN directory
A Netzbetreiber sends its datasheet to every party it works with. The company and contact data are its own and the same for every recipient. Only the contact blocks depend on the receiver’s role: a BKV gets no Rahmenverträge desk (PARTIN AHB 1.1). So the Zentrale keeps, per role (bkv, lieferant) and partner, the newest datasheet any Mandant
received in the last 180 days, by AS4 or as a mailed attachment. A
Mandant reads the datasheets of its own role.
It reads the mako365 account once per MP-ID in ZENTRALE_MANDANTEN, past
the MakoFlow cache, which keeps only the instance’s own traffic. It stores
partners and roles, never who received a datasheet: no Mandant’s MP-ID
and no other party’s traffic. Datasheets addressed to an MP-ID that is
not listed are not read.
In a Mandant’s directory its own inbox comes first: a datasheet it holds
appears once (via: as4 or email), and the Zentrale’s appears where
there is none, or where it is newer (via: zentrale). For the contact
address, the Mandant’s own datasheet wins.
Endpoints
POST /v1/process/rebap/aktualisieren on a Mandant also copies from the
Zentrale. GET /v1/process/marktdaten/roh (raw reads of the data
services) answers 409 on a Mandant: raw reads happen on the Zentrale,
which has the credentials.
Routines
Setting it up
1
On the Zentrale
Keep (or set) the netztransparenz client and the ENTSO-E token. In the
console, group Zentrale, set
zentrale_mandanten to every
Mandant’s BKV and Lieferant MP-ID. Create a report key per Mandant
(REPORT_API_KEYS). Then run POST /v1/process/zentrale/aktualisieren
once, or wait for the routine.2
On each Mandant
In the console, group Zentrale, set
zentrale_url and
zentrale_api_key. Run POST /v1/process/zentrale/aktualisieren and
check GET /v1/process/zentrale: rolle is mandant, and the reBAP
days and partners are there. Once they are, the netztransparenz
client and ENTSO-E token can be cleared on the Mandant.