Providers

Introduction

Providers are a core architectural component in the Harmoney application that enable integration with external or internal services and systems. They act as abstraction layers between the Harmoney platform and various third-party/in-house services, allowing for seamless interaction with different technologies and protocols while maintaining a consistent interface. 

Provider Architecture

What is a Provider?

A provider in Harmoney is a pluggable component that implements a specific interface to interact with an external service. Providers follow a standardized pattern:

• Consistent Configuration: All providers share a common configuration structure
• Pluggable Implementation: Each provider implements specific functionality while adhering to common patterns
• Service Abstraction: Providers abstract away the complexities of external service integration

Provider Components

Each provider typically consists of:

1. Provider Definition: Configuration in the database that defines how to connect to the external service
2. Provider Implementation: The code that implements the provider interface
3. Provider Settings: Additional configuration parameters specific to each provider type

Provider Types

Harmoney includes several types of providers:

Provider Type	Description
Monitoring Providers	Keep a list of parties under surveillance at an external provider, to be notified when their data changes
Dashboard Providers	Embed external dashboards
Document Assessment Providers	Validate the format and content of documents
Document Providers	Visualize and fetch documents from external systems
Due Diligence Providers	Connect to external compliance and due diligence services
Email Providers	Handle email communication through various email service providers
Field Definition Providers	Configure field visibility, conditional behavior and custom fields in the Harmoney platform. Typically on-demand implementation.
Field Value Providers	Used to automatically generate field values such as a dossier number.
FTP Providers	Used to pull/push data from/towards an external sFTP server.
Identity Providers	Fetch and verify personal identity data using e-id, biometrics, etc.
Party Providers	Pull party information from external systems
PDF Provider	Generates PDF documents for various purposes like reports, agreements, and summaries
Scheduled Providers	Various internal providers that can be used for automation purposes, such as periodic rescreening, periodic outreach, data retention, etc.
SMS Providers	Facilitate SMS communications for verification and notifications
SSO Providers	Single Sign-On providers that handle authentication with external identity systems (OAuth2, SAML, etc.)
Storage Provider	Manages file storage operations, abstracting different storage backends

Provider Configuration

Base Configuration

All providers share a common base configuration:

Field	Description
Identifier	Unique identifier for the provider instance
Client ID	ID used to authenticate with the external service (when applicable)
Client Secret	Secret or password used to authenticate with the external service (when applicable)
Resource URI	Base URL for the external service API
Authorize URI	URL for authorization (typically for OAuth flows)
Token URI	URL for token acquisition (typically for OAuth flows)
Redirect Path	Path for redirect callbacks (typically for OAuth flows)
Implementation Class	Java class that implements the provider functionality
State	Status of the provider (ACTIVE, MOCKED, INACTIVE)

Provider Settings

Each provider type has its own specific settings that extend the base configuration. These settings are stored as JSON and provide additional configuration options relevant to that provider type.

Provider States

Providers can be in different states:

• ACTIVE: The provider is fully operational and will connect to the actual external service
• MOCKED: The provider is active but will return mock data instead of connecting to the external service
• INACTIVE: The provider is disabled and will not be used

The mocked state is particularly useful for testing and development environments where the actual external service may not be available or when using real services would incur costs. 

Mock Providers

If the provider state is MOCKED, it is possible to use provider setting MOCKED_RESPONSE to define the response for the provider. Sometimes multiple calls are executed and MOCKED_RESPONSE_2 is also used.

By clicking Set default mock, a mocked response will be prefilled. Depending on the type of external call, this will usually be in JSON format. In the implementation we only try to mock the external call and still use the same code for mapping the response to the desired objects. This way, it should be possible to test how a response is ‘handled’ by the provider.

Example

{
"MOCK": {
  "MOCKED_RESPONSE": "..."
  }
}