L’exportació de SSRS falla a través d’un portal VPN sense client: què canvia

L’informe s’obre al navegador, els paràmetres es representen i el botó d’exportació produeix un error, una descàrrega buida o un fitxer que el full de càlcul es nega a obrir. Aquesta combinació té una forma estàndard. Una pàgina d’informe que funciona ha provat la representació i l’autenticació, i res més. L’exportació és una sol·licitud separada amb la seva pròpia resposta, i a través d’un portal sense client també travessa una capa de reescriptura que mai es va dissenyar per a descàrregues de fitxers.

Dos camins, una pàgina que funciona

Representar i exportar són operacions diferents encara que comencin del mateix botó. El servidor d’informes representa la pàgina per a un navegador i prepara l’exportació mitjançant una extensió de sortida diferent amb el seu propi tipus de contingut i el seu propi comportament davant d’errors, tal com descriu la documentació d’exportació. Un portal que deixa passar perfectament la primera encara pot malmetre la segona, perquè la segona és una resposta que el portal no esperava veure. Les dues comparteixen una sessió i una adreça, i gairebé res més.

Tracteu la pàgina que funciona només com a prova d’autenticació i d’abastabilitat. Demostra que el compte pot arribar al servidor d’informes i que el portal reenvia HTML. No diu res sobre respostes de fitxers, capçaleres de disposició del contingut o redireccions que acaben en una descàrrega en lloc d’un document.

Aquesta és tota la raó per comparar el camí d’exportació per si sol en lloc de tornar a provar la pàgina que ja funciona. Dues sol·licituds que comparteixen una sessió segueixen sent dues sol·licituds.

Tres condicions que decideixen on es trenca l’exportació

Tres preguntes situen la fallada de seguida, i cada resposta assenyala un propietari diferent.

Primer, la mateixa informació, el mateix compte i el mateix format s’exporten correctament des de la xarxa interna? Si és així, el servidor d’informes i el seu renderitzador estan bé i la diferència és al camí d’accés. Segon, la resposta fallida porta un tipus de contingut de fitxer, o una pàgina HTML amb una extensió de fitxer? Això separa un error del renderitzador d’una substitució del portal. Tercer, el portal reescriu l’URL de la sol·licitud o elimina capçaleres de la resposta? Un URL reescrit pot acabar en un punt final completament diferent.

Responeu les tres preguntes abans de canviar cap paràmetre, perquè cadascuna té un remei diferent. Una fallada del renderitzador pertany al servidor d’informes, un cos substituït pertany al portal, i una capçalera eliminada és una qüestió de política, no un error.

Anoteu les respostes. Un cas de suport construït amb aquestes tres línies val deu captures de pantalla.

Llegiu la resposta d’exportació en lloc del codi d’estat

Un estat HTTP correcte només demostra que alguna cosa ha respost la sol·licitud. Inspeccioneu el cos i les capçaleres alhora, perquè la fallada interessant és una resposta correcta que porta el contingut equivocat.

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

L’abocament de capçaleres mostra el tipus de contingut i qualsevol disposició del contingut que hagi retornat el portal. L’ordre file identifica què és realment el cos, i un fitxer de text on s’esperava un full de càlcul és la clàssica pàgina d’inici de sessió substituïda. L’ordre head mostra prou per reconèixer HTML sense abocar un informe sencer a un terminal.

Elimineu les galetes de sessió i els testimonis abans de compartir qualsevol part. Una captura d’una exportació que funciona és una prova útil, i una captura d’una sessió que pertany a algú altre és un incident.

Limiteu l’excepció a l’aplicació, no al compte

Si el portal reescriu o bloqueja la resposta, la reparació temptadora és eximir tot el lloc o fer l’informe anònim. Totes dues arreglen la descàrrega i eliminen la raó per la qual existeix el portal. Una excepció limitada anomena un camí d’aplicació, un tipus de contingut i una direcció, i continua sent revisable per qui posseeix la política.

Feu servir la versió de la passarel·la que realment executeu i la seva configuració d’aplicació documentada. Una opció que un proveïdor va descriure una vegada com a deixar el trànsit sense canvis no és una instrucció general, i copiar-la d’un fil antic del fòrum és com una excepció temporal es converteix en arquitectura permanent.

Si l’excepció no es pot limitar tan estretament, l’exportació probablement pertany al camí intern amb un mètode d’accés diferent en lloc de darrere del portal. Una exempció per a tot el lloc és una decisió del propietari del portal, no una solució alternativa per a un informe.

Accepteu l’exportació, no el diàleg de desament

L’última comprovació és el fitxer mateix: s’obre, conté les columnes esperades i els seus totals coincideixen amb l’informe que l’usuari ha aprovat.

Que aparegui un diàleg de desament no és èxit, i un fitxer que s’obre amb un avís de reparació tampoc no és èxit. Compareu un recompte de files i un valor conegut amb l’informe a la pantalla, perquè una exportació truncada passa qualsevol prova que només miri la mida del fitxer. Després exporteu una segona vegada, perquè una capa de memòria cau que una vegada serveix el cos equivocat pot servir el correcte en el següent intent.

Accepteu el flux de treball que l’usuari necessitava, i res menys que això. Una descàrrega que s’obre a l’aplicació equivocada continua sent una exportació fallida.