CENT lives inside S/4. There is no separate server to deploy, no broker to operate, no message bus to license. The capture happens in the same memory as the user's save, and the dispatch happens on the system's own background-RFC infrastructure.
The whole tool is two ideas: capture changes the moment they happen, then hand them to whoever asked for them. Everything else is configuration. You can explain it in a meeting in five minutes — and that simplicity is exactly what makes it scale to dozens of consumers without becoming someone's full-time job to maintain.
When something changes in S/4, CENT doesn't run "the dispatch job". It builds a small tree of background processes — each branch independent, each level adding parallelism. The picture below is what really happens, top to bottom, every time a configured change is saved.
Inside the same transaction the user is saving, CENT runs a tiny step that collects the change data from the standard change-document mechanism. No filtering, no dispatching, no calls to anything else — just record the change and hand off. Control returns to the user immediately. This step is small enough that the user can't perceive it.
The captured change is handed to a brand-new bgRFC process dedicated to this single change. That's where the analysis starts. The first thing it does is look up which Projects in the system are configured to track this kind of object — for the article object that might be MYHUB, PRICING_COCKPIT and REA_REPLICATION; for a contract it might be only one. Whatever the answer is, this process spawns one bgRFC per Project and walks away.
Each Project's process is in its own work process now, on its own thread. It walks through every Event the Project has on this object, evaluates the filter rows, and decides which events should fire. Some Projects will produce zero matches and quietly finish. Others will produce one match. Others will produce many. Whatever the result is, no Project's analysis blocks any other Project's analysis.
For every Event that fires, CENT spawns a separate bgRFC process for each Consumer registered against it. If MyHub has two consumers on an event and the Pricing Cockpit has one, that's three more independent processes. Each consumer runs in its own work process, in its own memory. Whatever it does — write a message, recalculate prices, push to a downstream system — it does in isolation.
Isolation by design. If a single consumer dumps — runs out of memory, hits a database deadlock, throws an unhandled exception, anything — the dump stays inside that consumer's bgRFC process. The other consumers don't see it. The other Projects don't see it. The original user's session has been done for ages. One broken downstream can't take the rest of the pipeline down with it. And throughput scales by adding workers to the pool, not by tuning a single job.
Whenever something is changed in S/4 — an article, a price, a contract, a supplier — the system already records that fact through its change-document mechanism. CENT plugs into that core flow. From the moment a save happens, CENT can pick the change up, evaluate the rules, and hand it off — for every change in the system, as long as the configuration says so.
Nothing leaves S/4 unless you've told it to. Nothing is observed unless you've configured it. The signal layer is part of the same system the data already lives in.
The Real Scenarios page walks through two everyday situations — a price change and an article discontinuation — without any of the technical detail. Useful for a business audience.