Skip to main content

The Infor IDO REST client

Audience: developers & AI agents · Scope: ConfigboxModelCsirestapi — the authenticated REST path into Infor · Last reviewed: 2026-07-20

TL;DR — Infor exposes its object layer as IDOs (Intelligent Data Objects). The client authenticates once, caches the bearer token in APCu for 48 hours, and then loads collections, invokes IDO methods and writes items. Failures emit CloudWatch metrics under the Infor-Rest-API namespace, which is the main way these calls are monitored.

Everything here lives in data/customization/models/csirestapi.php.

The API surface​

MethodPurpose
loadCollection($ido, $properties, $parameters, $cacheTtl, $sortingProperty, $sortingDirection, $dataClass)The workhorse read: fetch rows of an IDO with a property list and filter. Optional per-call caching and sorting.
invokeMethod($ido, $method, $parameters)Call an IDO method (Infor-side business logic).
updateItems($ido, $items, $propNames)Write changes back to existing IDO rows.
insertItem($ido, $properties)Create a new IDO row.
getIdoProperties($ido, $requiredOnly)Discover an IDO's properties — useful when building a new call.
getNextOrderNumber()Reserve the next order number.
getSwaggerDoc()Fetch the API's own description.
populateFromRestApiJsonData($pairs)Map a response row onto an object.

getApiSettings() assembles the endpoint/credentials from the Infor REST API Integration settings group (syteline_endpoint_root_url, syteline_configuration_name, syteline_api_username, syteline_api_password).

Authentication​

getAuthenticationToken()
  └─ fetchOrGenerateCacheData('cb.infor.auth_token.<md5 of settings>', _getAuthenticationToken, …, 48h, lock 10s)
       ├─ APCu hit  → return the cached token
       └─ APCu miss → take an APCu lock, POST the token endpoint, store, release
  • Lifetime: authTokenLifetime = 172800 seconds (48 hours).
  • Cache key is derived from the settings, so changing any credential yields a different key — but the old token stays cached under the old key until it expires.
  • Locking: fetchOrGenerateCacheData() sets <cacheKey>.lock in APCu, waits up to $maxLockTime seconds (polling once per second) for a concurrent generator, and throws if the lock never clears. A shutdown function releases the lock as a contingency against fatals — otherwise a crash mid-generation would wedge every later request.
  • Transport: cURL with CONNECTTIMEOUT 8s, TIMEOUT 9s and SSL_VERIFYPEER on. Token-endpoint failures are logged to custom_infor_api_connect_fails with the cURL error number, message and full curl_getinfo.

Credential rotation gotcha: because the token is cached for 48 hours, rotating the CSI password does not take effect immediately. The old token keeps working until it expires — so a bad rotation can appear to succeed and then break two days later, far from the change.

Reading data​

loadCollection() is the call almost everything uses. Notes that matter:

  • It takes an explicit property list — ask for what you need, not everything; IDO loads get expensive fast.
  • $cacheTtl enables per-call caching through the same APCu helper as the token, so a hot lookup can be memoised.
  • Sorting is done client-side via getSortingClosure() after the fetch, not by Infor.
  • Responses carry a MessageCode; a non-zero value means Infor accepted the request but rejected the content. That case is counted separately from a transport failure (see metrics below).

Monitoring — CloudWatch​

Namespace: Infor-Rest-API (cloudwatchNamespace). Metrics are emitted on the failure paths, with a dimension identifying the endpoint and configuration (getCwDimensionsRestApi() — the root URL minus https://, plus the configuration name).

MetricMeaning
Infor-Rest-API-Load-Collection-Count-Failsa collection load failed (transport / exception)
Infor-Rest-API-Load-Collection-Count-Fails-Request-IssueInfor answered, but with a non-zero MessageCode

Additional metrics are emitted around the write paths (updateItems, insertItem) in the same namespace.

This is the primary alerting surface for Infor REST. The MSSQL path has no equivalent — see database.md.

Logging​

Log typeWritten by
custom_infor_api_connect_failstoken-endpoint connection failures
errorgeneral exceptions via KLog::logException

Gotchas & caveats​

  • APCu is per-process-pool. The token cache is not shared with CLI runs, so cron scripts fetch their own token. That is fine, but it means a CLI run can succeed while the web pool holds a stale/broken token, or vice versa.
  • A 9-second timeout is short for heavier IDO calls. A slow Infor shows up as a transport failure, not as a slow page.
  • loadCollection sorts in PHP. Sorting a large collection means fetching it all first — filter in the $parameters, don't rely on sorting to bound the result.
  • Property names are Infor's, not the site's. Use getIdoProperties() or getSwaggerDoc() rather than guessing.