Skip to content
Open Warehouse Management System
Java Shell
Branch: master
Clone or download

Latest commit

Latest commit ec36d06 May 4, 2020


Type Name Latest commit message Commit time
Failed to load latest commit information.
doc docs May 4, 2020
org.openwms.core.lang typo Apr 15, 2020
org.openwms.core.util Switch to next development version Apr 15, 2020
scripts fetch tools from remote repo Apr 11, 2020
src docs Apr 21, 2020
.gitignore documentation Apr 8, 2020
.travis.yml fetch tools from remote repo Apr 11, 2020
Jenkinsfile removed non existing profile May 28, 2017
LICENSE Changed to Apache License 2.0 Nov 22, 2018 adopted site Apr 16, 2020
azure-pipelines.yml Update azure-pipelines.yml for Azure Pipelines Jun 14, 2019
pom.xml Switch to next development version Apr 15, 2020 added sonar Nov 12, 2018

Is a free to use and extendible Warehouse Management System with a Material Flow Control System for automatic and manual warehouses.


See further documentation at Atlassian Confluence...

Build status License Quality Join the chat at

Current state of development

Most components are under active development. In 2016 the whole product has been migrated from the technical structured OSGi architecture towards a business oriented architecture with Spring Boot microservices and Netflix OSS components. Documentation of previous released versions does still exist on

Current Architecture

Instead of applying a technical layered architecture (like with OSGi and before that with J2EE1.4) the current architecture focuses on business components. Business functions with a high degree of cohesion are kept together as small deployable software components. Each component has it's own development lifecycle with its roadmap of the API evolution and an separate data store. The following sketch shows all currently existing components of the system together with all potential surrounding systems.


Beside the user interface, several other systems interact with the system. On top, we have ERP systems sending high-level tasks to, e.g. a customer order with order positions where each refers to a product that is managed by the Inventory Service. fulfills these tasks by orchestrating the underlying subsystem. The communication between and an ERP system may not be exclusively unidirectional, can although send status messages back to the ERP or may request product catalog updates, this depends on the project needs. On the bottom we have devices that are close to actors and sensors in automatic warehouses. Those devices are almost limited in hardware resources and protocol stacks. Typical PLC (Programmable Logic Controllers) are used to interact with field sensors and to control actors. is open source software and therefore promotes the usage of open source hardware components over commercial PLC products. The first choice of supported devices are boards, like Arduino, Raspberry Pi or the industrial version Revolution Pi, with an open microcontroller architecture, free to use. All these subsystems in the field area have one thing in common: They are close to the hardware and expect responses from the server in no time to control motors and switch gates to the right direction. They although have the power to bring a serving component down just by sending requests all the time. Typical web applications are different in that the infrastructure takes care of DoS attacks and the application server pools incoming traffic.

Read more about each components architecture and design on the components Github page.

Previous Architectures

The project started in 2005 with an J2EE server approach based on EJB2.1 with XDoclets, Hibernate and JavaServer Faces (JSF). In more than 15 years we've seen a bunch of technologies that all address the same problems.

A POC has been implemented with EJB2.1, but the project actually started with EJB3.0. Since about 2007 is on the Spring Framework and this is still fine and the right choice. Spring in combination with OSGi seemed to be the perfect match to build a modular and extendible base project. Unfortunately Spring stopped their efforts on OSGi, in particular on Spring dmServer and Spring Dynamic Modules. In a transition step to the current microservice architecture, we put all the OSGi bundles into a fat JavaEE WAR deployment unit to run the application on a servlet container like Apache Tomcat. After that we redesigned all services and business functions and applied a microservice architecture.


In addition to a bunch of Spring Framework subprojects, uses one of the popular BPMN workflow engines Activiti, Flowable or Camunda as embedded engine to take routing decisions in the TMS layer. RDBMS access is shielded with the Java Persistence API. Some components might use NoSQL databases, like MongoDB, solely. RabbitMQ is used in combination with Spring Integration as notification and event broker. All hexagon components are Spring Boot applications designed to run on any modern PaaS, like Heroku, Azure Kubernetes Service or Redhat OpenShift.


11 12 11 12 11 12 11 12 11 12 11 12 11 12 11 12
2 3 4 5 6 7 8 9
11 12 11 12 11 12 11 12 11 12 11 12
10 13 14 15 16 17
You can’t perform that action at this time.