SAP MDG · DATA MODEL UI
How do I implement an SAP MDG GUIBB feeder class with proper GET_DEFINITION, GET_DATA, GET_FIELD_UI_PROP, and PROCESS_EVENT handling?
In SAP MDG feeder classes, use GET_DEFINITION for metadata, GET_DATA for runtime population and field usage, GET_FIELD_UI_PROP for field-level behavior, and PROCESS_EVENT for user-triggered actions. Read the change request context only when bound, keep roundtrips lightweight, and drive read-only/visibility from edit mode and CR phase.
In SAP MDG feeder classes, use GET_DEFINITION for metadata, GET_DATA for runtime population and field usage, GET_FIELD_UI_PROP for field-level behavior, and PROCESS_EVENT for user-triggered actions. Read the change request context only when bound, keep roundtrips lightweight, and drive read-only/visibility from edit mode and CR phase.
SAP MDG feeder classes should follow the FPM lifecycle: define the UI in GET_DEFINITION, fill data and runtime usage in GET_DATA, control individual field behavior in GET_FIELD_UI_PROP, and handle user-triggered actions in PROCESS_EVENT. The key implementation rules are to read `CL_USMD_APP_CONTEXT` safely, avoid expensive roundtrip logic, and centralize read-only or visibility decisions in a single branch model.
Process flow
- Use GET_DEFINITION to define the GUIBB metadata and actions.
- Use GET_DATA to populate runtime data and field usage.
- Read `CL_USMD_APP_CONTEXT=>GET_CONTEXT` only when the reference is bound.
- Extract CR ID, CR type, step, or process once and reuse them.
- Use GET_FIELD_UI_PROP for field-specific read-only, enabled, and visibility logic.
- Use PROCESS_EVENT to react to user actions and append messages to `et_messages`.
- Preserve standard behavior with `super->...` unless you intentionally override it.
- Keep DB access and context reads lightweight and avoid repeated calls in loops.
Referenced tables
| Object | Purpose |
|---|---|
CL_USMD_APP_CONTEXT | Runtime API used to access the MDG application context safely |
FPM GUIBB field usage structures | Used in feeder methods such as GET_DATA and GET_FIELD_UI_PROP to control read-only and enabled behavior |
The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- How do I build an MDG Form or List feeder class?
- How should I handle CR context safely in a feeder class?
- How do I control read-only and visibility in GET_FIELD_UI_PROP?
Possible questions
- How do I read the MDG change request context in a feeder class?
- How do I make a field read-only based on edit mode in MDG?
- How do I keep GET_DATA lightweight in an FPM feeder?
- How do I append messages from PROCESS_EVENT?
- How do I choose between GET_DATA and GET_FIELD_UI_PROP for UI logic?