Reading and writing MDG from code: the governance APIs

Three places data lives

In a migration you load straight into target tables. In MDG you never do. The active area holds approved data (BUT000, LFA1, CSKS, MARA). The staging area holds unapproved changes in generated tables. The change request (header USMD120C) is the envelope around them. Read active data through released views or APIs; change data only by creating a change request.

Data reaches the active area only after approval and activation.

Two APIs, two jobs

The governance API handles several objects in one change request, such as mass changes. The convenience API wraps the same steps for one object at a time, like the single-object UI. Both are documented in the MDG developer guides.

Write through a governance API. Read through the model API or released CDS views.

Creating a change request, step by step

Step through · 1 of 6

One API instance per data model; later calls use that model's entity types.

Same sequence for BP, material or finance objects.

What the code looks like

An outline with the convenience API. Check exact methods and parameters in SE24 on your release; the APIs have grown over MDG releases.

ABAP

" OUTLINE: verify method names and signatures in SE24 on your release
TRY.
    DATA(lo_api) = cl_usmd_conv_som_gov_api=>get_instance(
                     iv_model_name = '0G' ).
    lo_api->set_environment( iv_crequest_type   = 'ZCCTR1P1'
                             iv_create_crequest = abap_true ).
    " lo_api->enqueue_entity( ... CCTR key ... )
    " lo_api->write_entity_data( ... CCTR attributes ... )
    " IF lo_api->check( ) = abap_false -> log get_messages( ), stop
    " lo_api->save( ).
    " COMMIT WORK.  correct here: your own program owns the transaction
  CATCH cx_usmd_gov_api INTO DATA(lx_api).  " check exception classes
    MESSAGE lx_api->get_text( ) TYPE 'I'.
ENDTRY.

Try it: the API sequence

Try it · Put in order

A program creates a new cost center through the convenience API. Put the calls in order.

1Run the checks and stop on errors
2Lock (enqueue) the cost center key
3Write the cost center attributes
4Set the CR type and request a new change request
5Save, then COMMIT WORK in your program
6Get an API instance for data model 0G

From migration file to change requests

Your migration mapping skills carry over; only the target changes. Confirm entity names in MDGIMG (Edit Data Model) on your system.

Same discipline as a Migration Cockpit mapping, but the target is a change request.

One CR per object or one mass CR?

The trade-off is steward effort against blast radius. Check MDG's own upload and mass processing before writing a program.

Pick the granularity the business can actually approve.

Try it · What would you do?

300 new suppliers must be onboarded. Different stewards approve per region, and one bad row must not hold up the rest. What do you propose?

Why this matters for AI

Projects increasingly want AI agents that propose fixes: standard addresses, duplicate merges, missing tax numbers. The key design decision: the agent creates change requests through a small, tested ABAP service, and never writes active tables. Approval, validation, audit and replication stay intact.

AI proposes, governance disposes. Note the AI tool and confidence in the CR description.

Try it · Sort

Which of these can your code do, and which must it never do?

Fine

Never

Click an item, then a bucket (or drag it).

Remember

Active area, staging area and change request are different places; code changes data only via a change request.
CL_USMD_GOV_API handles multi-object scenarios; CL_USMD_CONV_SOM_GOV_API simplifies single-object ones; read via CDS or the model API.
AI integrations create change requests; they never write master data tables.

Check yourself

An AI tool proposes 500 address corrections for suppliers. What is the safest integration?

Your program cannot lock cost center 4711. What is the most likely reason?

Where should custom code read a supplier's approved name and country?