Simple. Reusable by design. Easy to read and write. Minimally error prone. Small. Get started immediately.


Relational & document data. Local & web services. Screens & forms. Search & analytics. Printing. Caching. L10n. Integration. More.


Flexible authc and authz. Usage audit and velocity limits. Web safe (XSS, CSRF, injection, etc).


Small instances (container or VM) with as little as 1GB RAM. Large clusters with dozens of nodes for millions of concurrent users.


Minimal core framework (~25MB). Extendable with tool components. Interfaces and configuration options to add tools or override default functionality.


More than just tools. Thousands of reusable business artifacts in modular components. Get your enterprise application projects on track from day one.

For more detail see Introduction: What is Moqui Framework? and other sections below.

Moqui Framework

The core framework

Moqui Runtime

Default runtime with browser libraries, nav bar, XML Screen macros, and system and tools apps


Example entities, services, and screens with tests


Endpoint for service level integration

Apache Camel

Endpoint for service level integration

Apache FOP

Generate PDF, PS, SVG, etc from XSL-FO and HTML


Alternative to the default Bitronix transaction manager


Faceted full-text search and analytics


Clustering and distributed computing


JBoss KIE integration for Drools rules, jBPM workflow, etc


Document and graph database with Entity Facade integration


SFTP Client using SSHJ for secure integration transport


Render a wide variety of wiki formats

Built With (and thanks to)

Open Source Projects Used in Framework

Open Source Projects Used in Tool Components

Selected Servlet Containers and Databases


Moqui Framework is a seamlessly integrated, enterprise-ready framework for building enterprise automation applications based on Java. It includes tools for database interaction (relational, graph, document), logic in local and web services, web and other UI with screens and forms, security, file/resource access, scripts, templates, localization, caching, logging, searching, business rules, workflow, multi-tenancy, and integration.

WARNING: What follows is generalized marketing text. If you're a developer and want to dive in, see the links at the left. If you want warm fuzzies, you're in the right place.

Moqui helps you build applications quickly and scale complex applications to hundreds of thousands of lines of efficient, well organized code instead of millions of lines of mess. Along the way you work on only what you care about, and let the framework take care of the rest.

  • Efficient tools and consolidated files make small apps easy and fast to build
  • A true 3-tier architecture and service-oriented design maintain clean structure for very large applications
  • You control your data, and with a comprehensive universal data model (Mantle UDM) it is easy to find your data and have a place to put everything you need
  • Built-in support for advanced tools such as Jackrabbit (content), Camel (integration), ElasticSearch (search), Drools (rules), and jBPM (workflow)
  • Advanced clustering using Hazelcast (other similar tools are pluggable) for database cache invalidation, web session replication, background service executor, user notification topic, and JCache
  • More flexible and secure than hosted framework PAAS solutions like while easy to host on-premise or in the cloud, even on Java IAAS and PAAS vendors like AWS Elastic Beanstalk, Cloudbees, Cloud Foundry, Heroku, etc
  • Easier to work with and more comprehensive than frameworks such as Spring, Rails, Grails, etc; takes care of more for you automatically and through simple configuration, while allowing you to drop into code wherever you want
  • The Mantle Business Artifacts project based on Moqui Framework offers a foundation for eCommerce, ERP, CRM, MRP, etc applications with data model and services to let you to focus on UI and differentiating features
  • A next-generation design based on over a decade of innovation and experience with Apache OFBiz

Is your current platform not flexible enough? Is development progressing too slowly, especially later in complex projects? Does your data lack structure? Are you finding it necessary to build things that seem really generic? Are you having issues with scalability or difficult deployment? Are your hosting options limited? Are you suffering from platform lock-in (especially with a PAAS solution)?

The Moqui Framework is an integrated tool set with everything needed to start building web-based and distributed enterprise applications right away. Rather than starting with a set of tools and figuring out how to use them together and filling in gaps that are not handled by default, Moqui is ready to go.

The framework features a well-defined Java API that makes it easy to get at the features listed below, especially in Groovy code. What's even better is that the Moqui tools are designed to be used in a declarative way so most of what you need to do will be possible with XML configuration and little or no code, unless you want code... which you can insert or override anywhere.

Comprehensive: Moqui Framework is designed to provide comprehensive infrastructure for enterprise applications and handle common things so you can focus your efforts on the business requirements, whether it be for a multi-organizational ERP system, an interactive community web site, or even a bit of simple content with a few forms thrown into the mix.

Automatic Functionality: By using the tools and practices recommended for the framework you can easily build complex applications with most security and performance concerns taken care of for you.

No Code Generation: Moqui relies on dynamic runtime functionality to avoid the need for code generation. This keeps your development artifacts small and easy to maintain, not just easy to create.

True 3-Tier Architecture: Many modern frameworks have tools for database interaction and user interaction but you have to roll your own logic layer. Moqui has a strongly defined and feature rich logic layer built around service-oriented principles. This makes it easy to build a service library for internal application use, and automatically expose services externally as needed.

The next layer up in the Moqui ecosystem is a project called Mantle that consists of a Universal Data Model, a Universal Service Library based on the data model, and a Universal Business Process Library to guide the design of it all. For more information please see the Mantle page.

For a more complete list see the Framework Features page.

When selecting an enterprise application framework there are many criteria to consider. These criteria drove the design of Moqui:

Strong Best Practices

Your mother probably encouraged you to maintain a policy of: "A place for everything, and everything in its place." For enterprise frameworks best practices involve identifying common development needs and having a tool planned for each (or sometimes a primary and secondary best practice). Some needs to consider include:

  • process incoming data
  • structure multi-area pages/screens
  • gather and prepare data for output
  • format/layout output
  • business (service) logic (including persistence related operations)
  • service orchestration, process triggering, etc
  • define business data structures
  • route web requests (process incoming data, render responses)
  • route logic calls (support remote and local implementations, sync/async/scheduled execution, tx mgmt, security, etc)

The main point here is consistency. There is an efficiency aspect to this, but more on that later. This becomes more important as teams and projects get larger, and where teams are distributed or too large to interact closely and have common review of the artifacts produced. Without these guidelines developers spend a lot of time researching possible tools, learning about tools others have used, and dealing with differences in tools when working on requirements that across a large application.

In some cases the choice for a "primary" best practice tool handle most cases really well, but doesn't handle certain things very well (or at all). In those cases a "secondary" best practice tool should also be specified along with reasons when it should be used.

Minimal Tool Set Redundancy

A small set of tools provides various benefits both during initial development, and to an even greater extent, in ongoing maintenance and improvements:

  • less technology switching as people work in different areas of the applications
  • less segmentation of development groups in your organization
  • easier to read, review, and maintain code
  • more consistency among the artifacts
  • easier choice of tools and areas to build things in as new designs are ready for implementation or existing designs are changed
  • easier for new people to learn the technologies (with fewer technologies to learn)

Individual developers may not be familiar with the set of tools chosen, and they may prefer the tools they are already familiar with (sometimes with strong bias). Some set of tools has to be chosen or you end up with the opposite of the benefits above. In the long run, and often short-term as well, a smaller tool set is better for both individuals and organizations.

Efficient Tools

This is #3 for a reason. If the overall tool set and practices are not adequate the benefits from efficient tools will be lost in the noise and overrun by the problems caused by other things. Efficient development tools result in development artifacts that are (in order of importance):

  • simple
  • reusable by design
  • easy to read as well as write
  • minimally error prone
  • small

Some tools are great for small and simple applications, but the size and complexity of artifacts scale poorly, resulting in applications that are unnecessarily large and complex.

Existing Artifacts

What existing artifacts (code, etc) do you have that you plan to continue using? Which tools were are those artifacts based on? The existing artifacts may include custom developed or packaged software, and may be currently in use or planned to be introduced as part of the project.

This is a lower priority because rewriting existing artifacts in a consistent way might not be better for initial development, but is definitely better for ongoing customization, extension, and maintenance. While this may seem expensive and difficult, there are various factors that make it easier than writing the original code:

  • existing artifacts represent a detailed specification that includes business and technical details, and nuances that would otherwise need to be defined or made up along the way
  • more junior developers can work on re-writing the code than were involved with the original
  • less risk involved in rewriting than was originally there for the initial design and build


As projects and teams get larger and go on longer a comprehensive and well organized set of tools can make the difference between costs growing exponentially and smooth sailing with minimal surprises as new requirements arise or changes are needed.

The Moqui Framework is based on a decade of experience designing the tools of the Apache OFBiz Framework using real-world business application requirements, and actually using those tools to build a system with a set of artifacts that have been reused and built on to create thousands of custom systems and dozens of open source and commercial derivative works. All of this was driven by people who do customization for a living, so tools that facilitate customization were a high priority.

So why Moqui? As OFBiz and the community around it grew in size it became more difficult to make dramatic changes to the framework and tools used in the project. Ideas kept coming about ways to improve things, organize artifacts better, use convention over configuration, get rid of redundant and unused tools, and generally make things more consistent. The Moqui Framework is the result of all of these experiences and ideas, combined into innovative and fresh ways to build the best applications in the shortest time and with the easiest to maintain artifacts.

ControlServlet, widgets (screen, form, menu, tree):

These tools are now all combined into the Moqui XML Screens.

There are no explicit menus and instead there are subscreens and a menu is automatically generated from the set of subscreens in a screen.

Instead of using the decoration pattern the XML Screens use subscreens to compose an hierarchy of screens. The subscreens for a screen can be configured in three different ways for different purposes including: a directory structure plus defaults for a normal screen/subscreens hierarchy, an XML element to include screens from other applications or that aren't in any application, and a database table that allows add-on component to add a subscreen to an existing screen somewhere else.

It is not an option to have multiple XML Screens in a single file. Each file represents a single screen to make it easier to see what an application looks like just by browsing the directory structure, kind of like it is for webapps with normal templates and such.

Forms and trees are kept in separate files and are simply in-lined in a screen. It is possible to refer to forms externally using the screen's file location and the name of the form.

The widgets don't have any style attributes that will be used for HTML class attributes. There are id attributes in various places, but the intent is to use automatic id and class elements based on names and types of elements in the XML Screens and then keep all of the styling in an external CSS file.

There aren't any AJAX- and HTML-specific elements and attributes. This goes back to the original intent of the OFBiz widgets and that is to be purely declarative and platform independent. Many XML Screens elements will be implemented using AJAX and DHTML, and options to control those or add to them will be available.

MiniLang simple-methods, screen/form/etc actions

All operations from these various places are combined in one XSD file and are referred to as XML Actions. These are included in various places using the "actions" and "condition" elements. With this approach there is no inconsistency for similarly named and designed operations or conditions.

Moqui XML Actions don't have operations that are not frequently used and some operations are like a combination of various simple-method operations. There are operations for a few additional things as well, like producing and consuming XML.

Some operations that are inconsistent in different places in OFBiz, like calling a service, have all similar features combined into one far more useful operation.

There is no performFind service needed in Moqui as the entity-find operation has an element that takes its place, and can be combined with various other elements of a find by condition for a great deal of flexibility that is easily usable.

The actions are available in many more places including ECA rules, screen transitions (like the OFBiz controller request events), and others.

Service definitions and implementations

The OFBiz Service Engine is most like the Service Facade in Moqui. There are many other facades, and for more info see the API Structure section below.

Service names are split into verb and noun parts, which together make up the service name (ie like: ${verb}${noun}). Services are called with the combined name and can separate the verb and noun parts of it using a hash mark ('#'). Services are also organized by path just like Java classes to facilitate lazy loading and to better organize code. The full name of a service will follow a pattern like: "${path}.${verb}${noun}".

Service parameters in Moqui are like the service attributes in OFBiz.

Service parameters are split into two groups: "in-parameters" and "out-parameters" so that parameters with the same name can have different settings going into or coming out of the service.

Parameters in Moqui have hierarchical sub-types for map and collection types.

Parameters have a fairly complete set of validation tags. Those validation tags will be used for server-side validation when the service is called, AND when the service is a target on a screen transition it will be used to generate client-side validation in JavaScript. This validation is defined once but run in both places.

As mentioned above XML Actions are available in many places, and one of those places is inside a service definition. With this a service implementation can be inline inside the service definition or external depending on preference.

Entity Engine

The OFBiz Entity Engine is most like the Entity Facade in Moqui. There are many other facades, and for more info see the API Structure section below.

Entity definitions are more streamlined and don't have the less useful attributes and elements. Primary key fields are designated with an attribute on the field element instead of using a separate element. The data type dictionary in Moqui is more simple and better organized than in OFBiz and the data types available are declared in the XSD for auto-completion help.

The API for dealing with entity values and for queries and such is much more simple, streamlined, and in a few small cases has additional functionality. The methods have far more consistent names than in OFBiz, using create/update/delete everywhere instead of things like store or remove.

Moqui does not have a concept of multiple delegators so the Entity Proxy configuration file is much more simple. The datasource elements are also far more simple because all of the database-specific settings are now in the database configuration file along with the data type dictionary (combined in one file instead of a separate file for each database).

API structure

The Moqui API is clearly separate into interfaces and implementations of those interfaces. Applications only need to worry about the interfaces part of the Java code and not the underlying implementation.

All tools in the Moqui framework are available through the ExecutionContext object, which is created and attached to a thread for each web request, remotely called service, etc. It keeps the current context for whatever is running and has a series of facades for each tool in the framework, including for sevices, entities, screens, localization, logging, caching, user info and preferences, and so on. Some of the implementations of these interfaces will be reusable from one thread to another, and others will be created for each thread.

The API is designed to take advantage of some of the syntax short cuts in Groovy such as using the dot syntax to start with the Moqui static object and get down to whatever part of the API you need.

Configuration and code layout

In Moqui the framework is one big happy set of tools that work together. There is no attempt to separate the tools or make them useful on their own. That was goal at first with OFBiz, but never really worked out very well and splitting the framework into components caused more difficulty than it helped things. So, in Moqui it's all one big framework, and one that can be easily compiled and deployed and so on. The basic idea is that the framework jar files (api and implementation) on the classpath plus the locaiton of the runtime directory are all you need to get started. Components can be loaded through an API or configuration.

Configuration files are meant to come from a runtime directory and are not spread around the code. There is a default-conf directory in the framework so that if a configuration file is left out the framework will have a default to fallback on that will work in most cases.

While Moqui supports multiple webapps, the normal deployment mode is be as a single big webapp with screen trees from add on components mounted on a certain path within the big webapp.

Content management

Instead of a set of entities and services for content management that are part of the project Moqui uses the JCR 2.0 interfaces (and by default the Apache Jackrabbit implementation) for content management. Anywhere there is a "location" in the API or XML files it can have a prefix of "content://" to access something from the JCR. This means that code and templates and such can go there as well.

Security: authorization

Moqui uses a set of entities to define user groups, artifact groups, and permissions for a group of users on a group of artifacts. These are external settings and support record level permissions too. With this approach there is no need make the artifacts responsible for permission checking, and no code changes are required to change permissions when customizing or maintaining or supporting an application.

There is a tarpit, like the idea in OFBiz, that uses the same model as the permissions for reduced redundancy and more features.

I18n and L10n

Internationalization is implicit everywhere in Moqui using natural text in the default language for a key instead of an artificial identifier. This reduces redundancy and effort. The localized labels are in a database table instead of an XML file to perform better (only lookup and cache labels that are used) and to support per-instance localizations in a multi-instance environment.