Sub-pipeline: riepilogo-ordini

• Scopo: riassumere gli ordini arricchiti per tier cliente, con il numero di ordini e l'importo totale di ogni tier, e restituire gli ordini validati come fatti. Il confine d'ingresso è il contratto del fatto: la root non lo ripete a monte.
• Proprietario: core
• Codice: src/sub-pipelines/riepilogo-ordini/sub-pipeline.ts, contratti in schema.ts

Corpo

0/2

Scegli una scena e premi ▶ per guardarla scorrere, oppure → per andare avanti un passo alla volta.

Lo scopo dei nodi

Nodo	Tipo	Scopo
tier-summary	transform	Conta gli ordini e somma i loro importi per fascia cliente. Gli ordini senza un cliente noto finiscono in una fascia a parte, così nessun ordine resta fuori dai totali.

Il corpo dell'istanza riepilogo-ordini di orders-enriched-daily, la prima nell'ordine di etl.config.ts, con tierMancante: unknown. Scarti e guard non compaiono: li decide la root che istanzia.

Istanziato con id <istanza>, il corpo diventa questi nodi. Lo scopo del nodo interno è nella tabella sotto il grafo; i confini li genera il core e non ne hanno uno, perché li rappresenta l'istanza col suo scopo.

Id qualificato	Id locale	Dettaglio tecnico
<istanza>	in	Confine d'ingresso, enrichedOrderSchema
<istanza>/tier-summary	tier-summary	groupBy per tier, tierMancante se il tier è assente
<istanza>/per-tier	per-tier	Confine d'uscita, tierSummarySchema
<istanza>/fatti	fatti	Confine d'uscita dall'ingresso, enrichedOrderSchema

L'uscita fatti parte direttamente dall'ingresso (.output(INPUT, "fatti")): è l'ordine com'è entrato, già validato dal confine d'ingresso.

Parametri

Parametro	Tipo	Default	Significato
tierMancante	stringa non vuota	"unknown"	l'etichetta del tier degli ordini senza cliente noto

Lo schema è riepilogoOrdiniParams in schema.ts. Col default il riepilogo è quello di sempre. Come ogni parametro compare in chiaro nel piano: non è un posto per un segreto.

Nessuna dipendenza: la sub-pipeline non fa IO.

Contratti

Lato	Nome	Schema
Ingresso	—	enrichedOrderSchema: ordine arricchito, tier nullable, amount positivo
Uscita	per-tier	tierSummarySchema: tier, order_count intero positivo, total_amount numero finito
Uscita	fatti	enrichedOrderSchema: l'ordine arricchito, lo stesso schema dell'ingresso

I due schemi sono definiti qui e orders-enriched-daily li riesporta: la root dipende dalla sub-pipeline, mai il contrario.

Errori

• Un ordine fuori contratto è rifiutato dal confine d'ingresso, <istanza>, e non arriva a nessuna delle due uscite.
• Un riepilogo il cui totale trabocca a Infinity è rifiutato dal confine d'uscita, <istanza>/per-tier. Gli ordini che l'hanno prodotto escono comunque da fatti.
• Il groupBy è stateful: un suo errore non si isola per record, chiude lo stream.

Dove vanno questi errori lo decide la root che istanzia: in orders-enriched-daily il guard a monte dell'istanza la copre per intero.

Dove si usa

Pipeline root	Istanza	Parametri	Alimentata da	Uscite verso
orders-enriched-daily	riepilogo-ordini	tierMancante: unknown	guard	per-tier → tier_summary fatti → enriched_orders

La tabella si ricava dai piani delle pipeline del catalogo (etl.config.ts): l'id dell'istanza apre la scheda della root dentro l'istanza.

Test

• src/sub-pipelines/riepilogo-ordini/sub-pipeline.test.ts: con runSubPipeline, recordIds acceso e spento, sulle due uscite: record validi col default di tierMancante e con un valore esplicito, un ordine rifiutato all'ingresso e un riepilogo rifiutato in uscita, ognuno col suo id qualificato, e i fatti che escono com'erano entrati.