Clearmatch integration - partner process
1.
Introduction
The purpose of this document, is to provide a high-level walk-through of different components involved in a Finance Company's integration with Clearmatch API focusing on the following:
- Partner Process Manager
- Notification Processor
- Notification Generator
- Database
- Extensions
1.1 Area of Interest
1.2 Prospects
2.
Component Overview
The following diagram is a high-level view of the technical implementation:
1. Clearmatch fires notification to Process Manager (notification controller).
2. Process manager stores notification in DB.
3. Process manager acknowledges notification to Clearmatch.
4. Notification Generator checks for new notifications that were not processed.
5. Notification Generator calls Clearmatch API to retrieve application data.
6. Notification Generator stores application data against notification and hands over the notification to Notification processor.
7. Notification processor works out the Finance Company logic to determine who is interested in the notification.
8. Notification processor sends notification to all identified subsystems.
2.1 Partner
Process Manager (aka Controller
Service)
This is a web API application which will now
receive the notifications from Clearmatch instead of Smartfund BOTS. Its sole
purpose is to receive the notification and save it into the database (table ClearmatchNotificationQueue).
2.2 Notification
Generator
A single notification from Clearmatch
could possibly be passed onto multiple extensions, for example BOTS, Google
Analytics, SiteCatalyst, etc. Also, each extension might potentially be
interested in only a subset of events.
This service processes notifications
from ClearmatchNotificationQueue table and workout the logic to determine which
extension have subscribed to this event and populates a queue accordingly
(table InternalNotificationQueue). The rule that governs this internal
notification is defined in table NotificationClientSubscription. The clients
are defined as NotificationClient.
In addition to that, the Notification Generator
pre-fetches Clearmatch API (e.g. Application) data and stores it in table InternalNotificationQueue
(column ResourcePayload).
This windows service is a multi threaded
resilient service. The number of active threads, number of retries on failure, and the interval between the retries are configurable in the application config
file.
Details on how it works is outlined below:
1) Grabs the ClearmatchNotificationQueue item.
2) Gets the resource from the Public API (e.g. Application).
3) Gets the clients that needs to be notified – only active clients are grabbed from NotificationClient (IsActive=1) and the client must be subscribed to receive the notification event. These rules are defined in NotificationClientSubscription e.g. BOTS will only receive a notification when event type is "ApplicationStatusChange” and event status is “Approved”.
4) Saves a record for each client in InternalNotificationQueue.
5) Moves ClearmachNotificationQueue to ClearmatchNotificationQueueHstory.
2.3 Notification
Processor
This
service is responsible to deliver notifications from InternalNotificationQueue
to respective extensions.
This
windows service is a multithreaded resilient service. The number of active
threads, number of retries on failure, and the interval between the retries are also configurable in the application config file.
Details on how it works is outlined below:
1) Grabs the InternalNotificationQueue item.
2) Grabs the client setting (endpoint, authentication details) from Notification.
3) Sends the notification to the client.
4) Moves InternalNotificationQueue to InternalNotificationQueueHistory.
2.4 Google
Analytics
Resource
(Application) information is sent to Google Analytics using Google Measurement
Protocol specifications. The implementation can be found in the Partner.Api.Analytics
project. The additional information is sent using custom dimensions and metrics.
These dimensions and metrics mappings are defined in table AnalyticsVariableMapping.
2.5 SiteCatalyst
Resource
(Application) information is sent to Adobe SiteCatalyst using their Data
Insertion API. The implementation can be found in the Partner.Api.Analytics
project. The additional information is sent using eVars and events. These eVars
and event mappings are defined in table AnalyticsVariableMapping.
2.6 BOTS
(maintained by Clearmatch)
BOTS
(SmartFund) works in conjunction with Clearmatch API. The notifications BOTS is
interested in need to be passed through by Notification processor. If
notifications are not passed through, BOTS would not know when to run the auto bid
process.
Related Articles
Clearmatch integration - overview
1. Introduction The Clearmatch platform consists of the following external facing application components: 1. Single Sign On – The single sign on service is a central service where registered users are authenticated. Additionally, the service can ...Clearmatch integration - notification
1. Introduction The purpose of this document is to provide a high-level explanation on how Clearmatch Notifications are used by a partner. A Clearmatch platform can be setup to send notifications when a certain “event” happens. For ...Partner notification queue
Partner notifications are notifications that are sent to an external "controlling service" that contains all the business logic that will in turn send notifications on to one or many other "services" . These services can be used to perform a number ...Clearmatch integration - API
1. Introduction The purpose of this document is to provide a high-level explanation on how the Clearmatch Public API is used by a partner. Clearmatch provides a REST based API to retrieve information from the platform. Some highlights include: The ...Clearmatch Fusion sign-in
ClearMatch is for the most part written in Microsoft .Net so is therefore optimised to work with the latest version of the Microsoft browser and only up to two versions backwards. For example if the latest version of IE was 11.0, then Clearmatch ...