How to add AI agents to proALPHA
Short answer
Put a thin tool layer between the agent and proALPHA: read-only queries through the OpenEdge SQL or service interface first, then narrow, approved write-back through proALPHA's own business logic. Run the model on your own GPUs if the data cannot leave the plant.
proALPHA is a mid-market ERP common in German-speaking and wider European discrete manufacturing and machine building. It is built on the Progress OpenEdge platform, which shapes everything about how an agent can talk to it: an OpenEdge database underneath, application logic in ABL, and service endpoints exposed through the OpenEdge application server. Many sites still run it on-prem or in a private hosting setup, often with years of customer-specific extensions.
Teams ask for agents because the repetitive work is obvious: chasing late purchase orders, explaining why a production order is short on material, drafting supplier reminders, checking whether a customer order can still hold its delivery date. An agent does not replace the planner. It does the lookups across Auftrag, Bestellung, Fertigungsauftrag and stock screens that a planner repeats forty times a day, and proposes the next action.
The risk is the same everywhere in ERP: an agent that writes directly to tables bypasses proALPHA's validation, number ranges, authorisations and audit. The design below keeps the model on the outside of that boundary and lets proALPHA remain the only system that changes its own data.
What teams use it for
Late purchase order expediting
The agent lists open purchase order lines past their confirmed date, reads supplier history, drafts a reminder per supplier in German or English, and queues it for the buyer to send.
Shortage explanation on production orders
Given a production order number, the agent walks the BOM and requirements, finds the missing component, shows open supply for it and states which customer orders are affected.
Delivery date check for customer orders
Sales asks whether a requested date holds. The agent reads stock, planned receipts and capacity-relevant open orders and returns a reasoned yes or no with the constraint named.
Master data hygiene
A nightly agent flags items with zero lead time, missing cost, inconsistent units or orphaned BOM components, and opens a review list rather than changing records.
Month-end exception triage
Before close, the agent collects uninvoiced goods receipts, open production orders with booked time and negative stock lines, and groups them by owner for follow-up.
Quote-to-BOM first drafts
For repeat configurations, the agent finds the closest historical BOM and routing, and drafts a variant for an engineer to approve in proALPHA.
proALPHA integration surface
- OpenEdge database: proALPHA data lives in a Progress OpenEdge RDBMS. Read access for analysis is typically through the OpenEdge SQL-92 engine (ODBC or JDBC) on a read-only account against a replica where possible. Table and field names are version and customisation dependent, so map them per installation.
- Application services: proALPHA exposes business logic through OpenEdge application server components and, in current releases, web service or REST style interfaces. The exact interface set and licensing differ by version, so confirm with your proALPHA partner which are enabled.
- Reports and exports: standard list and report outputs, CSV and Excel exports, and scheduled exports give a safe fallback when direct database access is not permitted.
- Events and files: batch jobs, interface tables and file drops are the usual integration pattern in older installations. Agents can poll these rather than require new event infrastructure.
- Users and rights: proALPHA's own user and authorisation model should decide what an agent may see. Use a dedicated service user rather than a named employee.
How it works
- 1
Pick two or three read-only questions
Start with late POs and production shortages. Fixed scope lets you validate answers against what the planner sees on screen.
- 2
Stand up a read replica or reporting copy
Point the agent at a replicated OpenEdge database or a nightly extract so a bad query cannot slow the live ERP.
- 3
Write a tool layer, not free SQL
Expose functions such as get_open_po_lines(supplier, days_late) and get_bom_explosion(item). Each tool has a tested query and returns typed JSON. The model never writes SQL against production.
- 4
Host the model
Use a private open-weight model on your GPUs for data that must stay in-house, or a cloud model under contract where policy allows. The agent loop calls tools and cites the rows it used.
- 5
Add proposals, not writes
The agent produces a draft reminder, a suggested reschedule or a proposed order. It is stored in a review queue with the evidence attached.
- 6
Execute approved actions through proALPHA services
After a human approves, call a proALPHA service or import interface so standard validation and audit run. Never update tables directly.
- 7
Log and evaluate
Record every tool call, answer and approval. Re-run a fixed test set of real questions after each model or schema change.
Example flows
Supplier expedite run
Trigger: Each morning at 06:00
- Tool returns open PO lines more than two days past confirmed date.
- Agent groups by supplier and checks which lines block a production order this week.
- Agent drafts one reminder per supplier, listing only the blocking lines.
- Buyer reviews the queue and sends or edits.
Result: Buyers start the day with a prioritised, pre-written list instead of building it from several screens.
Why is order 4711 late
Trigger: Planner asks in the chat panel
- Agent reads the production order and its component requirements.
- It finds the short component and its open supply with dates.
- It lists the sales orders pegged to the production order.
Result: A cited answer in seconds, with a suggested action the planner can accept or ignore.
Keeping data on-prem
Agents for proALPHA suit on-prem well because the ERP itself is often on-prem. Run the OpenEdge replica, the tool service and an open-weight model (a Llama, Qwen or Mistral class model served with vLLM or Ollama) inside the same network segment, with no outbound path for the model host. Retrieval over documents such as supplier agreements stays in a local vector store. If the plant is air-gapped, ship model weights and updates by controlled media. The main constraint is GPU sizing: planning questions are short, so a single modest GPU server usually covers a few dozen concurrent users, but test with your real tool outputs.
Security checklist
- Dedicated service account with read-only rights on the replica and the minimum proALPHA authorisations.
- Tools enforce row scope by company, plant or client so the agent cannot see more than the asking user.
- Human approval before any write, with the evidence and the exact service call shown.
- Prompt-injection hygiene: text from supplier emails or free-text fields is treated as data and never as instructions to the agent.
- Full audit log of prompts, tool calls, returned rows and approvals, stored outside the model host.
Ways to get it done
Use proALPHA's own assistant or analytics features
Effort: Low, but check what your licence and release actually include.
Enough if you only need reporting inside the standard product and your version includes it.
Build in-house on a tool layer
Effort: Typically several weeks for a first read-only agent, longer for governed write-back.
Fits teams with OpenEdge and ABL skills and a clear short list of workflows.
Work with a partner such as Netray
Effort: A scoped pilot of a few weeks, then extend workflow by workflow.
Fits when you want private on-prem models, a tested tool layer and a proALPHA partner involved for the service side.
Pitfalls
- !Pointing the model at raw OpenEdge tables with generated SQL: customised fields and ambiguous names produce confident wrong answers.
- !Querying the live database during peak planning runs and slowing the ERP.
- !Writing to tables directly, which skips validation, number ranges and audit.
- !Ignoring German and English mixed master data, so item searches miss synonyms.
- !No test set, so a model upgrade silently changes answers.
Frequently asked questions
Can an AI agent read proALPHA data directly?
Yes, usually through a read-only OpenEdge SQL connection to a replica or through exposed services. The safer pattern is a tool layer with tested queries, so the model asks for named functions instead of composing SQL against your production schema.
Does the agent need to change proALPHA data?
Not at first. Most value comes from read-only analysis and drafting. When you add write-back, route it through proALPHA services or import interfaces after human approval so validation and audit still apply.
Which proALPHA versions work?
The approach works across versions because it relies on OpenEdge access and your exposed services. Table names, available interfaces and licensing differ by release and customisation, so the tool layer is mapped per installation.
Can this run without the internet?
Yes. With an open-weight model on local GPUs, a local retrieval index and the tool service inside your network, nothing needs to leave. Updates to models and software can be delivered through controlled transfer.
How is this different from a report?
A report answers a fixed question. An agent chains lookups, explains the cause, drafts the follow-up and waits for approval. It still uses the same data and the same rights, so it should never exceed what the user may see.
Want AI agents working on your proALPHA?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment