Infor / ERP — the integration layer

Audience: developers & AI agents · Scope: how the site talks to Infor (Syteline / CSI / CPQ), and a map of what depends on it · Last reviewed: 2026-07-25

TL;DR — Infor is the ERP that owns items, BOMs, costs, jobs and sales orders. The site reaches it three completely separate ways: an authenticated IDO REST API (reads and writes against Infor's object layer), a direct MSSQL connection (reporting-style bulk queries), and CPQ's SOAP service (the rule engine — its own endpoint, its own settings, documented with the BOM System). They have different credentials, different failure modes and different consumers — knowing which path a feature uses is the first step in debugging it, and "Infor is down" is never one thing.

This is an integration layer: systems link to it, it is not owned by any one of them.

The parts

Doc	What it covers
This hub	the three paths, which consumer uses which, settings, and the failure modes
rest-api.md	the IDO REST client — auth/token caching, loadCollection/invokeMethod/updateItems, CloudWatch metrics
database.md	the direct MSSQL path — PDO/sqlsrv, the site-context call, connection reuse and retry
../bom/cpq.md	the CPQ SOAP path — owned by the BOM System, listed here because it is a third way into Infor

How it fits together

              ┌──────────────────────────────────────────────────────────┐
              │                        Infor                             │
              │                  (Syteline / CSI / CPQ)                  │
              └────────┬──────────────────┬──────────────────┬───────────┘
                       │                  │                  │
     IDO REST API      │                  │  MSSQL (bulk)    │   CPQ SOAP (rule engine)
   syteline_* settings │                  │ infor_db_*       │   cpq_* settings
                       ▼                  ▼                  ▼
        ConfigboxModelCsirestapi   BcHelper::getInforDb()   nusoap_client(WSDL)
          token in APCu (48h)      reuse + health + retry   Configure → LoadMfgData
          CW: Infor-Rest-API       log: custom_infor_pdo    log: custom_infor_cpq
                       │                  │                  │
        ┌──────────────┴───┬──────────────┼────────┬─────────┴────────┐
        ▼                  ▼              ▼        ▼                  ▼
  code normalization  costing/margin   BOM cache  CSI orders     CPQ BOM lookups
 (bccodenormalization) (bccostingsheet) + explosion (adminbccsiorders)  (bom/cpq.md)
                                       (bom/bom-cache.md)
                                            │
                                       SQL exports ("Infor App DB")

File	Role
data/customization/models/csirestapi.php	ConfigboxModelCsirestapi — the whole REST client
data/customization/system_overrides/BcHelper.php:~20-90	getInforDb() — the PDO/sqlsrv connection, reuse and retry
data/customization/models/bcitembomcalculator.php	the BOM cache engine — see bom/bom-cache.md
data/customization/models/bccostingsheet.php	Margin Analysis — costing sheet built from Infor data
data/customization/models/bccodenormalization.php	configuration-code normalization + its findings report
data/customization/models/csimaterials.php	BOM explosion (the five-level join) — see bom/cpq.md
data/customization/models/adminbccsiorders.php	CSI orders / order-scheduling
data/customization/models/sqlexports.php	runs saved SQL against the Infor App DB endpoint

Which path does what

Consumer	Path	Why
BOM explosion, item/material lookups, the BOM cache	MSSQL	a five-level self-join over job/jobmatl/item; far too big for the object layer
CPQ configuration (rule-engine BOMs)	SOAP	CPQ is a separate service with its own endpoint — not the IDO layer
Order creation	REST (IDO)	needs Infor's object layer — validation, business logic, writes
Code normalization findings	REST	reads item/configuration objects
Margin Analysis / costing sheet	MSSQL	bulk reporting query, too big for the object layer
SQL → Google Sheet exports (Infor App DB endpoint)	MSSQL	arbitrary saved reporting queries
Production / fabrication / assembly / kitting schedule exports	MSSQL	bulk job data

Rule of thumb: writes and single-object reads go through REST; anything that looks like a report — including BOM explosion — goes through MSSQL; rule evaluation goes through CPQ (SOAP).

A note on drift. ConfigboxModelCsimaterials::fetchMaterialsData() is the REST implementation of the material fetch and is dead code — nothing calls it. The live path is fetchMaterialsDataViaDb(). If you are following an old trail that says BOM data comes over REST, this is why.

Admin settings

Both groups live in Custom Settings and are per-environment.

Infor REST API Integration

Setting	Label	Notes
syteline_endpoint_root_url	CSI Installation Scheme/Hostname	the REST root, e.g. https://…
syteline_configuration_name	Configuration name	Infor "configuration" (which instance/site config to talk to)
syteline_api_username	CSI Username	secret
syteline_api_password	CSI Password	secret
infor_code_normalization_report_sheet	Sheet for code normalization reports	the findings destination — see Google Sheets

Infor DB (the MSSQL path)

Setting	Label
infor_db_ip_address	Infor DB server IP address
infor_db_port	Infor DB server port
infor_db_instance_name	Infor DB instance name
infor_db_database_name	database name
infor_db_username / infor_db_password	secrets

Infor CPQ Integration — the SOAP path's five settings (cpq_endpoint_url, cpq_instance, cpq_app_name, cpq_profile, cpq_site_id) plus two fail-reporting addresses are documented in full at bom/cpq.md.

Blank credentials do not disable anything gracefully — the consumer simply fails when it next runs. There is no "Infor off" switch.

Control / data flow

• REST authenticates once and caches the token for 48 hours in APCu, guarded by a lock so concurrent requests don't stampede the token endpoint. Every call is a POST to an IDO method or collection load.
• MSSQL reuses one PDO connection per process, health-checks it with SELECT 1 before reuse, and reconnects with bounded retries when the failure looks transient.
• Most Infor work is scheduled, not interactive — see Scheduled jobs for what runs when.

Data model

Infor owns its own data; the site stores only what it caches or reports on. The site-side tables that hold Infor-derived data are owned by their respective features (BOM caches, #__configbox_external_sql_export_log, the code-normalization findings). Nothing here is a source of truth — re-running the job is always the recovery path.

Deployment runbook (manual steps)

Per environment:

1. Ensure network reachability. The MSSQL path needs the site-to-site VPN to be up; the REST and CPQ paths need outbound HTTPS to the CSI and CPQ hosts.
2. Custom Settings → Infor REST API Integration: set the root URL, configuration name, username and password.
3. Custom Settings → Infor DB: set IP, port, instance, database, username and password.
4. Confirm the PHP sqlsrv/pdo_sqlsrv extension is present — the MSSQL path is a hard dependency on it.
5. Custom Settings → Infor CPQ Integration: set the CPQ endpoint and its four identifiers (bom/cpq.md).
6. Smoke test each path separately — they fail independently: an MSSQL-backed tool (Infor Flat BOM Calculator (Fresh), a small SQL export, or Margin Analysis), a REST-backed one, and the CPQ Flat BOM Calculator for SOAP.
7. Add the cron entries for the scheduled Infor jobs — see Scheduled jobs.

Turning it off: there is no feature flag. Removing the cron entries stops the scheduled work; the interactive admin tools will simply error when used.

Gotchas & caveats

• Three sets of credentials, three failure modes. "Infor is down" is not one thing — REST can be fine while MSSQL is unreachable (a dropped VPN does exactly that), and CPQ can be down while both are healthy. Check which path the failing feature uses before debugging.
• The site writes to production Infor. The BOM cache stamps item_mst.Uf_BCDateLastBomCalc on every refresh, and a purge nulls it for every row. Infor is not a read-only dependency.
• The MSSQL path depends on the VPN. Transient 08S01/HYT00-class errors on a network blip are retried; a VPN that is genuinely down just fails.
• The token is cached for 48 hours. Rotating the CSI password does not take effect until the cached token expires or APCu is cleared — a rotation can therefore look like it "worked" for two days and then break.
• Infor tools skip discontinued products (see discontinued products), so report totals won't reconcile against a raw product count.
• Failures are asymmetric. REST failures emit CloudWatch metrics; MSSQL failures only write to the custom_infor_pdo log. Don't assume an alert exists for both.

Testing

No dedicated specs — these paths need a live Infor. The practical check is running the interactive admin tool for the path you changed. See testing/guide.md.

Possible follow-ups

• Per-tool deep dives for the costing sheet and code normalization — each is 1000+ lines and only mapped at the surface here. (The BOM calculator now has one: bom/.)
• CloudWatch coverage for the MSSQL path, to match the REST path.

Related docs

• rest-api.md · database.md
• BOM & CPQ — the biggest consumer of this layer, and owner of the CPQ SOAP path
• Google Sheets — where most Infor output lands
• Scheduled jobs — what runs when
• Admin Guide: Pricing, BOM & ERP (admin-guide/pricing-bom-erp/README.md)