Fmap Image Not Shown When Printing to PDF only – Fmap Function Showing White Space Instead – Image Can be Seeing in Dashboard

I also had this problem (Thank you very much people at Oracle’s support):

When using the function @{fmap:images/my_image.jpg} no image is being returned on the PDF version of the report.

Image is properly shown in the dashboard screen.

It only happens with one Presentation Service and Web Server. The other one works fine.

No custom skins/styles used.

War file has already been redeployed.

Already have tested many things: paths, permissions, fmap syntax, war/ear webserver redeployment, invoking image url, copying image file from one server to the other, testing with different image files, smaller and bigger ones, testing with less data, using the fmap in different areas of the Dashboard (footer, narrative, title), verifying there is no custom style in Dashboard properties, etc.

Results are always the same: the image is shown in the dashboard but not in PDF print.

No error message reported in sawlog0.log.

Cannot see images when printing to pdf only. The image can be seen in the dashboard, and its direct URL shows the image fine too.

Is there a particular setting to get the images in PDF? A particular path PDF format uses that is different to the one used to show the image in the dashboard? Any additional path where the image needs to be copied? Something particular to Websphere?

Could you point us to where to look or how to get better detailed information on what is happening when printing to pdf when looking for the instance of the image? We have tried with different image files, very small ones, and copying the image that works from one server to the other. Customer also redeployed his war file after adding the image.

Could you give us any pointer to where to look or how to get better log info or how the printing to pdf looks for the image?

1. OBIEE Development provided the following answer for you:
”
Make sure the path to the file used by fmap is fully qualified (i.e. a complete path). The problem is likely because the PDF generation process which is being generated in the Javahost process, doesn’t have access to the same path.

The path to the file must be the same for both the Presentation Server, and also available to the Javahost process. If they’re on different servers then this will need to be a path that is common to both systems.

A fully qualified path would typically satisfy this requirement, but this really is dependent on the customers environment, and the permissions granted to each process. A webserver doesn’t necessarily have access to a fully qualified path, and the Javahost process may well have the same problem.

So the easy solution may be to duplicate the image file on the javahost server, and try to figure out a path where both the Presentation Server and Javahost server see the “same” file.
”

Please, review and follow it.

They also suggested to verify this image be downloaded to other file types. That is, it is shown when printing to html, or downloading to other file types.

Also, make sure adobe version to download to pdf is the same in both the environments. the one that works and the one that does not.

2. Additionally, you could, access the working environment via a web browser in Answers, open the HTML source code (like right-click and View Page Source (or View Image Info) in FireFox or View Source in MS IE) and search for the image.
you will see the HTML source like:
<img border=0 src=”analyticsRes/s_customSkin/mydirectory/my_image.jpg”> or
<img border=”0″ src=”res/s_oracle10/images/my.gif”>

Compare the values in both footers, for your working and not working environment.
The source of the image in the working environment should give a clue of the relative directory there. You could try to place the image in the same location on the non-working environment (see point 1 first).

3. Additionally, as a test, you could place the image in an accessible virtual directory via websphere (i.e. http://server/domain:port/virtualdir/../../mi_image.gif) and then in Answers, test with a URL mapping instead of the fmap. That is, try pointing the image as a URL instead of an fmap.

4. You could also look in the javahost log to search for errors thrown when the issue is reproduced.
They are all the log files in the following directory:

<install_drive>\OracleBIData\web\log\javahost

They are multiple and OBIEE rotates then.

5. Given that one environment is working and another is not, please, review your webserver/oc4j  mappings of both environments (in this case they were using Websphere). Moreover in relation to point 1. Websphere mappings and access given to process, fall outside of OBIEE scope.