2

I'm trying to go about setting up my BIRT reports and the iServer they sit on such that the database the Data Sources connect to are determined by the environment. Our setup is that currently there is just one iServer instance and many environments running a tomcat webapp that hit it (this may be the problem...).

Essentially the ideal is that the report connects differently in these places:

  1. Local developement, which is running a local tomcat instance of the application which talks to the iPortal/iServer. Local database, but should be able to easily change to other databases for debugging etc.
  2. QA deploy, qa database
  3. Production deploy, production database

I've seen two options for how to fix this:

  1. First option is to bind the Data Source to a configuration file in resources somewhere. Problem here is that if you have only one iServer, its resources are local to the server it is on, and not where the webapp. So, if I understand it correctly, this does not provide the flexibility I'm looking for.
  2. Second option is to pass in all the connection info as report parameters and get the application to determine the correct parameters to send in. This way the application could pull from a local configuration file. This option would work, but I'm weary of the security (or lack thereof) in passing around connection info/credentials.

Does anyone have a better option? Or have people just run local iServer instances for developement? I can see running an iServer for each environment may simplify this issue and allow the reports released to production to be updated and tested in a QA environment without disrupting production, so maybe that is the solution.

Cœur
  • 37,241
  • 25
  • 195
  • 267
KurToMe
  • 166
  • 1
  • 6

2 Answers2

1

One possible approach would be to set each of the connection properties conditionally in the Property Binding section of the Edit Data Source dialog, based on the value of a hidden parameter indicating which environment is to be accessed.

An example of this approach can be found here.

  • Thanks, I had forgotten about that option. I don't think it's what I'll use but it is a good alternative. I think I may wind up passing in the `Connection Profile Store URL` as a report parameter as a path to the connection profile file. This is needed because the path will be different in each environment. As long as that and the `Connection Profile Name` are set it should work. – KurToMe Mar 06 '12 at 18:19
  • I tried something similar but I'm now having difficulties getting cascading parameters to work as the connection environment is not yet defined.... – paul Aug 23 '12 at 09:38
1

You mention that you are looking for an option for development, including the possibility of a local iServer. I think this would be overkill. Do you Dev & initial testing in BIRT; you do not need an iServer to run the report. If you need resources on the iServer to run & test the report you can reference those through the Server explorer in BIRT Pro. Once you are ready to deploy, I would follow Mark's strategy above using property bindings on the data source itself. That is as close to a best practice as exists for this migration requirement as exists in BIRT.

MystikSpiral
  • 5,018
  • 27
  • 22
  • This is pretty much the conclusion we wound up with. We haven't fully implemented anything yet, but when we do I'll try to come back with a description of our full solution in case people are curious. – KurToMe Mar 09 '12 at 15:04