Implementation

The Flow

There is an events table in Maintenance schema with all the events that we will publish listed on it with some more properties. There is an IsEnabled column for all the events listed. Only for all those events where the IsEnabled field is set to true will publish to kafka.

oblm-services that wants to publish to kafka will fetch the events table in maintenance schema using the eventcode and check for the isEnabled field. If the isEnabled is ‘Y’ it will store the data in an eventlog table in LMX schema.

We have a cron job that will be triggered in configured time interval which will fetch the value from the integration schema and chck for the unpublished message. Those message that are not published and havenot errored out will be published to kafka.

Maintenance Service Functionality

The oblm-maintenance-services has the following events configured.

bank-pref
branch-pref
pricing-map

The oblm-maintenance-services will check the value of the isEnabled column for the above event_code, if ‘Y’ the event will be logged in the lmx schema in lmx_tb_event_log along with the event_code and event_topic.

The LMM_TM_EVENTS table in the maintenance schema has the following columns

ID
EVT_CODE
EVT_CATEGORY
EVT_DESC
EVT_TOPIC
EVT_ISENABLED
MAKER_ID
MAKER_DT_STAMP
CHECKER_ID
CHECKER_DT_STAMP
RECORD_STAT
AUTH_STAT
ONCE_AUTH
MOD_NO

Here the event_code will be predefined by the developers and this event_code will be used to map an event from service to the even_topic in which kafka will be publishing.

Depending on the requirement the consumer can alter the value of the isEnabled field to ‘Y’ if events need to be published for that event.

Events will have been pre-added into the database before the deployment.

Sweep Service Functionality

The oblm-sweep-services has the following events configured.

sweep-success (S)
sweep-error (E)
sweep-pending (P)
sweep-handOff (H)

The oblm-sweep-services will call the oblm-maintenance-services and for the above event_code it will check the value of the isEnabled column, if ‘Y’ the event will be logged in the lmx schema in lmx_tb_event_log along with the event_code and event_topic.

Structure Service Functionality

The oblm-structure-services has the following events configured.

structure-created
structure-createdAndAuthorized
structure-modified
structure-modifiedAndAuthorized
structure-closed
structure-closedAndAuthorized
structure-reopen
structure-reopenAndAuthorized
structure-expiry (structure expiring in n number of days where n is configurable)
structure-charge

The oblm-structure-service will call the oblm-maintenance-service and for the above event_code it will check the value of the isEnabled column, if ‘Y’ the event will be logged in the lmx schema in lmx_tb_event_log along with the event_code and event_topic.

The structure-expiry event is a scheduler. It will be triggered once a day. The scheduler is a cron job, the time is configurable, and it should be cron expression.

Cron expression example: ‘0 40 20 * * ?’ will trigger the service endpoint at 8.40pm every day.

Integration Service Functionality

The events that need to be published from the oblm-services will be stored in the lmx_tb_events_log.

The oblm-integration-service has a scheduler that will be triggered in configured interval. The scheduler is a cron job, the time interval is configurable.

The lmx_tb_events_log have columns event is a scheduler. It will be triggered once a day. The scheduler is a cron job, the time is configurable, and it should be cron expression.

Some important columns of lmx_tb_events which is generic for all the oblm-services that wants to publish to kafka.

ID
EVT_CODE
EVT_ TOPIC
LOG_TYPE
LOG_DESCRIPTION
LOG_TIME
SERVICE_DATA
PUBLISHED_TIME
IS_PUBLISHED
RETRY_COUNT
EVT_KEY

EVT_ TOPIC is the topic name on which the event will be published

EVT_ CODE is unique for each event and it helps to map the events from each service to an event_topic. The evt_code is developer specified.

LOG_TYPE is the name of the service which has logged this event in the lmx schema

LOG_DESCRIPTION is the brief description of that particular event.

SERVICE_DATA is the service specific data that will be logged from oblm-services as string

LOG_TIME is the time at which the events from an oblm-service is logged in the lmx schema, or else we can say it is the time at which an event occurred (Example: structure created )

PUBLISHED_TIME is the time at which an event will be published to kafka from oblm-integration-service.

RETRY_COUNT is the number of times an event entry in the lmx_tb_event_log will be retried to send the event for the retryCount(this is configurable will be fetched from properties table, so value of RETRY_COUNT<= retryCount  publish) number of times, and if it fails for retryCount number of times it will be marked as an error and will not be processed further.

EVT_KEY is the service specific id. If the event is from oblm-sweep-service, it will be storing the sweepId.

IS_PUBLISHED is the column which will store value such a ‘Y’ if the event is published, ‘N’ if the event is not published, ‘E’ if the event couldn’t be published for retryCount number of times. Default value of this field will be ‘N’, which will be updated for the above-mentioned scenarios.

Cron expression example: ‘0 0/10 * * * ?’ will trigger the the service endpoint on every 10 mins