Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
SQL Server 2016 (13.x) Serviços de Relatórios e versões posteriores Power BI Report Server
Para obter conteúdo relacionado a versões anteriores do SQL Server Reporting Services (SSRS), consulte O que é o SQL Server Reporting Services?
Pode instalar e executar SQL Server Reporting Services (SSRS) e Internet Information Services (IIS) no mesmo computador. A versão do IIS que estás a usar determina as questões de interoperabilidade que deves resolver.
| Versão IIS | Issues | Description |
|---|---|---|
| 8.0, 8.5 | Pedidos destinados a uma aplicação são aceites por outra aplicação. HTTP.SYS aplica regras de precedência para reservas de URL. Pedidos enviados a aplicações com o mesmo nome de diretório virtual e que monitorizam conjuntamente a porta 80 podem não chegar ao destino pretendido se a reserva de URL for fraca em relação à reserva de URL de outra aplicação. |
Sob certas condições, um endpoint registado que substitui outro endpoint URL no esquema de reserva de URL pode receber pedidos HTTP destinados à outra aplicação. Usar nomes únicos de diretórios virtuais para o serviço Web do Servidor de Relatórios e para o portal web ajuda a evitar este conflito. Informações detalhadas sobre este cenário são fornecidas neste artigo. |
Regras de precedência para reservas de URL
Antes de poder resolver questões de interoperabilidade entre o IIS e os Serviços de Relatório, deve compreender as regras de precedência de reservas de URLs. As regras de precedência podem ser generalizadas na seguinte afirmação: uma reserva de URL com valores mais explicitamente definidos é a primeira na linha para receber pedidos que correspondam à URL.
Uma reserva de URL que especifica um diretório virtual é mais explícita do que uma que omite um diretório virtual.
Uma reserva de URL que especifica um único endereço (através de um endereço IP, um nome de domínio totalmente qualificado, um nome de computador de rede ou um nome de host) é mais explícita do que um curinga.
Uma reserva de URL que especifica um coringa forte é mais explícita do que um coringa fraco.
Os exemplos seguintes mostram um intervalo de reservas de URL, ordenadas do mais explícito ao menos explícito:
| Example | Request |
|---|---|
https://123.234.345.456:80/reports |
Recebe todos os pedidos que são enviados para https://123.234.345.456/reports ou https://<computername>/reports se um serviço de nomes de domínio conseguir resolver o endereço IP para esse nome de anfitrião. |
https://+:80/reports |
Recebe quaisquer pedidos enviados para qualquer endereço IP ou nome de host válido para esse computador, desde que a URL contenha o nome do diretório virtual "reports". |
https://123.234.345.456:80 |
Recebe qualquer pedido que especifique https://123.234.345.456 ou https://<computername> se um serviço de nomes de domínio pode resolver o endereço IP para esse nome de host. |
https://+:80 |
Recebe pedidos que ainda não são recebidos por outras aplicações, para quaisquer endpoints de aplicação que estejam mapeados para All Assigned. |
https://*:80 |
Recebe pedidos que ainda não são recebidos por outras aplicações, para endpoints de aplicação que estão mapeados para Todos os Não Atribuídos. |
Uma indicação de conflito de porta é que vê a seguinte mensagem de erro: 'System.IO.FileLoadException: O processo não pode aceder ao ficheiro porque está a ser usado por outro processo. (Exceção do HRESULT: 0x80070020).'
Reservas de URL para IIS 8.0, 8.5 com SQL Server Reporting Services
Dadas as regras de precedência descritas na secção anterior, pode começar a perceber como as reservas de URL definidas para Reporting Services e IIS promovem a interoperabilidade. Os Serviços de Relatórios recebem pedidos que especificam explicitamente os nomes dos diretórios virtuais para as suas aplicações; O IIS recebe todos os pedidos restantes, que podem depois ser encaminhados para aplicações que correm dentro do modelo de processo IIS.
| Aplicação | Reserva de URL | Description | Receção do pedido |
|---|---|---|---|
| Servidor de relatório | https://+:80/ReportServer |
Forte uso de wildcard na porta 80, com diretório virtual para o servidor de relatórios. | Recebe todos os pedidos na porta 80 que especificam o diretório virtual do servidor de relatórios. O serviço Web do Servidor de Relatórios recebe todos os pedidos para https://< nomecomputador>/servidor de relatórios. |
| Portal Web | https://+:80/Reports |
Forte wildcard na porta 80, com diretório virtual de Relatórios. | Recebe todos os pedidos na porta 80 que especificam o diretório virtual dos relatórios. O portal web recebe todos os pedidos para https://<computername>/reports. |
| IIS | https://*:80/ |
Wildcard fraco na porta 80. | Recebe quaisquer pedidos restantes na porta 80 que não sejam recebidos por outra aplicação. |
Implementações lado a lado dos SQL Server Reporting Services no IIS 8.0, 8.5
Problemas de interoperabilidade entre o IIS e os Serviços de Relatórios ocorrem quando os sites do IIS têm nomes de diretórios virtuais idênticos aos nomes usados pelos Serviços de Relatório. Por exemplo, suponha que tem a seguinte configuração:
Um site no IIS atribuído à porta 80 e um diretório virtual chamado "Reports".
Uma instância de servidor de relatórios instalada na configuração predefinida, onde a reserva de URL também especifica a porta 80 e a aplicação do portal web também usa "Relatórios" como nome do diretório virtual.
Dada esta configuração, um pedido enviado para https://\<computername>:80/reports é recebido pelo portal web. A aplicação acedida através do diretório virtual de Relatórios no IIS deixará de receber pedidos após a instalação da instância do servidor de relatórios.
Se executar implementações lado a lado de versões antigas e mais recentes dos Serviços de Relatório, é provável que encontre este problema de encaminhamento. Vê-se este problema porque todas as versões dos Serviços de Relatórios usam "ReportServer" e "Reports" como nomes de diretórios virtuais para o servidor de relatórios e as aplicações do portal web, aumentando a probabilidade de existirem diretórios virtuais "relatórios" e "servidor de relatórios" no IIS.
Para garantir que todas as candidaturas recebam pedidos, siga estas orientações:
Para instalações dos Serviços de Relatório, utilize nomes de diretórios virtuais que não sejam já usados por um site do IIS na mesma porta que os Serviços de Relatório. Se houver algum conflito, instale os Serviços de Relatórios em modo "apenas ficheiros" (usando a opção Instalar mas sem configurar a opção do servidor no Assistente de Instalação) para que possa configurar os diretórios virtuais depois de terminar a Configuração. Uma indicação de que a sua configuração tem um conflito é ver a mensagem de erro: System.IO.FileLoadException: O processo não consegue aceder ao ficheiro porque está a ser usado por outro processo. (Exceção do HRESULT: 0x80070020).
Para instalações que configurar manualmente, adote as convenções de nomenclatura padrão nas URLs que configurar. Se instalar SQL Server 2016 (13.x) Reporting Services ou posterior (SSRS) como uma instância nomeada, inclua o nome da instância ao criar um diretório virtual.