Report SDK roadmap or workarounds?

Question

Hi, my company ships a metadata-driven 3rd-party application which creates and manages universes and WebI reports.  We're finally starting to get customer interest in upgrading to BOBJ BI 4.0, so our next release will support that.  Like a lot of other people, we were dismayed to learn that SAP has gutted the Java Report SDK, which was the only SDK capable of creating WebI reports.  So right now I'm faced with the prospect of a release which will only create WebI reports for 3.1 customers, and leave 4.0 customers out of luck.
Here are some of the workarounds I've been considering.  They are all pretty expensive/risky, so I don't want to commit to any of them until I have better insight into where SAP is taking things.  I'd appreciate any feedback on any of these ideas.
1. Ditch WebI reports and build Crystal Reports instead.
Pros:
i. There's still an SDK available for Crystal Reports
Cons:
i. We believe our customers still use WebI more than Crystal Reports. 
ii. We've not yet worked with this SDK so we can't estimate how hard it will be to use or how buggy it might be.
iii. We don't know if SAP will de-support that SDK in a later release as well. 
iv. We don't know if SAP is pushing customers toward Crystal Reports over WebI, or plans to continue with both over the long term.
2. Hope for an Report SDK replacement in a future release.
Pros:
i. Less to do now for us.
ii. The replacement, when it comes, may be more reliable and cheaper to use that the current Java SDK.  For example, it may be supported directly in .NET so we can strip out our Java components, or it may be a true XML SDK so we can simply build reports as XML docs and push them reliably to WebI
Cons:
i. Our 4.0 customers won't get any reports.
ii. The replacement may never come.
3. Hack it.
Possibilities include:
i. Use Fiddler, java reflection, etc, to emulate WebI and bypass the API.
ii. Look at BOBJ's report archive/migration utilities, or at the WebI repository, to find a way to fake it at a binary level
Pros:
i. Seamless to our customers
Cons:
i. Probably way too expensive and risky to really take seriously
Thanks in advance for any feedback or advice.  We are of course pursuing the same questions in parallel with our SAP partner contacts.
-Eric

Answer 1

Hi Terry, and thanks for that update.
I work for Noetix Corporation.  Weu2019ve been a Business Objects / SAP partner for almost 5 years with our Noetix Generator for Business Objects product.
Our core products (NoetixViews and Noetix Analytics) create database views and data warehouse tables used for real time reporting and analytics of Oracle EBS systems.  We also have a Noetix Generator product family, providing integration with major BI platforms (BOBJ, Cognos, OBI EE, etc.).
Noetix Generators do two main tasks:
u2022     Generate the semantic model for the BI Platform (in this case, BOBJ Universes) using metadata describing the views and tables from NoetixViews and Noetix Analytics.
u2022     Generate sample reports (in this case, WebI reports) using metadata from NoetixViews that provide report definitions in a BI-platform-independent form
Noetix Generators are admin tools and are not deployed outside of IT.   The generation process is essentially a one-time step (no u201Cre-creating the report each timeu201D, just occasionally during upgrade processes) .  So you are correct to some extent when you suggest that weu2019d want to create a u201C[set of reports] that can be easily deployed programmaticallyu201D.  The catches are that:
1.     We use the same metadata to create these reports on all BI platforms.  Maintaining separate metadata for each BI platform is not an option.
2.     The reports we create are sensitive to the customizations in customer EBS configurations.  Itu2019s unlikely (I think) that SAP could create a tool that could export a set of reports from one custom environment to another without allowing for some significant (metadata-driven) tweaks in between. 
All that said, hereu2019s what I think a report creation API should look like (and what the other major vendors' report creation APIs all actually do look like):
1.     Define each report as a single XML document.  Make that XML easily viewable, at least to super-users or developers.
2.     Define an API or create SDK tools for exporting/importing/securing these XML documents.  Good language support (.NET, Java, etc.) is nice here, but really secondary since 95% of the real work is in manipulating the XML.  We can always just shell out to a command line utility for the other stuff if we have to.
Thatu2019s pretty much it.  In the case of BOBJ, the XML would likely contain numerical ID pointers (rather than string references) to underlying semantic objects like Universe IDs and the columns defined in the Universe.  This might be an inconvenience, but not a significant one from our point of view since weu2019re already used to working with these IDs (from our experience with BOBJ XI).
Thanks, Eric