Hi all, I created a Jira ticket for query services regarding Production Run Data: https://issues.apache.org/jira/browse/OFBIZ-13422
Similarly we can create Jira tickets for querying routing and BOM data. Thanks Divesh Dutta -- www.hotwaxsystems.com On Mon, May 18, 2026 at 11:25 AM Divesh Dutta < [email protected]> wrote: > > Hi all, > > After further consideration of the proposal, I suggest a small adjustment > to the approach. > > Instead of immediately starting with a new plugin repository, I think it > may be better to begin by strengthening the core Manufacturing component > itself. > > Today, Manufacturing already contains a lot of business logic, but in many > places the data retrieval logic is still scattered and not exposed as > reusable services. > > For example: > > > - We currently lack services like getProductionRun that return a > complete production run view (tasks, status, produced items, etc.). > - We do not have wrapper services for functions like getAllRoutings. > - We lack dedicated services to retrieve routing tasks for a > production run. > - We do not offer services such as getProductBom for retrieving a > product's BOM structures. > > > My proposal is to first contribute such core fetch/query services directly > into the Manufacturing component. This offers several advantages: > > > - Existing Manufacturing users benefit immediately. > - These services become reusable building blocks. > - Later we can expose them through REST APIs. > > > UIs, AI agents, or future plugin applications can then consume those APIs. > > So the revised approach would be: > > Step 1: Contribute missing Manufacturing services to the core component. > Step 2: Expose them as REST APIs. > Step 3: Build PWA applications using those APIs. > Step 4: Explore agentic and AI-driven workflows. > > Steps 3 and 4 can be done in parallel. > > This still aligns with the larger modernization discussions around > API-first architecture, headless applications, and better separation > between framework and applications, but starts with incremental > improvements inside Manufacturing. > > Would love to hear thoughts on this approach. > > Thanks > Divesh Dutta > -- > www.hotwaxsystems.com > > > > On Thu, Mar 12, 2026 at 10:49 AM Ashish Vijaywargiya < > [email protected]> wrote: > > > > +1 for this idea. Thank you, Divesh, for sharing. > > > > I think this enhancement will be a big help for the community as well as > > for the Apache OFBiz project. > > > > -- > > Kind Regards, > > Ashish Vijaywargiya > > Vice President of Operations > > *HotWax Systems* > > *Enterprise open source experts* > > http://www.hotwaxsystems.com > > > > > > > > On Wed, Mar 11, 2026 at 1:23 PM Divesh Dutta < > [email protected]> > > wrote: > > > > > Hi everyone, > > > > > > Over the past few weeks we’ve had some very valuable discussions on the > > > mailing list about the future direction of Apache OFBiz, including > topics > > > such as modularization, API-first architecture, and making applications > > > more independent from the framework. > > > > > > Several people have pointed out that while Apache OFBiz has strong > > > capabilities, the current codebase still behaves largely as a > monolithic > > > system. Ideas such as gradually separating subsystems, improving > boundaries > > > between components, and enabling more modular deployment models have > come > > > up repeatedly. > > > > > > I wanted to propose a practical experiment that could help us explore > these > > > ideas concretely. > > > > > > > > > *Proposal: A New Headless, API-First Manufacturing Application* > > > The idea is to build a new Manufacturing application as a plugin in the > > > OFBiz plugins directory. > > > > > > This new application would aim to replicate the functional > capabilities of > > > the existing Manufacturing component, but with a modern architecture > > > approach: > > > > > > > > > - API-first > > > - Headless > > > - Framework-independent application layer > > > - PWA-based user interface > > > > > > > > > The goal is not to replace the current manufacturing component > immediately, > > > but rather to create a working reference implementation that > demonstrates > > > how modern OFBiz applications could be built going forward. > > > > > > This could help illustrate how OFBiz can operate as: > > > > > > > > > - A backend enterprise automation framework > > > - with applications built as modular plugins > > > - and UI layers decoupled from the backend > > > > > > > > > > > > > > > *Why Manufacturing?* > > > We recently documented the Manufacturing application and its workflows, > > > contributing them to the OFBiz wiki. This process gave us a solid > > > understanding of the domain. > > > > > > Because of this domain knowledge, Manufacturing felt like a good > candidate > > > for a reference implementation that could help validate architectural > ideas > > > while also producing something useful for the community. > > > > > > > > > > > > *Proposed Phases* > > > To keep the scope manageable, the work could be broken into incremental > > > phases. > > > > > > > > > > > > *Phase 1 — API-First Backend* > > > In the first phase: > > > > > > > > > - Reuse the existing manufacturing services where possible. > > > - Expose those services as REST APIs. > > > - If any workflows currently rely on events, convert those flows > into > > > services that can also be exposed via REST. > > > - Test complete manufacturing workflows purely through the APIs to > > > ensure the logic behaves correctly. > > > > > > > > > This phase would effectively produce a fully API-driven manufacturing > > > backend. > > > > > > > > > > > > > > > *Phase 2 — Headless PWA UI* > > > Once the APIs are stable: > > > > > > > > > - Build a Progressive Web Application (PWA) as the UI layer. > > > - The UI will communicate only through the REST APIs. > > > - Validate full workflows through the new UI. > > > > > > > > > This phase would demonstrate how headless OFBiz applications can work > in > > > practice. > > > > > > > > > > > > *Phase 3 — Agentic / AI Experiments* > > > In a later phase, we could experiment with agentic workflows, where AI > > > agents interact with the system through APIs. > > > > > > This could include: > > > > > > > > > - Agents invoking OFBiz services > > > - Workflow automation through LLM-driven interfaces > > > - experimenting with emerging agent frameworks > > > > > > The goal here would be to explore how OFBiz can integrate with > AI-driven > > > automation systems. > > > > > > > > > *Why This Could Be Valuable for the Community* > > > This effort could serve as a living example of several modernization > ideas > > > we have been discussing: > > > > > > > > > - API-first OFBiz applications > > > - Headless architecture > > > - Plugin-based applications > > > - Clearer separation between the framework and application layers > > > - modern UI approaches such as PWA > > > > > > > > > It would also give developers a reference implementation showing how to > > > build modern applications on top of Apache OFBiz. > > > > > > > > > *Development Approach* > > > To keep the process flexible and non-disruptive: > > > > > > > > > - I will initially start development in a personal GitHub > repository. > > > - Once the architecture stabilizes and the community finds the > direction > > > useful, we could discuss merging it into the OFBiz plugin > repository. > > > - I will also create a parent JIRA ticket for this initiative so > that > > > tasks can be tracked and broken into smaller child tickets. > > > > > > Additionally, I plan to create a requirements document describing the > > > manufacturing workflows that the new application should support. That > > > document can serve as the baseline for development and discussion. > > > > > > > > > > > > *Request for Feedback* > > > I’d really appreciate feedback from the community on this idea. > > > > > > Some questions that may be useful to discuss: > > > > > > > > > - Does building a reference application plugin feel like a useful > way to > > > explore modernization ideas? > > > - Are there architectural considerations we should keep in mind > from the > > > start? > > > - Are there other areas where this approach could be useful? > > > > > > > > > My hope is that this can become a collaborative experiment that helps > us > > > better understand how Apache OFBiz can evolve while still respecting > the > > > existing codebase and community practices. > > > > > > Looking forward to hearing your thoughts. > > > > > > Thanks > > > -- > > > Divesh Dutta > > > www.hotwaxsystems.com > > > >
