Pipelines

Pipelines are triggered at specific points in the risk action lifecycle. They call one or more REST endpoints in sequence, enabling server-side logic to run automatically as a user progresses through their workflow.

Pipeline files

Pipelines are defined as JSON files in:

config/{client}/pipelines/

One file per pipeline. The filename (without .json) must match the pipeline's name field.

Pipeline structure

{
  "name": "appetite_check_completion",
  "description": "Runs appetite check validation on completion",
  "components": [
    {
      "name": "call_appetite_check",
      "componentType": "SEND_AND_RECEIVE_VIA_REST",
      "attributes": {
        "urlPath": "${componentUrl.CLIENT_SPECIFIC_APP}/client-rest/v1/appetite-check/risk/{riskId}",
        "httpVerb": "POST",
        "auth": "BASIC"
      }
    }
  ]
}

Field	Description
name	Must match the filename (without .json extension)
description	Human-readable. Does not affect behaviour.
components	Array of endpoint calls. Executed in order.
componentType	See component types below.

Component types

componentType	Purpose
SEND_AND_RECEIVE_VIA_REST	POST/PUT/PATCH to an endpoint and wait for a response. The response is passed back into the risk context. Use this for calls where you need the result (e.g. appetite checks, rating, sanctions).
SEND_REST	Fire-and-forget POST to an endpoint. Does not wait for a response beyond HTTP 2xx acknowledgement. Use for notifications and async triggers.
RECEIVE_REST	GET from an endpoint and pull data into the risk context. Use for pre-populating risk data from an external source.
RUN_RULES_ENGINE	Invokes the rules engine for the current risk. No URL required — uses the rules engine URL from dynamodb/{env}/data.json.

Component attributes

All REST component types share these attributes fields:

Field	Valid values	Description
urlPath	string	The endpoint URL. Use ${componentUrl.CLIENT_SPECIFIC_APP} for client microservice calls.
httpVerb	GET, POST, PUT, PATCH, DELETE	HTTP method. RECEIVE_REST uses GET; SEND_REST and SEND_AND_RECEIVE_VIA_REST typically use POST.
auth	BASIC, NONE	Authentication scheme. Use BASIC for client microservice endpoints (handled by the platform). NONE for unauthenticated endpoints.

Endpoint URL format

Client microservice endpoints follow this pattern:

${componentUrl.CLIENT_SPECIFIC_APP}/client-rest/v1/{your-path}

CLIENT_SPECIFIC_APP is a constant placeholder for all client microservice endpoints. Only the path segment changes to match your Spring controller's @RequestMapping.

Available URL variables:

Variable	Value injected
{riskId}	The current risk's ID
{riskActionInstanceId}	The current risk action instance ID

Pipeline trigger points

Pipelines are referenced in the risk action config via two fields:

Field	When it fires
initialPipeline	When the action first becomes available. Use for pre-populating data before the user opens the action.
completionPipeline	When the user completes the action by clicking Save/Submit.

Multiple components in one pipeline

A pipeline can call multiple endpoints in sequence. All components execute in order, and Workbench waits for each to complete before calling the next:

{
  "components": [
    {
      "name": "validate_risk",
      "componentType": "SEND_AND_RECEIVE_VIA_REST",
      "attributes": { "urlPath": "...validate...", "httpVerb": "POST", "auth": "BASIC" }
    },
    {
      "name": "notify_downstream",
      "componentType": "SEND_AND_RECEIVE_VIA_REST",
      "attributes": { "urlPath": "...notify...", "httpVerb": "POST", "auth": "BASIC" }
    }
  ]
}

Error handling

If a pipeline component fails (non-2xx response), the pipeline stops and the failure is surfaced to the user. The action is not marked as complete. Ensure your client endpoints return appropriate HTTP status codes.

Tips

• Pipeline names must be unique across the client config
• Reference the pipeline name in the action config's initialPipeline or completionPipeline field
• For debugging pipeline calls, check the riskwire-underwriting service logs — pipeline execution and component responses are logged there
• Use the browser Network tab to see what the front end sends to the server when an action is completed