Notification templates plugin setup
The Notifications plugin is available as a docker image, and it has the following dependencies:
- a MongoDB database
- needs to be able to connect to the Kafka instance used by the engine
- a Redis instance for caching notification templates
- in case you need to also attach documents to the sent notifications, the plugin will need to be able to access your chosen storage solution. It can use an S3 compatible file storage solution (we have successfully used Min.io)
The plugin comes with most of the needed configuration properties filled in, but there are a few that need to be set up using some custom environment variables.
Basic mongo configuration - helm values.yaml
The plugin can use the Redis component already deployed for the engine.
You need to have an S3 compatible file storage solution deployed in your setup.
The following variables need to be set in order to connect to the identity management platform:
The only thing that needs to be configured is the DB access info, the rest will be handled by the plugin.
SPRING_DATA_MONGODB_URI - the URI for the MongoDB database
The following values should be set with the corresponding Redis related values.
The following Kafka related configurations can be set by using environment variables:
SPRING_KAFKA_BOOTSTRAP_SERVERS - address of the Kafka server
SPRING_KAFKA_CONSUMER_GROUP_ID - group of consumers
KAFKA_CONSUMER_THREADS - the number of Kafka consumer threads
KAFKA_AUTH_EXCEPTION_RETRY_INTERVAL - the interval between retries after
AuthorizationException is thrown by
KAFKA_MESSAGE_MAX_BYTES - this is the largest size of the message that can be received by the broker from a producer.
Each action available in the service corresponds to a Kafka event. A separate Kafka topic must be configured for each use-case.
Forwarding notifications to an external system
KAFKA_TOPIC_NOTIFICATION_EXTERNAL_OUT - the notification will be forwarded on this topic to be handled by an external system
Sending a notification
KAFKA_TOPIC_NOTIFICATION_INTERNAL_IN - topic used to trigger the request to send a notification
KAFKA_TOPIC_NOTIFICATION_INTERNAL_OUT - topic used for sending replies after sending the notification
Generating/validating an OTP
KAFKA_TOPIC_OTP_GENERATE_OUT - after the OTP was generated and send to the user, this is the topic used to send the response back to the Engine.
KAFKA_TOPIC_OTP_VALIDATE_IN - Event send on this topic with an OTP and an identifier will check if the OTP is valid
KAFKA_TOPIC_OTP_VALIDATE_OUT - Response to the request to validate an OTP will be sent back to the Engine on this topic
The Engine is listening for messages on topics with names of a certain pattern, make sure to use correct outgoing topic names when configuring the notifications plugin.
File storage configuration
Based on use case you can use directly a file system or an S3 compatible cloud storage solution (for example min.io).
The file storage solution can be configured using the following environment variables:
If you want to use a custom SMTP server:
SIMPLEJAVAMAIL_SMTP_HOST - used by mail servers to send, receive, and/or relay outgoing mail between email senders and receivers
SIMPLEJAVAMAIL_SMTP_PORT - refers to the specific part of the Internet address that’s used to transfer email
SIMPLEJAVAEMAIL_TRANSPORTSTRATEGY - sets the method on how the notifications are delivered, for example
EXTERNAL_FORWARD for forwarding to external adapters
The email and name to be used as sender for emails sent by the plugin:
Email attachments configuration
The maximum file size for files to be attached as email attachments can also be configured:
The desired character size and expiration time of the generated one-time-passwords can also be configured.
FLOWX_OTP_LENGTH - the number of characters allowed for OTP
FLOWX_OTP_EXPIRE_TIME_IN_SECONDS - expiry time (seconds)
The following environment variables could be set in order to control log levels:
LOGGING_LEVEL_ROOT - root spring boot microservice logs
LOGGING_LEVEL_APP - app level logs
LOGGING_LEVEL_MONGO_DRIVER - MongoDB driver logs
LOGGING_LEVEL_THYMELEAF - Thymeleaf logs, logs related to using notifications templates
KAFKA_CONSUMER_ERROR_HANDLING_ENABLED- default value:
FALSE→ allows control on Kafka consumer applications to handle errors and failures during message consumption - When this variable is set to
true, it enables the consumer application to handle any errors that occur during message consumption
KAFKA_CONSUMER_ERROR_HANDLING_RETRIES- default value:
KAFKA_CONSUMER_ERROR_HANDLING_ENABLED is set to
true, this environment variable specifies the maximum number of retries that the consumer application should attempt before giving up on processing a message; for example, if
KAFKA_CONSUMER_ERROR_HANDLING_RETRIES is set to
5, the consumer application will attempt to process a message up to 5 times before giving up
KAFKA_CONSUMER_ERROR_HANDLING_RETRY_INTERVAL- default value:
KAFKA_CONSUMER_ERROR_HANDLING_ENABLED is set to true and retries are enabled with
KAFKA_CONSUMER_ERROR_HANDLING_RETRIES, this environment variable specifies the amount of time that the consumer application should wait before attempting to retry processing a message
For example, if KAFKA_CONSUMER_ERROR_HANDLING_RETRY_INTERVAL is set to 5 seconds, the consumer application will wait 5 seconds before attempting to retry processing a failed message. This interval is applied to all retry attempts, so if KAFKA_CONSUMER_ERROR_HANDLING_RETRIES is set to 5 and the retry interval is 5 seconds, the consumer application will make up to 5 attempts, waiting 5 seconds between each attempt.