Un portale B2B che mette in relazione produttori, distributori e consumatori di carta deve scambiare ordini, conferme e documenti di consegna fra gestionali diversi, e nella filiera della carta un vocabolario XML pubblico per farlo esiste già: papiNet. Quando si progetta una piattaforma del genere, la decisione tecnica vera è una sola: adottare quel vocabolario con la pila di messaggistica che lo accompagna, oppure inventarsi un formato proprietario per ogni partner.

Contesto

La filiera della carta è frammentata e regolamentata: cartiere, merchant, trasformatori, tipografie, distributori. Ognuno ha il proprio gestionale, e gli scambi tradizionali passano da fax, e-mail e qualche volta EDI classico (EDIFACT). L’EDI a valore aggiunto costa molto da attivare per ogni singolo partner, e per una community ampia e in crescita di piccoli operatori resta poco praticabile.

papiNet nasce per riempire questo vuoto. È uno standard XML pubblico per le transazioni della filiera carta e legno: il primo blocco di messaggi esce come versione 1.0 nel giugno 2001, poi la 1.1 nel febbraio 2002 e in seguito la serie 2.x. Il governo dello standard è diviso fra il gruppo europeo e papiNet NA, formato da AF&PA (American Forest & Paper Association) e IDEAlliance. Le specifiche e gli schema si scaricano liberamente.

Architettura

Lo scambio si articola su tre livelli. Tenerli distinti è la prima condizione per progettare in modo pulito.

Il livello documento è papiNet: un insieme di schema XML che descrive le transazioni della filiera — ordine, conferma d’ordine, messaggio di consegna, fattura — con definizioni standard degli attributi di prodotto (grammatura, formato, finitura, qualità). Qui sta il valore principale dello standard: due controparti che usano gli stessi schema non devono mettersi d’accordo campo per campo su cosa significa un ordine.

Il livello di messaggistica è ebXML, e nello specifico la specifica ebMS (ebXML Message Service). ebMS definisce un metodo indipendente dal protocollo di trasporto per scambiare messaggi di business, con costrutti di imbustamento per una consegna affidabile e sicura. papiNet adotta ebMS come servizio di messaggistica di riferimento.

Il livello di trasporto è di solito HTTP/HTTPS, perché ebMS lascia libera la scelta del protocollo sottostante e SOAP su HTTP è la realizzazione più diffusa. Su questo livello si appoggiano l’autenticazione delle controparti e la cifratura del canale.

A marzo 2004 ISO approva come specifiche tecniche le quattro parti centrali di ebXML sotto la sigla ISO/TS 15000:

  • 15000-1 — Collaboration-Protocol Profile and Agreement (ebCPP): il profilo delle capacità tecniche di un partner e l’accordo fra due partner.
  • 15000-2 — Message Service Specification (ebMS): l’imbustamento dei messaggi di cui sopra.
  • 15000-3 — Registry Information Model (ebRIM).
  • 15000-4 — Registry Services Specification (ebRS).

Per un portale di filiera pesano soprattutto le parti 15000-1 e 15000-2: dicono come due sistemi dichiarano le proprie capacità e come si scambiano i messaggi in modo affidabile. Le parti 15000-3 e 15000-4 descrivono un registry distribuito, utile quando i partner si scoprono fra loro a runtime; in una community curata da un gestore centrale, dove l’anagrafica degli operatori è nota, il registry di solito non serve.

Punto critico

papiNet copre gli attributi del prodotto, ma quanto venga adottato davvero dipende da come ciascun partner mappa il proprio gestionale interno verso gli schema standard. Il problema non è XML: è la conciliazione semantica. Due cartiere possono codificare la stessa qualità di carta con nomenclature interne diverse, e nessuno schema XML risolve da solo la corrispondenza fra quei codici. Lo standard mette a disposizione il contenitore e una terminologia condivisa; la tabella di mappatura fra codici interni e codici papiNet resta lavoro a carico del singolo partner, e va versionata come codice perché cambia ogni volta che un fornitore aggiorna il catalogo.

Ne viene una conseguenza progettuale: un portale fatto bene tiene separato il modello canonico interno (l’anagrafica prodotti come la vede la piattaforma) dagli schema di interscambio. La validazione contro lo schema papiNet va fatta al confine del sistema, in ingresso e in uscita, non al centro. Così un messaggio malformato di un partner viene respinto prima che sporchi i dati condivisi, e un aggiornamento di versione dello standard si assorbe toccando solo lo strato di confine.

Implicazioni

Adottare uno standard pubblico ha un effetto diretto sul costo di onboarding di un nuovo operatore. Con un formato proprietario, ogni partner che si aggiunge richiede un’integrazione su misura, e il costo cresce con il numero di controparti. Con papiNet, un partner che già produce o consuma quei messaggi si collega mappando il proprio gestionale una volta sola, verso uno schema che non cambia da una controparte all’altra. È la differenza fra un’integrazione per ogni coppia di partner e un’integrazione per partner.

C’è poi un effetto sul governo dei dati. Gli schema papiNet e le specifiche ebXML sono pubblici e versionati da consorzi: una piattaforma che ci si appoggia non dipende da un formato che un singolo fornitore può cambiare quando vuole. Per chi gestisce una community di settore, questo abbassa il rischio di lock-in sul formato di scambio, che è cosa diversa dal lock-in sull’applicativo.

Limiti

Lo standard non risolve il problema politico dell’adozione: serve che una massa critica di operatori della filiera produca e consumi messaggi papiNet, altrimenti il portale finisce a tradurre fra papiNet e i formati ad-hoc dei partner che non lo supportano, e si riporta dentro proprio il costo che lo standard doveva togliere. In una filiera con tanti piccoli operatori il cui gestionale non sa emettere XML, per anni la realtà operativa resta un misto di import manuale, CSV e form web, con papiNet usato solo verso i partner più strutturati.

Restano fuori dal perimetro di papiNet i servizi a valore aggiunto che una piattaforma di filiera può offrire — logistica, finanza di filiera, certificazioni di provenienza. Per quelli, a oggi, uno schema condiviso altrettanto maturo non c’è, e l’integrazione torna a essere per fornitore. Lo standard copre la transazione commerciale di base, non tutto l’ecosistema di servizi che ci si costruisce sopra.

Un portale di filiera costruito su questi presupposti — Paper Web, per Trevi Trade — è descritto in un insight di noze: https://www.noze.it/insights/trevi-trade-paper-web/.

Immagine di copertina: Grandi rotoli di carta da giornale finita accatastati su più file in un magazzino di una cartiera — foto di U.S. Environmental Protection Agency, pubblico dominio — https://commons.wikimedia.org/wiki/File:Rolls_of_finished_newsprint_at_Macmillan-Bloedel_Ltd_in_the_Fraser_River_Valley,_British_Columbia,_Canada.JPG