Documentation for a newer release is available. View Latest

Core - Changes & Fixes

This page covers core changes and fixes provided in release IPF-2025.2.0.

MongoDB

Changed

This release adds support for MongoDB Client-Side Field Level Encryption (CSFLE). For more details see Mongo DB Starter.

Connector

Changed

  • The transport’s exception type has changed from IllegalStateException to NoAvailableTransportException which extends IllegalStateException.

  • Messages only try each transport once before failing. Previously it would try every transport until all the circuit breakers open.

Fixed

  • The RequestReplySendConnector now throws an exception, instead of returning the response to the caller, when response bean validation is enabled and the validation check(s) specified by the provided response bean validator fail(s).

  • DeadLetterAppender interface stage return type changed from CompletableFuture<Void> to CompletionStage<Void>

Payment Entries Processor (renamed from Payment Releaser)

Payment Releaser has become a generic Payment Entries Processor, able to do more than just releasing payment entries for the execution. Other than resilient releasing of instructions and individual transactions for the execution which was already supported, it is now possible to cancel all transactions of an instruction scheduled for the execution.

Added

  • New module: payment-scheduler-adaptor-kafka. Adaptor for the scheduler-received-connector-kafka. Enables the consumption of Kafka messages published by the Persistent Scheduler applications that use the scheduler-external-trigger-kafka module. The consumption of this message triggers the prepareInstruction or processTransaction (renamed from releaseTransaction) methods of the PaymentEntriesProcessor(renamed from PaymentReleaser), with overridable default configuration. Details can be found at How to trigger the Releaser from Persistent Scheduler via Kafka

  • Actual applying of RELEASE and/or CANCEL processing actions to Payment Entries is done via ProcessingStrategy interface implementations. To make the Payment Entries Processor able to process an Action (RELEASE, CANCEL or any custom one), you have to provide a bean implementing the ProcessingStrategy interface. You should also provide implementations of ProcessingRequestCreator and RequestProcessor interfaces, and use them in your ProcessingStrategy implementation.

Changed

Multiple changes in the process of making Payment Releaser generic:

  • ipf.core.payment-releaser config root path changed to ipf.core.payment-entry-processor

  • releaseExecutionInfos database collection renamed to executionInfos

  • Interfaces and classes renamed:

    • PaymentReleaser interface renamed to PaymentEntriesProcessor

    • AkkaPaymentReleaser class renamed to AkkaPaymentEntriesProcessor

    • ReleaserExecutor class renamed to InstructionExecutorActor

    • PaymentRequestCreator interface renamed to ProcessingRequestCreator

    • PaymentRequestSender interface renamed to RequestProcessor

    • ReleaserStore interface renamed to ExecutionInfoStore

    • MongoReleaserStore class renamed to MongoExecutionInfoStore

Ability to pass in additional information for the downstream execution service. Includes the following breaking changes:

  • PaymentEntriesProcessor (renamed from PaymentReleaser) interface method signatures updated:

    • the processInstruction (renamed from releaseInstruction) and processTransaction (renamed from releaseTransaction) method has an additional argument of SupportingContext to accept supporting data for the execution of the payment

  • OpenAPI specification updated, generating updated Java interfaces and therefore affecting the PaymentReleaserController method signatures

    • the prepareReleaseInstruction method no longer takes Mono<SupportingBusinessDataMapForPrepareOperation> as an argument

    • the processInstruction (renamed from releaseInstruction) method no longer takes Mono<SupportingBusinessDataMapForReleaseOperation> as an argument

    • the processInstruction (renamed from releaseInstruction) method takes Mono<SupportingContext> as a method argument

    • the processTransaction (renamed from releaseTransaction) method takes Mono<SupportingContext> as a method argument

  • OpenAPI specification updated, requiring updates to the ClientPort interfaces to accommodate:

    • the PrepareInstructionClientPort interface methods no longer take SupportingBusinessDataMapForPrepareOperation as an argument

    • the ReleaseInstructionClientPort interface methods no longer take the SupportingBusinessDataMapForReleaseOperation as an argument

    • the ReleaseInstructionClientPort interface methods can take SupportingContext as an argument

    • the ReleaseTransactionClientPort interface methods can take SupportingContext as an argument

  • OpenAPI specification changes mean ProcessingContext is no longer required in the request body for:

    • POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/prepare-release

    • POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/release

  • ProcessingRequestCreator (renamed from PaymentRequestCreator) takes in SupportingContext, enabling the constructed Payment Request to incorporate supporting data before being passed on to the execution service

    • Change to method signature getPaymentInitiation() in PaymentDataSource; now it returns Mono<Optional<INIT>>

    • initationAggregatorFunction, supplied to BasePaymentWarehouseDataSource is now an optional bean, since not all users will be required to supply an initiation function.

IPF Persistent Scheduler

Added

  • New module: scheduler-external-trigger-kafka. Enables an ExternalTriggerCommand (implementation of SchedulingCommand) to be sent out over a Kafka SendConnector to be processed up by another service at the scheduled date-time.

  • New module: scheduler-received-connector-kafka. Enables the receiving of ExternalTriggerCommand 's via kafka. This module is to be brought in as a dependency in receiving systems.

  • Scheduler Floclient support for sending/receiving executed scheduled-releases through means of a specific ExternalSchedulingHelper that triggers the domain and provides a 'completion' input command when the ExternalSchedulingCommand is executed.

Changed

  • Breaking: the SchedulerConnectorInterface (from the scheduler-client-connector-http maven artefact) uses HTTP API models as method arguments, as opposed to 'core' models.

  • Breaking: HTTP API takes the ExternalTriggerCommand object in the nested payload for scheduling new jobs

  • Scheduler Floclient: renamed PaymentAsyncScheduleCompletedCommand to SchedulePaymentReleaseCommand

Human Task Manager

Changed

Previously, the Task Manager flow emitted an additional domain event, Registered, in response to the Flow Initiated domain event. There are no changes to the flow’s states or execution path. The only modification is that the Registered domain event has been removed, and the Flow Initiated domain event has been renamed to Registered. As a result, newly created tasks will no longer have the Flow Initiated domain event stored in the database.

This change does not affect application functionality, as an appropriate event adapter has been provided. If any consumers were relying on the Flow Initiated domain event, they can safely use the Registered domain event instead, as it contains the same business data.

Serialization

Changed

Fixes a bug where IPF Serialization would lose trailing zeroes from decimals when deserializing into a JsonNode instance, e.g. the decimal in {"number": 123.450} would become 123.45, and the decimal in {"number": 123.000} would become 123.

Test Framework

Changed

The test framework now runs exclusively on JUnit 5 (Jupiter). You may face compilation failures if using JUnit-4-specific annotations or assertion classes. See migration for more specific migration steps.