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 पहचानने के लिए पर्याप्त दिखाता है।

इसका कोई भी भाग साझा करने से पहले सत्र कुकीज़ और टोकन हटाएँ। कार्यशील निर्यात का कैप्चर उपयोगी प्रमाण है, और किसी और के सत्र का कैप्चर एक घटना है।

अपवाद को खाते पर नहीं, एप्लिकेशन पर सीमित करें

यदि पोर्टल प्रतिक्रिया को फिर से लिखता है या अवरुद्ध करता है, तो लुभावना उपाय पूरी साइट को छूट देना या रिपोर्ट को अनाम बनाना है। दोनों डाउनलोड ठीक करते हैं और पोर्टल के होने का कारण हटा देते हैं। सीमित अपवाद एक एप्लिकेशन पथ, एक सामग्री प्रकार और एक दिशा का नाम देता है, और जो नीति का मालिक है उसके लिए यह समीक्षा योग्य रहता है।

जिस गेटवे संस्करण को आप वास्तव में चलाते हैं और उसकी प्रलेखित एप्लिकेशन सेटिंग्स का उपयोग करें। कोई विकल्प जिसे किसी विक्रेता ने कभी ट्रैफ़िक को अपरिवर्तित छोड़ने वाला बताया था, सामान्य निर्देश नहीं है, और पुराने फ़ोरम थ्रेड से उसकी नकल करना ही वह तरीका है जिससे अस्थायी अपवाद स्थायी आर्किटेक्चर बन जाता है।

यदि अपवाद को इतना संकीर्ण सीमित नहीं किया जा सकता, तो निर्यात संभवतः पोर्टल के पीछे नहीं, भिन्न पहुँच विधि के साथ आंतरिक पथ का है। पूरी साइट की छूट पोर्टल स्वामी का निर्णय है, एक रिपोर्ट के लिए कोई कामचलाऊ उपाय नहीं।

निर्यात स्वीकारें, सहेजें संवाद नहीं

अंतिम जाँच फ़ाइल स्वयं है: यह खुलती है, अपेक्षित स्तंभ रखती है, और इसके योग उपयोगकर्ता द्वारा स्वीकृत रिपोर्ट से मेल खाते हैं।

सहेजें संवाद दिखना सफलता नहीं है, और मरम्मत चेतावनी के साथ खुलने वाली फ़ाइल भी सफलता नहीं है। स्क्रीन पर रिपोर्ट के साथ पंक्ति गणना और एक ज्ञात मान की तुलना करें, क्योंकि कटा हुआ निर्यात केवल फ़ाइल आकार देखने वाले हर परीक्षण में पास हो जाता है। फिर दूसरी बार निर्यात करें, क्योंकि एक बार गलत बॉडी परोसने वाली कैश परत अगले प्रयास में सही परोस सकती है।

उपयोगकर्ता को जिस कार्यप्रवाह की आवश्यकता थी उसे स्वीकारें, और उससे कम कुछ नहीं। गलत एप्लिकेशन में खुलने वाला डाउनलोड अभी भी विफल निर्यात है।