14. Notifications to 3rd party systems¶
Trak.e considers a series of events when certain resources are created, modified and deleted:
Resource | Create | Update | Delete |
---|---|---|---|
Profile | x | x | x |
Document | x | x | x |
Alerts | x | x | x |
Transaction | x | x | x |
Trake can be configured so that an endpoint is invoked for each of these events (either the same endpoint or a specific one for each).
Trake handles a retry scheme with exponential backoff and penalizes those endpoints with high response times or high failure rates. Notifications start in the low latency queue and are downgraded to the high latency queue.
- Low latency and high priority: it has a 2s timeout when invoking the endpoint and 2 retries. The goal is to quickly notify the customer of new events.
- Medium latency and medium priority: it has a timeout of 10s when invoking the endpoint and 8 retries.
- High latency and low priority: it has a timeout of 30s when invoking the endpoint and 16 retries. For those customers who do not have the capacity to quickly process trak.e events.
This scheme allows us to quickly notify events to those clients with processing capacity and not penalize them with clients that have problems in their endpoints while avoiding the loss of notifications due to the sporadic malfunction of a client endpoint. When all the retries are exhausted, the notifications are dumped to a deadletter queue and downloaded to a temporary base that can be consumed via the notifications API for that purpose.
graph TD
high_priority -- error + retry --> high_priority
high_priority -- error + 2 retries exhausted --> medium_priority
medium_priority -- error + retry --> medium_priority
medium_priority -- error + 8 retries exhausted --> low_priority
low_priority -- error + retry --> low_priority
low_priority -- error + 16 retries exhausted --> deadletter
The notification service handles different types of security:
- No Auth: intended for testing and integration.
- Basic Auth: allows you to configure
user
andpassword
that will be sent in each invocation. - Oauth 2 Client Credentials Flow: Allows you to configure
client_id
,client_secret
and the requiredscope
. The claims service takes care of the oauth2 flow and getting and using the token. - Api Key: allows you to configure the key for access to the api. The key will be sent in the default
X-Api-Key
header.
14.1 Resources¶
Resource |
---|
notification_error |
notification_config |