OData - Troubleshooting

Intended audience: Developers administrators

AO Platform: 5.0

Troubleshooting

• Connection refused / timeout: Ensure the platform server is running, OData is enabled in the OData config group, and firewall/network allows access to the server host and port.

• Power BI does not show the sign-in dialog: Power BI’s OData connector typically prompts for credentials only when the server returns 401 Unauthorized. If you get 403 Forbidden without ever being asked to sign in, the request is reaching the server without authentication. Ensure that the /odata/** path is secured by the platform (it is by default). Unauthenticated requests to /odata/** must receive 401 so that Power BI will show the authentication dialog.

• 401 Unauthorized: The server returns 401 with a WWW-Authenticate: Basic header so that Power BI shows the sign-in dialog. Use valid platform credentials; ensure the user has access to the ontology (schema prefix) in the URL. If you get 401 but Power BI still does not prompt, ensure the response includes the WWW-Authenticate header (the platform OData controller sets it automatically).

• Sign-in dialog appears but login fails / no messages in logs: Power BI sends credentials using HTTP Basic. The platform must have Basic authentication enabled for the OData path. When using database/LDAP/hybrid auth, the OAuth2 resource server configuration enables Basic for /odata/** so that the Authorization: Basic header is processed. If login still fails, enable debug logging for com.apporchid.cloudseer.odata (and optionally org.springframework.security) to see whether the request is authenticated and what principal is set; the OData controller logs at INFO when it returns 401 and at DEBUG the auth state for each request.

• 403 Forbidden: The user does not have RBAC access to that ontology; check ontology-level permissions. If you see 403 only after signing in, your user account lacks access to that ontology—an admin must grant ontology access.

• 404 on $metadata or entity set: Verify the schema prefix in the URL is correct and that the ontology (and its MSO schema) is loaded; try the service document first (/odata/{schemaPrefix}).

• Empty or partial data: Check $top/$skip and server-side max page size; for very large MSOs, use paging or filters to reduce result size.

• Internal Server Error / "Connection reset by peer" on large entity sets: Large responses can cause the client (Power BI) to timeout and close the connection while the server is still writing. The server limits unbounded requests to min(5000, server.odata.max.page.size) rows per response and returns @odata.nextLink for the next page, so Power BI can load in chunks. If you still see timeouts, use $top in the query (e.g. in Power Query) or adjust the OData max page size configuration only if needed; smaller pages are often more reliable.

• "Cannot get a connection, pool error / Timeout waiting for idle object" (including borrowMaxWaitDuration=PT0S or PT40S): The platform uses stateless session policy only for /odata/** (no session per OData request) and closes the MSO datasource after each request so the DB connection is returned to the pool. If the pool is still exhausted, set a positive max wait time (e.g. 10000–40000 ms) and a sufficient max size (e.g. 5–10 or more) for the ontology’s datasource (e.g. assetAIDB) in the platform’s datasource settings. See Connection pool below.

For server-side errors (e.g. 500), check platform server logs; the OData layer will log errors when translating OData to MSO queries or when executing them.

Contact App Orchid | Disclaimer