For Module Developers

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 Add-ons index has been developed to facilitate searching and sharing of modules and Open Web Apps. 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

These are the basic types of modules.  Note that these are not necessarily mutually exclusive (e.g., a Community-Owned module may also be a Bundled module).

• Core Modules

  • Required to run OpenMRS.  When we want to take some functionality within core and iterate on it more rapidly than the OpenMRS release cycle, we may move it into a core module. This was 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 (e.g., 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.

• Community-Supported Modules

  • A module that the community will ensure continues to be maintained even if the author/owner disappears

• Community-Owned Modules

  • A module that the community will ensure continues to be developed, maintained, and (most likely) bundled as long as it is useful to the community.

• Community Modules

  • A module created by anyone and shared with the community

• Commercial Module

  • A module that must be purchased or has a subscription fee to be used.  OpenMRS does not make commercial modules, but the platform supports members of the community creating closed- as well as open-sourced modules.

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.

• Modules can configure caches by creating apiCahceConfig.properties file in resources directory. More information can be found here Caching service methods

   

How to write a module

The Creating Modules page is the next step.

Examples

Some development examples are available here .