Attribute Validation

A common requirement from channels is the ability to validate and/or allow certain fields on API calls. This involves the need to define a set of allowed values or a specific pattern against certain fields for certain paths. To address this, Eclipse provides the PayloadValidationPlugin, which can be activated by setting the following global configuration:

impl.com.ukheshe.arch.conductor.aaa.PayloadValidationProvider=com.ukheshe.eclipse.conductor.aaa.EclipsePayloadValidationProvider

This is a global property, not a tenant config. Set it once at the global level to activate the plugin for all tenants. Individual validation rules are then configured per-tenant, per-institution, or globally as described below.

This plugin validates only POST and PUT request attributes. No code changes are required — all validation rules are driven by configuration. Rules can be set at three levels, with the following precedence (highest to lowest):

1. Tenant level — request.payload.validation.rules.<tenantId>
2. Institution level — request.payload.validation.rules.<institutionCode>
3. Global level — request.payload.validation.rules.global

For example, if we want to validate a certain set of values for the industrial classification while creating an organization for a specific tenant, we can configure the property as follows:

request.payload.validation.rules.\<tenantId\>=rest/v1/tenants/(?\<tenantId\>\d+)/organisations=$.industrialClassification=(?i)(Manufacturing|Construction)

The key in this configuration is request.payload.validation.rules.<tenantId>, where the suffix can be:

• A numeric tenantId for tenant-specific rules
• An institution code (e.g. DTB) for institution-wide rules
• The string global for rules that apply to all tenants

Rule Value Format

Each rule value is a newline-separated list of path rules. Each path rule has the format:

<url-path-pattern>=<json-path>=<regex>[,<json-path>=<regex>...]

Multiple fields for the same path are comma-delimited. Multiple paths are placed on separate lines.

Example: tenant-level validation on tenant 12345

Key:   request.payload.validation.rules.12345

Value:
rest/v1/tenants/(?<tenantId>\d+)/organisations=$.industrialClassification=(?i)(Manufacturing|Construction),$.phone1=^\d{10}$

Example: institution-level validation for institution DTB — validates organisation creation and document uploads for all tenants under that institution:

Key:   request.payload.validation.rules.DTB

Value:
rest/v1/tenants/(?<tenantId>\d+)/organisations=$.industrialClassification=(?i)(Manufacturing|Construction),$.phone1=^\d{10}$
rest/v1/tenants/(?<tenantId>\d+)/organisations/(?<organisationId>\d+)/documents=$.base64EncodedDocument=^\s*$

Note: After configuring path and attribute rules, the plugin automatically applies null and empty checks by default. If a validatable attribute is present in the request but is null, empty, or missing, the plugin returns an HTTP 400 error indicating the request is invalid. To make a field optional — i.e. only validate it when it is present — do not include it in the rule configuration.