This guide explains how to define transformation rules and use the transformation workspace. A tutorial video demonstrating how to create a transformation rule can be found here.
A transformation rule describes how a source pattern is matched and how result elements are produced.
Core concepts:
- LHS (left-hand side): match pattern
- RHS (right-hand side): output pattern
- NAC (negative application condition): forbidden pattern(s)
- priority: ordering/precedence signal
- enabled flag: active/inactive state
Open Transformations from the main navigation. The dashboard has two tabs:
- Rule Editor
- Execution
Use Rule Editor to author and manage rules. Use Execution tab to run transformation flows.
Typical rule-authoring flow:
- Open Rule Editor.
- Create new rule and assign a name.
- Define LHS pattern structure.
- Define RHS pattern structure.
- Add NAC patterns if needed.
- Set priority and enabled state.
- Save and verify rule list updates.
A rule contains embedded pattern objects (not separate persisted pattern entities in backend API):
lhsPatternrhsPatternnacPatterns[]
Patterns typically include:
- pattern name/type
- pattern elements
- attributes/references constraints
Supported management operations:
- edit rule metadata (name, description, priority)
- update embedded pattern content
- enable/disable rule
- delete rule (owner-level restrictions apply)
Execution tab is used to run transformation processes and inspect outcomes.
Important implementation note for users:
- backend API fully supports rule CRUD
- some execution/pattern workflows are handled client-side service logic and compatibility routes
This means authoring and managing rules is stable, while execution behavior may depend on current frontend orchestration paths.
- start with small, single-purpose rules
- keep NACs minimal and explicit
- use priorities only when deterministic order is required
- avoid overloading one rule with too many concerns
Cause: mismatch between LHS conditions and actual model state.
Fix: simplify LHS and verify element/attribute names.
Cause: NAC pattern is matched, so rule application is intentionally prevented.
Fix: review NAC logic and reduce overly broad conditions.
Cause: multiple rules overlap with same intent.
Fix: adjust priorities and rule scope.
Cause: expecting standalone pattern persistence while backend stores embedded patterns inside rules.
Fix: manage patterns through rule objects in Rule Editor.
- Finalize metamodel and baseline models.
- Create one transformation rule at a time.
- Verify outcomes incrementally.
- Add NAC and priority only when needed.
- Keep rules readable and modular.
frontend/src/components/transformation/TransformationDashboard.tsx: Main transformations workspace container.frontend/src/components/transformation/TransformationRuleEditor.tsx: Rule authoring UI for LHS/RHS/NAC and metadata.frontend/src/components/transformation/TransformationExecutionPanel.tsx: Execution tab UI and result views.frontend/src/services/transformation/transformation.service.ts: Frontend transformation service orchestration.backend/src/routes/transformation.routes.ts: Backend API endpoints for transformation rule CRUD and execution paths.