Open Warehouse Management System

An open source software to build intralogistic projects with.

OpenWMS.org is a software project to build modern warehouse management systems with. Integrators use and extend OpenWMS.org to realize customer projects. Over the years even customers ramped up DevOps teams to customize and operate OpenWMS.org in their own way to reduce cost and time-to-market. Integration with a varying number of enterprise information systems (like ERP) and field controllers (e.g. PLC) is essential for this project. Almost all customer projects in the intralogistics domain bring their own specific functional requirements. This strives for extendability and flexibility of the software to realize features efficiently. OpenWMS.org consists of a Warehouse Management part (the WMS domain), the WCS (TMS domain) and connectors to other systems. The WMS part is connected to ERP systems whereas the Transport Management System controls field controllers, like Raspberry Pi or PLC. Non-functional requirements like the systems availability, performance and reliability are first-class requirements, too.

Technology

Microservices

The Microservice architecture drives the design of the software towards small and well defined modules of business functions with high cohesion.

Cloud Native

Strictly following the Twelve-Factor manifesto all services are cloud enabled but do not require to run in the cloud.

Polyglot

OpenWMS.org does not depend on a particular database product nor on storage technology. Different services may use different types of datastores. From relational to NoSQL databases.

Workflow

A workflow engine is used to control and change the material flow handling (MFC/WCS) dynamically without interrupts nor downtimes.

Frontends

Admin UI

Monitoring and supervising of microservices based on SpringBoot Admin

Auth Server

A multitenant, multidomain OAuth2.0 OIDC AuthN & AuthZ server based on Spring Authorization Server

COP

A web application for operators and superusers to manage warehouse inventory and processes.

Roma

The OpenWMS.org cross-platform mobile handheld application for warehouse operations on mobile phone or tablet devices built with Flutter.

Grafana

Monitoring and supervising capabilities of OpenWMS.org microservices, RabbitMQ, databases and servers

Kibana

Kibana on top of Logstash and Elasticsearch is used for business transaction monitoring and log analysis.

Eureka

Microservice health monitoring based on Spring Cloud Netflix.

Project References

Beside of the non-public OpenWMS.org installations some customers allow to refer to their usage of OpenWMS.org.

BMW Group AG

Uses OpenWMS.org to drive and supervise automatic warehouses

Scheppach GmbH

Uses OpenWMS.org to manage multiple manual warehouses with typical receiving, inventory management, picking and shipping processes.

DSHS

OpenWMS.org has been established successfully by a partner in the US for national health government.

General Electric

Built their own product on top of OpenWMS.org to fully control their warehouses on their own.

Deployment Scenarios

A typical customer project built with OpenWMS.org is usually a composition of microservices to fulfill the functional requirements. Whereas a service may run in the cloud or on premise customer side. This mainly depends on the quality requirements of the project. For example, a service like the tcp/ip driver must obviously run with low latency close to the automation systems layer whereas and UI services may easily run off-side.

OpenWMS.org is designed to run in four deployment models

Cloud
All microservices run off-site in the cloud and may shared with other customers. Service access is secured but no QoS are defined.
Fog
All microservices run on-side in the private cloud and are solely dedicated to the customer project.
Hybrid
In a combination of Cloud and Fog deployment, some common shared services may reside on the public cloud where other mission critical of time critical services run locally in the private cloud
Monolith
All microservices are packaged into a single monolithic deployment unit that runs on traditional application services. Notice that in this scenario elasticity is only available on infrastructure level (IaaS) not on service level.

Microservice Hub

As we've built a couple of microservices, we find it reasonable to create a central website where all microservices are listed and explained in detail. Beside a functional service description each microservice' website contains informtion about how a service consumer can access and use the outer public API. This API documentation explains how to operate with the exposed resources and describes the interaction model, how service calls can be combined to fulfill common use cases.

We differentiate between RTU and BYO services. The former ready-to-use services are already deployed in the public cloud and require valid access tokens for access. The latter build-your-own services are not installed and not online available. For all online services an account registration is required.

Online services may guarantee SLA depending on the non-functional service requirements and based on their runtime environment. Some services (like the service registry and configuration service) run in a geo distributed cluster on different PaaS platforms (e.g. Heroku Cloud and OpenShift Cluster) to achieve a high degree of availability. The SLA are defined by the service itself and documented on the service website.

The Public Microservice Hub.