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 ओळखण्याइतके दाखवते.

त्याचा कोणताही भाग सामायिक करण्यापूर्वी सत्र कुकीज आणि टोकन काढा. कार्यरत निर्यातीचे कॅप्चर उपयुक्त पुरावा आहे, आणि दुसऱ्याच्या सत्राचे कॅप्चर ही घटना आहे.

अपवाद खात्यावर नाही, अनुप्रयोगावर मर्यादित करा

पोर्टल प्रतिसाद पुन्हा लिहित असेल किंवा अडवत असेल, तर मोहवणारा उपाय म्हणजे संपूर्ण साइटला सूट देणे किंवा अहवाल अनामिक करणे. दोन्ही डाउनलोड दुरुस्त करतात आणि पोर्टल असण्याचे कारण काढून टाकतात. मर्यादित अपवाद एक अनुप्रयोग मार्ग, एक सामग्री प्रकार आणि एक दिशा नाव देतो, आणि धोरणाचा मालक असलेल्यासाठी तो पुनरावलोकनयोग्य राहतो.

तुम्ही प्रत्यक्षात चालवत असलेली गेटवे आवृत्ती आणि तिची दस्तऐवजीकृत अनुप्रयोग सेटिंग्ज वापरा. विक्रेत्याने एकदा रहदारी अपरिवर्तित सोडणारा असे वर्णन केलेला पर्याय ही सामान्य सूचना नाही, आणि जुन्या फोरम थ्रेडमधून त्याची नक्कल करणे हा तात्पुरता अपवाद कायमचा स्थापत्य होण्याचा मार्ग आहे.

अपवाद इतका संकुचित मर्यादित करता येत नसेल, तर निर्यात बहुधा पोर्टलच्या मागे नाही, वेगळ्या प्रवेश पद्धतीसह अंतर्गत मार्गाचा आहे. संपूर्ण साइटची सूट हा पोर्टल मालकाचा निर्णय आहे, एका अहवालासाठीचा पर्यायी उपाय नाही.

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

शेवटची तपासणी फाइल स्वतःच आहे: ती उघडते, अपेक्षित स्तंभ ठेवते, आणि तिच्या बेरजा वापरकर्त्याने मंजूर केलेल्या अहवालाशी जुळतात.

जतन संवाद दिसणे हे यश नाही, आणि दुरुस्ती इशाऱ्यासह उघडणारी फाइलही यश नाही. स्क्रीनवरील अहवालाशी ओळींची गणना आणि एक ज्ञात मूल्य यांची तुलना करा, कारण कापलेली निर्यात केवळ फाइल आकार पाहणाऱ्या प्रत्येक चाचणीत उत्तीर्ण होते. नंतर दुसऱ्यांदा निर्यात करा, कारण एकदा चुकीची बॉडी देणारा कॅश स्तर पुढील प्रयत्नात योग्य ती देऊ शकतो.

वापरकर्त्याला आवश्यक असलेला कार्यप्रवाह स्वीकारा, आणि त्यापेक्षा कमी नाही. चुकीच्या अनुप्रयोगात उघडणारे डाउनलोड तरीही अयशस्वी निर्यात आहे.