Hi all, I created a parent Jira ticket for BOM management PWA app along with APIs and services in manufacturing component of OFBiz.
https://issues.apache.org/jira/browse/OFBIZ-13466 This ticket has two child tickets: one for building the PWA app and one for building the APIs and services in the manufacturing component of OFBiz. App will be based on design : https://www.figma.com/design/1wantteXXUlzPRYev1X5gr/Ionic-8-Material-UI-Kit--Community---Community-?node-id=36313-1243&t=5yG89NEbeUgemZgH-1 I also shared this design in a another email. I am sharing it again here for your reference. Thanks -- Divesh Dutta www.hotwaxsystems.com On Fri, May 22, 2026 at 8:54 PM Divesh Dutta <[email protected]> wrote: > 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 >> > > >> >
