SoD — Objects
The Objects screen attaches source-system programs to SoD activities. One line per (Application, Process, Activity, Row, Object). Each row says: running this object counts as performing this activity. An activity typically maps to several objects — interactive forms, batch programs, the same program with different versions.
This is the bridge between the abstract SoD model and the concrete programs the source system runs.
At a glance
Goal of the view
- Tell Nomasx-1 what counts as "doing" an activity. Each row pins an SoD activity to a concrete source-system object.
- Multiple rows per activity is normal. Row numbers them — the engine considers any of them as evidence the activity was performed.
- Source for Conflicts → Proven. Without an object mapping the activity has no observable footprint, so the proven analysis cannot work.
Columns
| Column | Source | What it tells you |
|---|---|---|
| Application ID | OBJECT_APPS_ID — application. | The application. |
| Process ID | OBJECT_PROCESS_ID — process. | The SoD process. |
| Activity ID | OBJECT_ACT_ID — activity. | The activity the object backs. |
| Row ID | OBJECT_ROW_ID — sequence. | Stable identifier among the objects of the same activity. |
| Object ID | OBJECT_ID — technical object. | Program code (e.g. JDE P0401). |
| Object Name | OBJECT_NAME — friendly label. | Human-readable name of the program. |
Edit dialog
Click Add or double-click a row to open the form.
| Field | What to enter |
|---|---|
| Application | Drop-down of declared applications. |
| Process | Drop-down filtered to the chosen application's processes. |
| Activity | Drop-down filtered to the activities of the chosen process. |
| Row | Sequence number within the activity's object list. Auto-incremented; edit to reorder. |
| Object ID | Source-system program code (e.g. JDE P0401). |
| Name | Friendly name of the program. |
Tips & best practices
- Map every program that touches the activity — the Proven view depends on a complete mapping. Missing rows produce false negatives on the conflict analysis.
- Re-check the mapping after a source-system patch — new versions of a program (or a new alternative entry point) need to be added here.
- Per-activity mappings should not overlap. The same object on two different activities makes the model ambiguous.