Developer ToolsFree calculatorPDF, Excel, Word exportInfor M3All Infor M3 tools

Infor M3 EXPORTMI Extraction Call Volume Calculator

This calculator plans a paged extract from Infor M3 13.x through EXPORTMI or a list (Lst) API transaction when each call returns at most a fixed number of records. It gives the number of calls per run, the elapsed time with parallel workers and the daily call volume.

Your numbers

records
records

Infor announced a 10,000 record limit per transaction for EXPORTMI and CMS100MI; set your own value for your M3 level and API.

10 %

Page size below the cap so a key range never silently truncates.

seconds

Measure with a real call on your system.

seconds
workers
runs

Your results

Calls per run
28
Elapsed minutes per run
2 min
Rows per call
9,000
Calls per day
112

Latency and parse time are inputs to measure. Paging only works when each call covers a key range on an index; the cap and paging behaviour depend on your M3 level and fixes.

Save results:

Calls and minutes vs records

Sweeps Records to extract from 10000 to 2000000, holding your other inputs fixed.

Get your M3 extract design reviewed

Send us the tables, volumes and timing you need and we will suggest the paging or Data Lake design that fits.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

Why a per-call cap forces paging

Infor announced that EXPORTMI and CMS100MI transactions are limited to 10,000 retrieved records per transaction, and recommends Data Lake for large extracts. For an on-prem 13.x level, check the behaviour on your system and set the cap input accordingly. If a call hits the cap, you get exactly the cap and no error, so the extract silently loses rows: that is why the calculator pages below the cap by a safety margin.

  • Rows per call = cap x (1 - margin)
  • Calls = ceil(records / rows per call)
  • Minutes = (calls x latency + records / 1000 x parse time) / workers / 60

Key-range paging

Page on the primary key or an index: each call selects rows where the key is greater than the last key returned, ordered by that key, and you stop when a call returns fewer rows than the page size. For M3 tables the company field (for example CONO) is the leading key, so include it in every condition. MDBREADMI transactions read a table through a defined index and return list records, which makes key-range paging straightforward when the index matches your filter. Avoid offset-style paging on unindexed selections.

Worked example

250,000 records with a cap of 10,000 and a 10 percent margin gives 9,000 rows per call, so 28 calls. At 4 seconds per call that is 112 seconds, plus 125 seconds to parse 250 thousand rows, about 237 seconds; with 2 workers about 2 minutes per run, and 112 calls per day at 4 runs. At 2 million records it becomes 223 calls and about 16 minutes per run, the point at which Data Lake or a database replica is usually the better design.

Common mistakes

Do not page on a field that is not unique: rows with the same value straddle pages and are lost or duplicated, so add the remaining key fields to the order. Do not run many workers against the production M3 at peak hours; extraction competes with users. Check that the last page is smaller than the page size before you stop, and log row counts per page so a truncated page is visible.

Frequently Asked Questions

How does pagination work with the Infor M3 API?

M3 MI transactions do not have a generic page token. You page yourself: request rows above the last key you received, ordered by that key, with a maximum record count, and repeat until a call returns fewer rows than requested. This calculator tells you how many such calls an extract needs.

Why does EXPORTMI return only 10,000 records?

Infor announced a limit of 10,000 retrieved records per transaction for EXPORTMI and CMS100MI and recommends Data Lake for bulk retrieval. If you receive exactly 10,000 rows, assume the result is truncated and narrow the selection by key range.

Should I use EXPORTMI, MDBREADMI or a custom list API?

MDBREADMI reads a table through a defined index and is efficient for key-range paging. EXPORTMI accepts a free selection and is convenient for ad hoc extracts but is capped. Custom list APIs built in CMS100 suit fixed business views. For large repeated extracts, Infor points to Data Lake instead.

How do I measure latency per call?

Time a representative call from the same server that will run the extract, with the same page size and selection, at the hour the job will run. Repeat it several times and use the average. Network distance to the M3 server can matter more than the query itself.

If you want people to query M3 data in plain English on your own servers without building more extracts, we can set that up.

ArchRay builder
Design the on-prem AI stack for Infor M3: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring