The Moqui ecosystem gives developers a structured foundation for building enterprise applications without creating every database operation, business service, user interface, and integration from scratch. It combines the Moqui Framework with reusable business artifacts, application components, development tools, integrations, and community resources.
What Is the Moqui Ecosystem?
The Moqui ecosystem is broader than the core framework alone. The framework provides the technical tools used to define data, execute business logic, create screens, secure application functions, process transactions, manage resources, and connect with external systems.
Above the core framework, Mantle provides reusable business data models, services, screens, and forms for common enterprise processes. Applications can use and extend those artifacts rather than define every business concept from the beginning.
5 Development Concepts for Building With the Moqui Ecosystem
1. Components Organize Application Functionality
A Moqui component is a modular package containing the artifacts required for a specific application or business function. A component may include entity definitions, services, screens, configuration files, templates, security data, and seed data.
For example, an order management component could contain the entities used to store orders, services for creating and updating them, screens for warehouse or customer service teams, and integration endpoints for receiving orders from another platform.
Component-based development helps teams separate business domains instead of placing an entire enterprise application inside one tightly connected codebase. Developers can maintain, test, reuse, or extend individual components while reducing the risk that one change will unexpectedly affect unrelated functionality.
See how these components fit into Moqui's architecture.
2. Entities Define the Application Data Model
Entities represent the business data used by a Moqui application. Developers define entities and their relationships in configuration files, and the Entity Facade provides a consistent interface for creating, reading, updating, deleting, and querying records.
This approach reduces the need to scatter database-specific queries throughout an application. Developers can concentrate on the business meaning of the data, such as products, facilities, inventory balances, orders, shipments, invoices, or customers.
Entity relationships are especially important in enterprise software because a single transaction often affects several parts of the system. A shipment may be connected to an order, warehouse, carrier, package, customer, inventory transaction, and invoice. Defining these relationships clearly makes later service and reporting development easier to manage.
3. Services Contain Reusable Business Logic
Services are used to implement business operations inside the Moqui ecosystem. A service can define its expected inputs, outputs, validation rules, transaction behavior, and implementation logic.
Typical services might create an order, reserve inventory, calculate a charge, approve an invoice, generate a shipment, or update a product record. Because the logic is contained in a service, it can be called from different parts of the application without being rewritten.
The same inventory allocation service, for example, could be triggered from an administrative screen, an ecommerce integration, a scheduled job, or an API request. This separation keeps business rules away from presentation code and makes the application easier to test and maintain.
Developers should avoid placing important business logic directly inside screens or frontend scripts. Keeping the logic within clearly defined services creates a more reliable boundary between the application interface and its underlying processes.
4. Screens and Forms Build Business Interfaces
Moqui screens define how users navigate and interact with an application. Screens can include forms, transitions, actions, subscreens, templates, and content required to support a particular workflow.
A warehouse receiving screen, for instance, might display an expected purchase order, collect received quantities, identify discrepancies, and call a service that updates inventory. The screen handles the user interaction, while the service manages the business rules and the entities store the resulting data.
Moqui applications can support server-rendered screens as well as client-rendered interfaces that communicate with backend services. This means frontend development does not need to depend on one JavaScript library. Teams can select an interface approach that fits the application while continuing to use Moqui for business logic, data access, security, and integrations.
This separation is particularly useful for applications that need several interfaces, such as an administrative portal, customer portal, warehouse handheld interface, and external partner dashboard.
5. Execution Context, Security, and APIs Connect the Application
The Execution Context provides access to the main framework capabilities used during a request or service call. Through it, developers can work with entities, services, screens, resources, localization, caching, messages, users, transactions, and other framework functions.
Moqui also uses artifact-aware security to control access to application functionality. Permissions can be applied to services, screens, entities, and related artifacts instead of relying only on navigation-level restrictions. This is important in ERP applications where finance, warehouse, sales, customer service, and administrative users may require different levels of access.
Web services and REST APIs allow Moqui applications to exchange information with ecommerce platforms, payment systems, warehouse tools, accounting applications, carrier services, and other external systems. Developers can expose controlled service functions through APIs while keeping validation and business logic within the application’s service layer.
Moqui Component Development Example: A Warehouse Transfer Request
Consider a warehouse application that needs a transfer request and approval process. Before writing code, check whether existing Mantle entities and services cover the requirement. Reuse suitable artifacts and add custom functionality for the missing behavior.
Document which existing artifacts the component uses and which requirements need custom entities, services, or screens. This helps the team maintain clear boundaries between reused functionality and project-specific behavior.
The following example outlines how to organize the feature. Creating and approving a request are separate from physically moving inventory, which requires its own operational workflow.
Organize the Component Files
A custom component can group the data definitions, business services, screens, configuration, and security data needed for the feature. The filenames below are illustrative.
| File or directory | Purpose in this example |
|---|---|
component.xml |
Describe the component and declare component dependencies where needed. |
entity/TransferEntities.xml |
Define any additional request data or relationships not covered by existing entities. |
service/transfer/TransferServices.xml |
Define operations for submitting, approving, or rejecting a request. |
screen/TransferRequests.xml |
Provide forms and transitions for viewing requests and performing permitted actions. |
data/ |
Keep the required configuration and security data separate from sample records. |
MoquiConf.xml |
Supply component configuration, including screen integration where required. |
A team can start with an existing application, reuse Mantle business artifacts, or build custom functionality on the Moqui Framework. The appropriate starting point depends on how closely the available workflows match the requirement. Not every project needs every ecosystem component.
Connect the Screen, Service, and Data
- Collect the request: The screen captures the source facility, destination facility, product, quantity, and requested date.
- Validate the operation: A service checks required values, a positive quantity, different source and destination facilities, and access to the relevant records.
- Save the request: The service uses the Entity Facade to persist the request and its initial status. Related changes should follow the operation's transaction requirements.
- Handle approval: A separate operation checks the approver's permissions and the current request status before recording the decision.
- Connect other interfaces: If a handheld application needs the feature, an authenticated API can call the appropriate service using the integration account's permissions.
Test the Feature Before Release
- A valid request creates the expected records.
- Invalid quantities and identical source and destination facilities are rejected.
- A user cannot submit or approve requests for facilities outside their access.
- An approval cannot be repeated or applied to an invalid request status.
- A failed operation does not leave partially saved related records.
- The screen and API enforce the same business rules.
For source examples of entities, services, screens, REST APIs, and tests, explore the Moqui example component.
Common Moqui Development Mistakes
One common mistake is approaching Moqui as though it were only a conventional Java web framework. Writing large amounts of custom Java or Groovy code before evaluating existing entities, services, screens, and framework tools can undermine the main benefits of the platform.
Another mistake is mixing interface logic with business rules. When validation, calculations, or workflow decisions are placed directly inside screens, the logic becomes difficult to reuse through integrations, scheduled jobs, or alternative interfaces.
Developers should also avoid building one oversized component for an entire business system. Dividing the application into logical components can improve code ownership, testing, upgrades, and long-term maintenance.
Planning a Moqui Development Project?
If your team needs help choosing reusable artifacts, building custom components, or reviewing an existing implementation, see Moqui development and consulting services.