A B2B portal connecting paper producers, distributors and consumers has to exchange orders, confirmations and delivery documents between different back-office systems, and in the paper supply chain a public XML vocabulary for the job already exists: papiNet. When you design such a platform, there is really only one technical decision: adopt that vocabulary with the messaging stack that comes with it, or invent a proprietary format for every partner.

Context

The paper supply chain is fragmented and regulated: mills, merchants, converters, printers, distributors. Each runs its own back-office system, and traditional exchanges go through fax, e-mail and occasionally classic EDI (EDIFACT). Value-added EDI costs a lot to set up for each single partner, and for a large and growing community of small operators it stays impractical.

papiNet exists to fill this gap. It is a public XML standard for paper and forest-products transactions: the first block of messages comes out as version 1.0 in June 2001, then 1.1 in February 2002 and later the 2.x series. Governance is split between the European group and papiNet NA, formed by the AF&PA (American Forest & Paper Association) and IDEAlliance. The specifications and schemas are freely downloadable.

Architecture

The exchange breaks into three layers. Keeping them distinct is the first condition for a clean design.

The document layer is papiNet: a set of XML schemas describing supply-chain transactions — order, order confirmation, delivery message, invoice — with standard definitions of product attributes (grammage, size, finish, grade). This is where the standard’s main value sits: two counterparties using the same schemas need not agree field by field on what an order means.

The messaging layer is ebXML, specifically the ebMS (ebXML Message Service) specification. ebMS defines a transport-protocol-independent method for exchanging business messages, with enveloping constructs for reliable, secure delivery. papiNet adopts ebMS as its reference messaging service.

The transport layer is usually HTTP/HTTPS, because ebMS does not tie your hands on the underlying protocol and SOAP over HTTP is the most common realisation. Counterparty authentication and channel encryption sit on this layer.

In March 2004 ISO approved the four core ebXML parts as technical specifications under the label ISO/TS 15000:

  • 15000-1 — Collaboration-Protocol Profile and Agreement (ebCPP): a partner’s declared technical capabilities and the agreement between two partners.
  • 15000-2 — Message Service Specification (ebMS): the message enveloping mentioned above.
  • 15000-3 — Registry Information Model (ebRIM).
  • 15000-4 — Registry Services Specification (ebRS).

For a supply-chain portal, parts 15000-1 and 15000-2 weigh most: they say how two systems declare their capabilities and how they exchange messages reliably. Parts 15000-3 and 15000-4 describe a distributed registry, useful when partners discover each other at runtime; in a community curated by a central operator, where the roster of partners is known, the registry usually serves no purpose.

The critical point

papiNet covers product attributes, but how much it is actually adopted depends on how each partner maps its internal back-office system onto the standard schemas. The problem is not XML: it is semantic reconciliation. Two mills may encode the same paper grade with different internal nomenclatures, and no XML schema on its own resolves the correspondence between those codes. The standard provides the container and a shared terminology; the mapping table between internal codes and papiNet codes stays the work of each single partner, and it should be versioned as code because it changes every time a supplier updates its catalogue.

From this comes a design consequence: a portal done well keeps the internal canonical model (the product catalogue as the platform sees it) separate from the interchange schemas. Validation against the papiNet schema goes at the system boundary, inbound and outbound, not at the centre. A malformed message from a partner is then rejected before it dirties shared data, and a version upgrade of the standard is absorbed by touching only the boundary layer.

Implications

Adopting a public standard has a direct effect on the cost of onboarding a new operator. With a proprietary format, every partner you add asks for a bespoke integration, and the cost grows with the number of counterparties. With papiNet, a partner that already produces or consumes those messages connects by mapping its back-office once, against a schema that does not change from one counterparty to another. It is the difference between an integration per pair of partners and an integration per partner.

There is also an effect on data governance. The papiNet schemas and the ebXML specifications are public and versioned by consortia: a platform that builds on them does not depend on a format a single vendor can change whenever it wants. For whoever runs a sector community, this lowers the risk of lock-in on the exchange format, which is a different thing from lock-in on the application.

Limits

The standard does not solve the political problem of adoption: a critical mass of supply-chain operators has to produce and consume papiNet messages, otherwise the portal ends up translating between papiNet and the ad-hoc formats of partners that do not support it, bringing back inside the very cost the standard was meant to remove. In a chain with many small operators whose back-office cannot emit XML, for years the operational reality stays a mix of manual import, CSV and web forms, with papiNet used only towards the more structured partners.

Outside papiNet’s perimeter stay the value-added services a supply-chain platform may offer — logistics, supply-chain finance, provenance certification. For those, as of today, no equally mature shared schema exists, and integration goes back to being per-vendor. The standard covers the basic commercial transaction, not the whole ecosystem of services built on top of it.

A supply-chain portal built on these premises — Paper Web, for Trevi Trade — is described in a noze insight: https://www.noze.it/en/insights/trevi-trade-paper-web/.

Cover image: Large rolls of finished newsprint stacked in rows inside a paper mill warehouse — photo by U.S. Environmental Protection Agency, public domain — https://commons.wikimedia.org/wiki/File:Rolls_of_finished_newsprint_at_Macmillan-Bloedel_Ltd_in_the_Fraser_River_Valley,_British_Columbia,_Canada.JPG