Search Results gma_actdef_wf_uk

Overview

GMA_ACTDEF_WF is a table owned by the GMA schema (Process Manufacturing Systems) within Oracle E-Business Suite. As the "_WF" suffix suggests, it stores workflow-related activity definitions used by Process Manufacturing. Per the ETRM documentation, it "is used to define the activity where a role has to be" — in other words, it maps process activities to Oracle Workflow item types and processes so that the correct responsibility or role is engaged at a given step in a business flow. It is a configuration and metadata repository rather than a transactional table: records are static definitions, maintained infrequently by administrators, and referenced at runtime by the Workflow engine.

From a Data Vault modeling perspective, the mined relationship data classifies this object as standalone. In heuristic terms, this suggests treating GMA_ACTDEF_WF as a hub candidate, keyed on ACTIVITY_ID, with the descriptive and audit attributes (DESCRIPTION, COLUMN_DATA_SQL, and the standard WHO columns) behaving as satellite attributes. Because no foreign keys are documented, the table is not a natural link table.

Key Information Stored

The documented physical schema contains eleven columns. The following are the most significant:

• ACTIVITY_ID — the surrogate primary key, enforced by the GMA_ACTDEF_WF_PK index. Uniquely identifies each activity definition row.
• WF_ITEM_TYPE — the Oracle Workflow item type that the activity belongs to. This is the top-level qualifier of the activity's workflow context.
• PROCESS_NAME — the workflow process (activity) name within the item type.
• ACTIVITY_NAME — the specific activity within the process. Together with WF_ITEM_TYPE and PROCESS_NAME, this forms the business-key candidate GMA_ACTDEF_WF_UK, guaranteeing that a given item type/process/activity combination is defined only once.
• DESCRIPTION — free-text explanation of what the activity represents or which role it targets.
• COLUMN_DATA_SQL — a SQL fragment, presumably used to resolve or supply column-level data for the activity dynamically at runtime.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN, the standard Oracle EBS WHO columns tracking row-level change history.

The distinction to note is between the surrogate key (ACTIVITY_ID, exposed via the _PK index) and the composite business key (WF_ITEM_TYPE, PROCESS_NAME, ACTIVITY_NAME, exposed via the _UK index). Application code should query by the latter when resolving a workflow definition by name.

Common Use Cases and Queries

Typical use cases include tracing which activities belong to a Workflow item type, resolving the correct definition for a given process step, and auditing definitional changes to Process Manufacturing flows. A common pattern resolves an activity by its business key:

• SELECT activity_id, description, column_data_sql FROM gma.gma_actdef_wf WHERE wf_item_type = :p_item_type AND process_name = :p_process AND activity_name = :p_activity;
• SELECT wf_item_type, process_name, activity_name FROM gma.gma_actdef_wf WHERE activity_id = :p_activity_id;
• Audit reporting on recently changed definitions: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to track who modified an activity and when.

Because the table is small and definition-oriented, queries are generally lightweight and are best executed directly against GMA rather than through a public API.

Related Objects

No formal foreign keys are documented, so relationships are logical rather than enforced at the database level. The most significant dependencies are:

• Oracle Workflow base tables (WF_ITEM_TYPES, WF_PROCESS_ACTIVITIES, WF_ACTIVITIES) — joined via WF_ITEM_TYPE, PROCESS_NAME, and ACTIVITY_NAME to link GMA activity definitions to the Workflow engine's own metadata.
• Other GMA activity-definition tables (e.g., GMA_ACTDEF and its _B/_TL variants, if present) — related by ACTIVITY_ID as the shared surrogate key.
• Process Manufacturing workflow configuration views and responsibility/role assignments that consume ACTIVITY_ID to determine which role performs an activity.

Any custom integration should treat GMA_ACTDEF_WF as the authoritative source for the mapping between an ACTIVITY_ID and its Workflow identity, and should join to the Workflow tables on the composite business key rather than assuming a referential constraint exists.