Modularity/Extensibility decisions, questions

Owned by Rich Magnuson (Deactivated)
Last updated: Apr 20, 2016

Use Cases

Common Use Cases the solution must address.  Assumes definition of terms, like "Reference Distribution"

Use Case 1:  Project deploys "vanilla" OpenLMIS Reference Distrubution

For this simple case, we want to deploy the reference distribution.  No additional modules or enhancements

  • Seeding data?
  • Configuration:  email, db connection, and other items typically found in default.properties

Use Case 1a:  Project updates "vanilla" OpenLMIS installation to a newer version

A project has deployed the stock OpenLMIS Reference Distribution.  Over time, updates were made to the Reference Distribution services, e.g. updates to Requisitions.  The project now wishes to update the installation to use the newer services.  Must consider DB migration, etc.

Use Case 2:  Country Project creates new Service, deploys as part of Reference Distribution

A country project enhances the OpenLMIS Reference Distribution with a new service and deploys it.  The module is not part of the Reference Distro, but is published and available for others to include in their own distribution.  Use case should include how other projects obtain and leverage this module.

Use Case 3:  Project extends a core domain model

As an implementer, I want to add several new fields to a Facility record, say "Color", "Max Occupancy" and "Chairs", an n-length list of chairs available at the facility (this is simply non-sense data for this use case).  OpenLMIS should define a means to persist these new fields in the database, and retrieve them with RESTful calls, and use them in standard queries (e.g. return all facilities where color == 'blue'). 

Use Case 3a:  Project updates UI for a core domain extension

A project has extended the Facility record as described in the above Use Case 3.  How is the reference Facility UI screen extended to display these new fields?  Note the potential data types that the UI might need to accommodate, e.g. "Max Occupancy"  as an integer, Color as a color choose or set of RGB values, and Chairs is a selection list widget.

Use Case 4:  Add a new service -- Informed Push -- as part of Reference Distribution

We want to uate the reference distribution with a new capability.  For this example, say it is Informed Push

  • Update reference distribution
    • Update docker image configuration to add new docker instance for Informed Push.  Will hold image of the new Spring boot application
  • Starting published Spring boot application template, create new Spring boot application.  Write informed push logic here
    • If extensibility is foreseen, instead write informed push as a Spring module  
  • UI:  create new UI component (starting from published UI template).  Update reference UI application to include

Use Case 5:  Adding a Strategy to Requisition

How does a project insert their own strategy to an OpenLMIS extension point?

 

Modularity

Hybrid approach:

  • OpenLMIS "core" composed as a Spring Boot application.
    •  Core modules are created as Spring components.  This is likely the requisition/fulfillment set of services
    • The OpenLMIS application is a composition of these components into a distribution.  The distribution:
      • assembles various components together using standard Spring wiring, using Maven to locate dependencies
  • See 

Repositories

This section is outdated compared to later discussion.  

  • OpenLMIS Organization in GitHub publishes several repositories:
    • openlmis-core-domain
      • One or more modules for reference entities, such as Users, Facilities, etc.
      • Artifacts:  jar file, than can run as a single service
    • openlmis-requisition-core
      • Spring boot application.  Composed of several Spring modules (see openlmis-requisition-module-xx)
      • Artifacts:  jar file, that can run as a single service
    • openlmis-requisition-module-xx
      • where xx is requisition, fulfillment, etc.
      • holds core modules that are composed in openlmis-core
      • Artifacts:  jar file for each module
    • openlmis-requisition-module-xx-ui
      • UI components that match the service (pending ref UI strategy)
    • openlmis-reference-distro
      • projects fork or copy this to create the actual application.  Reference distribution produces a set of docker images
        • project could create a monolithic app, too. 
      • Artifacts:  the actual OpenLMIS applications, made up of several docker images, stitched together with Docker Compose and configuration (such as DB connecton details if we're sharing a Postgres image).
        • each Docker image is domain bounded.  E.g. one for Requisition/core, one for Inventory Management, one for core domain (ref data), another for UI, and potentially others for add-on modules
    • Reference UI

Questions/Issues

  • Reference UI - how to build, compose
    • Do modules package UI into the same repo as module code, or a separate repo?
    • Still need reference UI solution that pulls together various web components, both "core" and additional modules
  • Database - how to extend core domains, or even new module domains?
  • Domain model areas that need more attention:
    • Products, especially for packaging (GTIN/GS1), "kits" and some concept of "product Types" to satisfy scenarios such as, "I need 100 doses of BCG (not "BCG 10" or "BCG 20")"
    • Hierarchies, such as supervisor nodes, Requisition Groups, etc.
    • Design for Program Data
    • Should Programs have different supply models enabled for different parts of the supply chain, e.g. requisitions for one portion, informed push for another
  • What to call these docker image boundaries...Feature?  Vertical?  Service?
  • Extending domains, e.g. adding attributes to Facilities
  • Upfront cost of creating docker images?  
    • build, deploy, logging, etc.  Also, remember this needs to run on (Windows) laptops.  Minimum hardware requirements?
    • Promotes vertical development amongst different teams

 

Thought Experiment - Add New Module

Use case:  as an implementer, I want to create a module for Informed Push in OpenLMIS 3.x.  Team started this thought experiment, but was never finished as evidenced by the sparse content below 

Need:

  • description of delivery routes (e.g. Delivery Zones)
  • Calculating distribution quantities for each Facility on a route
    • based on ISA, Consumption, or other means

Thought Experiment - Add Vaccine Management (New data collection forms (IVD report), new requisition UI, inventory management service, CCE service, new reports, new ISA strategy and population data collection screens, DIVO dashboard )

Use case:  as an implementer, I want to ...

Need:

OpenLMIS: the global initiative for powerful LMIS software