The CSN Generator — one clean model, the same way every time

Part 4 of 7 · Series index · ← The MCP BW Connector · Next: The Web App →

This is the brain of the tool: raw metadata in, a finished Datasphere model out. The punchline is that it’s deterministic — feed it the same input and you get a byte-for-byte identical result, every time. Along the way we built one feature we were sure we needed, then deleted it. This post is about why „the same correct thing every time“ beat every cleverer idea.

Part 3 ended with a merged, faithful record of what BW knows about a concept. This post is about the piece that turns that record into something Datasphere can actually use — and, as Part 2 noted, it’s the one piece that holds no credentials and needs no network. It just transforms. This walks through what it produces, the tempting shortcuts we turned down, and the test that finally convinced us.

What we’re producing

Datasphere can import a model described in a format called CSN — think of it as a structured blueprint that lists tables, views, the relationships between them, and the keys that tie everything together. The generator’s whole job is to produce that blueprint from the tidy metadata coming out of the connector.

The CSN generator takes harmonized metadata in and produces one CSN model out — local tables, dimension views, text views, hierarchy views, associations and keys — and the same input always produces identical output.

Metadata in, one model out. For a single business concept the generator emits a small family of related parts: the tables that will hold the data, the views that present it for reporting, the text and hierarchy views that describe it, and the associations and keys that connect them all. They’re produced together and checked together.

CSN generator: tidy metadata in, one valid Datasphere model out, the same every time.

The shortcut we didn’t take: loose files (or a creative AI)

Two tempting shortcuts presented themselves early. One: generate each part as its own file and hand over a folder of them. Two: let an AI write the model — it’s good at this sort of thing.

We turned down both, for the same underlying reason. A relationship is only valid if the thing it points at actually exists; a key is only consistent if every part lines up. So we emit one model and validate the whole thing as a unit before anything leaves the tool — every relationship resolves, every key is complete, nothing dangles. You either get a model that hangs together or a clear explanation of what’s wrong. You never get a folder of files that each look fine alone but don’t fit together.

And the AI? An AI might produce a slightly different — even slightly better — model each run. For migrating a company’s reporting foundation, that’s the wrong kind of clever. The same correct thing every time beats a creative new thing every time. Feed the generator the same input and settings and it produces a byte-for-byte identical result — no timestamps, no random ordering, no „it depends.“ That sounds like a small technical nicety; it’s actually the thing that lets you diff two runs to see exactly what changed, audit the output because it’s reproducible, and re-run it without holding your breath.

Templates that are also tests

Where does the confidence come from that the output is right, not merely consistent? From real, working Datasphere exports. We took genuine, known-good models out of Datasphere, cleaned them up, and put them to work in two roles at once: as scaffolds the generator fills in, and as golden references — the answer key. A test regenerates the model from the original metadata and checks it matches the known-good version exactly. So the examples that teach the generator how to build a model are the same ones that prove it did. Drift away from the proven shape and the tests fail loudly. The structure can’t quietly rot.

The feature we built, then deleted

Here’s the honest detour. Early on we were certain the deliverable should be a Datasphere ER model — a single packaged object with the tables and views wired together inside it. It sounded right, so we spent a spike making it.

It didn’t survive contact with reality. When you import a model, Datasphere quietly ignores the ER-model wrapper; the packaging isn’t transportable that way and brings nothing to the table. The thing we thought we needed turned out to be decoration. So we cut it. The plain multi-object model already gives us the one guarantee we actually wanted — „one document, validated as a whole“ — without the wrapper. Deleting a feature you were proud of stings, but shipping it would have been complexity pretending to be value.

The type-mapping rabbit hole

A surprising amount of care goes into one humble question: what type is each field? BW describes fields in its own type system; Datasphere expects its own. Dates, numbers that must keep their leading zeros, fixed-length units, decimals — each needs a deliberate, correct translation. SAP’s official CSN specification was our most-thumbed resource here — it spells out exactly how each type must be expressed, and saved us a lot of guesswork. We hold ourselves to a hard rule: every field resolves to a known type, with zero untyped fields. An unmapped type is an error to fix, never a silent guess. That single rule kills a whole category of „it imported fine but the numbers look wrong three weeks later“ problems.

Clean names, and no holy wars about them

Two more principles keep the output tidy. First, the model carries clean, business-friendly names — no leftover internal SAP technical codes leaking into Datasphere; it reads like something a person designed, not a database dump. Second, naming conventions are a setting, not an argument. SAP publishes naming guidance, teams hold strong opinions about prefixes, and rather than bake one opinion into the code, every name comes from a configuration file. Want a different convention? Change the config, not the program. The generator itself contains no hard-coded names at all — which is also what lets one generator serve customers with different house styles.

Proof it actually works

The convincing test isn’t a green checkmark in our own suite — it’s a full round trip through a real system. We generated a complete model for a Cost Center (thirteen interlocking parts, including the notoriously fiddly hierarchies), imported it into a live Datasphere tenant, deployed it, and exported it back out. What came back was identical to what we generated. Datasphere added nothing, changed nothing, fixed nothing. That’s about as direct a confirmation as you can get that the blueprint is genuinely valid, not merely plausible.

Lessons learned

One validated model beats a tidy pile of files. Validate the whole, or you’ve validated nothing.
Determinism is a feature, not a constraint. It’s what makes the output auditable and safe to re-run.
Let your examples double as your tests. Known-good exports keep the generator honest for free.
Be willing to delete a feature you were sure about. The ER-model wrapper looked essential and turned out to be ballast.

Wrap-up

The generator is pure machinery — metadata in, model out, the same way every time. What turns that machinery into something a person can actually drive is the web app: the search box, the review screen, the download button. That’s Part 5.