Infor M3 Technical Architecture Explained Layer by Layer
Infor M3 is a Java-based ERP whose core is the M3 Business Engine, deployed as applications inside the Infor Grid runtime and backed by a relational database such as DB2 for i, SQL Server, or Oracle. Around that core sit the H5 browser client, the MI API layer, M3 Enterprise Collaborator for messaging, Event Hub for change events, and Infor OS services including ION, Infor Document Management, and Ming.le. Knowing which tier owns which responsibility is the difference between a clean extension and a modification you pay for at every upgrade.
M3 Business Engine and the Infor Grid Runtime
The M3 Business Engine holds all transactional logic: order entry, allocation, planning, costing, and posting. It does not run as a monolithic service. Instead, the Infor Grid hosts it as a set of grid applications distributed across nodes, with routers handling session affinity, a registry tracking node health, and grid agents starting and stopping JVMs on each host. Interactive sessions, batch jobs, and API requests are served by different node types, which is why sizing a batch-heavy month-end differs from sizing peak order entry. Administrators work almost entirely through the Grid Management Pages: node counts, JVM heap, thread pools, log levels, and application binding all live there rather than in an M3 program.
- Separate interactive, batch, and API node groups so a long MRP run cannot starve order entry sessions
- Watch JVM heap and garbage collection per node before adding hardware; most M3 slowdowns are configuration, not CPU
- Keep the grid registry and routers on their own hosts in production for clean failover
- Use grid log levels selectively; leaving debug on across all nodes can add measurable request latency
The M3 Data Model: Tables, Field Prefixes, and Company Keys
M3 tables use short, stable names and a two-character field prefix per table, which makes SQL against M3 readable once you learn the pattern. MITMAS holds the item master, MITBAL the item-warehouse record, MITLOC the balance identity at location and lot level, and MITTRA the stock transaction history. Sales lives in OOHEAD and OOLINE, purchasing in MPHEAD and MPLINE, manufacturing in MWOHED, MWOMAT, and MWOOPE, and finance in FGLEDG and FSLEDG. Customer and supplier masters are OCUSMA and CIDMAS. Nearly every table is keyed first by company (CONO) and often by division (DIVI), so any report or integration that omits those keys will silently mix entities.
- Always filter on CONO, and on DIVI for financial tables, in every custom query or extract
- Join MITMAS to MITBAL for planning attributes and to MITLOC for physical on-hand by location and lot
- Treat MITTRA as the audit trail for inventory value questions rather than recomputing from balances
- Read directly from the database for reporting, but never write to M3 tables outside the MI API layer
Presentation, Integration, and Infor OS Around M3
The H5 client is a browser front end that talks to the M3 UI Adapter, which in turn drives Business Engine panels. Personalization and JavaScript scripting live here, not in the engine. Integration runs through MI programs, the REST facade over them, Event Hub for publish-subscribe on data changes, and M3 Enterprise Collaborator for EDI and file-based partner messaging. Above that, Infor OS supplies ION for BOD-based document flows between Infor and third-party applications, Infor Document Management for output and archiving, and the API Gateway for OAuth-protected external access. Drawing this map before any project starts tells you where a requirement belongs and prevents teams from solving an integration problem inside the engine.
Environments, Sizing, and Where M3 Performance Actually Goes
A typical on-premises M3 landscape runs at least development, test, education, and production environments, each with its own grid and database. Refreshing test from production is a database copy plus grid reconfiguration, and teams that script it get refresh time down from days to a few hours. Performance problems concentrate in a small number of places: unindexed custom queries against MITTRA or FGLEDG, batch jobs scheduled to overlap with allocation-heavy order entry, oversized picking list runs, and API callers requesting large list transactions without a maximum record limit. Measure at the grid before you buy hardware; in most landscapes the fix is scheduling and query design.
How Netray Maps and Documents an M3 Landscape
Netray AI agents read grid configuration exports, database catalogs, MI API call logs, and script repositories to produce a current-state architecture map in days rather than the four to six weeks a manual discovery normally takes. The agents flag every direct database write, undocumented interface, and orphaned batch job, then rank them by upgrade risk. For aerospace and defense clients who cannot send M3 data to a public model, we run the same agents fully on-premises inside the customer network. Output is a living document set: node topology, interface register, table-level data ownership, and a prioritized remediation list your team can execute.
Frequently Asked Questions
What database does Infor M3 run on?
M3 supports DB2 for i on IBM Power systems, Microsoft SQL Server, and Oracle in on-premises deployments. Many long-standing M3 customers still run DB2 for i because the product descends from the AS/400-era Movex application. In Infor CloudSuite the database is managed by Infor and customers do not choose or administer it directly, which is one reason cloud migrations force teams to replace any direct database access with API-based integration.
What is the Infor Grid in M3?
The Infor Grid is the Java runtime and management layer that hosts M3 Business Engine applications and related services. It handles node startup, routing, session management, load distribution, and logging across one or more servers. Administrators configure node counts, JVM memory, and application placement through the Grid Management Pages. Understanding the grid matters because most M3 performance tuning and high-availability design happens there rather than inside M3 programs.
Can I query M3 tables directly with SQL?
Reading M3 tables directly with SQL is common and supported for reporting, as long as you filter by company and division and understand the field prefix conventions. Writing directly to M3 tables is not supported: it bypasses business logic, allocations, and accounting rules, and it will corrupt data in ways that are expensive to unwind. Use MI API transactions for any create, update, or delete operation.
Key Takeaways
- 1M3 Business Engine and the Infor Grid Runtime: The M3 Business Engine holds all transactional logic: order entry, allocation, planning, costing, and posting. It does not run as a monolithic service.
- 2The M3 Data Model: Tables, Field Prefixes, and Company Keys: M3 tables use short, stable names and a two-character field prefix per table, which makes SQL against M3 readable once you learn the pattern. MITMAS holds the item master, MITBAL the item-warehouse record, MITLOC the balance identity at location and lot level, and MITTRA the stock transaction history.
- 3Presentation, Integration, and Infor OS Around M3: The H5 client is a browser front end that talks to the M3 UI Adapter, which in turn drives Business Engine panels. Personalization and JavaScript scripting live here, not in the engine.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
ERP Database Growth Forecaster
Forecast how large your ERP database will be in one to ten years, what storing it across environments will cost, and how much archiving could save.
Free ToolCapEx Payback and NPV Calculator
Build the payback period, net present value, and lifetime ROI numbers your capital approval request needs for equipment, automation, or ERP investments.
Free ToolERP Disaster Recovery Readiness Assessment
Ten questions on backups, RTO/RPO, restore testing, and failover that score whether your ERP would survive ransomware or a hardware failure.
Terms used in this article
Want an accurate, current map of your M3 landscape before your next upgrade or integration project? Ask Netray for an AI-assisted M3 architecture assessment.
Related Resources
Infor M3 API Integration: MI Programs and REST
Infor M3 API integration guide covering MI programs, the m3api-rest v2 endpoint, ION API gateway OAuth, Event Hub, and error handling for reliable interfaces.
Infor M3Infor M3 Customization vs Modification Strategy
Infor M3 customization vs modification strategy: when to personalize, extend by API, or build a MAK mod, and how to control lifetime retrofit cost per change.
Infor M3Infor M3 Upgrade and CloudSuite Migration
Infor M3 upgrade and CloudSuite migration guide: modification inventory, extensibility rework, data strategy, testing waves, and 9 to 18 month timelines.