Event processing in OBDX application initiates from the business logic. A developer needs to determine the service class from which alert needs to be triggered. Following steps/instructions can be followed to use event processing mechanism

1. Determine and create an event ID to be used and the group it belongs to. If any existing group cannot be used define a new group.
2. Determine all the parameters that can be used as attributes or actions in the alert’s message content. These parameters will be used in the activity log. Keep in mind the end message content while determining the parameters in the activity log.
3. Find the location in the business logic to generate the event and use the API information provided above.
4. Make all the necessary Day 0 entries in the database tables discussed in the previous section.
5. The event processing in OBDX happens in 2 steps, Generation of event and Processing of that event. In a regular REST based service scenario, developer needs to write the logic to generate the event, however the processing of that event is done by OBDX framework upon successful completion of transaction.
6. This 2-step process is based on queue notification framework which is based on either JMS or KAFKA implementation. Ensure that proper configurations are in place based on the implementation preferences. Queue setup information is given in the following sections.
7. Upon successfully completion of the transaction, event is processed by event framework and notifications are sent to the receiver over the configured and desired channels.
8. Populating Notification Details in the activity log – In general, if a user who has logged in into the application, performed a specific transaction and the same user needs to receive the alert, event framework considers its contact details and dispatches the message correctly. However, it the message needs to be delivered to a receiver who has not logged in, developer needs to populate its contact details in notificationDetails field of the ActivityLog object. If the receiver is an OBDX application user, its user id can be set. In other cases,(or alternately for OBDX users case as well) direct contact details like email id or mobile number can also be set in the notification details.
9. DND settings – Event Processing framework allows DND options for the user to stop receiving few alerts. Developer can decide the event groups that are applicable for DND settings. There are 2 ways to set DND for the receiver.
   1. An admin user can map DND groups to other users using User management transaction
   2. A user can do the DND mapping by itself using preferences transaction
10. Delivery Mode preferences – A receiver may choose its preferred delivery mode using preferences transaction. By default, all the destinations are set as preferred delivery modes. A user must have at least one delivery mode enabled.
11. Language Preference – A receiver may choose preferred language to receive the alerts. If preferred language is not set Bank’s default language will be used to deliver the message. Developer needs to ensure that message templates are properly configured for all the supported languages defined in the implementations. If the language specific template is not available, by default, template in the English language will be taken up for processing and delivered.
12. Events in OBDX are categorized in 2 types
    1. Mandatory Alert – this alert is always sent to the receiver whenever the event occurs
    2. Subscription Alert – this alert is sent to the receiver only if the receiver has subscribed for it. A receiver can subscribe for events using ‘Alert Subscription’ transaction under preferences.
13. Message Template maintenance – as explained above, the message templates for the events can be maintained using Day-0 scripts. However, Administrator user can create or edit these message templates using message Template Maintenance transaction. A template can be deleted as well using this transaction.

(More information on all the above transactions is given in the user manuals.)

Important Tables in Event Processing

1. DIGX_EM_ALERT_DISPATCH_LOG – Provide the final status of the alert
2. DIGX_EM_ALERT_STATE_LOG – Provides the in-detail logging of the alert processed and the various states it passed through
3. DIGX_EM_SUBSCRIPTION – Lists all the users who have subscribed for the event
4. DIGX_EM_SUBSCRIBED_EVENTS – contains the mapping of receivers and the events they have subscribed to
5. DIGX_EM_DND_PREF – Contains the mappings of receiver and the event groups that the respective user has marked for DND.
6. DIGX_EM_PREFERRED_DESTINATION_PREF – provides the listing of destination preferences maintained by the users

Event Processing Dispatchers

OBDX application uses dispatcher classes to provide business logic for sending the notifications to the receiver on desired destination or channel. Each destination must have a dispatcher class associated with it. The application provides a default dispatcher for all five pre-defined destination. An implementor may use custom dispatcher classes for these destinations.

Default Email dispatcher class uses standard JAVA mail APIS to send emails using SMTP server. SMTP configurations need to be maintained in the configuration related tables. Also, SMTP configurations maintenance and testing can be done using ‘System Configurations’ transaction. Details on this transaction are given in the OBDX core user manual.

Default SMS dispatcher is not pre-integrated with any SMS provider. An implementor is advised to use a custom SMS dispatcher as per the requirements.

Custom dispatcher class must extend following class and implement the necessary methods - ‘com.ofss.digx.app.em.alert.service.process.dispatch.dispatcher.AbstractDispatcher’. A custom message class can also be used to use specific recipient details. This message class must implement ‘com.ofss.digx.app.em.alert.service.process.message.IMessage’.