• 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.

​
Dependencies

​
Mongo database

Basic mongo configuration - helm values.yaml 
notification-mdb:
    existingSecret: {{secretName}}
    mongodbDatabase: {{NotificationDatabaseName}}
    mongodbUsername: {{NotificationDatabaseUser}}
    persistence:
      enabled: true
      mountPath: /bitnami/mongodb
      size: 4Gi
    replicaSet:
      enabled: true
      name: rs0
      pdb:
        enabled: true
        minAvailable:
          arbiter: 1
          secondary: 1
      replicas:
        arbiter: 1
        secondary: 1
      useHostnames: true
    serviceAccount:
      create: false
    usePassword: true

​
Redis server

The plugin can use the Redis component already deployed for the engine.

​
Document storage

You need to have an S3 compatible file storage solution deployed in your setup.

​
Configuration

​
Authorization configuration

The following variables need to be set in order to connect to the identity management platform:
  • SECURITY_OAUTH2_BASE_SERVER_URL
  • SECURITY_OAUTH2_CLIENT_CLIENT_ID
  • SECURITY_OAUTH2_CLIENT_CLIENT_SECRET
  • SECURITY_OAUTH2_REALM

​
MongoDB configuration

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

​
Redis configuration

The following values should be set with the corresponding Redis related values.
  • SPRING_REDIS_HOST
  • SPRING_REDIS_PASSWORD
  • REDIS_TTL

​
Kafka configuration

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 KafkaConsumer
  • 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_IN
  • 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:
  • APPLICATION_FILE_STORAGE_S3_SERVER_URL
  • APPLICATION_FILE_STORAGE_S3_ACCESS_KEY
  • APPLICATION_FILE_STORAGE_S3_SECRET_KEY
  • APPLICATION_FILE_STORAGE_S3_BUCKET_PREFIX

​
SMTP Setup

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
  • SIMPLEJAVAMAIL_SMTP_USERNAME
  • SIMPLEJAVAMAIL_SMTP_PASSWORD
  • 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:
  • APPLICATION_MAIL_FROM_EMAIL
  • APPLICATION_MAIL_FROM_NAME

​
Email attachments configuration

The maximum file size for files to be attached as email attachments can also be configured:
  • SPRING_HTTP_MULTIPART_MAX_FILE_SIZE
  • SPRING_HTTP_MULTIPART_MAX_REQUEST_SIZE

​
OTP Configuration

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)

​
Logging

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

​
Error handling

  • 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: 0→ when 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: 1000→ when 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.