ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

Content Filter

Message pruning — not to be confused with Message Filter which drops the whole message.

Problem

An incoming message carries 200 fields; the downstream consumer uses only 30. Transmitting the 170 unused fields exposes to GDPR risks, inflates bandwidth, and complicates the target schema.

Forces

  • Partner EDI flows are intentionally rich — an IFTMIN can weigh 200 KB.
  • Downstream pull does not tolerate 200 fields (too-wide schema).
  • Some fields are PII and must not travel outside a secured envelope.
  • Filtering must be traceable for audit (who filters what when).

Solution

Insert a Content Filter component in the pipeline. It takes the whole message, selects / masks / drops fields per a whitelist (or blacklist), and emits a reduced message. Selection is codified (XPath, JSONPath, XSLT for XML; jq / mapping rules for JSON). The filter keeps an audit log (dropped fields, reason).

EDI implementation

In EDI, Content Filter is typical between the ingestion hub and internal consumers: GDPR-unused fields (birthdate, loyalty card numbers) are dropped after functional control, only accounting / operational fields are kept. Implementations: Apache Camel `<setBody>` with XPath, MuleSoft DataWeave with `// fields removed`. The pattern is complementary to Claim Check — Content Filter for short fields, Claim Check for blobs.

Anti-patterns

  • Filter that silently redefines the schema — consumers do not know what they are missing.
  • Filter that drops legally required fields (VAT number, partner contracts) — non-compliance risk.
  • Filter without audit — impossible to justify why a field disappeared in case of dispute.
  • Filter that contradicts the downstream Content Enricher — wasted cycle.

Sources