...
Prior Knowledge of Java/J2EE
Prior Knowledge of SpringBoot
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc
Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic etc.
Setup:
Step 1: Start the ID-Gen service present in the following repo:
...
Following are the properties in application.properties file in collection hrms service which are configurable.
Property | Value | Remarks |
egov.hrms.employee.app.link |
This is the link to the mseva app, which differs based on the environment. | ||
egov.hrms.default.pagination.limit | 200 | This is the pagination limit on search results of employee search, it can be set to any numeric value without decimals. |
egov.hrms.default.pwd.length | 10 | This is the length of password to be generated at the time of employee creation. However, please ensure this is in sync with the egov-user pwd policy. |
open.search.enabled.roles | SUPERUSER,ADMIN | This is a list of Role codes that are allowed to perform an open-search in hrms. |
kafka.topics.notification.sms | egov.core.notification.sms | Kafka Topic to push the sms request. Please ensure this is in sync with egov-notification-sms service. |
kafka.topics.save.service | save-hrms-employee | Kafka topic to push the save request in hrms. Please ensure this in sync with the persister. |
kafka.topics.update.service | update-hrms-employee | Kafka topic to push the update request in hrms. Please ensure this in sync with the persister. |
hrms.employeecode | Key to be configured in Idgen alongwith the ID format to generate employee code. | |
egov.idgen.ack.format | EMP-[city]-[SEQ_EG_HRMS_EMP_CODE] | Format to be configured in ID gen to generate employee code. |
APIs:
_create: API to create an employee in the system. Information about the employee such as - Basic Details, Jurisdiction, Assignment, Education, Service History, Tests etc are captured during this process.
_update: API to update an employee in the system. Information about the employee such as - Basic Details, Jurisdiction, Assignment, Education, Service History, Tests etc are captured during this process.
NOTE: Deactivation / Reactivation of employee is part of the same update flow. Inorder deactivate / reactivate an employee, Deactivation / Reactivation details such as reason for deactivation / reactivation, deactivation / reactivation effective from, order number etc have to be passed._search: API to search employees from the system. Information about the employee such as - Basic Details, Jurisdiction, Assignment, Education, Service History, Tests etc are retrieved during this process. This API provides both: protected and open search. Open search is allowed only for a set of roles that are configures, for others, it protected by default.
_count: This API is used to get count of active and inactive employee present in the system.
Postman Collection: https://www.getpostman.com/collections/7205a669dbd888affe8bb036288557361e71975d
API Contract: https://editor.swagger.io/?url=https://raw.githubusercontent.com/egovernments/egovbusiness-services/master/docsDocs/rainmaker/egovhrms-hrms/v1-.0-.0.ymlyaml#!/
Entities:
Jurisdiction: It is the geographical area within which an employee can operate. This area can range from a small zone with an ULB to the entire state or more. Currently,
Jurisdictions are can defined only within a multiple ULB, wherein multiple localities/zones/blocks can fall under one jurisdiction.
...
Persister configuration:https://raw.githubusercontent.com/egovernments/egov-services/master/rainmaker/egov-hrms/src/main/resources/config/hrms-employee-persister.yml
Dependencies:
User:
HRMS depends on egov-user for creating user on every create employee call. Similarly update user and search user whenever required. HRMS uses /user/users/_createnovalidate, /user/users/_updatenovalidate, /user/v1/_search APIs.
...
For Details on entities and constraints go through README.md at https://github.com/egovernments/business-services/tree/master/egov-hrms.
Interaction Diagram:
