Lesson 2 of 5
Modeler basics
11 min
The modeler works on a migration project. When you open LTMOM, you choose the project created in the Migrate Your Data app, and you see the migration objects that belong to it. Changes you make in the modeler apply to the objects as they exist in that project, which is why a well-run program keeps one controlled project per purpose rather than many personal ones.
The four parts of an object
Every migration object, predefined or your own, is built from the same parts. Understanding them is most of what you need to read and change an object safely.
Read an object from the bottom up when debugging ("which rule fills this target field?") and from the top down when designing ("which source fields will users fill in the template?"). The source structures are what the business and the staging process see. The target structures are what SAP sees. Everything in between is the mapping you own.
Rules and their building blocks
| Building block | Purpose | Example |
|---|---|---|
| Translation object | A value mapping from source codes to target codes, which shows up as a mapping task in the app | Legacy payment term CR30 to target payment term 0004 |
| Fixed value | A constant offered as a mapping task, the same for every record | Sales organization 1910 |
| Variable | A value set once per run and used by rules | A key date for the extract |
| Rule | Logic, often a small piece of ABAP, that derives a target value from source fields | Derive the business partner grouping from the legacy customer type |
Rule building blocks in the modeler. Names and options can vary by release.
Prefer translation objects and fixed values over coded rules. They are visible to the business as mapping tasks in the Migrate Your Data app, they can be reviewed against the mapping specification, and they need no developer to change a value. Use coded rules for genuine logic, keep them short, and document each one in the specification with an example.
Generating and synchronizing
After changing an object, you generate it so that the runtime that the cockpit uses reflects your changes. When source structures change in a staging table project, the staging tables must be synchronized with the new structure before data is filled; a downloaded template from before the change no longer fits. Build this into the team's routine: every structural change ends with generation, synchronization where needed, a fresh template download and a note in the change log.
- Open projectChoose the migration project in LTMOM
- Change objectSource structures, mapping or rules
- GenerateRuntime object regenerated from the model
- SynchronizeStaging tables updated for changed source structures
- New templateDownload again; old templates no longer fit
- Log itChange, version and reason recorded with the specification
Authorizations and who does what
Using the modeler is a developer-level activity and needs its own authorization, separate from the business user role that runs migrations. SAP delivers role templates for both; in many releases the modeler role is SAP_CA_DMC_MC_DEVELOPER and the migration user role is SAP_CA_DMC_MC_USER, but check your release documentation. At Contoso, the data migration specialist and one ABAP developer hold the modeler role in development only; everyone else runs migrations.
| Task | Migration specialist | ABAP developer | Data owner |
|---|---|---|---|
| Decide adapt or create | Proposes | Advises on APIs | Approves the data scope |
| Change structures and mappings | Does | Supports | Reviews the specification |
| Write coded rules and function modules | Specifies | Does | None |
| Maintain translation values | Prepares | None | Approves |
| Test and transport | Leads tests | Fixes and transports | Validates results |
What would you do?
After a Wave 2 specialist adds a field to the product source structure and generates the object, the next staging upload fails. The team had filled the staging tables from a template downloaded last week. What is the most likely fix?
- An object has source structures, target structures, structure mapping and field mapping with rules.
- Prefer translation objects and fixed values, which appear as mapping tasks, over coded rules.
- After changes: generate, synchronize staging tables, download a fresh template, log the change.
- Modeler work needs a developer-level role, separate from running migrations.
Check your understanding · not graded
Lesson check
1. What do target structures represent in a migration object?
2. Why prefer translation objects over coded rules for value mappings?
3. What must happen after a source structure changes in a staging table project?
4. A user adds a column to a downloaded template by hand. What is the risk?