CENT — The signal layer for SAP master-data changes

The problem

Five integrations. Five maintenance burdens. Zero shared signal.

The default way to react to a master-data change in S/4 is whatever was easiest at the time: a nightly job that re-reads CDPOS, an IDoc with a custom mapping, an RFC poll every fifteen minutes, an email plugin, a Z-table flag column. Each one solves one downstream's problem and adds another moving part to operate.

Every team that needs the same event ends up writing it again. The capture logic drifts. Latency creeps up. When a field is renamed, three of those integrations break silently and one just keeps emailing the wrong group.

The shape of CENT

One capture point. One declarative rule engine. Many consumers.

CENT sits inside S/4 as an implicit enhancement on the change-document save. Rules live in customizing — a Project, a Change Document Object, an Event, and a list of Filter rows. When a save matches the rules, CENT writes a row to its event table and queues a bgRFC unit. Workers pick the unit up immediately and call whatever consumer classes the receiver group registered.

You configure once. Every downstream — MyHub, Pricing Cockpit, REA replication, anything you build next — subscribes by registering a consumer class against the same event. No new capture code per integration.

How you use it

Three steps. No code. The event is configured and ready for any consumer.

1

Create a Project

Give it a name, activate it. A Project is just a container for the events you want to broadcast — one Project per logical pipeline.

2

Pick an Object & create an Event

Choose the change-document object you want to track, define an Event, and add the filters you want. That's it — the rule is live. No code, no transports of program changes.

3

Consumers subscribe

Any system can register as a consumer of your event. Same Event, many consumers — MyHub, the Pricing Cockpit, REA Replication, anything you build next. None of them re-implement capture.

Why it works

Four properties that make CENT pleasant to operate.

Real-time, not job-based

Capture happens inside the save transaction. Dispatch happens on a bgRFC queue with a worker pool. There is no scheduler to monitor and no "next run" window to miss.

Parallel by design

Each captured event is its own bgRFC unit. Independent units run on independent work processes — throughput scales by adding workers, not by tuning a single job.

Declarative, in customizing

Rules live in tables, not in ABAP. Filter Values are reusable named constants. New events add rows; they don't add code or a transport of program changes.

Multi-consumer, by registration

A receiver group registers consumer classes. Adding a new downstream means writing one class and adding one row — every existing event is then available to it without rewriting capture logic.

Auto-retried

Each event has its own Retry Mode and Retry Count. If a downstream consumer fails, the dispatch replays automatically — operators don't need to babysit.

One signal source for everything

MyHub, the Pricing Cockpit, REA replication, special-buy site management, promotion-quantity changes — they all consume the same CENT events. Add a downstream by adding a consumer, not a new capture stack.

Who it's for

If you ship anything that reacts to SAP master data, CENT is the layer underneath it.

🛠

SAP integration teams

One configurable capture instead of N IDoc / RFC / job stacks per downstream.

📋

Master-data teams

A single, auditable trail of what was changed, by whom, and what reacted to it.

⚙️

Downstream app owners

Subscribe by registering a consumer class. Don't write change-capture logic again.

📊

Data platform teams

Real-time master-data signals to feed your warehouse / streams / reporting layer.

See it in action

Open ZCENT_SET to walk the Dialog Structure tree, then watch the bgRFC Queue Monitor process events in real time.

Open the demo → Read the architecture

The signal layer for your SAP master-data changes.