User Events Services
Technical Configuration Doc
Was this helpful?
Technical Configuration Doc
Was this helpful?
eGov-User-Events service provide a common point to manage all the events generated for the users in the system. Events include updates from multiple applications like PT, PGR, TL; events created by the employee addressing the citizen etc. This service provides the users with APIs to create , update and search the events.
Before you proceed make sure the following pre-requisites are met -
Java 8
Kafka server is up and running
egov-persister service is running and has egov-user-events persister config path added in it
PSQL server is running and database is created
Provide a common platform to create, manage and notify events
Events can be created either by an API call or by pushing records to the Kafka queue
Add the MDMS configs required for egov-user-events
Add the Role-Action mapping details for APIs
Deploy the latest version of egov-user-events
Add egov-user-events file in config folder in git and add that path in the persister . (The file path should be added in environment yaml file in param called persist-yml-path )
Add master data in MDMS service with the module name as mseva. The sample master data for the service is given below: Event Categories
Event Types
Use /localization/messages/v1/_upsert to add localisation (templates) for notification messages to be sent. The product notification templates are given below:
Configurable Properties
The following properties are configurable in the application.properties file in egov-user-events service.
Property
Value
Remarks
kafka.topics.persister.save.events
save-user-events
This is the persister topic onto which user-events pushes records for persistence. This is for creating events.
kafka.topics.persister.update.events
update-user-events
This is the persister topic onto which user-events pushes records for persistence. This is for updating events.
kafka.topics.lat.details
user-events-lat
This is the persister topic onto which user-events pushes records for persistence. This is for storing last-access-time / last-login-time of the user.
kafka.topics.save.events
persist-user-events-async
Topic to which the user-events consumer is subscribed. Producers willing to create events must push records to this topic.
kafka.topics.update.events
update-user-events-async
Topic to which the user-events consumer is subscribed. Producers willing to update events must push records to this topic
mseva.notif.search.offset
0
Default pagination offset.
mseva.notif.search.limit
200
Default pagination limit.
Entities
Events: Model to capture the events information. This object captures all event details that is either created or updated.
EventDetails: Captures details of the event such as organiser, location, time etc are captured here. This is the child object to the Events object. This holds significance only if the type of the event is ‘EVENTSONGROUND’.
Action: This captures the user-actions involved in the event. For instance, the pay now option, reopen option, download certificate option etc.
Recipient: Every event is addressed to a crowd to which a notification for the same is sent. This model captures information about the recipients of the notification of this event or can also be framed as details of the addressee of the event.
Event Type: Events are divided into multiple types as follows:
BROADCAST - These are messages broadcasted addressing a group of people. For instance, “There’s road blockage near the bus stand, please use a different route”
EVENTSONGROUND - These are events organised by a group of people addressing another group of people. Usually, it is the ULB organising events for the citizens. It can be any activity like a 10K Marathon, Polio Drive, Property Tax collection drive etc.
SYSTEMGENERATED - These events are generated by different systems on the egov platform like PT, TL, PGR etc addressing a group of people. For instance, “Dear Citizen, Your TL has been approved please proceed to pay <PAY_NOW>”
OTHERS - Events that don’t belong to the types mentioned above.
The following are configured in MDMS.
Event Category: Events are categorised into the following:
PUBLICHEALTH - Events related to public health
CULTURAL - Cultural events
WARDCOMMITEEMEETING - Events for recurring meetings of the ward committee
These event categories are mapped to event types internally. The categories mentioned here are for EVENTSONGROUND type. These are configured in MDMS.
How does it work
This service manages user events on the egov-platform, which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service. Events can be created either by an API call or by pushing records to the Kafka queue.
Every event contains information about the event type, event category, event name, description, recipient, actions, event details etc. Based on the type of event, the list of mandatory fields varies.
Once the event is sent for creation, the service validates all the required fields and assigns a recipient list to that event. An event can be addressed to a particular person, group of people, a user type and also roles. Events like updates on the TL application are addressed to the TL owners while events like Polio drive are addressed to the entire ULB. Some events like mass Bill generation are addressed only to those who are required to pay those bills. A recipient list is generated based on the request and stored in the system.
When an event is updated a counter-event is generated. Counter events are of 2 types: Counter event on Delete and Counter event on Update. When an event in ACTIVE status is made INACTIVE or CANCELLED, counter-event on delete is generated. When details of an event are updated irrespective of the status a counter-event on update is generated. These counter-events are stored along with the actual events in the system. However, when a counter-event on delete is generated, its corresponding actual event is marked INACTIVE.
One of the important aspects of this service is the search API. Searching for the events stored in the user-events system is different for different roles. When citizens search, all the events addressed to the citizens are retrieved. The events that contain corresponding counter-events are deduplicated and only the latest ACTIVE events are returned.
We have a use case where past events have to be marked INACTIVE. This applies to all the BROADCAST and EVENTSONGROUND types of events which are time-capped. If a BROADCAST event is active from 1/Jan to 10/Jan, it will be marked inactive post 10/Jan, after which the citizens stop receiving any updates to that event. This change of status of the events is achieved by a lazy-update technique instead of a cron-job. Due to this, the search API not only returns the events but also updates the status of events before returning it to the user based on whether it has expired.
When an employee searches, all the EVENTSONGROUND posted in the particular ULB are returned by default irrespective of the status. Once the actions are performed on the events that are active, the notifications are triggered to the citizens.
Employees can search for events based on the date range. The events created or last modified in that range are displayed in the search response. So, to get the details about event in a particular date range pass the value in fromDate and toDate field of search criteria.
fromDate and toDate fields accept epoch values only.
And to get details about the Delete event, pass Status as CANCELLED. To get details about the Broadcast event pass eventType as BROADCAST.
Review the code and descriptions for every method to understand the use-cases and flow-of-logic in a better way.
eGov-user-events can be integrated with any organisation or system which wants to send the events generated for the user in the system
Easy management of user events on the system - which means all the events about which the user (essentially citizen) has to be notified are stored and retrieved through this service.
Employees can create events in the system using /egov-user-event/v1/events/_create endpoint
Employees can update events in the system using /egov-user-event/v1/events/_update endpoint
Events are searched in the system using /egov-user-event/v1/events/_search endpoint
/egov-user-event/v1/events/notifications/_count API is used to fetch the count of the total unread and read notifications.
/egov-user-event/v1/events/lat/_update API is used to update the last-login-time of the user. We store the last-login-time of the user through this API thereby deciding which notifications have been read.
Title
Link
API Swagger Documentation
(Note: All the APIs are in the same postman collection therefore the same link is added in each row)
MDMS configurations file link:
All content on this page by is licensed under a .
