A exportação do SSRS falha através de um portal VPN sem cliente: o que muda

O relatório abre no navegador, os parâmetros são renderizados e o botão de exportação produz um erro, um download vazio ou um ficheiro que a folha de cálculo se recusa a abrir. Essa combinação tem uma forma padrão. Uma página de relatório funcional testou a renderização e a autenticação, e nada mais. A exportação é um pedido separado com a sua própria resposta, e através de um portal sem cliente também atravessa uma camada de reescrita que nunca foi concebida para downloads de ficheiros.

Dois caminhos, uma página funcional

Renderizar e exportar são operações diferentes, mesmo quando começam no mesmo botão. O servidor de relatórios renderiza a página para um navegador e prepara a exportação através de outra extensão de saída, com o seu próprio tipo de conteúdo e o seu próprio comportamento perante erros, como descreve a documentação de exportação. Um portal que deixa passar perfeitamente a primeira ainda pode estragar a segunda, porque a segunda é uma resposta que o portal não esperava ver. As duas partilham uma sessão e um endereço, e quase nada mais.

Trate a página funcional apenas como prova de autenticação e alcançabilidade. Prova que a conta consegue chegar ao servidor de relatórios e que o portal reencaminha HTML. Não diz nada sobre respostas de ficheiros, cabeçalhos de disposição do conteúdo ou redirecionamentos que terminam num download em vez de num documento.

É toda a razão para comparar o caminho de exportação isoladamente em vez de testar novamente a página que já funciona. Dois pedidos que partilham uma sessão continuam a ser dois pedidos.

Três condições que decidem onde a exportação falha

Três perguntas localizam a falha rapidamente, e cada resposta aponta para um proprietário diferente.

Primeiro, o mesmo relatório, conta e formato são exportados corretamente a partir da rede interna? Se sim, o servidor de relatórios e o seu renderizador estão bem e a diferença está no caminho de acesso. Segundo, a resposta falhada transporta um tipo de conteúdo de ficheiro, ou uma página HTML com uma extensão de ficheiro? Isso separa um erro do renderizador de uma substituição do portal. Terceiro, o portal reescreve o URL do pedido ou remove cabeçalhos da resposta? Um URL reescrito pode aterrar num ponto final completamente diferente.

Responda às três antes de alterar qualquer definição, porque cada uma tem um remédio diferente. Uma falha do renderizador pertence ao servidor de relatórios, um corpo substituído pertence ao portal, e um cabeçalho removido é uma questão de política, não um erro.

Anote as respostas. Um caso de suporte construído com essas três linhas vale dez capturas de ecrã.

Leia a resposta de exportação em vez do código de estado

Um estado HTTP bem-sucedido prova apenas que algo respondeu ao pedido. Inspecione o corpo e os cabeçalhos em conjunto, porque a falha interessante é uma resposta bem-sucedida com o conteúdo errado.

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

A descarga de cabeçalhos mostra o tipo de conteúdo e qualquer disposição do conteúdo devolvida pelo portal. O comando file identifica o que o corpo realmente é, e um ficheiro de texto onde se esperava uma folha de cálculo é a clássica página de início de sessão substituída. O comando head mostra o suficiente para reconhecer HTML sem despejar um relatório inteiro num terminal.

Remova os cookies de sessão e os tokens antes de partilhar qualquer parte disso. Uma captura de uma exportação funcional é uma prova útil, e uma captura de uma sessão pertencente a outra pessoa é um incidente.

Limite a exceção à aplicação, não à conta

Se o portal reescreve ou bloqueia a resposta, a reparação tentadora é isentar todo o site ou tornar o relatório anónimo. Ambas corrigem o download e removem a razão pela qual o portal existe. Uma exceção delimitada nomeia um caminho de aplicação, um tipo de conteúdo e uma direção, e continua a ser revisível por quem possui a política.

Use a versão do gateway que realmente executa e as suas definições de aplicação documentadas. Uma opção que um fornecedor descreveu uma vez como deixando o tráfego inalterado não é uma instrução geral, e copiá-la de um tópico antigo de fórum é como uma exceção temporária se torna arquitetura permanente.

Se a exceção não puder ser delimitada de forma tão estreita, a exportação provavelmente pertence ao caminho interno com um método de acesso diferente, e não atrás do portal. Uma isenção para todo o site é uma decisão do proprietário do portal, não um contorno para um relatório.

Aceite a exportação, não a caixa de diálogo Guardar

A última verificação é o próprio ficheiro: abre, contém as colunas esperadas e os seus totais correspondem ao relatório que o utilizador aprovou.

O aparecimento de uma caixa de diálogo Guardar não é sucesso, e um ficheiro que abre com um aviso de reparação também não é sucesso. Compare uma contagem de linhas e um valor conhecido com o relatório no ecrã, porque uma exportação truncada passa em todos os testes que só olham para o tamanho do ficheiro. Depois exporte uma segunda vez, porque uma camada de cache que uma vez serve o corpo errado pode servir o correto na tentativa seguinte.

Aceite o fluxo de trabalho de que o utilizador precisava, e nada menos do que isso. Um download que abre na aplicação errada continua a ser uma exportação falhada.