Interfaces
The Harmoney platform can be extended with custom code. This code is written in Java and can be used to implement custom business logic, such as custom automations, custom integrations, etc.
The following interfaces are available to implement custom code:
| Interface | Notes |
|---|---|
| Provider | See providers for more details. |
| Action | Used for automation purposes. Actions can be executed when certain events are thrown or when a dossier changes status. |
| Validation | Used for at various points in the application, such as before dossier status changes or during an information request. |
| DynamicDocumentConfiguration | Used in document flow steps to make certain cards required, optional, read-only, etc. |
| ConditionalSectionClass | Used in a questionnaire section steps to conditionally show/hide the section. |
| DynamicDueDiligenceMetadataSupplier | Used during due diligence check to provide additional data towards due diligence providers. |
| DynamicRbaParameterSupplier | Extension point for the RBA module: used to indicate the relevant due diligence subjects (dossier and/or certain associated parties) and their corresponding set of parameters that are used for the RBA calculation. |
| DynamicRbaParameterConfiguration | Used during the RBA calculation if the score calculation of a parameter is not static. For example if the score depends on the dossier type. |
| DynamicSensitivitySupplier | Used during the RBA calculation to calculate the sensitivity of a dossier, so it can be taken into account during the score calculation. |
| RbaConfiguration (legacy) | Allows for even more customization of the RBA calculation rules if the other interfaces are not sufficient. Superseded by the more specific DynamicRba* and DynamicSensitivitySupplier interfaces above, so avoid it for new configurations. |
| DossierSummaryConfiguration | Allows defining a custom summary page that can be used on the dossier page and/or in an information request. |
| Profiler | Allows defining a custom profile calculation in an information request. E.g. for MiFiD or sustainability profiling. |
Avoiding custom code​
The platform provides a wide range of built-in implementations for the above interfaces. Most can be further configured via settings. In most cases, it is possible to achieve the desired functionality without requesting custom code. It is recommended to check existing implementations and settings to see if they can be used to achieve the desired functionality.
While it is technically possible (but will be further restricted in the future), it is not allowed to use custom code that was explicitly written for organization A in organization B. When similar custom code is necessary for multiple organizations, request a more generic implementation that can be used by all organizations.
Activation of custom code​
Custom code is never executed without configuration changes. It must be activated by referencing the implementation
class in the related configuration. For example, a specific DynamicRbaParameterSupplier is only executed when it is
configured in the RBA module settings.
The available custom classes are exposed in the admin UI via an autocomplete input or as options in the JSON editor.
Backward compatibility​
See Backward Compatibility Policy for more details.
Retention policy​
To keep the amount of custom code manageable, a semi-automated deprecation policy is in place.
When custom code is no longer needed, let us know!