locked
Issue with Decomposition tree and image corruption. RRS feed

  • Question

  •  

    First off, my apologies if my question is not phrased correctly - this is due to my limited knowledge on Proclarity. Have been brought in to troubleshoot an issue at a client where a decomposition tree is rendering correctly. However whenever a user drills down into specific nodes (these translate to specific users in AD), the screen changes and shows a screen without the image (just the +,- links and the broken image tag in the browser) for the individual nodes. I have discovered that the ***.png file that Proclarity is generating is for some reason getting corrupt (ie either it doesn't finish building the file or something with the data is causing Proclarity to not complete it's process of generating the image on the fly). The way I have confirmed this is if I use Firefox/Internet Explorer and view the frame info, the .png file is showing up as unknown with a size of 0 bytes. Additionally if I modify the url to point directly to the png file, it throws a 500 Internal server error. If I however modify the url to point to a png file for one of the other nodes that is generated, this is displayed correctly in the browser as the image file I'd expect.

    So question to the guru's out there
    a) Does this sound familiar? Is there a patch that fixes this (I tried installing SP2 for Proclarity 6 today and it didn't make any difference).

    b) Is there a setting I can change in either global.asa or in the registry?

    c) Can someone maybe point me in the right direction as to where else to look?
    d) Is there any additional information I can provide which might help?


    Please also note that in general Proclarity is working as expected with other reports, I am able to consistently reproduce this problem on the same node without any issues. If I log in as the user who's node is not working, his version of the report is being generated correctly.

    Thanks in advance for any help that I can get.

    Sanjay

    Friday, December 5, 2008 5:05 AM

Answers

  • Just a  follow up on this issue. I discovered using Fiddler that the image that was always generated for DecompImage3 (if you view the source you can see the listings of the *.png files) was always corrupt (if you navigate to the image directly via a browser you'd get a 500 Error on the page.
    I have confirmed that the query is not corrupt - if this was the case, I believe I'd see the error across the report and not just on specific nodes being expanded.
    The fix I've had to do was modify the GetDecompChartSize function in pbExecDecomp.js to identify whether an image about to be loaded is corrupt or not. If it is corrupt then I loop through the array of images and pick one which is not corrupt.
    I do think this is some type of limitation within the product itself especially since it's only happening with specific images (while others are fine).
    If anyone (from MS) is interested, I can provide more details as needed.

    Thanks for your help Sean in pointing out the Fiddler tool and giving me an idea of what to do.

    Sanjay
    asian_warrior
    • Marked as answer by Sean_Flanagan Thursday, December 18, 2008 3:55 PM
    Saturday, December 13, 2008 5:08 AM

All replies

  •  

    Hi Sanjay,

     

    This does sound perplexing..  If it's only specific AD users that are having the problem on all workstations, it could be security related, somewhere.  If the problem is restricted to a specific workstation instead of a user then I'd focus throubleshooting the workstation itself.  As a first step you could run a Diagnostic report and catch some fiddler traces of broken and working scenarios and compare.  Fiddler is a free tool and feel free to post the traces on this thread for us to look at.  Also, more specific information would be helpful as well.

     

    Sean

    Tuesday, December 9, 2008 6:32 PM
  • Sean - thanks for the response regarding my first post. I have tried Fiddler and the issue is not machine specific or user specific. Here is what is more perplexing - I was able to resolve the issue by fixing the width of the generated image (in pbexecDecomp.js) inside the PBDecompChartSize function and this resolved the issue. Basically I could not use anything above 751 pixels as a valid width.
    This solution has worked for a couple of days but now we're down to 521 in pixel size and we're still getting the issue intermittently. The main problem (I think) lies in the generation of the *.png file that is used for the background of the decomp tree image. For some reason, this image is not viewable in a browser (if you go to it by the link directly - ie localhost/PAS/cache/a5/XXXXX.png when it is broken in the report. However for any of the levels that do show up correctly, I can navigate to the image using the same method and it shows up fine. To me (and my limited knowledge), this implies that maybe the image is not being fully generated during the calculations that Proclarity is using to build the image and consequently there is some corruption in the image file which is causing it to not get loaded.
    Again, this is from my limited knowledge of Proclarity in general so apologies if something sounds really novice like...


    Thanks

    Sanjay

     

    Wednesday, December 10, 2008 9:37 PM
  • Just a  follow up on this issue. I discovered using Fiddler that the image that was always generated for DecompImage3 (if you view the source you can see the listings of the *.png files) was always corrupt (if you navigate to the image directly via a browser you'd get a 500 Error on the page.
    I have confirmed that the query is not corrupt - if this was the case, I believe I'd see the error across the report and not just on specific nodes being expanded.
    The fix I've had to do was modify the GetDecompChartSize function in pbExecDecomp.js to identify whether an image about to be loaded is corrupt or not. If it is corrupt then I loop through the array of images and pick one which is not corrupt.
    I do think this is some type of limitation within the product itself especially since it's only happening with specific images (while others are fine).
    If anyone (from MS) is interested, I can provide more details as needed.

    Thanks for your help Sean in pointing out the Fiddler tool and giving me an idea of what to do.

    Sanjay
    asian_warrior
    • Marked as answer by Sean_Flanagan Thursday, December 18, 2008 3:55 PM
    Saturday, December 13, 2008 5:08 AM
  • Sanjay, thanks for posting your steps and the resolution you found.  Did you see any corruption issues with the unmodified version of the PBDecompChartSize function, or only after it was modified from its original configuration?  I'm not very familiar with this function and have personally not every modified it nor seen corruption issues like this, but kudos to you for working through the problem.  For internal investigation we'd need to have this repro'd in our lab to investigate if something is wrong with ProClarity, or if this was a problem with the way the function was modified.  And no, it doesn't sound novice like : )

    Cheers,

    Sean
    Microsoft ProClarity | This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, December 18, 2008 3:39 PM
  • Sean - so more good news. I was able to narrow this problem down even more - In our specific case, we were not using the Windows Authentication mode - We used the PImpersonate.dll logic that has been posted previously on the internet to pass through the AD credentials for the user. One of the steps for getting the alternate model to work was to modify the registry and changing the SSOEnabled value to 1 instead of it's default of 0. In our case if we did this, the broken images would start appearing. So you guys should be able to reproduce this easily in the labs using the SSOEnabled key in the registry and setting it's value to 1 to get the broken images.

    Sanjay
    asian_warrior
    Thursday, December 18, 2008 8:08 PM