and Overview
The Department Entity service manages the department and its hierarchies metadata. It deals with department entity and department hierarchy only.
Department Hierarchy store only hierarchies definition like metadata for department level and department entity stores actual department data with its ancestry information.
...
It contains department entity information along with its hierarchy level and also attaches master department information (department id - UUID). It keeps all child level information lists at every department node (department record). The leaf level department does not have any children’s info.
ChiThe childld child list contains the department entity ID list, which makes the current department entity parent of all children list (department ID list). This is how it maintains the department entity level.
...
Create Department Entity:
It passes tenant Id, master department id, hierarchy level, and its cand children list with department entity name and code. Tenant, hierarchy level and the master department is are root info about the department entity. If the department entity does not contain any child, that means it is a leaf department entity it can only seek for its parent.Search Department Entity:
It can make search requests based on any department entity attribute but can't skip tenant information, it returns the whole department entity details along with its child information. It finds all ancestry information of the current department entity.Update Department Entity:
Update the existing department entity by searching based on department entity id and tenant id.
Mandatory Fields to update department entity "id" and "tenant id".
We can update any attribute in the department entity except “id” itself.
updatable attribute list: tenantId, departmentId, code, name, hierarchyLevel hierarchy level and children.It does a few validation validations before updating the department entity.
departmentId and children can not be update updated without hierarchyLevela hierarchy level.
hierarchyLevel hierarchy level value should be valid for departmentId and children. If the value got mismatch mismatched then it will throw an appropriate error message.
It checks in the system before doing an update, that department entity id is available or not. If exist then it'll update else throw a meaningful error message.
...
In the above image, the first row contains the definition about of the data that is there in the second row. Ideally, we are considering the first row as Meta-Data of subsequent row data.
Department Hierarchy Create API - creates the hierarchy based on the Meta-Data. Creation The creation of the Department Hierarchy follows a Top to Bottom approach.
Top The top or first label will be named as “Department”, with no parent (parent as null) in the create department hierarchy apiAPI. Once the hierarchy is created, in api API response will get a unique id and level as 0.
For the next subsequent create hierarchy api API request, will pass the label as “Zone", with a parent as the previous request unique id. This request will also return the response with a new unique id and with level as 1(you can refer to the hierarchy level evaluation section).
Similarly, for the next hierarchy, create will pass pass labels as “Circle”, “Division”,... and corresponding previous unique id as a parent.
For this example , we will stop the hierarchy creation till labeled as “GPWSC”.
...