Understanding the role of the `ServiceRegister` entity vs. JVM Cache (`ServiceDefinition`)

Community
1

Hi everyone,

While tracing the execution flow through ServiceFacadeImpl.groovy and ServiceDefinition.java, I noticed the following behavior:

  1. Standard XML-based services are parsed and compiled into ServiceDefinition objects.

  2. These objects are then cached directly into JVM memory (the serviceLocationCache Map), either during startup via warmCache() or lazy-loaded at runtime.

  3. Because they are pulled directly from RAM for performance, it appears these file-based services completely bypass the moqui.service.ServiceRegister database entity.

Since the engine relies heavily on the JVM memory cache for standard execution, I want to make sure I fully understand the architectural intent behind the database table.

My questions are:

  1. What is the primary intended use case for the ServiceRegister entity?

  2. Are there any scenarios where a developer should manually register standard file-based services into this database table, or is it best practice to leave the table empty and let the framework rely on the file/RAM cache?

2

As far as I have seen, the ServiceRegister is intended as a way to discover certain services within the execution of a process or action. One example is for payroll calculation, where you may configure organization-specific services to run within the process, for each phase. Take a look at the mantle.humanres.employment.PayrollAdjCalcService entity (which requires the moqui.service.ServiceRegister to exist) and the mantle.humanres.PayrollServices.get#EmploymentPayDetail service.
You may look at the relationships at the moqui.service.ServiceRegister entity detail screen and will find other such cases, including:

  • mantle.account.invoice.SettlementTerm
  • mantle.product.ProductPriceModify
  • mantle.product.store.ProductStoreApprove
  • mantle.product.store.ProductStorePromotion

So, no, there is normally no need to register services using ServiceRegister unless you need to dynamically discover/configure them. For day-to-day use of the services, they are discovered automatically according to the directory structure of framework, runtime and components.