Skip to main content
Rules and schemas are backend-owned contracts. Changes to either propagate through every run that references them. The UI creates and edits them through facade services; the backend validates, stores, compiles, and executes them.

​
RuleSet model

RuleSet reconciliation is centered on these entities: All six live in entity/RuleEntities.xml under the darpan.rule package. Facade services create saved runs and RuleSet structures together when the workflow needs a runnable compare.

​
Rule execution

Rule execution is owned by:
Key service responsibilities:
  • Save and delete RuleSets and Rules
  • Compile active rules into a Drools/KIE container
  • Execute rules against compare-ready data
  • Execute rules against matched pairs from the Spark base diff
  • Clear the RuleSet cache after rule changes
The rule engine service file defines:
sweep#RuleChildTenantStamps backfills the tenant stamp on rule-set child rows and runs as a registered data migration. save#Rule accepts either structured ruleLogic or plain-text ruleText; plain text is parsed by RuleConditionParser and rejected when it cannot be parsed into an explicit operator expression. Saving or deleting a Rule or RuleSet invalidates the compiled Drools cache for that RuleSet. Rule logic is validated twice: when save#Rule stores it, and again at compile time, so a rule row that reached the database by another path is checked before Drools sees it. Raw DRL rule … end blocks authored by a tenant are rejected at compile time. Platform rules loaded from seed data and field-comparison rules, whose DRL the server regenerates, still compile. An environment can allow tenant raw DRL only by setting the darpan.rules.allowRawDrl system property to true; it is off by default. Execution services are file type agnostic. Callers parse CSV, JSON, or other source payloads into compare-ready data facts before invoking the RuleSet engine.

​
JSON schema model

Schemas describe source data shape and parsing expectations. The backend stores schema definitions as records, not UI-only configuration. The main schema entity is:
It is defined in entity/JsonSchemaEntities.xml with a tenant-scoped unique name index on (companyUserGroupId, schemaName), so each tenant has its own schema namespace. Schema records include fields such as:
  • jsonSchemaId
  • schemaName
  • description
  • systemEnumId
  • ownerUserId
  • companyUserGroupId
  • createdByUserId
  • schemaText
  • statusId
The service layer under service/jsonschema/** owns schema validation, inference, persistence, and lookup behavior.

​
Backend ownership

Workflows that depend on rules or schemas use Darpan component service contracts. Rules and schemas are persisted backend configuration, not browser-local state.