Establishing a baseline example
Because there are so many variations of how to configure various components, I'm going to use the following assumptions for a Forms and Reports development-to-deployment environment.
- Your 6i forms have been successfully migrated to a 9i/10g state ("10g" will refer to both versions)
- You are using Application Server 10g Forms and Reports Services (the steps here work for the full scale version as well) and everything will be on one server
- When Reports were used in your 6i client-server environment, the reports were called via a "Run Report" button on a form or via a report filter type of form (it also uses a "Run Report" button after the user inputs parameter type of information)
- You want Reports on the Web to appear in a new browser window, and that browser window has its "normal" buttons removed (when the user is finished viewing, saving, or printing the report, the user closes the browser window and returns to the report-calling browser window)
- If a user wants to save a report, he has to click on the Save button (reports appear as PDF documents), and reports cached or saved on the Application Server machine are not intended to be directly accessed by users
The above sounds like a lot of restrictions or assumptions, but it really boils down to a fairly simple - and easy to install/configure - environment. If your primary task is to get things working as soon as possible, then you just bought into a happy meal. Later on, when you have time to sit back and figure out how you are going to spend the raise you got for turning your Oracle-based application into a Web product, you can experiment with ordering the big chicken dinner (SSO, a separate report server machine, using the "other" report server, and so on).
The code to make a report run on the web
Let's clarify the difference between parameters and data. Parameters tell the report how it is supposed to run or display. Data is what the report shows. How you provide the data to make a report run is up to you. How you provide the parameters falls into two categories: those required by Oracle, and those you want or need. Further, several items that you used to pass in as parameters under 6i are now required to be set using a built-in with 10g. The best way to describe the code is to show an example. Some of what is shown below comes from an example Oracle has in a note on MetaLink. The code below is what you can put behind a "Run Report" button. I formatted some comments with a different font to help point out what is taking place. There's nothing worse than reading dry code, so that's another reason for all of the comments.
The code above looks like a lot, but the good news is that the procedure is virtually 100% reusable. If you standardize your Forms and Reports development environment, all that needs to be changed here is the name of the report, and even then, you can pass that in to the procedure via the code behind when-button-clicked for the "Run Report" button. Your calling Form needs to have a report object added to it (that's covered in Oracle's documentation) in addition to having a "reportserver" parameter (the name of the report server).