Apache OFBiz architecture combines a web MVC framework, reusable business services, a shared enterprise data model, interface tools, and component-based applications. These architectural layers provide the technical foundation for implementing and extending OFBiz as an ERP system or custom enterprise application.
This guide explains the core Apache OFBiz architecture, how requests and business data move through the framework, and how architectural decisions affect implementation, customization, deployment, and future maintenance. For a broader platform introduction, see our Apache OFBiz overview guide.
How Apache OFBiz Architecture Works
At a high level, OFBiz separates request routing, business logic, data access, interface rendering, and application functionality into connected framework layers. This separation allows services, entities, screens, and custom components to be reused across multiple business applications.
This flow is configurable. Depending on the request mapping, OFBiz may invoke an event, execute a reusable service, access enterprise data through the Entity Engine, render a widget screen, or return an integration response.
The official Apache OFBiz developer manual provides detailed technical documentation for developers working with these framework systems.
Core Layers of Apache OFBiz Architecture
Each layer of the OFBiz architecture has a distinct responsibility, but the layers work together through shared services, entities, and component configurations.
| Architecture Layer | OFBiz Mechanism | Primary Responsibility |
|---|---|---|
| Request handling | Control Servlet and controller mappings | Routes requests to events, services, views, and response handlers |
| Business logic | Service Engine | Executes reusable operations, business rules, and transaction logic |
| Data access | Entity Engine | Manages entities, relationships, queries, and database persistence |
| Presentation | Widget System and templates | Renders screens, forms, menus, and application views |
| Application structure | Components and plugins | Organizes applications, services, entities, interfaces, and extensions |
| Integration | Services and integration interfaces | Connects OFBiz processes and data with external applications |
How These OFBiz Systems Work Together
When a user or external application submits a request, the OFBiz web layer routes it through the Control Servlet. Request mappings defined in the component's controller configuration determine whether the request calls an event, service, or view.
Business logic can then be executed through the Service Engine, while the Entity Engine retrieves or updates enterprise data. Results may be returned through an OFBiz widget screen, API response, integration, or another application interface.
Example of an OFBiz Request Flow
Consider a request to /accounting/control/findInvoices. The web application directs the request to the Control Servlet, while the component’s controller.xml identifies the matching request map. The mapping may invoke an event or service and then select a view map.
If invoice data is required, the event or service retrieves it through the Entity Engine. The selected widget screen then prepares and renders the response.
Request flow:
URL → Control Servlet → controller.xml request map → Event or Service → Entity Engine → View Map → Widget Screen → Response
Not every request passes through every architectural layer. Depending on the controller configuration, a request may invoke an event, call a service, retrieve or update data, redirect to another request, or render a view.
Entity Engine and Shared Enterprise Data
The Entity Engine provides database abstraction and data persistence across Apache OFBiz applications. Instead of placing database-specific SQL throughout the codebase, developers define business entities for products, parties, customers, orders, inventory items, shipments, invoices, payments, and other enterprise records.
OFBiz services and applications use the Entity Engine to create, retrieve, update, and relate these records through a shared enterprise data model. This allows processes such as order management, inventory control, fulfillment, invoicing, and accounting to operate on connected business data.
Service Engine and Business Logic
The Service Engine manages reusable business logic and coordinates operations between user interfaces, integrations, and enterprise data. Services can perform validation, apply business rules, manage transactions, update records through the Entity Engine, and return structured results.
The same service can be called from an OFBiz screen, an external integration, a scheduled job, or another service. This reduces duplicated logic and helps organizations apply consistent business rules across multiple applications and channels.
OFBiz services can be invoked synchronously when the calling process requires an immediate result or asynchronously when an operation should execute independently. Services can also be scheduled for delayed or recurring execution, allowing the same business logic to support user interfaces, integrations, background processing, and other services.
Events and Services in OFBiz Request Processing
Events and services can both participate in OFBiz request processing, but they serve different architectural purposes. An event commonly handles request-level logic, such as reading parameters or controlling the immediate response. A service represents a reusable business operation that can be called from screens, other services, scheduled jobs, or integrations.
Business rules that may be needed in more than one workflow should generally remain in services instead of being tied directly to a web request. This keeps the logic reusable and prevents different interfaces or integrations from implementing the same operation differently.
Widget System and User Interfaces
The OFBiz Widget System renders native user interfaces using reusable screens, forms, menus, trees, layouts, and other interface elements. Screen definitions can prepare data, apply conditional logic, include forms and menus, and render output through templates and themes.
Organizations can use the native Widget System for administrative and internal applications or connect a separate frontend to OFBiz services and enterprise data. In this arrangement, OFBiz remains responsible for business rules and connected records while the external application manages the user experience.
Components and Plugins
Components are the primary organizational units used to structure Apache OFBiz applications. A component can contain entity definitions, services, business logic, web applications, request routing, widgets, configuration files, data, and tests.
Core OFBiz applications and optional plugins follow this component-based structure. Custom functionality can therefore be placed in dedicated components or plugins instead of being added directly to the core framework, helping reduce conflicts during maintenance and future version upgrades.
How Transactions and Permissions Cross OFBiz Layers
Authentication and authorization should not depend only on whether an action is visible in the user interface. Request mappings, services, administrative functions, scheduled processes, and integration endpoints may each require appropriate security controls. A user who cannot see an action on a screen should not be able to perform the same operation by calling the underlying request or service without authorization.
Transaction boundaries are equally important. A service may update an order, reserve inventory, generate an invoice, or call related services as part of one business operation. The implementation must define which changes should succeed or fail together so that a partial error does not leave connected records in an inconsistent state.
Keeping permission checks, validation, and transaction behavior close to reusable business operations helps the same rules apply whether the operation originates from an OFBiz screen, another service, a scheduled job, or an external application.
Apache OFBiz Integration Architecture
An Apache OFBiz implementation may need to exchange data with ecommerce platforms, payment systems, warehouse applications, shipping providers, customer portals, reporting tools, or other enterprise systems. The integration architecture should define which system owns each record, which operations remain inside OFBiz, and how updates move between systems.
Where practical, external applications should interact with reusable OFBiz services instead of writing directly to the underlying database. Using the service layer allows OFBiz business rules, validation, permissions, and transaction behavior to remain part of the operation.
Integration planning should define:
- The source of truth for customers, products, orders, inventory, and financial records
- Whether each data exchange is synchronous, asynchronous, scheduled, or event-driven
- How external identifiers map to OFBiz entities
- How failed requests, duplicate messages, and partial updates are handled
- Which services and components own the integration logic
- How authentication, authorization, logging, and monitoring are managed
Clear integration boundaries reduce duplicated business logic and help prevent different systems from producing conflicting versions of the same enterprise data.
Architecture Decisions Before an OFBiz Implementation
The architecture should then define component boundaries, data ownership, service responsibilities, user roles, integration points, security controls, reporting requirements, and expected transaction volume. These decisions influence how easily the implementation can be tested, maintained, and upgraded.
For a complete process covering requirements, module selection, customization, data migration, testing, and deployment, read our guide to building and implementing a custom ERP system with Apache OFBiz.
OFBiz Runtime and Deployment Architecture
Apache OFBiz runs as a Java application and includes Apache Tomcat as its web container. The runtime combines web applications, framework services, entity operations, scheduled processes, and plugins within the OFBiz environment.
Deployment architecture should account for interactive requests, background services, integrations, scheduled jobs, reporting workloads, database activity, and availability requirements.
A smaller implementation may run within one application environment, while a higher-volume system may separate application workloads, background processes, reporting, and database resources. Development, testing, staging, and production environments should remain separate so that code, configuration, and data changes can be validated before release.
Keeping a Custom OFBiz Architecture Maintainable
A maintainable OFBiz architecture should make component responsibilities, service dependencies, entity extensions, and integration boundaries clear. This makes the implementation easier to test, support, and upgrade as technical and business requirements change. See our guides to Apache OFBiz customization and Apache OFBiz maintenance and support for those topics.
For projects moving from an older release, see our Apache OFBiz 18.12 to 24.09 upgrade guide.
Conclusion
Apache OFBiz architecture is built around connected framework layers rather than isolated ERP modules. The Web MVC framework handles request routing, the Service Engine manages reusable business logic, the Entity Engine provides shared data access, the Widget System renders native interfaces, and components organize applications and extensions.
A successful Apache OFBiz implementation depends on using these layers deliberately. Teams should understand existing entities and services before creating custom functionality, define clear component and integration boundaries, and account for testing, deployment, maintenance, and future upgrades from the beginning.
Need Help With Apache OFBiz Architecture or Implementation?
NOI Technologies helps organizations plan and implement Apache OFBiz environments, including component architecture, custom development, integrations, deployment preparation, testing, and modernization of existing systems.
Explore our Apache OFBiz development and consulting services.
Disclaimer: The views expressed in this article are personal and do not necessarily represent the official position of the Apache Software Foundation or the Apache OFBiz project.
Frequently Asked Questions
What are the main layers of Apache OFBiz architecture?
Apache OFBiz architecture includes request handling through the Web MVC framework, reusable business logic through the Service Engine, data access through the Entity Engine, interface rendering through the Widget System, and application organization through components and plugins. These systems work together across ERP applications, integrations, and custom extensions.
How do the Service Engine and Entity Engine work together?
The Service Engine executes reusable business operations, validation, and transaction logic. Those services use the Entity Engine to create, retrieve, update, and relate enterprise data. Keeping business rules in services allows the same operation to be used by screens, integrations, scheduled jobs, and other services.
Can Apache OFBiz use a separate frontend?
Yes. Apache OFBiz can continue to manage business services and enterprise data while a separate web, mobile, or customer-facing application provides the user interface. The integration should preserve OFBiz validation, permissions, transaction rules, data ownership, and failure-handling requirements.
What is the difference between an OFBiz component and a plugin?
Components organize OFBiz functionality such as entities, services, web applications, widgets, configuration, and tests. Plugins follow the component structure but are added separately to extend the standard environment. Project-specific functionality is commonly organized in plugins or dedicated components instead of being placed directly in core framework code.