XML Publisher 5.6 Conclusions
I said the other week, when I wrote the first two articles about XML Publisher 5.6 Enterprise, that'd I'd come back in a few days to report on how straightforward it was to put together more complicated reports. I've been delayed since then by putting together the OTN article on XML Publisher but it's given me a good opportunity to put the product through it's paces. I've not had the chance to try out everything I wanted to but I've got a good idea now of how the product hangs together.
I'm my posting "XML Publisher 5.6 Enterprise : Producing My First Reports" I went through the process of firstly defining a template based on XML data, and then a template based on an SQL query. I then deployed the SQL-based template, together with the .xdo file that the SQL Report Wizard had created, to XML Publisher 5.6 Enterprise where I then viewed it. I wasn't able to get the XML-based report to deploy as it had to run against an XML file accessed via HTTP or a Web Service, neither of which I had handy, and I wasn't quite sure how you went about generating the .xdo file for the XML template, which was generated for you automatically for SQL queries by the Report Wizard.
What I know now is this: for SQL-based reports, you can generate both the template file, and the .xdo file that brings together the template, the data source, translations and parameters, using the Report Wizard. This wizard creates all of the files for you and places them in a directory on the filesystem. The wizard then gives you a default template layout which you can then reformat, change the colours and fonts, add additional charts or indeed additional tables or text areas.
If you want to upload this report to XML Publisher Enterprise 5.6, you then go into the XML Publisher 5.6 Web interface and then firstly upload the .xdo file, and then the template file (below). When you've done this you can then run the report from your Web browser.
With XML-based reports, it's a slightly different process. You firstly lay out your template file as before, but using an extract of the XML document that you will eventually run the report against. The idea here is that you obtain an extract with say 50 customers in it, or 50 products, or something like that, and lay the report template items out against that. Then, after you've saved the template file to the filesystem, you go into XML Publisher 5.6 Enterprise and use the Web interface to create your report (below).
What you're doing here is creating what will become your .xdo file - but at this point it's empty. You then go into the Edit option for the report and specify the data source (which is the actual XML feed, not the extract file you built the template from), upload the template file you created earlier, and define any parameters and lists of values.
You can make this whole process a bit more integrated by creating a WebDAV folder over the directory in your application server that XML Publisher 5.6 Enterprise saves it's report definitions and template files to, and using that as the place where you save your template files and .xdo files when you use the Microsoft Word Add-in. Once you've figured all of this out, it's fairly simple to build and run most kinds of reports.
Once or twice I got execution errors when trying to run reports for the first time, and the error message that XML Publisher comes up with is fairly vague and non-committal ("The report cannot be rendered because of an error, please contact the administrator."). The way to find out what's really happened is to enable debugging output on the J2EE application server that's running XML Publisher, to do this you need to edit the xmlp-server-config.xml file under j2ee\home\applications\xmlpserver\xmlpserver\WEB-INF and update the DEBUG_LEVEL to ERROR, then bounce the application. From that point on you can refer to the Java stack trace to work out what's gone wrong.
I had a go at putting together a dashboard in the same style as the demo one provided by Oracle and I had mixed success. By dissecting the template file provided by Oracle it became clear that the basis of the template was built using Microsoft Word, with the page orientation set to landscape and the page size set a bit wider than normal. It became clear though after a bit of playing around that this sort of report requires you to step outside of the Word template wizards and start coding in the markup language that XML Publisher comes with - XML Publisher has an RTF Template Parser that takes tags and markup language that you either generate automatically using the Word add-in, or code yourself, and turns this into XSL-FO which then gets rendered by the XML Publisher reporting engine. From speaking to the product guys, whilst the dashboard is more than do-able it's not something you'd normally put together using Word, it's more of an experienced user task where you understand the tags and markup language that XML Publisher uses.
I was able to test out the online running of the XML-based reports by copying the XML extract file into the \j2ee\home\applications\xmlpserver\xmlpserver directory of the application server, and then referencing it via a http://localhost:8888/xmlpserver/InvoiceListing.xml URL. I haven't tried out accessing data via a Web Service but I'm sure I could knock something up via JDeveloper or PL/SQL if needed.
One final thing that I found fairly impressive was the security and scheduling. I won't go into too much detail as it'll spoil the OTN article but it was very straightforward to create users (although not tied in with SSO users), assign them to roles and then grant access to folders to these roles. One gotcha was that access is granted to folders, not reports, and therefore you have to put all reports with the same access profile into a folder, or sub-folders within other folders, to create granular access to data.
Anyway, hopefully the article should be out in a month or so to correspond with the full production release. That's it for me for XML Publisher for a while, on to Oracle Warehouse Builder next...