Reading Many Records from M3
When a workflow reads a list of records from M3, M3 decides how many records come back. The limit depends on three things:
- The M3 environment: M3 CE (the Infor-hosted cloud edition) or on-premise (on-prem).
- The program and transaction you call, for example the
SearchorSelecttransaction ofEXPORTMI. - The request itself: a list transaction only returns up to the maximum number of records set in the request (
maxReturnedRecords).
This page shows which limit applies when, and what to do when you need more records. Use it together with the M3 API component.
The limits and timeouts on this page are to the best of our knowledge. They come from observed behavior in real integrations and documentation, and they are subject to change. They may also differ between M3 versions and environments. Keep up to date with the release notes from Infor, and always verify the record count in a test run before relying on a large export.
What works when
| Records you need | M3 CE | On-prem |
|---|---|---|
| Up to 1,000 | Any list transaction, including Search | Any list transaction, including Search |
| Up to 10,000 | EXPORTMI Select, or CMS100MI after raising its default in CMS015 | Any list transaction except Search, with maxReturnedRecords set |
| Up to 100,000 | EXPORTMI/Select with a direct index, MDBREADMI, or any other list transaction except Search | Any list transaction except Search, up to the grid maximum (normally 100,000) |
| More than 100,000 | Data Lake | Data Lake |
Search transactions stop at 1,000 records in every environment, no matter which maximum you set. See Search stops at 1,000 records.
Where the maximum comes from
Every list transaction should have the maximum number of records set in the request (maxReturnedRecords). What happens beyond that depends on the environment:
- On-prem: the maximum is also governed by the grid configuration of M3. Normally this is 100,000 records. An M3 administrator can change it.
- M3 CE: the maximum cannot be configured. On top of that, the more generic list APIs have extra limits on how many records they return, which is why the limit differs per program (see the table below).
Limits per program and transaction
| Program and transaction | Environment | Limit | Notes |
|---|---|---|---|
Any Search transaction (e.g. EXPORTMI/Search, CRS610MI/Search) | All | 1,000 records | maxReturnedRecords does not raise the limit |
EXPORTMI Select | M3 CE | 10,000 records by default | Preferred for larger exports |
EXPORTMI Select with a direct index | M3 CE | 100,000 records | For example the query MMITNO from MITMAS00, which reads the item master table MITMAS through its index MITMAS00. Verify the count in your own environment |
EXPORTMI Select | On-prem | The grid maximum, normally 100,000 records | |
CMS100MI | M3 CE | 1,000 records by default, 10,000 at most | The default is defined in CMS015 and can be increased |
MDBREADMI | M3 CE | 100,000 records | |
Any other program and transaction (except Search) | M3 CE | 100,000 records | Applies to every list transaction not named above |
Any other program and transaction (except Search) | On-prem | The grid maximum, normally 100,000 records | Set in the grid configuration. Ask your administrator for the value |
Search stops at 1,000 records
Any Search transaction, for example EXPORTMI/Search or CRS610MI/Search, returns a maximum of 1,000 records. This applies even if you set maxReturnedRecords to a higher value. No error is raised: the call succeeds and returns only the first 1,000 rows, so a result set can look complete when it is not.
If a workflow that reads from M3 returns exactly 1,000 rows when you expect more, this limit is the most likely cause. Use EXPORTMI/Select instead.
Use Select for larger result sets
Select is the EXPORTMI transaction for larger exports:
- On M3 CE,
Selectreturns up to 10,000 records. When the query uses a direct index, you can get up to 100,000 records. Use a direct index whenever you can for large exports. - On on-prem, the limit is the grid maximum, normally 100,000 records.
Ways of limiting the number of records
- Narrow the query. Filter on key fields (for example company, warehouse, or a date range) so each call stays well below the limit.
- Set the maximum deliberately. Set
maxReturnedRecordsin the request to what you expect to need, within the limits above. - Check the count. Compare the number of returned rows against the expected count, for example from a count query in M3, before using the data downstream.
- Check the Max rows setting in Vince. The Max rows setting under Configure execution in the M3 API component controls how many rows the step handles. It does not raise the limit that M3 itself applies. See M3 API component.
Timeouts
A large read can also fail because the call takes too long. A call that is still running when a timeout is reached fails, even if it would have stayed within the record limits. Two timeouts matter. The ION API Gateway timeout comes first, because every call from Vince to M3 depends on it. The Vince Platform timeouts apply on top, depending on the step you use.
ION API Gateway timeout
Calls from Vince to M3 go through the ION API Gateway, which has its own timeout.
| Environment | ION API Gateway timeout |
|---|---|
| M3 CE | 1 minute by default. An administrator can extend it to 5 minutes |
| On-prem | Set by your administrator. The default is likely 2 minutes, but confirm the value with your local administrator |
See the Infor documentation for how the timeout is configured: Infor OS administration: ION API Gateway timeout.
Vince Platform timeouts
| Step | Timeout |
|---|---|
| M3 API step in a High Volume workflow | The timeout risk is the ION API Gateway timeout for extracting records |
| REST API step | 3 minutes. If not all data has been loaded by then, the step times out and no records are returned |
If a large export times out, narrow the query or use Data Lake instead of only raising the timeout.
More than 100,000 records: use Data Lake
For result sets above 100,000 records, use the Infor Data Lake. It holds a copy of your M3 data and is built for reading large volumes at once. Use the Data Lake component to run a SQL query against it from a workflow.
The Data Lake is not real-time: changes made in M3 take some time to show up. If you need up-to-date data, use the M3 API and keep each call within the limits above.