Cloning & customising models

[Enevoldsen]

Sooner or later you'll find a model that's almost what you want. You're after sales orders, there's a CP: Sales Order model sitting right there in the list, you open it to make a small change, and the form won't let you. The model is read-only, and a message tells you it belongs to a content pack. That isn't a permissions glitch. It's the product steering you toward the right move, which is to clone the model and change the copy.

This article is about why that's the pattern, what a clone actually hands you to start from, and where the real work happens once you have one.

Why you clone instead of edit

The models that ship with Zero Copy Connector for ERP fall into two groups, and neither is meant to be edited in place. There's a standard set, things like SAP Material Stock and SAP Purchase Document, and there are the content pack models, which carry a CP prefix on their names. Both are read-only on purpose.

The reason is that other things already depend on them. A shipped model defines a data structure, and once a remote table, a flow, or another application on the platform is wired to that structure, changing it underneath them is how you break things you didn't mean to touch. Cloning sidesteps that entirely. You take a copy into an application scope you control, and from then on you're changing your model, not the one half the platform is leaning on. The original keeps doing its job for whatever already uses it, and your changes stay contained to your copy. 

So a content pack model being read-only isn't a wall, it's a starting line, it is an accelerator. You're expected to clone it. The CP prefix is just how you spot which models came from a pack and therefore need cloning before you can make them yours.

What a clone gives you to start from

It helps to be clear about what content packs and standard models actually are, because the name "content pack" makes them sound like a fixed catalogue of what's possible. They aren't. They're examples and accelerators. The pre-built Sales Order model is one worked example of how to read and write sales orders, not the boundary of what ZCC can do with them.

What that means in practice is that a clone doesn't hand you a blank model to fill in. It hands you one that already works. The operations are there, the input and output mappings are done, the entity is connected, and the protocol is already chosen and tested. Someone has already done the fiddly part of getting a sales order to read or write correctly, and you're starting from that and changing the bits you need, rather than assembling the whole thing from scratch. For most use cases that's the difference between an afternoon and a couple of days.

The mistake worth avoiding

The most common way people misread content packs is to treat the protocol the pack chose as a requirement. The Sales Order content pack uses RFC and BAPI, and from that it's easy to conclude that sales orders have to go over RFC and BAPI. They don't. If your S/4HANA landscape makes OData v2 the better fit, you can build a sales order model on OData v2 against API_SALES_ORDER_SRV and it's every bit as valid. The content pack picked one route because it had to pick something, not because the others are closed off.

This matters because it changes how you treat the clone. The Model Manager is the same building block whether you're going over a BAPI, a SAP table, or OData v2. The clone gives you an example in one of those styles, and you're free to keep that style, adjust it, or rebuild the operation on a different protocol if that's what your system and your use case call for. The content pack is a head start.

Where the customising actually happens

Once the clone is sitting in your own scope, the work moves into managing the model. This is where you swap or add the table the model reads, define the read, create, and update operations you need, and set up the inputs and outputs. Reads can come from a table or through a BAPI or OData call. Writes go back through a BAPI, OData, or IDoc. If the data has structure to it, this is where you add the nested parameters that carry it, and where you build the joins that pull related tables together. You can also rename the mapped values to something a person reading a flow will understand, instead of the system-generated names.

Keeping a custom model healthy

A clone is only as good as your understanding of it. The model works because someone got the mappings and the operation right, so it pays to see what it's doing before you start changing things, rather than tearing out parts whose job you haven't worked out yet. Change one thing at a time and test it against real ERP data, because a mapping that looks right and a mapping that returns the right values aren't always the same thing.

The other habit to build is around SAP versions, because the instinct to worry about the wrong risk is strong here. BAPI signatures are stable across SAP releases, so an upgrade isn't going to silently change the shape of a call you built on. What does happen is that a BAPI gets deprecated, or replaced by an S/4HANA-native OData equivalent, or quietly changed in the logic of what it returns or how it behaves. Those are the things that catch out a custom model over time, not the signature shifting under you. Knowing that tells you where to look when something that worked last year stops behaving.

Keep the model in its own application scope and that maintenance stays clean, including moving it from a non-production instance to production through an exported update set when you're ready.

Starting out

Find the shipped or content pack model nearest to what you need, clone it into a scope you own, and change the smallest thing that makes it fit. Test that, then go further. Building a model from scratch is always there if nothing close exists, but it's rarely the fastest way to something that works, and with a good example in front of you it's seldom the one you'll reach for.