SSRS નિકાસ ક્લાયન્ટ વિનાના VPN પોર્ટલ દ્વારા નિષ્ફળ જાય છે: શું અલગ છે

રિપોર્ટ બ્રાઉઝરમાં ખૂલે છે, પેરામીટર રેન્ડર થાય છે, અને નિકાસ બટન ભૂલ, ખાલી ડાઉનલોડ અથવા એવી ફાઇલ બનાવે છે જે સ્પ્રેડશીટ ખોલવાની ના પાડે છે. આ સંયોજનનો પ્રમાણભૂત આકાર છે. કાર્યક્ષમ રિપોર્ટ પૃષ્ઠે રેન્ડરિંગ અને પ્રમાણીકરણની પરીક્ષા કરી છે અને બીજું કંઈ નહીં. નિકાસ એ પોતાના પ્રતિભાવ સાથેની અલગ વિનંતી છે, અને ક્લાયન્ટ વિનાના પોર્ટલ દ્વારા તે એવા ફરીથી લખવાના સ્તરમાંથી પણ પસાર થાય છે જે કદી ફાઇલ ડાઉનલોડ માટે રચાયું ન હતું.

બે માર્ગ, એક કાર્યક્ષમ પૃષ્ઠ

રેન્ડરિંગ અને નિકાસ ભિન્ન ક્રિયાઓ છે, જ્યારે તેઓ એક જ બટનથી શરૂ થાય ત્યારે પણ. રિપોર્ટ સર્વર બ્રાઉઝર માટે પૃષ્ઠ રેન્ડર કરે છે અને નિકાસને પોતાના સામગ્રી પ્રકાર અને પોતાના ભૂલ વર્તન સાથેના અલગ આઉટપુટ એક્સ્ટેન્શન દ્વારા રેન્ડર કરે છે, જેમ નિકાસ દસ્તાવેજીકરણ વર્ણવે છે. જે પોર્ટલ પ્રથમને સંપૂર્ણ પસાર કરે છે તે બીજાને તોડી પણ શકે છે, કારણ કે બીજો એ પ્રતિભાવ છે જે પોર્ટલ જોવાની અપેક્ષા રાખતું ન હતું. બંને એક સત્ર અને એક સરનામું વહેંચે છે, અને લગભગ બીજું કંઈ નહીં.

કાર્યક્ષમ પૃષ્ઠને ફક્ત પ્રમાણીકરણ અને પહોંચનો પુરાવો ગણો. તે સાબિત કરે છે કે ખાતું રિપોર્ટ સર્વર સુધી પહોંચી શકે છે અને પોર્ટલ HTML આગળ મોકલે છે. તે ફાઇલ પ્રતિભાવો, સામગ્રી સ્થાન હેડરો કે દસ્તાવેજને બદલે ડાઉનલોડમાં પૂરા થતા રીડાયરેક્ટ વિશે કંઈ કહેતું નથી.

એ જ કારણ છે કે નિકાસ માર્ગની અલગથી સરખામણી કરવી જોઈએ, પહેલેથી કામ કરતા પૃષ્ઠને ફરી પરખવાને બદલે. જે બે વિનંતીઓ એક સત્ર વહેંચે છે તે હજી બે વિનંતીઓ છે.

ત્રણ શરતો જે નક્કી કરે છે કે નિકાસ ક્યાં તૂટે છે

ત્રણ પ્રશ્નો ખામીને ઝડપથી સ્થાન આપે છે, અને દરેક જવાબ ભિન્ન માલિક તરફ ઈશારો કરે છે.

પ્રથમ, શું એ જ રિપોર્ટ, ખાતું અને ફોર્મેટ આંતરિક નેટવર્કથી યોગ્ય રીતે નિકાસ થાય છે? જો હા, તો રિપોર્ટ સર્વર અને તેનું રેન્ડરર ઠીક છે અને તફાવત પ્રવેશ માર્ગમાં છે. બીજું, શું નિષ્ફળ પ્રતિભાવ ફાઇલ સામગ્રી પ્રકાર ધરાવે છે, કે ફાઇલ એક્સ્ટેન્શન પહેરેલું HTML પૃષ્ઠ? તે રેન્ડરર ભૂલને પોર્ટલની બદલીમાંથી અલગ પાડે છે. ત્રીજું, શું પોર્ટલ વિનંતીનું URL ફરીથી લખે છે કે પ્રતિભાવમાંથી હેડરો કાઢે છે? ફરીથી લખાયેલું URL સંપૂર્ણપણે ભિન્ન અંતિમ બિંદુ પર ઉતરી શકે છે.

કોઈપણ સેટિંગ બદલતા પહેલાં ત્રણેયના જવાબ આપો, કારણ કે દરેકનો ઉપાય ભિન્ન છે. રેન્ડરર ખામી રિપોર્ટ સર્વરની છે, બદલાયેલી બોડી પોર્ટલની છે, અને કાઢી નાખેલી હેડર ભૂલ નહીં, નીતિનો પ્રશ્ન છે.

જવાબો લખી રાખો. તે ત્રણ લાઇનમાંથી બનેલો સપોર્ટ કેસ દસ સ્ક્રીનશોટ જેટલો છે.

સ્થિતિ કોડને બદલે નિકાસ પ્રતિભાવ વાંચો

HTTP સફળ સ્થિતિ ફક્ત એ સાબિત કરે છે કે કંઈકે વિનંતીનો જવાબ આપ્યો. બોડી અને હેડરો સાથે તપાસો, કારણ કે રસપ્રદ ખામી એ ખોટી સામગ્રી ધરાવતો સફળ પ્રતિભાવ છે.

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

હેડર ડમ્પ સામગ્રી પ્રકાર અને પોર્ટલે પરત કરેલી કોઈપણ સામગ્રી સ્થિતિ દર્શાવે છે. file આદેશ ઓળખે છે કે બોડી ખરેખર શું છે, અને જ્યાં સ્પ્રેડશીટની અપેક્ષા હતી ત્યાં ટેક્સ્ટ ફાઇલ એ ક્લાસિક બદલાયેલું સાઇન-ઇન પૃષ્ઠ છે. head આદેશ સંપૂર્ણ રિપોર્ટ ટર્મિનલમાં રેડ્યા વિના HTML ઓળખવા જેટલું દર્શાવે છે.

તેનો કોઈપણ ભાગ શેર કરતા પહેલાં સત્ર કૂકીઝ અને ટોકન દૂર કરો. કાર્યક્ષમ નિકાસનું કેપ્ચર ઉપયોગી પુરાવો છે, અને બીજા કોઈની સત્રનું કેપ્ચર ઘટના છે.

અપવાદને ખાતા પર નહીં, એપ્લિકેશન પર મર્યાદિત કરો

જો પોર્ટલ પ્રતિભાવને ફરીથી લખે છે કે અવરોધે છે, તો લાલચભર્યો ઉપાય આખી સાઇટને મુક્ત કરવી કે રિપોર્ટને અનામી બનાવવો છે. બંને ડાઉનલોડ સુધારે છે અને પોર્ટલ હોવાનું કારણ દૂર કરે છે. મર્યાદિત અપવાદ એક એપ્લિકેશન માર્ગ, એક સામગ્રી પ્રકાર અને એક દિશાનું નામ આપે છે, અને જે નીતિ ધરાવે છે તેના માટે તે સમીક્ષાપાત્ર રહે છે.

તમે ખરેખર ચલાવો છો તે ગેટવે આવૃત્તિ અને તેની દસ્તાવેજીકૃત એપ્લિકેશન સેટિંગ્સ વાપરો. વેન્ડરે એક વખત ટ્રાફિક અપરિવર્તિત છોડતો હોવાનું વર્ણવેલો વિકલ્પ સામાન્ય સૂચના નથી, અને જૂના ફોરમ થ્રેડમાંથી તેની નકલ કરવી એ કામચલાઉ અપવાદને કાયમી આર્કિટેક્ચર બનાવવાનો માર્ગ છે.

જો અપવાદને આટલો ચુસ્ત મર્યાદિત કરી શકાય નહીં, તો નિકાસ સંભવતઃ પોર્ટલ પાછળ નહીં, ભિન્ન પ્રવેશ પદ્ધતિ સાથે આંતરિક માર્ગની છે. આખી સાઇટની મુક્તિ પોર્ટલ માલિકનો નિર્ણય છે, એક રિપોર્ટ માટેનો વૈકલ્પિક ઉપાય નહીં.

નિકાસ સ્વીકારો, સેવ ડાયલોગ નહીં

છેલ્લી તપાસ ફાઇલ પોતે છે: તે ખૂલે છે, અપેક્ષિત કોલમ રાખે છે, અને તેના કુલ વપરાશકર્તાએ મંજૂર કરેલા રિપોર્ટ સાથે મેળ ખાય છે.

સેવ ડાયલોગ દેખાવો સફળતા નથી, અને સમારકામ ચેતવણી સાથે ખૂલતી ફાઇલ પણ સફળતા નથી. સ્ક્રીન પરના રિપોર્ટ સાથે પંક્તિ ગણતરી અને એક જાણીતી કિંમતની સરખામણી કરો, કારણ કે કપાયેલી નિકાસ ફક્ત ફાઇલ કદ જોતી દરેક પરીક્ષામાં પાસ થાય છે. પછી બીજી વાર નિકાસ કરો, કારણ કે એક વાર ખોટી બોડી પીરસતું કેશ સ્તર આગલા પ્રયાસમાં સાચી પીરસી શકે છે.

વપરાશકર્તાને જે કાર્યપ્રવાહની જરૂર હતી તે સ્વીકારો, અને તેનાથી ઓછું નહીં. ખોટી એપ્લિકેશનમાં ખૂલતું ડાઉનલોડ હજી નિષ્ફળ નિકાસ છે.