# Infor M3 EXPORTMI Extraction Call Volume Calculator

> Source: https://netray.co/tools/infor-m3-exportmi-extraction-call-volume-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Plan paged extracts from M3 through EXPORTMI or Lst transactions: calls per run, elapsed minutes and daily call volume under a record cap.

## Category

developer

## Erp

Infor M3

## Audience

- M3 developer
- Integration developer
- Data engineer

## Tool

**Kind:** calculator

**Inputs:**

#### Records to extract

**Key:** recs

**Type:** number

**Default:** 250000

**Min:** 1

**Step:** 1000

**Unit:** records

#### Record cap per call

**Key:** cap

**Type:** number

**Default:** 10000

**Min:** 1

**Step:** 100

**Unit:** records

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

#### Safety margin below cap

**Key:** margin

**Type:** slider

**Default:** 10

**Min:** 0

**Max:** 50

**Step:** 5

**Unit:** %

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

#### Latency per call

**Key:** lat

**Type:** number

**Default:** 4

**Min:** 0.1

**Step:** 0.5

**Unit:** seconds

**Help:** Measure with a real call on your system.

#### Parse and write time per 1,000 rows

**Key:** parse

**Type:** number

**Default:** 0.5

**Min:** 0

**Step:** 0.1

**Unit:** seconds

#### Parallel workers

**Key:** workers

**Type:** number

**Default:** 2

**Min:** 1

**Step:** 1

**Unit:** workers

#### Runs per day

**Key:** runs

**Type:** number

**Default:** 4

**Min:** 1

**Step:** 1

**Unit:** runs

**Outputs:**

#### Rows per call

**Key:** rpc

**Expr:** floor(cap * (1 - margin / 100))

**Format:** integer

#### Calls per run

**Key:** calls

**Expr:** ceil(recs / rpc)

**Format:** integer

**Primary:** true

#### Elapsed minutes per run

**Key:** mins

**Expr:** (calls * lat + recs / 1000 * parse) / workers / 60

**Format:** minutes

**Primary:** true

#### Calls per day

**Key:** daily

**Expr:** calls * runs

**Format:** integer

**Chart:**

#### Calls and minutes vs records

**Type:** line

**X:** recs

**From:** 10000

**To:** 2000000

**Steps:** 40

**Series:**

- calls
- mins

**Disclaimer:** 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.

## Content

**Intro:** 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.

**Sections:**

#### Why a per-call cap forces paging

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

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

**Faq:**

#### How does pagination work with the Infor M3 API?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

infor m3 api pagination, infor m3 api, exportmi 10000 records, m3 exportmi select, cms100mi record limit, mdbreadmi, m3 data extraction

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json