By Tim Dexter-Oracle on Dec 03, 2010
Congrats to Glen Ryen for winning Brent's ticket to OAUG 11 over on Brent's blog. Thanks to all of you for the comments on some of the challenges you face with BIP/XMLP. I have passed those on to the product management team. I wanted to try and address some of the issues and comment on them.
We have two main issues using BIP in conjunction with the 11i Oracle E-Biz suite. The first is the conversion of 6i reports to BIP and the second is user adoption. It has been a real struggle to adjust the user from the straight forward method of delivery using Oracle Reports to the options provided through BIP.
Up front, yes the Reports converter needs some work. Having used it in anger with a few customers I have got frustrated with the outputs from the converter. The data side is pretty good in terms of the data template generated. The generated pl/sql packages from the Oracle Reports trigger do have some challenges but are not insurmountable. The RTF layouts generated often present more of an issue. Some of the layouts are a complete waste of time. The issue is that in Oracle Reports there tend to be an abundance of frames. In RTF these have to be mapped to a table. If you have repeating frames nested inside fixed frames, these will map to nested tables inside the RTF. If you use the report wizard in Oracle Reports you can build reports with multiple levels of nesting, the resulting template will be a complete mess at best. What I have found to be useful is to open the Oracle Report before converting and strip out as many extraneous frames as possible. Once this is done the resulting RTF is a lot more useful and does not need to be thrown away.
To Rob's other point, I'd be interested to hear more about the lack of user adoption. Inside EBS, I think that the integration with the concurrent manager is pretty good. There is an extra step if the user does not want the default output format but that's a small price to pay to get far more flexibility over output formats. Comments please!
To Sidh's points:
A hyperlink opening in a new window.
Clob column in excel sheet
With HTML outputs you do have the control but with other formats its not supported. That's an enhancement and I have logged that recently.
For the CLOB column not rendering correctly in Excel. For my CLOB, Im hitting another issue:
My data looks like it is wrapping until I turn on the grid for the sheet. You can see that each sentence in my clob is assigned its own cell. Using a collapse white space command in the template gets rid of this and I can replicate the problem Sidh is seeing. As many of you know, the Excel output from an RTF template is actually XHTML. There is not much we can do to help solve the issue and get Excel to wrap the contents in the cell. The only thing I can thinkg of right now is to use a true Excel template. That way you have complete control over how a cell renders its data.
To the Glen's points:
For the EBS version, I'd add some small points:
1) Template version control during development. It would be helpful if the seeded XML Publisher Administrator pages would display the file size, last updated date, and/or version number of the RTF or eText template that you uploaded. Had to work around with scripts.
2) Ability to generate PCL from the template, for printer tray control, duplex printing, etc. This would also eliminate the need for a third-party bolt-on to get a true hardware secured digital signature on AP checks. The workaround of mapping a specific drive letter to a plugged-in USB drive on the AP clerk's PC is difficult to achieve when the apps and/or network infrastructure is hosted by a third party.
3) Reports development on pre-printed stationary. The examples you can find on the web work well, but the process is a lot more complex than it needs to be.
1. Versioning is not supported in the Template Manager and do not think file size is stored anywhere but getting at the other columns should be exposable using the customization framework in OAF.
2. There is lots of work going on around PCL outputs and the ability to embed printer escape sequences inside your template that will survive the conversion to PCL ... this will be huge for things like hardware controlled check signatures, etc.
3. Again, Glen, it would be great to get some more detail on the complexity and the process.
That's enough for today, I have a flight to catch soon to get back home after a week away. I will cover some of the other comments in coming posts.