Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » BIRT » Best practice for managing design, test and production environments
Best practice for managing design, test and production environments [message #886524] Fri, 15 June 2012 05:37 Go to next message
Paul Ramsden is currently offline Paul Ramsden
Messages: 79
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 Go to previous messageGo to next message
Jason Weathersby is currently offline Jason Weathersby
Messages: 9167
Registered: July 2009
Senior Member

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 #888421 is a reply to message #886808] Mon, 18 June 2012 05:24 Go to previous messageGo to next message
Paul Ramsden is currently offline Paul Ramsden
Messages: 79
Registered: February 2011
Location: BW, Germany
Member
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 Smile

Paul
Re: Best practice for managing design, test and production environments [message #888771 is a reply to message #888421] Mon, 18 June 2012 15:48 Go to previous message
Jason Weathersby is currently offline Jason Weathersby
Messages: 9167
Registered: July 2009
Senior Member

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
Previous Topic:BIRT timezone value
Next Topic:XML DataSource report with XML tag as parameter
Goto Forum:
  


Current Time: Sun Sep 21 16:07:54 GMT 2014

Powered by FUDForum. Page generated in 0.09356 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software