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 ਪਛਾਣਨ ਲਈ ਕਾਫੀ ਦਿਖਾਉਂਦੀ ਹੈ।

ਇਸਦਾ ਕੋਈ ਵੀ ਹਿੱਸਾ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੈਸ਼ਨ ਕੂਕੀਜ਼ ਅਤੇ ਟੋਕਨ ਹਟਾਓ। ਕੰਮ ਕਰਨ ਵਾਲੇ ਨਿਰਯਾਤ ਦੀ ਕੈਪਚਰ ਲਾਭਦਾਇਕ ਸਬੂਤ ਹੈ, ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੇ ਸੈਸ਼ਨ ਦੀ ਕੈਪਚਰ ਇੱਕ ਘਟਨਾ ਹੈ।

ਅਪਵਾਦ ਨੂੰ ਖਾਤੇ ’ਤੇ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ’ਤੇ ਸੀਮਿਤ ਕਰੋ

ਜੇ ਪੋਰਟਲ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਜਾਂ ਬਲੌਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਲੁਭਾਉਣ ਵਾਲਾ ਸੁਧਾਰ ਪੂਰੀ ਸਾਈਟ ਨੂੰ ਛੋਟ ਦੇਣਾ ਜਾਂ ਰਿਪੋਰਟ ਨੂੰ ਗੁਮਨਾਮ ਬਣਾਉਣਾ ਹੈ। ਦੋਵੇਂ ਡਾਊਨਲੋਡ ਠੀਕ ਕਰਦੇ ਹਨ ਅਤੇ ਪੋਰਟਲ ਦੇ ਹੋਣ ਦਾ ਕਾਰਨ ਹਟਾ ਦਿੰਦੇ ਹਨ। ਸੀਮਿਤ ਅਪਵਾਦ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਰਾਹ, ਇੱਕ ਸਮੱਗਰੀ ਕਿਸਮ ਅਤੇ ਇੱਕ ਦਿਸ਼ਾ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਨੀਤੀ ਦੇ ਮਾਲਕ ਲਈ ਇਹ ਸਮੀਖਿਆਯੋਗ ਰਹਿੰਦਾ ਹੈ।

ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜੋ ਗੇਟਵੇ ਸੰਸਕਰਣ ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ ਉਸਦੀ ਦਸਤਾਵੇਜ਼ੀ ਐਪਲੀਕੇਸ਼ਨ ਸੈਟਿੰਗਾਂ ਵਰਤੋ। ਕੋਈ ਵਿਕਲਪ ਜਿਸਨੂੰ ਵਿਕਰੇਤਾ ਨੇ ਇੱਕ ਵਾਰ ਟ੍ਰੈਫਿਕ ਅਣਬਦਲਿਆ ਛੱਡਣ ਵਾਲਾ ਦੱਸਿਆ ਸੀ, ਆਮ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹੈ, ਅਤੇ ਪੁਰਾਣੇ ਫੋਰਮ ਥ੍ਰੈਡ ਤੋਂ ਇਸਦੀ ਨਕਲ ਕਰਨਾ ਹੀ ਅਸਥਾਈ ਅਪਵਾਦ ਨੂੰ ਸਥਾਈ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ ਦਾ ਰਾਹ ਹੈ।

ਜੇ ਅਪਵਾਦ ਨੂੰ ਇੰਨਾ ਤੰਗ ਸੀਮਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਨਿਰਯਾਤ ਸੰਭਵਤਾ ਨਾਲ ਪੋਰਟਲ ਦੇ ਪਿੱਛੇ ਨਹੀਂ, ਵੱਖਰੀ ਪਹੁੰਚ ਵਿਧੀ ਵਾਲੇ ਅੰਦਰੂਨੀ ਰਾਹ ਦਾ ਹੈ। ਪੂਰੀ ਸਾਈਟ ਦੀ ਛੋਟ ਪੋਰਟਲ ਮਾਲਕ ਦਾ ਫੈਸਲਾ ਹੈ, ਇੱਕ ਰਿਪੋਰਟ ਲਈ ਕੋਈ ਬਦਲਵਾਂ ਉਪਾਅ ਨਹੀਂ।

ਨਿਰਯਾਤ ਸਵੀਕਾਰ ਕਰੋ, ਸੇਵ ਸੰਵਾਦ ਨਹੀਂ

ਆਖਰੀ ਜਾਂਚ ਫਾਈਲ ਆਪ ਹੈ: ਇਹ ਖੁੱਲ੍ਹਦੀ ਹੈ, ਉਮੀਦ ਕੀਤੇ ਕਾਲਮ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਇਸਦੇ ਕੁੱਲ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤੀ ਰਿਪੋਰਟ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਸੇਵ ਸੰਵਾਦ ਦਿਖਣਾ ਸਫਲਤਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਮੁਰੰਮਤ ਚੇਤਾਵਨੀ ਨਾਲ ਖੁੱਲ੍ਹਣ ਵਾਲੀ ਫਾਈਲ ਵੀ ਸਫਲਤਾ ਨਹੀਂ ਹੈ। ਸਕ੍ਰੀਨ ’ਤੇ ਰਿਪੋਰਟ ਨਾਲ ਕਤਾਰ ਗਿਣਤੀ ਅਤੇ ਇੱਕ ਜਾਣਿਆ ਮੁੱਲ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਕੱਟਿਆ ਨਿਰਯਾਤ ਹਰ ਉਸ ਜਾਂਚ ਵਿੱਚ ਪਾਸ ਹੁੰਦਾ ਹੈ ਜੋ ਕੇਵਲ ਫਾਈਲ ਆਕਾਰ ਵੇਖਦੀ ਹੈ। ਫਿਰ ਦੂਜੀ ਵਾਰ ਨਿਰਯਾਤ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ ਵਾਰ ਗਲਤ ਬਾਡੀ ਦੇਣ ਵਾਲੀ ਕੈਸ਼ ਪਰਤ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਸਹੀ ਦੇ ਸਕਦੀ ਹੈ।

ਵਰਤੋਂਕਾਰ ਨੂੰ ਲੋੜੀਂਦਾ ਕਾਰਜ ਪ੍ਰਵਾਹ ਸਵੀਕਾਰ ਕਰੋ, ਅਤੇ ਉਸ ਤੋਂ ਘੱਟ ਨਹੀਂ। ਗਲਤ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਖੁੱਲ੍ਹਣ ਵਾਲਾ ਡਾਊਨਲੋਡ ਅਜੇ ਵੀ ਅਸਫਲ ਨਿਰਯਾਤ ਹੈ।