Dynamic Processing Settings - Changes & Fixes

This page covers changes and fixes to Dynamic Processing Settings provided in IPF Release 2025.3.0

New

Processing Entity Support for DPS Operations

DPS now supports processing entity isolation through an optional processingEntity parameter across all DPS operations. This enables multi-tenant scenarios where settings belonging to different processing entities should be isolated from each other.

GET Operations with Processing Entity Support

  • GET /settings-objects/{settingType}/{settingId} - Added optional processingEntity query parameter

  • GET /settings-objects/{settingType}/history/{settingId} - Added optional processingEntity query parameter

  • GET /settings-objects/approvals/{settingType} - Added optional processingEntity query parameter

  • GET /settings-objects/approvals/{settingType}/{settingId} - Added optional processingEntity query parameter

  • GET /settings-objects/scheduled-settings/{settingType}/{settingId} - Added optional processingEntity query parameter

  • GET /settings-objects/{settingType} - Added optional processingEntity query parameter for search operations

  • GET /settings-objects/{settingType}/getIds - Added optional processingEntity query parameter for ID search operations

  • GET /settings-objects/scheduled-settings/{settingType} - Added optional processingEntity query parameter for scheduled settings search

When processingEntity is provided: * Settings are only returned if they belong to the specified processing entity or have processing entity "UNKNOWN" * Returns 404 (Not Found) if the setting exists but belongs to a different processing entity * Preserves existing behavior when parameter is not provided

POST Operations with Processing Entity Support

All POST operations now support an optional processingEntity parameter in the request body:

  • POST /settings-objects/{settingType} - Create setting with optional processingEntity parameter in request body

  • POST /settings-objects/approvals/{settingType}/{settingId}/approve - Approve setting with processing entity validation

  • POST /settings-objects/approvals/{settingType}/{settingId}/reject - Reject setting with processing entity validation

  • POST /settings-objects/{settingType}/getBatch - Get batch settings with optional processingEntity parameter in request body

When processingEntity is provided: * Operations are only allowed if the request processing entity matches the setting’s processing entity * Returns 400 (Bad Request) with descriptive error message if processing entities don’t match * Preserves existing behavior when parameter is not provided

PUT Operations with Processing Entity Support

All update operations now support an optional processingEntity parameter in the request body:

  • PUT /settings-objects/{settingType}/{settingId} - Update setting with optional processingEntity parameter in request body

  • PUT /settings-objects/scheduled-settings/{settingType}/{settingId} - Update scheduled setting with optional processingEntity parameter in request body

When processingEntity is provided: * Update operations are only allowed if the request processing entity matches the setting’s processing entity * Returns 400 (Bad Request) with descriptive error message if processing entities don’t match * Preserves existing behavior when parameter is not provided

DELETE Operations with Processing Entity Support

All delete operations now support an optional processingEntity parameter:

  • DELETE /settings-objects/{settingType}/{settingId} - Delete setting with processing entity validation

  • DELETE /settings-objects/scheduled-settings/{settingType}/{settingId} - Delete scheduled setting with processing entity validation

When processingEntity is provided: * Delete operations are only allowed if the processing entity matches the setting’s processing entity * Returns appropriate error response if processing entities don’t match * Preserves existing behavior when parameter is not provided

Usage Examples

Query setting with processing entity filtering:

GET /settings-objects/participant/12345?processingEntity=BankA
GET /settings-objects/participant/history/12345?processingEntity=BankA
GET /settings-objects/approvals/participant?processingEntity=BankA
GET /settings-objects/participant?processingEntity=BankA

Approve setting with processing entity validation:

POST /settings-objects/approvals/participant/12345/approve
{
  "approvedBy": "operator1",
  "processingEntity": "BankA"
}

Delete setting with processing entity validation:

DELETE /settings-objects/participant/12345?processingEntity=BankA

Create setting with processing entity:

POST /settings-objects/participant
{
  "source": "manual",
  "createdBy": "operator1",
  "requiresApproval": false,
  "processingEntity": "BankA",
  "payload": {
    "agentId": "TIPS",
    "countryCode": "GB"
  }
}

Update setting with processing entity:

PUT /settings-objects/participant/12345
{
  "source": "manual",
  "createdBy": "operator1",
  "requiresApproval": false,
  "processingEntity": "BankA",
  "payload": {
    "agentId": "SWIFT",
    "countryCode": "FR"
  }
}

Get batch settings with processing entity filtering:

POST /settings-objects/participant/getBatch
{
  "idList": ["12345", "67890"],
  "processingEntity": "BankA"
}

Indexes for Approvals and History

Default indexes for settings-approvals collection are created.

ipf.dps.mongodb.index-config.approvals {
  index-1 = ["processingEntity:ASC"]
  index-2 = ["entityId:ASC"]
  index-3 = ["entityCollection:ASC"]
  index-4 = ["lastUpdatedAt:ASC"]
}

Default indexes for settings-history collection are created.

ipf.dps.mongodb.index-config.history {
  index-1 = ["processingEntity:ASC"]
  index-2 = ["entityId:ASC"]
}

Indexes for these collections are configurable with the properties described above.