Ich habe eine sehr seltsame Anomalie in SSRS geerbt. Eine neue SSRS-Instanz wurde mit 2019 erstellt und es scheint, dass sie dieselbe ReportServer-Datenbank verwendet wie die vorherige 2016-Instanz. Dies wurde möglicherweise getan, um das Portieren von Tausenden von Berichten und zugehörigen Elementen zu vermeiden.
Die Instanz von 2016 scheint noch zu laufen, das für den Zugriff auf die ReportingService-Datenbank verwendete Konto ist jedoch nicht mehr gültig. Daher enden alle Versuche, über die URL von 2016 auf einen Bericht zuzugreifen, mit der Meldung „Auf die Berichtsserver-Datenbank kann nicht zugegriffen werden.“
Wenn ich im Jahr 2019 auf einen Bericht zugreife, kann ich ihn im Berichtsmanager rendern.
Wenn ich denselben Bericht unter Verwendung der URL der 2019-Instanz über einen WCF-Dienstaufruf an ReportService2010.Render() aufrufe, erhalte ich denselben Fehler, als würde ich über die 2016-Instanz auf die Dienste zugreifen.
Außerdem weiß ich, dass die Version 2016 versucht, den an 2019 gerichteten Aufruf zu rendern, da die Protokollinformationen zum Renderversuch und zum Fehler „Verbindung zur Berichtsserver-Datenbank kann nicht hergestellt werden“ nur im Fehlerprotokoll von 2016 angezeigt werden.
Ich habe das IIS-Protokoll erneut geprüft und gesehen, dass der WCF-Dienst den 2019-Server aufruft, um das Rendern mit dem Ergebnis 200 anzufordern (es handelt sich um „Fire and Forget“, sodass immer eine 200 zurückgegeben wird, wenn der Endpunkt zugänglich ist).
Es scheint, als würde WCF tatsächlich die Instanz 2019 aufrufe und einen Bericht anfordern. Die Protokollierung für diese Anforderung wird jedoch in der SSRS-Instanz 2016 durchgeführt.
Könnte es sein, dass die Konfiguration in der Berichtsserver-Datenbank nicht richtig ist?
Antwort1
Dies war ein Benutzerfehler. Die app.config für den WCF-Dienst verwies auf die richtige Instanz, daher die richtigen Protokollmeldungen. Die web.config im API-Projekt, die auf alle WCF-Dienste verwies, hatte zwei App-Einstellungen mit demselben Schlüssel. Ein Schlüssel war falsch und dieser wurde für die ReportExecution-Endpunktbindung verwendet.
Ich bin davon ausgegangen, dass die Konfigurationen makellos waren.