OpenDocument API

Passing parameter information from Web Intelligence Report into Winform

Posted on Updated on

A little background, we are doing some R&D for integrating Business Objects Reports into a .Net windows application. In this post, I’m using a WebBrowser control opens a Web Intelligence report using the OpenDocument API.

During a discussion about a week ago, there was an interesting question raised, from a hyperlink, can we pass some values from the report into the winform?

An idea that came to me was using HTML Bookmark (#) where the major benefit is the page will not be posted back or navigated into somewhere else. So if I can construct something like  <a href=”#parametervalue”> for the hyperlink, I should be able to capture this value in the WebBrowser Navigating event and don’t have to worry about post back issue ;)

Now the problem lays on the creation of the hyperlink, in the screen shot below, the =[City] function will not be parsed with the City value for the current row, but it will be parsed as raw string/text instead.


So what we need to add is only adding the question mark (?) behind the #, so that the values can be parsed correctly into the hyperlink, notice in the screen shot below that the custom param is specified in the Customize URL parameters instead of in the URI itself like previously in the example above.


And there you go, once the link is clicked, it will actually triggered WebBrowserNavigatedEventHandler (WebBrowserNavigatingEventHandler also works) then we can capture the bookmark value and parse the customparam value

void webBrowser1_Navigated(object sender, WebBrowserNavigatedEventArgs e)
    txtURL.Text = e.Url.Fragment;
    // Use ParseQueryString will automatically decode the special characters, Substring(1) is to exclude the (#) character
    txtParameter.Text = HttpUtility.ParseQueryString(e.Url.Fragment.Substring(1))["customparam"];


An interesting request/feature I would say ;)

Business Objects – OpenDocument API – C# Code snippet to construct the URL parameters for the prompts

Posted on

Code snippet below will be useful to construct the URL parameters for OpenDocument API where the prompt name and value will also be URLEncoded.

        /// <summary>
        /// Prompt types defined in OpenDocument API
        /// </summary>
        public enum InputParameterType

        /// <summary>
        /// Construct the URL parameter for the prompt
        /// </summary>
        private static string ConstructParam(string promptName, string value, InputParameterType paramType)
            string paramFormat = "&ls{0}{1}={2}";
            string prefix = null;

            switch (paramType)
                case InputParameterType.MultiValue:
                    prefix = "M";
                case InputParameterType.Range:
                    prefix = "R";
                    prefix = "S";

            return string.Format(paramFormat, prefix, HttpUtility.UrlEncode(promptName), HttpUtility.UrlEncode(value));

        /// <summary>
        /// Provide simple overload with Single prompt type as the default
        /// </summary>
        private static string ConstructParam(string promptName, string value)
            return ConstructParam(promptName, value, InputParameterType.Single);

Business Objects – OpenDocument API – URL Length Limitation Gotcha

Posted on Updated on

Based on the OpenDocument documentation, It has a limitation below:

Link length limit

The encoded URL cannot exceed 2083 total characters. 

Where this is actually the maximum URL Length for Internet Explorer as well.

This has been a concern to me since this will eventually limit the parameter values that can be passed into the report in the URL, especially for multiple values.

This morning, I was testing on the passing multi values parameters into the report using OpenDocument and when I specified more parameter values for a multiple value prompt, the report panel just simply hang (running forever) with the hourglass icon :(

When I checked the constructed URL, to my surprise, it was only 1341 characters in total length, so what went wrong then? My assumptions are either :

  1. The report was not able to handle too many values for the multi values prompts -> Negative, tested by adding a very long dummy param into the URL for a working link and the report then stopped working.
  2. Some internal processes affected the URL and in the end it exceed the limit (2083) -> Positive, I noticed that when we passed the URL into the browser, actually there are some internal processes happenning before the report is rendered into the screen.

Supporting Evidences

I tried to view the source for the report which is hanging.


And in the end of the file (image below), I found one javascript function which seems to have an URL string as the parameter so I suspect that this is actually the part where it will render the report to the screen. 


The length of URL is 2054 characters where if I add the whole path, I assume it will definitely more than 2083 characters.

Which means from the URL has changed from 1341 into 2054+, where additional parameters / query strings have been added within the OpenDocument internal processes.

I might be wrong with this, but it is best if you check this out yourself when you have a report which accepts long multi values for the parameters.

I was actually thinking to use POST instead of GET to access the OpenDocument page, however it won’t help because it will also fail in the same end because of the OpenDocument internal processes will construct URL string (GET) :|

Business Objects – OpenDocument API – An error has occurred: An error occured while trying to view the document

Posted on Updated on

If you get this error when trying to use OpenDocument API to open up a Web Intelligence report (this is my case), you may be using iDocId parameter like I did.
Try using the sDocName parameter with the report name instead, it worked for me that way after scratching my head for several hours ;)

**Update: Turned out that the parameter name is case sensitive, after I changed the parameter from iDocId to iDocID, it’s working fine now ;)