On the other hand, accessing the data within the service is done using two different options, as follows:
- A webservice
- A REST API
Both utilize http or https (depending on server configuration).
Using the webservice:
Rather than specifying a target on every command, you can establish a connection once, using the Connect-RsReportServer command:
Connect-RsReportServer -ReportServerUri "http://sql2017/reportserver/"
This will establish a persisted connection; all further commands that do not explicitly specify a target will use this connection.
You can use the New-RsWebServiceProxy command to create a proxy object to a Reporting Services service:
New-RsWebServiceProxy -ReportServerUri "http://sql2017/reportserver/"
There are many options to connect, but which option is for which scenario?
- Establish a connection using Connect-RsReportServer if you persistently work against a single service
- Explicitly specify the URI for calls to secondary servers in scenarios where you primarily work against a single SSRS service but occasionally have to connect others
- Establish individual proxy objects/connections using New-RsWebServiceProxy in situations where you heavily jump between instances but have multiple calls against the same services during the operation (for example, during migrations)
Using the REST API:
All commands connecting via the REST API have a -ReportPortalUri parameter and have an extended command prefix (*-RsRest*).
Since there is no real way to establish a persisted session for the purpose of faster connections, there is no point in juggling such a session object. Still, it is possible, using Connect-RsReportServer, to set the link to connect to, removing the need to explicitly specify the path:
Connect-RsReportServer -ReportPortalUri 'http://sql2017/reports'