Tine Staric

We can have Codeunits as implementations of Interfaces, but since we can declare procedures on Page, Table, Report, and Query objects, I see no reason, why those couldn't implement interfaces as well.

Right now, if we want to decouple for example which Query is being used in the process, we have to wrap it in a codeunit. If Queries could implement interfaces, we could skip the wrapper. The same goes for decoupling other objects.

The new Ext. File Storage framework includes three connectors out of the box: Blob Storage, File Share, and SharePoint.

The SharePoint connector works well, but it currently only supports authentication via clientId/clientSecret, which relies on the User Grant flow. However, some of our integration scenarios require background access without user interaction—this is only possible using the Client Credentials flow, which uses certificate-based authentication.

Additionally, some clients explicitly prefer not to use client secrets in production due to security concerns, as certificates offer a more secure and manageable alternative.

The ask: Extend the SharePoint connector to support certificate-based authentication using the Client Credentials flow, in addition to the existing client secret method.

Business Central limits the maximum response content size of the HttpClient to 150 MB by default, controlled by the NavHttpClientMaxResponseContentSize server setting. It means that any files above that limit fail to download from SharePoint.

The answer is to download in chunks; however, the REST APIs do not support chunked downloads, only uploads.

Graph API, on the other hand, does. We could change only the GetFile implementation to use the Graph API; however, that would mean that the app registration would need mixed API permissions for both Graph and SharePoint APIs, which I find messy.

The proposal is to add the Graph API implementation of the SharePoint connector alongside the REST APIs, with a toggle in the connector setup for backwards compatibility.