Herdei uma anomalia muito estranha no SSRS. Uma nova instância do SSRS foi criada em 2019 e parece que está usando o mesmo banco de dados ReportServer da instância anterior de 2016. Isso pode ter sido feito para evitar a portabilidade de milhares de relatórios e itens associados.
A instância de 2016 parece ainda estar em execução, no entanto, a conta usada para acessar o banco de dados ReportingService não é mais válida, portanto, qualquer tentativa de acessar um relatório usando o URL de 2016 termina com 'não é possível acessar o banco de dados do servidor de relatório'.
Quando acesso um relatório em 2019 posso renderizá-lo no gerenciador de relatórios.
Quando invoco o mesmo relatório, usando o URL da instância de 2019, por meio de uma chamada de serviço wcf para ReportService2010.Render(), recebo o mesmo erro como se estivesse acessando os serviços da instância de 2016.
Além disso, sei que a versão 2016 está tentando renderizar a chamada feita para 2019 porque as informações de log sobre a tentativa de renderização e o erro "não é possível conectar ao banco de dados do servidor de relatório" aparecem apenas no log de erros de 2016.
Verifiquei novamente o log do iis e vi que o serviço wcf está chamando o servidor 2019 para solicitar a renderização com resultado 200 (é disparado e esquecido, então 200 é sempre retornado se o endpoint estiver acessível).
Parece que o WCF está de fato chamando a instância de 2019 e solicitando um relatório; no entanto, o registro dessa solicitação está sendo feito na instância de 2016 do SSRS.
Isso poderia ser algo mal configurado no banco de dados do servidor de relatórios?
Responder1
Este foi um erro do usuário. O app.config do serviço WCF apontava para a instância correta, daí as mensagens de log corretas. O web.config no projeto da API, que referenciava todos os serviços WCF, tinha duas configurações de aplicativo com a mesma chave. Uma chave estava incorreta e foi usada para a ligação do endpoint ReportExecution.
Presumi que as configurações estavam perfeitas.