Rule Designer

The Clarive Rule Designer is the interface for designing, prototyping, writing and testing Clarive rules.

This document describes how to use the rule designer interface. For specific details on how to implement specific rules, head over to the (creating rules)[/rules/creating-rules] document.

The Rule Designer is divided into 3 specific area:

• Rule explorer - navigate through available rules in the system
• Rule editor - edit a rule content
• Rule palette - list available ops for dragging and dropping

Rule Explorer

The rule explorer shows the list of rules available in the system. The rule explorer has 2 modes: list and tree. The mode can be changed with the list/tree button in the button panel.

Every rule has a name and an id. Also the modified time and the last modifier username is shown in the list.

Actions

Actions defined are:

• Create - Use to start a configure a new rule.
• Edit - Edit selected rule.
• Delete - Delete selected rule.
• Tree view - Organise the rules based on the type.
• Activate - Activate selected rule.
• Tools - Import or Export the rule to other Clarive system in YAML format.

Palette

The palette contains all available ops in the system.

What are ops anyway?

Clarive ops (from operations) are the elements that give a rule its functionality. They have been called tasks or actions, but we think ops, with just 3 letters, is a better, if not geeky, name for such tiny bit of functionality.

Depending on what plugins and features are installed, there may be more or less ops available to the user.

It has an action tab with two action:

Search - To find a rule with a mask as input.

Refresh - To refresh the palette

If the parameter show_in_palette is set to one in the JS config file, the operation defined will be available in the palette.

Palette Ops

It is divided in seven types of tasks:

1. Statements -Provide control flow rule, they are IFs and Fors, and ad- hoc tasks.
2. Services - Operating in the pass, they can be:
3. Job Services - Tasks associated to a job.
4. Generic Services - General type.
5. Workflow - All services related to workflow rules.
6. Blueprint - All variables created as a Resource that user can use in Blueprint rules.
7. Rules - Allow including rules within other rules, these rules to be include have to be of independent type.
8. Dashlets - Use to build dashboards.
9. Fieldlets - Fieldlets that shape the form.

Rule Editor

The rule editor (central) panel is where the rule logic can be created and modified.

It's also the drag-and-drop destination for palette ops. Drag and drop ops from the palette into the rule editor to get started.

Rule Tree Area

Area where selected rule is displayed as a tree, it has an action tab with some operations, they are:

• Refresh - To refresh the rule
• Save - To save rule.
• Check - To check rule (see Quality Analysis).
• DSL - Raises up a new window with DSL code from the rule selected. This code can be executed. This functionality will be described in the rule palette page.
• Tools - Some additional options:
• Regular expression - Allow to search a regular expression.
• Ignore case - Activate/Desactivate case sentitive to search text.
• Blame by time - Mark the changes in the elements by a specific period of time.
• Variables - Show rule variables (Resources).
• Expand all : Expands every single rule in any job step.
• Collapse all - Collapse every rule and step, just viewing start point.
• Version - Expands all history versions from the rule selected. The output shows date, time and user who saved the rule. It is possible here to add tags to one or more previous versions of the rule by right-clicking on each selected version, selecting Add tag, and entering a name in the Tag field. This makes it possible to revert back to an earlier version in the event of an error occurring when deploying Topics using the latest version.
• HTML - Displays in another navigator tab, op properties values and configuration from every op included in the selected rule.
• Flowchart - Displays tree of the rule

Version History and Compare

The Rule Designer keeps a history of every saved version of a rule. To access the version history, click MORE > History in the toolbar.

The history panel replaces the rule tree with a list of all saved versions, showing the version number, date, and who saved it.

Right-clicking on a version in the history panel opens a context menu with:

• Compare with Current - Opens a visual side-by-side comparison between the selected version and the current (latest saved) rule tree.
• Compare with Previous - Opens a visual side-by-side comparison between the selected version and the version directly below it in the history.
• Add tag - Assigns a label to the version for quick reference.
• Uninstall - Reverts the rule to this version.

Visual Compare Panel

The compare panel displays two rule trees side by side with color-coded differences:

• Yellow - The operation has been modified (its configuration changed).
• Green - The operation was added (exists only in one version).
• Red (with strikethrough) - The operation was removed.
• Gray (italic) - Placeholder shown on the opposite side of an added or removed operation to keep both trees aligned.

Parent nodes (such as GROUP, ELSE, IF blocks) are highlighted in yellow if any of their child operations have changes, even when the parent's own configuration is identical.

Each side of the panel displays a header with version information (version number, author, and date) so you can identify which version is on each side at a glance.

Use the PREVIOUS and NEXT buttons in the toolbar to navigate between changes. The navigation skips parent container nodes and jumps directly to leaf operations that have actual configuration differences.

When comparing with the current editor version, a Copy to Current button appears in the toolbar. Click it to copy the version's configuration for the currently navigated operation into the live editor tree. The rule will be marked as unsaved so you can review the changes before saving.

Double-click on any modified operation to open a configuration comparison modal. This modal shows all configuration fields for both versions side by side, with changed fields highlighted in yellow, added fields in green, and removed fields in red. Each side of the modal also shows the version information in its header. When comparing with the current version, a Copy to Current button appears at the bottom of the modal to apply the version's configuration to the live editor tree.

When a field contains code (such as Perl expressions or JavaScript), the comparison modal displays a line-by-line diff with proper formatting: added lines appear in green, removed lines in red, and unchanged lines in their original form. Code fields are shown in collapsible sections with monospace formatting.

Only meaningful configuration changes are shown — metadata fields such as internal IDs and timestamps are automatically filtered out.

HCL View

The rule tree can be read and edited as Clarive HCL text. There are two ways in, both leading to the same editor:

• the HCL button in the toolbar — an icon showing braces around an H;
• MORE > HCL in the menu.

The button is a toggle: its tooltip reads HCL View on the way in and Back to the tree on the way out, and it turns the primary colour while the view is active.

pipeline "deploy-foo" {
  desc = "Deploys foo"
  when = "promote"

  step "PRE" {
    sh "Restart app" {
      host     = generic_server.web01
      run      = "systemctl restart app"
      on_error = "continue"
    }
  }
}

The HCL view replaces the rule tree the way the flowchart does, and hides the rule toolbar while it is open. Every way out — the editor's Back, the designer's Back and the toggle — restores the toolbar, and each asks before discarding unsaved changes.

The rule list offers the same editor per row: the row action menu has an HCL entry that opens it in a modal.

Validation runs half a second after you stop typing. Problems appear as gutter markers and as one line in the status bar, <count> - <line>:<col> <message>, with the first error taking precedence over any warnings. A file with diagnostics is never stored.

Saving goes through the same save the tree editor uses, so versioning, the concurrent-edit check and rule events are all unchanged. The text is formatted before it is sent, and the editor reloads afterwards — a save legitimately changes the text as defaults settle and references canonicalise.

An All attributes switch re-encodes the rule with every operation parameter written out, including those sitting at their form default. It is the same thing cla export --all-attributes does.

There is no setting that opens rules in HCL by default; the view is always entered by explicit action.

See Rules for the operation vocabulary and In the UI for the rest of the editor's behaviour.

Rule Runner

The rule runner is a debug panel shown when there are any issues found with the rule. It's possible to see the operation that caused the problem and a short description.

Creating a Rule

When creating a rule, the rule creation wizard opens. The user has to decide first which type of rule to create, type a name and configure the rule.

There are many types of rules that can be created using the Rule Designer. These are the available rule types in Clarive:

• Independent
• Webservice
• Event
• Pipeline
• Form
• Workflow
• Dashboard
• Report
• Blueprint

Read more about the different rule types in the creating rules documentation.

The rule creation options can be changed later if needed with the Edit button.