Glimpses of Fusion
By Tim Dexter-Oracle on May 02, 2008
Spent some time this morning with one of our star developers ... well they all are in my opinion. But Incheol has been tasked with coming up with the BIP Fusion integration. Things are changing in Fusion with respect to the BIP architecture and for end users when it comes to reporting but its good change I assure you.
Rather than the embedded approach we have right now in 11i/12, where templates are managed by BIP but report defnitions are in the realm of the concurrent processing UI and schema. In Fusion there will be complete report definitions managed by the BIP server ie extracts, templates, parameters, etc. Im not getting into the details of LOVs here, in 11i/12 LOVs or ValueSets are not just used in report submission but get leveraged all over the place so we're still nailing the 'where, when and how' down for those, so dont ask ... yet!
With the server on the outside of apps the development process will be much much smoother and we think faster, without the need to go to a report definition form in one app, then to an extract definition program, then to a layout definition program, then to the XMLP UI to upload said objects - its all in one place, the BIP server with, data extract building tools, connectivity to the desktop template building tools and even an online template builder so you never need to leave the comfort of your favorite browser!
Getting back to Incheol, he has been working on some of the integration between BIP and Fusion Apps and how developers will create reports and make them available to users and then how users will be able to invoke said reports. There are 3 scenarios that have been identified so far:
1. Ability to schedule a report
2. View an existing instance of a previously run report
3. Run a report from a link ie run it immediately
The first and second are being worked on in conjunction with the scheduling team, Incheol has been looking at the third scenario from an end user perspective but focusing on the developer experience.
The links to reports in this image will not sit in their current position - there are plans to have a common region on the page that will list pertinent reports for the page or the users current role - so ignore the position of the links. Its whats going on under the links thats important. When the link is clicked the data from the associated ADFbc component ie a VO is extracted and the relevant report is called via a BIP API that in turn calls the report on the server via a web service call. The data is passed along with template and output required, the server runs the report and returns the output requested.
This is a little different to other scenarios where the report is called and the BIP server extracts, formats and delivers. Here we are essentially telling the BIP server that we already have the data so just format it for us and pass back the output so dont deliver it.
The returned report will have all of the data present in the VO and not just what you can view on the page itself. The ADFbc will handle all the security required to generate the appropriate data set for the current user. We'll be turning this into a common component that development teams and customers alike can embed in their pages.
A small glimpse of whats coming and as we get more concrete I'll try and share more ...