|Best practice for managing design, test and production environments [message #886524]
||Fri, 15 June 2012 01:37
| Paul Ramsden
Registered: February 2011
Location: BW, Germany
Is there a document / tutorial covering the best approach to take when developing reports which will run in different environments?|
For example, I have a number of reports which fetch data from web services. The web service may be deployed locally (when developing the service), on a test server (for integration tests) or on a production server. The service endpoint will vary accoringly.
BIRT will be installed on a separate server (2x: test and production) and reports called by URL.
What is the best way to manange this without having to modify the reports? A configuration file? A report parameter? ???
(using BIRT 3.7.2)
[Updated on: Fri, 15 June 2012 01:58]
Report message to a moderator
|Re: Best practice for managing design, test and production environments [message #888771 is a reply to message #888421]
||Mon, 18 June 2012 11:48
| Jason Weathersby
Registered: July 2009
I am not sure I understand the problem with connection profiles here.
You can design your report to use connprof.myconnectionprof which you
can then put in the resource folder. This may take a little script but
it is easy enough. If you use 4.2 (coming out later this month) no
script is even needed. Next the connprof file can be different for each
of your environments, as long as it has the same name you do not even
need to change anything in the report between different environments.
BTW BIRT also supports JNDI on jdbc connections that allow a pool of
connects to be created in each env and BIRT will use them.
On 6/18/2012 1:24 AM, Paul Ramsden wrote:
> thanks for the reply. I had already found that document but it's not
> really what I'm looking for. As I understand it, the connection profile
> store is just a way of securely saving all the connection details that a
> project might need. What I'm looking for is a way to set up a group of
> connections which can be replaced depending on the current target system.
> when designing I want to use con1_design and con2_design;
> when testing I want to use con1_test and con2_test;
> in production I want to use con1_prod and con2_prod;
> In the report I would just refer to con1 and con2 in an external
> resource. This resource would be target-dependant and contains the
> relevant connection details.
> Or perhaps I haven't understood your answer :)
Powered by FUDForum
. Page generated in 0.01910 seconds