Supporting Multiple SQL Servers [message #1048395] |
Wed, 24 April 2013 12:08  |
Sebastiaan Hendriks Messages: 13 Registered: March 2013 Location: Netherlands |
Junior Member |
|
|
I'm working on a Eclipse Scout project that uses BIRT for the reporting functionality.
One of the requirements is that reports are generated over one or more SQL servers. The actual connection information is to be passed to the report at runtime, since the actual SQL servers being used upon creation of the report can differ.
So, lets say that I have a report that produces a report over multiple databases at the same time. During the designing of the report, I create multiple JDBC datasources along with the accompanying reportparameters (SqlUrl1, SqlUrl2, ect)
These parameters are then filled at runtime and passed on to the BIRT engine so that BIRT can build one or more connections.
This means that I'll have multiple parameters per datasource, cluttering up the parameter list for each report. Along with the required code in my application to add every single parameter to a HashMap to be added to task.setParameterValues(). It is doable, but if possible, I would prefer a different approach.
Such as the following. I came across the option to add a complete Connection object to the BIRT runtimes for BIRT to execute the queries in the report, namely adding the connection to the AppContext.
AbstractSqlService service = SERVICES.getService(myDBSqlService.class);
Connection conn = service.getConnection();
task.getAppContext().put("OdaJDBCDriverPassInConnection", conn);
Now my question is this. Is there a way to add multiple connection objects to the AppContext? And if that is possible, how can I tell BIRT that a certain connection should be used for a certain Dataset?
[Updated on: Wed, 24 April 2013 12:11] Report message to a moderator
|
|
|
Re: Supporting Multiple SQL Servers [message #1048505 is a reply to message #1048395] |
Wed, 24 April 2013 15:06   |
|
You should be able to pass as many connection details as you want over the AppContext. As for telling BIRT which one to use, if you open your dataSource and go to the property binding tab, there are expression builders available to dynamically define your connection. Let me know if I'm misunderstanding the question.
Michael
Developer Evangelist, Silanis
|
|
|
Re: Supporting Multiple SQL Servers [message #1049215 is a reply to message #1048505] |
Thu, 25 April 2013 14:12   |
Sebastiaan Hendriks Messages: 13 Registered: March 2013 Location: Netherlands |
Junior Member |
|
|
Michael Williams wrote on Wed, 24 April 2013 17:06You should be able to pass as many connection details as you want over the AppContext.
If it is indeed possible to pass on multiple Connection Objects to the Appcontext, how would I be able to do that? Something like this?
List<Connection> connectionList = someServiceOrClass.getConnectionList<Connection>();
task.getAppContext().put("OdaJDBCDriverPassInConnectionList", connectionList );
Since I havent found any documentation (yet) on what I can pass on to the AppContext, I'm simply guessing weither "OdaJDBCDriverPassInConnectionList" is a option or not.
Michael Williams wrote on Wed, 24 April 2013 17:06As for telling BIRT which one to use, if you open your dataSource and go to the property binding tab, there are expression builders available to dynamically define your connection. Let me know if I'm misunderstanding the question.
That sounds quite similar to passing the connection details to BIRT using Report Parameters. Seeing as a Connection Object isnt predefinded in a report definition, where-as a Report Parameter is, how would I be able to access the Connection Object then?
|
|
|
Re: Supporting Multiple SQL Servers [message #1050012 is a reply to message #1049215] |
Fri, 26 April 2013 15:19  |
|
I've not tried it with a list, but I don't see a reason why it wouldn't work.
You would just access this through the reportContext, like: reportContext.getAppContext().get("OdaJDBCDriverPassInConnectionList");
Michael
Developer Evangelist, Silanis
|
|
|
Powered by
FUDForum. Page generated in 0.02002 seconds