Extensions OpenLMIS in our project

We aim to reduce the cost of our upgrade OpenLMIS, in April Our team starts to make some code changes based on Malawi’s successful experience and OpenLMIS official documents . We create a new microservice and have it talk to other services。Below we will introduce our new service in detail,If anyone has any questions about this, please let us know. We hope to help other teams and individuals using openLMIS

  1. A new micro-service “siglus-api” will build and all customized logic will be in this service (more micro-services may be created in the future). So we will not modify the core v3 source code directly, and origin v3 docker images will be deployed to our system directly.
  2. As we need do customization, there are some situations we can handle in our own services, but there are also many situations we need to change some logic of v3 source code, in this case we will reuse v3 source code and copy v3 source code to our siglus-api codebase and modify the part we want to change.
  3. Sometimes we just want to change a bit of logic, we still need to copy dozens of java files to complete the whole process, but only 1 or 2 java files need be changed, so it is difficult to handle and will conflict easily(for example, a developer needs to copy two methods of a class, and another person needs to copy other three methods of the same class), and also difficult to figure out which are the origin v3 source code and which are the modified v3 source code. In order to ensure that we can clearly distinguish our modifications to the v3 code and ensure that future upgrades to the v3 code will be easy, we created some sub-modules(such as requisition module, stockmanagement module) to keep the v3 source code. When we need to change some logic of v3, we will reuse the v3 source code in sub-module and only modify the part we need to, and any modification against v3 source code will be marked with comments(in a special format) to explain the reason for the modification.
  4. If the original v3 APIs meet our business requirements, we will call the v3 APIs directly from frontend or through internal service call service.

@jingzhao Thank you very much for taking the time to write this up. While the idea of creating a custom service for the API and UI seems like a good plan, when I read that your plan is to “copy dozens of java files” I feel like we are going in the wrong direction.

I would appreciate some additional thoughts from @joshzamor but generally I think that if there is functionality that would require changes to core designs/code the better approach would be to either:

  1. Discuss the functionality with the community to see if it could be developed within and then contributed back the core service (taking into account the OpenLMIS coding standards and general compatibility)
  2. Discuss the functionality with the community and see if an extension point or other extension mechanism can be created in the core service to facilitate the required functionality without copying source files.