Action Catalog
The action-type catalog is the shared library of actions that appear in the BizOps Engine Step Palette. Every canvas step references a catalog action by type and name.
Why the catalog exists
| Without a catalog | With a catalog |
|---|---|
| Each job invents its own action shape | All jobs share consistent action definitions |
| UI forms are hardcoded per step | Forms are generated from catalog parameters and tables |
| Runtime plugins drift from the designer | Plugin deployments bind to the same action names |
| Operators guess available capabilities | Titles and descriptions document what each action does |
Catalog contents
Each catalog entry typically includes:
| Field | Purpose |
|---|---|
| typeName | Action lane / family (Source, Logic, HTTP, and so on) |
| actionName | Concrete action identifier used by steps |
| title | Human-readable name in the palette |
| description | Short guidance for operators |
| parameters / tables | Schema that drives the configuration panel |
| version metadata | Supports versioned action definitions when present |
Optional nested title and description values on imported JSON are persisted to Mongo and returned by the catalog API unless overridden by palette mapping files.
How the client uses the catalog
- Loads
GET /api/v1/workflow/action-type-catalog(or a local mock when configured). - Groups actions in the Step Palette for search and drag-and-drop.
- When you place or select a step, binds
actionType+actionon the step. - Renders parameter and table forms from the selected action definition.
- Saves the configured values into the job workflow document.
For local palette development, the client can use VITE_USE_MOCK_ACTION_CATALOG=true so the UI does not depend on a live catalog API.
How the service seeds the catalog
On startup the workflow service can:
| Mode | Behavior |
|---|---|
| Seed when empty | Insert the in-code / classpath catalog if Mongo has no action-type rows |
| File sync | Import a JSON array from BIZOPS_ACTION_CATALOG_JSON_PATH |
| Always sync | Replace Mongo action-type documents on every startup when enabled |
| Dev reload | Optional POST .../action-type-catalog/reload when the reload endpoint flag is enabled |
| Metadata patch | Optional POST .../action-type-catalog/metadata to update titles/descriptions in Mongo |
Use always-sync and reload endpoints carefully — they are intended for local and controlled environments, not casual production toggles.
Plugin deployment registry
Alongside the catalog, the service maintains a plugin-deployment registry. GET /api/v1/workflow/plugin-deployments joins deployment records with action-type bindings so Orchyron can provision the right plugin runtime for an action.
| Concern | Why it matters |
|---|---|
| Lazy K8s provisioning | Runtime pods are created for actions that need them |
| Binding accuracy | Action names in the designer must match deployable plugins |
| Environment differences | Different clusters can expose different plugin sets |
Demo actions
The mock observability walkthrough commonly uses:
| Action | Role |
|---|---|
kafkaStreamTrigger | Source / ingest |
aiDebugScenario | Logic / diagnosis |
killProcessAction | Remediation dry-run |
These are safe for UI demos. Confirm real plugin availability before expecting production side effects.
Operator tips
- Prefer catalog titles over raw action IDs when training new users.
- If a step form looks empty, verify the catalog loaded and the action still exists after a sync.
- After importing a large catalog export, spot-check a few actions for missing descriptions.
- Keep designer catalog and runtime plugin registry in the same release train whenever possible.