SaaS_IHRM: a Spring Cloud human resources backend from 2020

What the system is, and the stack it was written against

SaaS_IHRM is a Java backend for a human resource management system built on a SaaS model, meaning one code base serving multiple companies. The repository description calls it a SaaS Intelligence Human Resource Management backend, and the README title describes a SaaS-based IHRM system.

The technology line in the README is short: SpringBoot plus SpringCloud plus SpringMVC plus SpringData. The topic list of the repository adds springcloud, springboot and redis, and the primary language is recorded as Java.

The development environment is pinned in a way that dates the project precisely. The README lists Oracle JDK 1.8, MySQL 5.7, Maven 3.5.2 and Redis 2.4.5. Those are the versions of roughly 2020, and they matter if you try to build this today, because a JDK 8 and Redis 2.4 combination is unlikely to be what you have on hand.

The front end is a separate repository, written in Vue, at github.com/Han-YLun/SaaS_IHRM_Vue, and the README is careful to say that the frontend is written in Vue with the address given there, which tells you this repository is the server half only.

The repository root is minimal, with a .gitignore, the README, an IntelliJ module file SaaS_HRM.iml and an ihrm_parent directory, so the code lives under a single parent project directory. There are no GitHub releases, and the last push was on 2026-04-20, so the code has moved recently even though the design and dependency set are from an earlier era.

Nine services, and why the startup order is not arbitrary

The microservice layer is a set of nine modules, and the README gives their startup order together with the reasoning, which is the most useful part of the document.

The order runs: ihrm_eureka, ihrm_gate, ihrm_company, ihrm_system, ihrm_attendance, ihrm_social_securitys, ihrm_salarys, ihrm_employee, ihrm_audit.

The reasons given are worth reading carefully, because they describe the dependency graph.

Because all modules register with Eureka, the Eureka module starts first. Because the modules after the gate are business modules, the gateway is started second. Because the system module calls the company module's interfaces through Feign, company has to start before system. And because the salarys module calls the attendance and social security modules through Feign, salarys comes after those. The last two orders can be shuffled, and the general rule given is that when a service calls another service's interfaces, you should start the called service first.

That is a compact statement of the whole architecture: a service registry, a gateway in front, and a set of business services that talk to each other through declarative clients with no configuration of URLs.

The three roles in the system are visible in the module names. A SaaS administrator manages the platform, an enterprise administrator manages one company, and an employee is a third role, and the README includes screenshots of each of these module sets.

The Feign dependencies are worth calling out as a design consequence. A payroll module that reads attendance and social security data over the network means those two services must be up for payroll to work at all, which is the price of splitting a coherent business process across service boundaries.

Databases, table prefixes and the workflow engine

The persistence story is described in the README with a bit of unusual clarity about naming conventions.

There are two databases. The main one is called ihrm, and the other is called act, which is used by activity7 and can be generated automatically. The act database is described as the one mainly used by the activity7 workflow.

Inside the main database, the table prefixes carry the meaning. Tables starting with bs are business related, tables starting with pe are permission related, tables starting with co are company related, and tables starting with em are employee related. That convention is what makes a multi-tenant, role-splitting schema navigable, and it is the kind of thing you would want to copy into your own project.

The workflow side is used for overtime, leave and resignation, and it is built on the Activity 7 workflow engine. The BPMN process files are provided separately, and the README explains what happens with them: deploying the BPMN files to the online demo parses them directly into the act database, and the act database is created automatically during that deployment.

So there are two deployment paths described here, one for the application and one for the process definitions, and the process definitions are what actually create the workflow schema.

The remaining assets are the Swagger interface documentation and the project archives, both distributed as downloadable archives with separate extraction codes. The Swagger bundle is served through nginx, and the README notes that you have to run nginx.exe from a directory in cmd, because double-clicking it does not work, and that the interface is then reachable on localhost:801, with the endpoint configurable in nginx.conf.

How the login works, and why it is not something to copy

The authentication section is short and, in places, a warning.

The username is the phone number, and the password is mostly 123456. The account information lives in the bs_user table, which is the bs prefix again pointing at business tables. On login the password goes through MD5 encryption three times, with the salt being the phone number. Redis has to be running at login time, because the login information is stored in Redis after a successful login. And if your Redis has a username and password set rather than the default, that is configured in ShiroConfiguration.java, since the author's own Redis uses the default configuration.

Three MD5 rounds with the phone number as salt is a weak scheme by any modern measure, and salted with a value that is already the identifier. The seeded accounts make it worse. There are three of them, one per role:

  * 13800000001
  * 123456
  * 13800000002
  * 123456
  * 13800000003
  * 123456

The first is the SaaS administrator, the second the enterprise administrator and the third the employee, and all three share the same default password.

The use of Apache Shiro for the security layer is consistent with the era of the dependencies, and the configuration point named in the README is where you would add Redis credentials.

None of this is disqualifying for a training project, and the README is honest about it by publishing the credentials. But it is worth reading this section as a list of things to change rather than as a design to adopt. A phone number as the salt means two people with the same phone number across different tenants are the same principal, and a hard-coded default password in the seed data is exactly the kind of thing that ends up in a production database.

The known bug, and what to expect when you run it

The README has a section on the problems in the project, which is short and unusually candid.

In the employee management module, the department id and the department name are not consistent when user information is saved. That is the whole list of known issues under that heading, plus an invitation to open issues for anything else, and a mention of a public account for contact.

It is worth being clear about what that bug implies in practice. If the department id and the department name can disagree, then any screen that joins on one and displays the other can show a mismatch, and any export or report built on that pairing inherits the same inconsistency. In a demo with seed data you may not notice it. In a deployment where people create and edit employee records, it is a data integrity problem rather than a display glitch.

There is also a deployment tutorial linked from the README, and a Star History chart, which is a common badge for a course or bootcamp project. The combination of a linked tutorial, screenshots of three role dashboards, seeded accounts with a default password and a self-described known bug tells you what kind of artifact this is. It is a course project that has been published as a repository, and it is best used as a worked example of how this style of Chinese enterprise HR system is decomposed into services.

The audit module, ihrm_audit, is the last in the startup order and is one of the two whose position is explicitly said to be interchangeable, since the remaining orderings can be shuffled.

For a reader evaluating whether to build on this, the practical checklist is short. The dependency set is from 2020 and will need attention on a current JDK. The database dump and the BPMN files are distributed as archives with extraction codes rather than as migrations, so there is no versioned schema history. The password handling is weak. And the employee module has a known data inconsistency that the author flags but has not fixed.

Editorial conclusion

Treat SaaS_IHRM as a reference for how a Chinese enterprise-style HR system was decomposed into Spring Cloud services, with Eureka, a gateway, a shared permission and company model and per-module databases, rather than as a foundation for new work. Do not deploy it as it stands, because the login model is three rounds of MD5 with the phone number as salt, the seeded accounts use a shared default password, and the dependency set is pinned to JDK 8, MySQL 5.7, Maven 3.5.2 and Redis 2.4.5. Before running it, read the startup order notes, start the registry and gateway first, and replace the default credentials, and expect to fix the employee module's department id and name mismatch that the author lists as a known issue.

Frequently asked questions

Official sources

1. Han-YLun/SaaS_IHRM on GitHub
2. Issues
3. README