# Reporting in CloudSuite Industrial Multi-Tenant Without Direct SQL Access

> Source: https://netray.co/erp-help/csi-reporting-without-direct-sql-multi-tenant-options
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

When a multi-tenant CloudSuite Industrial tenant does not expose its SQL Server, replace direct queries with three supported patterns: IDO-based reports and the IDO REST service for operational reads, Infor reporting tools for standard documents, and data lake extracts for analytics and history. Choose by freshness and volume: REST for small, current reads, the data lake for large, historical or cross-system analysis.

## Kind

advanced

## System

syteline

## Erp

Infor CloudSuite Industrial (SyteLine) Multi-Tenant

## Module

Reporting / Data Lake / IDO REST

## Query

CloudSuite Industrial multi-tenant no direct SQL access reporting options

## Alternate Queries

- SyteLine multi-tenant cannot connect to database for reports
- how to report on SyteLine cloud data without SQL access
- CloudSuite Industrial data lake vs IDO REST for reporting
- replace SyteLine SQL views in cloud

## Applies To

Infor CloudSuite Industrial (SyteLine) multi-tenant cloud with Infor OS; ION API, IDO REST and data lake availability depend on your subscription and release

## Steps

### How to replace direct SQL reporting

**Items:**

- Inventory every report and consumer that connects to the database: SSRS reports, ODBC and Excel links, SQL views, BI tools and integration jobs.
- For each, record the data it reads, how fresh it must be, the row volume and the audience, because these decide the pattern.
- Map small, current-state reads such as open orders or item availability to IDO REST calls through the ION API gateway.
- Map standard documents and operational reports to IDO-based reports in the supported reporting tools for your release.
- Map large, historical or cross-system analytics to extracts in the Infor data lake, then query with its SQL interface or a BI tool.
- Rebuild the business logic that lived in views, such as joins and calculations, as documented queries, and validate row counts against the old output.
- Run old and new in parallel for one period close, reconcile differences, then decommission the database connection.

## Sections

### Why direct SQL goes away

**Body:**

Direct SQL access depends on exposing the database to the customer. On a shared multi-tenant platform, that would expose infrastructure that Infor operates for many customers, and it would let custom objects interfere with upgrades. So tenants generally access data through the application layer, where business rules, security and tenant isolation apply, rather than through the database.

This is a real change for teams used to writing views and joining tables freely. It also brings a benefit: reports that go through the application layer respect the same permissions as the UI. Whether any read access to a replica exists in your agreement is a contractual question, so ask Infor rather than assume.

### Choosing between IDO REST, reports and the data lake

**Body:**

IDO REST is best for operational reads of modest size. Each call goes through business logic and security, supports filters and property lists, and is paged. It is slow and awkward for millions of rows or deep multi-table joins, because you are limited by page size and round trips.

The data lake suits history, aggregates and cross-system analysis. Data is ingested from the ERP, usually on a schedule or via ION, then queried in bulk. The trade-off is freshness: it is not a live view, so a dashboard that must show the current open order book to the minute may need REST while trend and margin analysis use the lake. Many teams use both, and it is rarely worth building a third path.

**Code:**

# Operational read through the ION API gateway (paged)
GET https://<ion-api-host>/<TENANT>/CSI/IDORequestService/ido/load/SLCoitems?properties=CoNum,CoLine,Item,QtyOrdered,DueDate&filter=Stat%20%3D%20'O'&rowcap=200
Authorization: Bearer <token>

### Rebuilding the logic hidden in views

**Body:**

The hardest part is rarely the connection. It is the business logic embedded in SQL views: a hand-written join for margin, an exclusion for internal customers, a currency conversion nobody documented. Extract each view's definition, write down its rules in plain language, and have the report owner confirm them before rebuilding.

Then reconcile. Pick a closed period, run old and new, and compare totals and a sample of rows. Differences are usually a missing filter, a timezone boundary on dates, or a status excluded in the old view. Fix and document each so the new definition is the single agreed truth.

### Security, cost and operating model

**Body:**

Access through the ION API uses a service account and tokens. Give each integration its own account with least privilege, rotate credentials and keep them in a secret store. Rate limits and quotas may apply, so a nightly job that pulls everything through REST can be throttled; for that, use the data lake instead.

Budget for the operating model, not just the build. Someone must own the data lake ingestion, schema changes after upgrades and the BI layer. Without an owner, the old SQL shortcuts return as exports to spreadsheets, which is the worst of both worlds.

## Pitfalls

- Pulling large history through IDO REST page by page instead of using a data lake extract.
- Rebuilding a view without writing down its hidden business rules and getting them confirmed.
- Using one shared service account for every integration, which hides who read what and breaks least privilege.
- Expecting data lake data to be live; it reflects the last ingestion.
- Decommissioning old reports before a full period close reconciliation.

## Ai Angle

An AI assistant grounded in SyteLine can translate a business question into the right read path, saying whether it fits an IDO query or needs the lake, and can document a legacy view's logic by reading its definition. DataRay and ERPray are built for conversational access to data sources with the query shown and read-only by default, which helps owners validate results during reconciliation. It does not bypass the access your tenant allows.

## Faq

### Can I still use ODBC or Excel links to SyteLine in the cloud?

**Answer:** Only if your agreement exposes a database endpoint, which multi-tenant generally does not. The usual replacements are IDO-based reports, REST calls through the ION API and data lake extracts. Confirm with Infor for your tenant.

### When should I use the data lake instead of IDO REST?

**Answer:** Use the lake for large volumes, history, aggregates and cross-system analysis. Use REST for small, current reads where freshness matters. Remember lake data is only as fresh as its last ingestion.

### How do I rebuild a complex SQL view?

**Answer:** Document its rules in plain language, have the business owner confirm them, rebuild against supported access, and reconcile with the old output for a closed period before switching.

### Are there limits on API calls?

**Answer:** Quotas and rate limits can apply to API gateways, depending on subscription. Design bulk jobs to use extracts rather than thousands of small calls, and check the limits documented for your tenant.

## Search terms

CloudSuite Industrial reporting no SQL access, SyteLine multi-tenant database access, SyteLine IDO REST reporting, Infor data lake SyteLine, replace SyteLine SQL views cloud, SyteLine ODBC cloud, ION API IDORequestService, SyteLine cloud BI reporting

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