| Best practice for managing design, test and production environments [message #886524] |
Fri, 15 June 2012 05:37  |
 Paul Ramsden
Messages: 84
Registered: February 2011
Location: BW, Germany |
Member |
|
|
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? ???
Thanks
(using BIRT 3.7.2)
[Updated on: Fri, 15 June 2012 05:58] Report message to a moderator |
|
|
| Re: Best practice for managing design, test and production environments [message #886808 is a reply to message #886524] |
Fri, 15 June 2012 17:03  |
|
I would use connection profiles in this case. They are stored
externally from the report and allow you to use different ones for
different environments.
Take a look at this article:
http://www.birtreporting.com/BIRT%20Connection%20Profiles.pdf
Jason
On 6/15/2012 1:37 AM, Paul Ramsden wrote:
> 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.
>
> What is the best way to manange this without having to modify the
> reports? A configuration file? A report parameter? ???
>
> Thanks
|
|
|
|
| Re: Best practice for managing design, test and production environments [message #888771 is a reply to message #888421] |
Mon, 18 June 2012 15:48 |
|
Paul,
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.
Jason
On 6/18/2012 1:24 AM, Paul Ramsden wrote:
> Jason,
> 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.
>
> e.g.
> 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 :)
>
> Paul
|
|
|
Powered by
FUDForum. Page generated in 0.02076 seconds
] 
Search
Help
Register
Login
Home
