Skip to content

Testing Configuration Changes

Making configuration changes to a live Workbench implementation carries real risk — a bad form definition prevents users from submitting risks, a broken pipeline blocks a risk action mid-workflow, and an incorrect be_config.json value can prevent services from starting. This page explains how to validate configuration changes before they reach SIT, UAT, or production.

Note

Workbench configuration lives in two places: business config (everything under config/ in the repository, including be_config.json and ui_config.json) and the environment profile (dynamodb/{env}/data.json) which holds environment-specific settings only. be_config.json sits in config/ — it is business config, not part of the environment profile. Both are deployed via the Send Partner Portal.

The testing hierarchy

Configuration changes should pass through at least three layers of validation before production:

  1. Local syntax validation — catch JSON errors before deployment
  2. Local functional testing — exercise the change in a running Workbench instance
  3. SIT/UAT smoke tests — verify the change behaves correctly in a production-like environment

1. Local syntax validation

Validate JSON before committing

All Workbench config files are JSON. Malformed JSON will cause a config reload failure, leaving the platform in its previous state (or failing to start if the file is loaded at startup).

Run a JSON lint check on all changed files before pushing:

# Validate a single file
cat config/{client}/actions/{business-class}/open-market-actions.json | python3 -m json.tool > /dev/null && echo "OK"

# Validate all JSON files in the repo (run from the config repo root)
find . -name "*.json" | while read f; do
  python3 -m json.tool "$f" > /dev/null 2>&1 || echo "INVALID: $f"
done

Schema validation

For form configs and action configs, the platform enforces a schema. Key structural rules to check manually:

  • Every action must have a code and a label
  • Every submission form field must have a code and a type
  • Pipeline JSON must have a name and a configuration array
  • Every pipeline component must have a componentType and a status of ACTIVE

2. Local functional testing

Picking up a config change locally

After making a change to a config file, copy/save it into the config directory mounted into your local Docker stack. Workbench refreshes its configuration periodically — there is no manual base-data reload step required during normal operation. If you need to force the change in immediately, restart the affected service (typically riskwire-underwriting).

Tip

Keep the service logs visible in a terminal (docker logs -f riskwire-underwriting). Config parse errors are logged with the file path and line number, making them easy to locate.

Testing form configuration changes

After reloading:

  1. Open the Workbench UI (http://localhost:3001 in the standard local setup)
  2. Navigate to or create a risk of the relevant business class and placing type
  3. Open the submission form and check that your changed fields appear correctly
  4. Test display conditions by setting field values that should show/hide other fields

Check the browser console for JavaScript errors if a field is not rendering as expected — display expression parse errors appear here.

Testing action configuration changes

  1. Navigate to a risk in the appropriate state
  2. Verify the action button appears (or is correctly hidden, if using displayCriteriaExpression)
  3. Click the action and verify prerequisites are enforced correctly
  4. Run the action through to completion and confirm the pipeline fires

Testing pipeline changes

Pipeline execution can be monitored via the pipeline admin endpoints on the Riskwire Hub service:

GET http://localhost:7443/swagger-ui.html

The Hub exposes endpoints to list pipeline instances, view their current state, and inspect component-level execution logs. Use this to confirm your pipeline component changes are being picked up.

For pipeline failures, check the Riskwire Hub database (agateway schema) — the pipeline_audit table logs each component execution attempt with its input, output, and error details.

Testing document generation

Generated documents can be previewed without completing a full risk action by using the document preview endpoint:

POST http://localhost:4858/v1/documents/preview

Pass a sample risk record payload and the template reference to generate a preview document. This lets you iterate on template changes quickly without having to trigger a full pipeline run.

3. Rule and expression validation

Rules engine testing

Rules can be tested in isolation via the Rules Engine Swagger UI:

GET http://localhost:4831/swagger-ui.html

The /v1/rules/evaluate endpoint accepts a rule code and a test payload and returns the evaluation result. Use this to verify that:

  • Boolean rules return the expected true/false
  • Value rules return the correct computed value
  • Nested rules (RULE type) resolve correctly through their chain

JSONPath expression validation

Display expressions in actions and form fields use JSONPath. Test JSONPath expressions against a sample risk record using an online JSONPath evaluator or a command-line tool:

pip install jsonpath-ng --break-system-packages

python3 -c "
from jsonpath_ng.ext import parse
import json

risk = json.load(open('sample-risk.json'))
expr = parse('\$.riskData[?(@.contractType == \"OPEN_MARKET\")]')
print([match.value for match in expr.find(risk)])
"

Keep a sample-risk.json file in your local development toolkit representing a typical risk in your business class. Update it periodically as the risk data model evolves.

4. File upload and validation testing

For bordereau or asset schedule changes, test the full file processing pipeline:

  1. Upload a test file via the File Management endpoint: 
    POST http://localhost:4990/file-management/v1/process
  2. Monitor the Validation Service (port 4991) logs for validation results
  3. Check the resulting asset records created on the risk

Keep a library of test files covering common edge cases: files with missing columns, files with unexpected data types, files at the row count limit.

5. be_config.json change testing

Changes to be_config.json (S3 business config) are among the highest-risk configuration changes because a bad value can prevent services from starting or initialising correctly. Test the following before promoting:

  1. Apply the equivalent change in your local PDE configuration (pde.dev.json), which stands in for be_config.json in the local Docker stack
  2. Stop your Docker stack: docker-compose down
  3. Start it again: docker-compose up -d
  4. Watch service startup logs for errors: docker-compose logs -f
  5. Once all services are healthy, exercise the affected feature

The homePartyId field is particularly critical — if it does not match the insurer trading party file, the platform will not start.

Note

In deployed environments, be_config.json is deployed via the Send Partner Portal and Workbench picks up the change on its next periodic configuration refresh. A service restart is only required for a subset of settings that are read at startup — confirm with your delivery lead which apply.

Common config errors and how to find them

Symptom Where to look
Form field not appearing Browser console for JSONPath parse errors; Underwriting service logs for form config load errors
Action button missing Check displayCriteriaExpression and actionPrerequisites in action config; check user role includes the action's defaultOwningRole
Pipeline not firing Hub database pipeline_audit table; Hub service logs
Config reload returns 500 Underwriting service logs — JSON parse error with file path
Service fails to start Check pde.dev.json locally / be_config.json in S3 — homePartyId and feature switch values in particular
Document generation fails Document converter service logs; check template Handlebars syntax
Rules not evaluating Rules Engine logs; use /v1/rules/evaluate endpoint to test in isolation

Automated testing patterns

For larger implementations, consider adding automated config validation to your CI pipeline:

  • JSON schema validation — run a JSON schema linter against all config files on every pull request
  • Config integration tests — use the platform's test harness (if enabled for your environment) to run scripted risk journeys and assert expected outcomes
  • Contract tests — the platform ships Spring Cloud Contract tests for inter-service communication; run these when changing pipelines that cross service boundaries

See also