Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Platform developers create add-on modules (aka plugins) for OpenMRS and leverage our API to build new applications.The goal of the module system is to allow other developers to write and integrate code into OpenMRS without having to modify the core code base. Our online Module Repository has been developed to facilitate searching and sharing of modules. For simple user administration of modules, see Administering Modules.

What is a module?

  • A module is packaged java code that can be installed into a running OpenMRS instance and is able to modify almost all aspects of OpenMRS. It can provide web pages, add tables, change how service calls work, and add new functionality (like report options, person attribute types, etc)

Types of Modules

  • Core Modules
    • We want to take some functionality in core and iterate on it more rapidly than the OpenMRS release cycle. This is the case for the logic module. Core modules must be loaded for OpenMRS to run; if a core module is missing, you cannot start OpenMRS.
  • Bundled Modules
    • We have functionality needed by core, but can have multiple implementations or benefits may benefit from the ability to swap in an alternative (eg, faster or better suited for a particular site) implementation.  This is the case with the XStream module, which implements the serialization API on which core OpenMRS code depends.
    • Some modules are just generally/widely useful, so get shipped with OpenMRS. We call these "bundled" modules. Examples are FormEntry and HTML Form Entry.
    • In very few cases, a bundled module might be required (e.g., XStream is required because at least one module implementing the serialization interface is required). In most cases, bundled modules are bundled for convenience.

In general, we would prefer to move toward a world where more & more functionality is done in modules and the core is getting leaner over time – ie, a framework. 

Quick Overview

  • Modules can modify with the service layer methods via Aspect Oriented Programming (AOP). All core services and all module services are able to be wrapped and manipulated.
  • If in a web context, modules can add their own jsp web pages in their /web/module folder. They link these pages to controllers and to OpenMRS via the Spring context /omod/src/main/resources/moduleApplicationContext.xml
  • Modules can add to and current jsp page in the web layer via extension points. A module registers an extension in the /omod/src/main/resources/config.xml for each extension point in the system to which it wants to add content.
  • Modules are able add and modify tables in the database. The sqldiff.xml and/or liquibase.xml file in the metadata folder holds the diffs.
  • The file extension for modules is ".omod". However, a module is simply a jar underneath. This different extension was chosen for two reasons: First, its just a short form of "OpenMRS Module". Second, its a unique extension and there aren't any other programs known to be using it.

How to write a module

The Creating Modules page is the next step.

Examples

Some development examples are available here

  • No labels