XML Publisher: Aargh! Another reporting tool for Oracle Apps

There is alot of hype and expectation being generated around Oracle XML Publisher and the use of it within the Oracle eBusiness Suite (Oracle Applications).

Having developed a number of reports with it specifically for Customer facing documentation, I can safely say some of this hype is deserved. The major benefit of the product from my perspective is the separation of the data and presentation.

Combine this with the ability to take an Oracle Reports report, switch it into XML mode without change, and feed the output into Oracle XML Publisher an you have a very attractive package. Of course, the ability to output the given data into a variety of formats is also immensely beneficial. This has long been a drawback of concurrent manager based Oracle Applications reports and so the ability to output a report to Microsoft Word, Excel, PDF is also excellent.

However, at the end of the day it is just another reporting tool. It has its quirkiness, limitations and suitability for given scenarios.

Some of the considerations having used the product are:

• Its position relative to Oracle Reports. Oracle Reports is a very powerful and mature product. There is a huge amount of functionality and capabilty built into Oracle Reports that either does not exist in XML Publisher or cannot be done in XML Publisher. As time goes by this gap may diminish, but like the old saying "if it ain't broke, don't fix it", I wouldn't go coverting Oracle Reports to XML Publisher unless there is a very specific business need to do so. Primarily this would be when the User base need to define their own layouts based on a known dataset.
• Data Model Knowledge. The major obstacle with developing reports for Oracle Applications / Oracle eBusiness Suite is the fact that the data model is hugely complex and lacking in constraints - primary, foreign keys etc to guide the uninitiated. Oracle XML Publisher doesn't solve the issues around this and currently doesn't provide anything like the End User Layer (EUL) meta-data of Oracle Discoverer. I'm keen to put some effort into this arena, so watch this space AppsReports.
• Robustness given its time in the market. As with all things software, market maturity is something that takes time. I must say that for something I used the first time a number of months ago, it worked very well and I had few problems I couldn't overcome with a bit of delving into related issues, plus a heap of trial and error.
• Versions and Features. My first few experiences were with Oracle XML Publisher version 5.0 where the feature list was relatively small compared to the latest releases. Within the context of Oracle Applications, many companies are "patch adverse" meaning regular software updates to technology stack components are minimised. So my advice would be get the latest available certified version for XML Publisher and apply the patch before you start your foray into XML Publisher. Check out Certify on Metalink
• Watch your file size. Almost all standard Oracle Applications reports are character based, and usually use up a heap of trees. If you take a character report and add high definition layout objects, the filesize will blow out. I had an RTF template given to me to use as a basis that had equivalent of a 5Mb company logo in it. Doh! Of course hardware is cheap, but the impact must be taken into account for things such as this, and developers beware.

More and more I am finding that the work required to develop customizations to, and maintain Oracle Applications is decreasing. The right decisions on tools and design make a huge difference in cost, quality and time to implement. New features such as Oracle XML Publisher, Forms Personalizations and the like need to be utilized wherever possible.

If you are wondering about the various reporting tools, what is best in a given situation, and how you can enhance the level of reporting in your enterprise, visit our Virtuate or AppsReports websites or drop me an email.

We have experience reporting with Oracle Developer(Oracle Forms, Oracle Reports), Oracle Discoverer, Oracle XML Publisher, Financial Statement Generator FSGs, Oracle Application Express (APEX) / HTML DB, Noetix, Oracle Application Desktop Integrator (ADI) amongst others.

Bananas and Requirements Specification

During a stressful week I recently discovered a new way for me to work out what day of the week it is. At the start of each week I bring in 5 bananas to eat for breakfast, one for each day of the week. So I can work out what day it is based on how many bananas there are left on my desk, ie: 4 = Monday 3 = Tuesday 2 = Wednesday 1 = Thursday 0 = Friday So let's call this Gareth's Banana Calendar. That got me thinking about something in some text I was researching at the time. In the text, the author kept commenting in his text about how "the perceptive reader would notice x,y,z" based on details he just wrote. And that got me thinking how there is a very strong relation to this and how Software Developers interpret requirements, that is in order to get the rules right they need to interpret the business rules presented to them. However the perceptive developer will not only take the rules strictly, but also apply considerations to the rules, and if there is something they consider relevant that would brake or change the rules, then they should probe further for more detailed requirements or try it out. So the perceptive developer would realize there are a number of shortcomings to consider about Gareth's Banana Rule and seek answers. E.g. How do you work out what day it is if there is a public holiday during the week? Keen to hear what anyone else thinks about Gareth's Banana Rule ;-)