Flow and Custom Processor Engineering

Flows that the next engineer can read.

Building and reworking flows

Some estates need new flows; most need the old ones made understandable. We build and rework NiFi dataflows so that they are versioned, parameterised and documented, and so that the next engineer can read them without a guided tour.

What we build

  • Source and sink integration. Databases, message brokers, object storage, SFTP drops, HTTP APIs and the odd legacy system that only speaks files.
  • Record-oriented flows. Record readers and writers with a schema registry in place of chains of split, extract and merge processors, which cuts FlowFile counts and makes schemas explicit.
  • Custom processors and controller services. In Java when performance or an existing library calls for it, or with the NiFi 2 Python processor API when your team is stronger in Python.
  • Parameter contexts and promotion. One flow definition promoted from development to test to production through a registry, with environment differences held in parameters rather than in hand-edited copies.
  • Registry-backed CI. Flow versions reviewed and promoted like code, with automated checks before a change reaches production.
  • Secure site-to-site. Encrypted transfer between clusters and sites, with the certificates and policies written down.
  • Access control and audit. User and group policies, component-level permissions and the provenance and audit configuration regulated environments ask for.

How we work on it

We work inside your security boundary and your change process. Every flow we touch leaves with a short write-up: what it does, what it depends on, how to tell it is unhealthy, and what to do about it.

Billed hourly. Talk to an engineer.

Tell us which NiFi version you run, roughly how many flows, and what is hurting. The first conversation is with the engineer who would do the work.
Talk to a NiFi engineer