If you run abas ERP and want live reporting, a tablet app for the floor, or an AI assistant that can actually answer questions about your orders, the first decision is not which tool to buy. It is which way into abas each job should use. abas gives you several: EDP, the REST API, abas Connect, SOAP, and scheduled exports. Pick the wrong one and reports crawl, or a write skips the validation your business depends on.
This is how we choose when we build on abas. It is the third piece in our series on ERP access paths, after Epicor BAQ vs REST vs Excel exports and Made2Manage Web API vs SQL.
The short answer#
- Reporting and dashboards: point them at a SQL database kept in sync with abas, not at abas itself.
- Apps, automations and AI that need to write: go through a supported abas interface (EDP or the REST API) so abas core logic, your customizations and validation run on every write.
- AI assistants and chatbots: build on the REST API where it is available, because it returns data the way your abas client sees it.
- Older installs without API access: start with scheduled exports. Answers are only as fresh as the last export, and that still beats waiting days for a report.
Why reporting straight against abas crawls#
Reporting against the abas database is slow. Run a margin-by-customer report against the live system and you wait.
So we keep a SQL database in sync with abas and point reports and dashboards at that copy instead. The numbers come back in seconds and the reporting load never lands on abas. That is what makes a live wall-screen dashboard of backlog, throughput, on-time delivery and margin by job practical, refreshing on a schedule you set rather than a deck somebody rebuilds every Friday.
The synced copy is for reading. Nothing writes back into abas through it.
EDP: doing the work the way your people do#
EDP is the interface abas provides for doing real work: posting transactions, querying the database and running Infosystems. Because it goes through abas rather than around it, abas's own rules and validation still apply.
That is why we trained our AI on EDP and on the abas database itself. We built our own tools and ran them against the real database, over every table and field, until the AI could find things reliably, including knowing which copy to trust when the same fact lives in more than one place.
The abas REST API: real-time reads and writes with your logic intact#
abas has something most ERPs do not: a REST API that runs the ERP core logic and your company-specific customizations on every call. For anyone building on top of abas, that matters a lot.
- A floor tablet app where an operator clocks a job, flags a scrap part and uploads a photo can post back through the REST API, and abas core logic and your customizations run exactly as they do in the client.
- An AI assistant reading through the REST API sees your abas, not stock abas: your custom fields, your screens and the FOP logic somebody wrote years ago. Generic connectors reading raw tables have no idea what those mean.
That is why it makes a good base for an MCP server. MCP (Model Context Protocol) is the open standard that lets assistants like Claude, ChatGPT or Copilot query a real system. An MCP server over the abas REST API describes what the assistant may ask for and answers from live data, with every request scoped and logged. It is read only by default, and each write is turned on deliberately.
abas Connect and SOAP#
abas Connect handles routed message exchange between abas and other systems. It fits when you are wiring abas into the rest of your stack, such as CRM, shipping, EDI and accounting, so an order entered once shows up everywhere it should. SOAP is there for older systems.
Both are supported interfaces, which matters at upgrade time: an upgrade changes what sits behind the interface, not the interface itself.
Scheduled exports: slower, but they work almost anywhere#
When the REST API is not available on your install or licensing, scheduled CSV, XML, JSON or XLSX exports still support reading. Reports, dashboards and even an AI assistant can work from them. The trade-off is freshness: answers are as current as the last export, not live. We check what your version and licensing actually expose on the first call.
Side by side#
- Synced SQL copy: refreshed on the schedule you set; read only; keeps reporting load off abas; best for reports and dashboards.
- EDP: live; runs abas rules and validation; best for posting transactions, querying and running Infosystems.
- abas REST API: real time; runs core logic plus your customizations on every call; best for custom apps, MCP servers, chatbots and agents.
- abas Connect: routed message exchange; best for integrations with CRM, shipping, EDI and accounting.
- SOAP: for older systems that already use it.
- Scheduled exports: as fresh as the last export; read only; best for older installs without API access.
What we will not do#
- We do not modify your abas core. What we build sits alongside it, so your next upgrade is not something it has to survive.
- We do not write straight into tables. Writes go through a supported abas interface so validation, your customizations and the audit trail still run.
- We do not enable writes by default. New connections start read only.
- We do not hold your data. Everything is deployed to your infrastructure and your accounts, and your abas data is not sent anywhere for training.
- We do not need you to change abas versions, licenses or modules to start.
Talk it through with us#
If you want a second set of eyes on which path fits your install, book a 30-minute fit call and bring your abas version and the questions people keep digging through exports to answer. You can also see what we build on abas ERP and abas AI.