I have had a long running email thread running between Dan and David over at Valspar and myself. They have built some impressive connectivity between their in house apps and BIP using web services. The crux of their problem has been that they have multiple databases that need the same report executed against them. Not such an unusual request as I have spoken to two customers in the last month with the same situation. Of course, you could create a report against each data connection and just run or call the appropriate report. Not too bad if you have two or three data connections but more than that and it becomes a maintenance nightmare having to update queries or layouts. Ideally you want to have just a single report definition on the BIP server and to dynamically set the connection to be used at runtime based on the user or system that the user is in.

A quick bit of digging and help from Shinji on the development team and I had an answer. Rather embarassingly, the solution has been around since the Oct 2010 rollup patch last year. Still, I grabbed the latest Jan 2011 patch - check out Note 797057.1 for the latest available patches. Once installed, I used the best web service testing tool I have yet to come across - SoapUI. Just point it at the WSDL and you can check out the available services and their parameters and then test them too.

The XML packet has a new dynamic data source entry. You can set you own custom JDBC connection or just specify an existing data source name thats defined on the server.

<pub:runReport>
 <pub:reportRequest>
  <pub:attributeFormat>xml</pub:attributeFormat>
  <pub:attributeTemplate>0</pub:attributeTemplate>
  <pub:byPassCache>true</pub:byPassCache>
  <pub:dynamicDataSource>
   <pub:JDBCDataSource>
   <pub:JDBCDriverClass></pub:JDBCDriverClass>
   <pub:JDBCDriverType></pub:JDBCDriverType>
   <pub:JDBCPassword></pub:JDBCPassword>
   <pub:JDBCURL></pub:JDBCURL>
   <pub:JDBCUserName></pub:JDBCUserName>
   <pub:dataSourceName>Conn1</pub:dataSourceName>
   </pub:JDBCDataSource>
  </pub:dynamicDataSource>
  <pub:reportAbsolutePath>/Test/Employee Report/Employee Report.xdo</pub:reportAbsolutePath>
 </pub:reportRequest>
 <pub:userID>Administrator</pub:userID>
 <pub:password>Administrator</pub:password>
</pub:runReport>

So I have Conn1 and Conn2 defined that are connections to different databases. I can just flip the name, make the WS call and get the appropriate dataset in my report. Just as an example, here's my web service call java code. Just a case of bringing in the BIP java libs to my java project.

publicReportServiceService = new PublicReportServiceService();
   PublicReportService publicReportService = publicReportServiceService.getPublicReportService_v11();
    String userID = "Administrator";
    String password = "Administrator";
    ReportRequest rr = new ReportRequest();
     rr.setAttributeFormat("xml");
     rr.setAttributeTemplate("1");
     rr.setByPassCache(true);
     rr.setReportAbsolutePath("/Test/Employee Report/Employee Report.xdo");
     rr.setReportOutputPath("c:\\temp\\output.xml");
   

     BIPDataSource bipds = new BIPDataSource();
     JDBCDataSource jds = new JDBCDataSource();
      jds.setDataSourceName("Conn1");
      bipds.setJDBCDataSource(jds);
     rr.setDynamicDataSource(bipds);
   

     try {
      publicReportService.runReport(rr, userID, password);
      }
     catch (InvalidParametersException e) {
      e.printStackTrace();
     } 

     catch (AccessDeniedException e) {
      e.printStackTrace();
     } 

     catch (OperationFailedException e) {
      e.printStackTrace();
     }


   }

Note, Im no java whiz kid or whizzy old bloke, at least not unless Ive had a coffee. JDeveloper has a nice feature where you point it at the WSDL and it creates everything to support your calling code for you.

Couple of things to remember:

1. When you call the service, remember to set the bypass the cache option. Forget it and much scratching of your head and taking my name in vain will ensue.
2. My demo actually hit the same database but used two users, one accessed the base tables another views with the same name. For far too long I thought the connection swapping was not working. I was getting the same results for both users until I realized I was specifying the schema name for the table/view in my query e.g. select * from EMP.EMPLOYEES. So remember to have a generic query that will depend entirely on the connection.

Its a neat feature if you want to be able to switch connections and only define a single report and call it remotely. Now if you want the connection to be set dynamically based on the user and the report run via the user interface, thats going to be more tricky ... need to think about that one!