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 پہچاننے کے لیے کافی دکھاتی ہے۔

اس کا کوئی بھی حصہ شیئر کرنے سے پہلے سیشن کوکیز اور ٹوکن ہٹائیں۔ فعال برآمد کی ریکارڈنگ مفید ثبوت ہے، اور کسی اور کے سیشن کی ریکارڈنگ ایک واقعہ ہے۔

استثنا کو اکاؤنٹ پر نہیں، ایپلیکیشن پر محدود کریں

اگر پورٹل جواب دوبارہ لکھتا یا روکتا ہے، تو آزمائشی مرمت پوری سائٹ کو چھوٹ دینا یا رپورٹ کو گمنام کرنا ہے۔ دونوں ڈاؤن لوڈ درست کرتے ہیں اور پورٹل کے ہونے کی وجہ ہٹا دیتے ہیں۔ محدود استثنا ایک ایپلیکیشن راستہ، ایک مواد کی قسم اور ایک سمت کا نام دیتا ہے، اور پالیسی کے مالک کے لیے یہ جائزے کے قابل رہتا ہے۔

وہ گیٹ وے ورژن استعمال کریں جو آپ واقعی چلاتے ہیں اور اس کی دستاویزی ایپلیکیشن ترتیبات۔ کوئی آپشن جسے وینڈر نے ایک بار ٹریفک کو غیر تبدیل شدہ چھوڑنے والا بتایا تھا عام ہدایت نہیں ہے، اور پرانے فورم تھریڈ سے اس کی نقل کرنا ہی وہ راستہ ہے جس سے عارضی استثنا مستقل فن تعمیر بن جاتا ہے۔

اگر استثنا کو اتنے تنگ دائرے میں محدود نہیں کیا جا سکتا، تو برآمد غالباً پورٹل کے پیچھے نہیں، مختلف رسائی طریقے والے اندرونی راستے کا ہے۔ پوری سائٹ کی چھوٹ پورٹل مالک کا فیصلہ ہے، ایک رپورٹ کے لیے کوئی متبادل راستہ نہیں۔

برآمد قبول کریں، محفوظ کرنے کا ڈائیلاگ نہیں

آخری جانچ فائل خود ہے: یہ کھلتی ہے، متوقع کالم رکھتی ہے، اور اس کے مجموعے صارف کی منظور شدہ رپورٹ سے میل کھاتے ہیں۔

محفوظ کرنے کا ڈائیلاگ نظر آنا کامیابی نہیں، اور مرمت کی انتباہ کے ساتھ کھلنے والی فائل بھی کامیابی نہیں۔ اسکرین پر موجود رپورٹ کے ساتھ قطاروں کی گنتی اور ایک معلوم قدر کا موازنہ کریں، کیونکہ کٹی ہوئی برآمد ہر اس جانچ میں پاس ہو جاتی ہے جو صرف فائل کے حجم کو دیکھتی ہے۔ پھر دوبارہ برآمد کریں، کیونکہ ایک بار غلط باڈی پیش کرنے والی کیش پرت اگلی کوشش میں درست پیش کر سکتی ہے۔

صارف کو درکار ورک فلو قبول کریں، اور اس سے کم نہیں۔ غلط ایپلیکیشن میں کھلنے والا ڈاؤن لوڈ اب بھی ناکام برآمد ہے۔