SSRS-Export scheitert über ein clientloses VPN-Portal: was anders ist

Der Bericht öffnet sich im Browser, die Parameter werden gerendert, und die Export-Schaltfläche erzeugt einen Fehler, einen leeren Download oder eine Datei, die die Tabellenkalkulation nicht öffnen will. Diese Kombination hat eine Standardform. Eine funktionierende Berichtsseite hat Rendern und Authentifizierung getestet und sonst nichts. Der Export ist eine eigene Anfrage mit eigener Antwort, und durch ein clientloses Portal durchläuft er zusätzlich eine Umschreibungsschicht, die nie für Dateidownloads entworfen wurde.

Zwei Wege, eine funktionierende Seite

Rendern und Exportieren sind verschiedene Vorgänge, auch wenn sie von derselben Schaltfläche ausgehen. Der Berichtsserver rendert die Seite für einen Browser und rendert den Export über eine andere Ausgabeerweiterung mit eigenem Inhaltstyp und eigenem Fehlerverhalten, wie die Exportdokumentation beschreibt. Ein Portal, das das erste perfekt durchlässt, kann das zweite trotzdem verunstalten, denn das zweite ist eine Antwort, die das Portal nicht zu sehen erwartete. Beide teilen eine Sitzung und eine Adresse und fast nichts anderes.

Betrachten Sie die funktionierende Seite nur als Beweis für Authentifizierung und Erreichbarkeit. Sie beweist, dass das Konto den Berichtsserver erreicht und dass das Portal HTML weiterleitet. Sie sagt nichts über Dateiantworten, Content-Disposition-Header oder Weiterleitungen, die in einem Download statt in einem Dokument enden.

Das ist der ganze Grund, den Exportweg für sich zu vergleichen, statt die bereits funktionierende Seite erneut zu testen. Zwei Anfragen, die eine Sitzung teilen, bleiben zwei Anfragen.

Drei Bedingungen, die entscheiden, wo der Export bricht

Drei Fragen verorten den Fehler schnell, und jede Antwort zeigt auf einen anderen Verantwortlichen.

Erstens, exportiert derselbe Bericht, dasselbe Konto und dasselbe Format aus dem internen Netz korrekt? Wenn ja, sind der Berichtsserver und sein Renderer in Ordnung, und der Unterschied liegt im Zugriffsweg. Zweitens, trägt die fehlerhafte Antwort einen Datei-Inhaltstyp, oder eine HTML-Seite mit Dateiendung? Das trennt einen Rendererfehler von einer Ersetzung durch das Portal. Drittens, schreibt das Portal die Anfrage-URL um oder entfernt es Header aus der Antwort? Eine umgeschriebene URL kann auf einem völlig anderen Endpunkt landen.

Beantworten Sie alle drei, bevor Sie eine Einstellung ändern, denn jede hat eine andere Abhilfe. Ein Rendererfehler gehört zum Berichtsserver, ein ersetzter Body gehört zum Portal, und ein entfernter Header ist eine Richtlinienfrage und kein Fehler.

Schreiben Sie die Antworten auf. Ein Supportfall aus diesen drei Zeilen ist zehn Screenshots wert.

Lesen Sie die Exportantwort statt des Statuscodes

Ein HTTP-Erfolgsstatus beweist nur, dass etwas die Anfrage beantwortet hat. Prüfen Sie Body und Header zusammen, denn der interessante Fehler ist eine erfolgreiche Antwort mit dem falschen Inhalt.

curl -sS -D export.headers -o export.bin --location "https://portal.example.com/reports/export?format=xlsx"
file export.bin
head -c 300 export.bin

Der Header-Dump zeigt den Inhaltstyp und jede Content-Disposition, die das Portal zurückgegeben hat. Der Befehl file erkennt, was der Body tatsächlich ist, und eine Textdatei, wo eine Tabellenkalkulation erwartet wurde, ist die klassische ersetzte Anmeldeseite. Der Befehl head zeigt genug, um HTML zu erkennen, ohne einen ganzen Bericht in ein Terminal zu schütten.

Entfernen Sie Sitzungscookies und Token, bevor Sie irgendetwas davon teilen. Eine Aufzeichnung eines funktionierenden Exports ist nützlicher Beweis, und eine Aufzeichnung einer Sitzung, die jemand anderem gehört, ist ein Vorfall.

Grenzen Sie die Ausnahme auf die Anwendung ein, nicht auf das Konto

Wenn das Portal die Antwort umschreibt oder blockiert, ist die verlockende Reparatur, die ganze Website auszunehmen oder den Bericht anonym zu machen. Beides behebt den Download und beseitigt den Grund, warum das Portal existiert. Eine eng gefasste Ausnahme benennt einen Anwendungspfad, einen Inhaltstyp und eine Richtung, und sie bleibt für den prüfbar, der die Richtlinie besitzt.

Verwenden Sie die Gateway-Version, die Sie tatsächlich betreiben, und ihre dokumentierten Anwendungseinstellungen. Eine Option, die ein Anbieter einmal als trafficunverändert beschrieb, ist keine allgemeine Anweisung, und sie aus einem alten Forumsthread zu kopieren, ist der Weg, auf dem eine vorübergehende Ausnahme zur dauerhaften Architektur wird.

Lässt sich die Ausnahme nicht so eng fassen, gehört der Export wahrscheinlich auf den internen Weg mit einer anderen Zugriffsmethode statt hinter das Portal. Eine Ausnahme für die ganze Website ist eine Entscheidung des Portaleigentümers und kein Workaround für einen Bericht.

Akzeptieren Sie den Export, nicht den Speichern-Dialog

Die letzte Prüfung ist die Datei selbst: Sie öffnet sich, sie enthält die erwarteten Spalten, und ihre Summen stimmen mit dem Bericht überein, den der Benutzer freigegeben hat.

Dass ein Speichern-Dialog erscheint, ist kein Erfolg, und eine Datei, die sich mit einer Reparaturwarnung öffnet, ist ebenfalls kein Erfolg. Vergleichen Sie eine Zeilenzahl und einen bekannten Wert mit dem Bericht auf dem Bildschirm, denn ein abgeschnittener Export besteht jeden Test, der nur auf die Dateigröße schaut. Exportieren Sie dann ein zweites Mal, denn eine Cache-Schicht, die einmal den falschen Body ausliefert, liefert beim nächsten Versuch vielleicht den richtigen.

Akzeptieren Sie den Arbeitsablauf, den der Benutzer brauchte, und nichts weniger. Ein Download, der in der falschen Anwendung öffnet, ist immer noch ein gescheiterter Export.