Oracle BI Publisher Blog

Last time I wrote I was getting numbers on layout templates, I have now been looking at concurrent programs, my alarm at there being 9631 programs was realized - there really are that many in R12. What are they all? In Fusion BIP is going to be responsible for the 'reporting' programs, the concurrent manager, the 'processing' program. To you dear user, from a UI persepective no changes - a common, if dynamic interface to submit jobs. The need to try and characterize the programs is therefore important. 

Here's how they break out:

Still more than 3000 Oracle Reports based programs? I checked our 11i instance (numbers to the right) the numbers of OReports had risen in R12?
I then checked the enabled flag was set to 'Y' - that Concurrent Program form will not let you delete a CP only disable it. Running again with the flag set.

Ahhh thats better ... I thought we had removed some reports, nearly 200 is not bad. Come Fusion they will have all been converted!
So far I have been referring to Oracle Reports because I know that nearly all of them will produce some humanly readable output. But Im after the total number and type of 'reports' versus 'processes' e.g. invoice import. I guess I can lump the SQL*Plus CPs in with the reports. The big question is how many of those PLSQL procedures are generating report output - not that many Ill be bound. RXi reports use PLSQL to create the query but there is a 'Spawned' C program that actually generates the output but the plsql is related to reporting. Its tough to tell exactly, there are no nice flags saying 'Process' rather than 'Report' - thats gonna change in Fusion. Of those 3783 PLSQL objects lets guess at 300 ish. So of the 7855 CPs around 3000 are Report related thats about 38% of the total. I could be way off on the reporting plsql but there is no way to tell for sure without opening the plsql.

That's 3000 seeded objects we have to migrate to the Fusion BIP stack, of which, whenever I poll you folks out there on how many of them you use I get answers ranging from none to 100 - of course, you all use a different set of 100 so we need to support the migration for all of them anyway ... joy!

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 ...    

We have had a busy few daze here at Fusion Publisher central. We have been working on the 11g Publisher release that will be the 'Fusion Publisher' version - loads of testing of the UI with 'select * from emp' being the order of the day for a while. These last four days we have not been selecting * from emp, ohhh no! We have been getting into 20 query reports (I kid you not) and 40 parameter reports, not kidding here either - took me 10 mins just to fill out the damn parameters!

There are some of those 40 parameters!

Its all good, we have been working with the Financials development team, they handed over about 15 reports and told us to get on with it! Being the cunning fellows that we are, we have built a migration utility to take the R12 data template based reports and migrate them to the new fusion model. We actually went the whole hog and migrated all of the R12 data template based reports but dont tell the finapps team! It's not quite all there, it does not yet grab the report definition from the concurrent manager and supporting value sets and migrate those but thats not far off.

Migrating is the easy part- knowing the report and R12 EBS functionally so you can run the danged thing is a whole other ball game. My background is in Financials development, so I have dredging up all sorts of useful facts I accumulated over the years that are now not relevant in the new world that is R12. Thankfully, we did not have to get data into Apps to generate the reports - that was the FinApps team responsibility!

For those of you in EBS, you'll know that Publisher has a Data Defnition that maps to a concurrent program on the concurrent manager (CM) side and we assign templates to it. You'll also know that the CM orchestrates the whole process from calling the extract program to calling Publisher to format. In fusion it will still call us but we will have everything defined on our side so its a simple 'hey Publisher! Run report A' we'll get the data, format the data, deliver the report. We're talking just printing either, you can email, fax, print, etc. Deliver multiple times, once to customer say and another to your favored document repository replete with meta data to describe it so for the itinerant customer who claims thay have lost your invoice can be sent another with COPY striped through it, post haste!

For those of you using the 10.x standalone release we have made some changes - we have separated the report from the data object. This will allow you to create data models (the new name) that can support multiple reports. So you might have 40 parameters on the extract but each report may only need to fill say 10 of them, the rest will either carry default or null values and be hidden from the user - a step in a good direction we think.

I dont think Fusion is on so many of your lips for now but its front and centre for us and somehow, especially for me, for the next few months - all good clean fun!

Ever wondered, in an idle moment, how Publisher got started? Maybe not, but if you head on over to Ashish's shiny new Oracle blog you'll find out. Ashish recently moved back to India and then to a new (or old) team in Oracle Financials. Those of you that have met me have probably heard, several times, where my back ground lies. Ashish's is very similar, I might have a few years on him, inside Oracle and out and he definitely has more hair than I do but we go back a long way, to a small project called 'Financials Reporting Strategy.'

We both worked on a prototype with the Oracle Reports team to provide some means for the 'average' user to customize a report layout. I still have it on a drive and go back and fire it up occasionally and reminisce about the old days. Soon after that we were helping to build Publisher, the rest they say is history.

Get on over to Ashish's blog read it then bookmark it. Ashish is on the other side of the fence now, he's a customer, albeit an internal one, but will be sure to have golden nuggets of info to share and maybe even a glimpse of Fusion or three.