Eating your own dogfood – use of Oracle Development tools within the Oracle Applications development group

Reporting: birth of a new tool: XML Publisher

For Reporting there is very interesting news. Apps is shortly switching over to a new reporting framework, called XML Publisher.

Reporting has always been somewhat of a challenge for Oracle Apps. They did not seem to be able to get it exactly right for all customers. Either they needed additional data – or less – on the report or they wanted different layout or output formats.

Apps has decided on a different course, whereby there will be a fairly rigid separation between content – which data must be in the report – and the layout – what should it look like. Existing RDF (report definition files) will be used as definition of the content: they contain the SQL queries etc. that specify what data is assembled for creating the report. The second step, morphing the content in the desired layout and output format, will be performed by XML Publisher. The content is published by the Reporting Engine as an XML Document. XML Publisher takes the XML, applies an XSL-T Stylesheet and renders the result in one of many output-formats, such as PDF, text-file, HTML, Excel-format etc.

Apps will ship a substantial library of stylesheets for creating generally desirable outputs for the reports. These will replace the RDF files where it comes to defining layout and look and feel. There are currently no plans for a tool that can automatically convert RDFs into XSL-T templates. Customers can very easily customize the standard Apps reports by editing the XSLTs. Oracle Apps will still take care of providing the data that is presented in the report, though of course by editing the underlying RDF-file (or its successor format).

Currently, XML Publisher is not planned to have a UI, a graphical XSL-T editor. You can use (plug in?) your own 3rd party XSL-T Editor to create the stylesheets used by XML Publisher to render the report.

John told me that in the US many Government agencies are already publishing XSL-T stylesheets that allow organizations to create reports such as Tax-forms in the layout required by the federal agencies. He expects many more such stylesheets to become available in the near future.

I am not exactly sure what functionality XML Publisher will offer over and above standard XSL-T transformation engines. I suppose at least better management facilities.

An interesting reversal of the XML Publisher functionality could be the following: A PDF Form – in the same layout as would be produced by XML Publisher when reporting data – is used to allow users to enter data. John gave the example of Clinical Trials where paper-forms are filled in over and over again. An electronic form in exactly the same layout can be produced using a PDF Form. The input in this form could then be returned to the XML Publisher Engine that would strip away the layout and produce the content (filled in data) as end result.

XML Publisher will also be bundled with the Oracle 10g Database in the near future, which makes it available to non-Apps customers. John could not give me an exact timeline for this bundling.

Open Source

Student Registration system – almost a Student specific ERP. Open Source initiative from University of Ohio. John stresses that the challenge of ERP-type applications is not so much development – as hard as that can be – but primarily the implementation. Working with the customer, configuring the software for the specific requirements of individual organisations etc. He does not believe in an Open Source model for the implementation effort – which would basically mean people coming to your site, implementing the software and not charging any money for that.

He did describe an Open Source style project Oracle is contemplating and may be sponsoring in the near future. It does not deal with Open Source Software Development, but instead entails an Open Source project for Content Gathering and Management. Oracle Health Care, a module for Hospitals, Doctors etc., has to deal with lots of medical terminology. One of the characteristics of that terminology is that it widely varies across the globe and even across universities, research facilities, private hospitals and public facilities. Terms used for medicines, protocols, diagnoses, treatments etc. vary a lot even though they may refer to the same things. To make Oracle Health Care useful to a wide audience, the system should be able to ‘translate’ between the various ‘dialects’. That means, it needs to have a humongous dictionary or repository with all relevant terms in all dialects.

Oracle is contemplating to start and sponsor an Open Source project that will build up such a knowledge base of medical terminology. Of course its contents would be available to the world – that is the open source part of it – and it would allow Oracle to deliver a widely useful Health Care Module. In this case, it seems hardly viable for Oracle by itself to gather all contents for such a repository.

When I asked him specifically about Oracle Apps’s stance on adopting Open Source technology, the likes of Struts, he specified that there is no policy against using these components. Each component is evaluated based on its own merits.

Standards & Guidelines and Reusable Frameworks

I asked John whether the enormous experience gathered in the Apps development organization with use of Oracle technology and doing Oracle based development could not somehow be shared with the rest of the world. Undoubtedly Apps must have assembled piles of Standards & Guidelines, Hints and Tricks, Checklists and reusable components, utilities etc.

He told me that indeed they are working on plans to publish first of all a number of their development frameworks to allow Apps customer developing extensions to the Apps product to use the same frameworks Apps developers themselves use.

Slightly further down the line, they also intend to make Standards & Guidelines available, for Programming with Oracle Technology and for User Interface design. Currently, they are editing their Standards and Guidelines, mainly for two reasons:

1. some of the guidelines are not phrased in a way that Oracle thinks should be exposed to customers (“You are an idiot if you do it this way�), though it may get the message across
2. more importantly, many of the guidelines may assume a certain base knowledge of technology, terminology and implicit ways of working that without rephrasing them, they would not be clear enough for outsiders

John could not specify exactly when they would start making these documents available. The decision of shipping them only to Apps customers or publishing them on OTN for the rest of us, like the BLAF guidelines, is also still pending.

Miscellaneous

I asked John whether Apps makes use of HTML DB or intends to make use of it. He started with an elalorate answer in which he explained all the strengths of HTML DB and then concluded: we have no plans for using it.

John spoke briefly about an effort going on between Apps and the ServerTech department, responsible for developing the database, that addresses upgrade challenges. With Apps implementations getting more and more globalized – heavily pushed by Oracle itself, recommending customers to consolidate their worldwide IT activities in globalized data centers with global instances of the E-Business Suite – downtime as a result of upgrades must be minimized. A substantial portion of unavailability of Apps instances as part of an upgrade is caused by the invalidation and subsequent recompilation of zillions of PL/SQL packages. Apps and ServerTech are looking at ways that prevents a large portion of the need for this recompilation.

Apps of course are a big user of the Oracle Workflow engine in the database server – I believe they practically invented it. With the recent acquisition by Oracle of Collaxa’s BPEL product, many people wonder about the future of Workflow and Oracle’s ProcessConnect product. John did not have details at this point – nor has anybody else I have spoken about this – but it seems inevitable, he said, that some sort of merger between these products will come about. Given the fact that BPEL is an industry standard, the Oracle BPEL process manager seems likely to lead the way in such a synthesis. Apps will not rush into a migration away from Workflow – is my impression.

Remaining Questions

Some questions I had planned to ask but did not have time for:

How is development organized? Do you apply XP principles?
Do Apps developers participate in discussion forums such as the ones on OTN? Do they go out and share their experience in articles or presentations during conferences?
How are developers in Apps organization trained and kept up to speed with new technological developments?
What tools is Apps using within the development environment, for testing, quality control, incident management?

What is Apps’ position on implementation of Business Rules – data oriented business logic in specific. Should that be in all tiers (client, middle and server)? Or should that be inside the database and where necessary for user feedback reasons sometimes in the Client? Does Apps make use of Declarative Database Constraints (as far as I know they did not do so in the past, has that changed?)? If not, why not? What is the Apps way of enforcing constraints?

Do you intend to make intensive use of the Java integration features in Oracle Forms?
How is your software configuration management process organized? Based on what tools? (I believe to know that a technology that has the same roots as the product we know as Oracle Software Configuration Manager, often used in conjunction with Oracle Designer, is the cornerstone in the SCM for both the Apps and ServerTech divisions. Staff previously from the Oracle Designer & Oracle Repository teams in the UK now work on this technology).