Today's post is inspired by this question from OTN forums: https://community.oracle.com/thread/3943615. Topic starter tried to invoke a BI Publisher (XML Publisher) web service from OBIEE using an Action, and something went wrong. But the same web service worked fine when he invoked it with the same parameters using a third party tool.
I'm not sure that this use case is important, but it was very interesting for me to find out what causes this behaviour and is it possible to change it.
I've started from the very beginning and confirmed that everything works (or should I say doesn't work?) exactly as topic starter said.
Works perfectly with Altova XMLSpy:
Gives java.lang.NullPointerException in OBIEE:
Well, I can see the same problem. No magical "everything works by itself".
I've started with reading logs but haven't found anything worth mention. So the next step was to look at the network traffic and see what exactly is going on.
I used Wireshark tool to capture the traffic. No surprises for XMLSpy's request. I captured the same text as sent.
But there was a surprise with an OBIEE's request. Although I've filled in only six fields, captured request contained all of the available fields.
The same XML in XMLSpy:
For fields without values, OBIEE sends tags like this:
This tag has no value and marked as xsi:nil="true". Even while this OBIEE's wordiness looks strange, W3C's XSD specification allows it.
It was the obvious idea to take this request and send it using XML Spy to see what will happen. That check was supposed to confirm that the error is caused by the request text itself, not the way OBIEE sends it. No miracle have happened.
At this step, I was ready to bring an accusal against OBIEE and say that the problem emerges because OBIEE creates an incorrect request. Case closed. To prove it I decided to validate both requests against the service XSD schema and see which one is incorrect (non-working obviously, right?).
And here goes the second surprise. Booth requests are invalid.
OBIEE requst validation:
Manual (aka XMLSpy) request validation:
On the face of it, OBIEE's request appears more incorrect as in contains more errors. But after a closer look at errors, I saw that they are not that critical: a few attributes don't have values. And on the contrary, the only error of the manual query is more serious. The element is not expected at this position. That means a mandatory element is missing. Evening ceases to be languid.
It's time to look at the XSD and find out once and forever the order of attributes.
Almost all attributes are mandatory. Yes, they have property nillable="true", but they are mandatory (minOccurence=1). And it wasn't a surprise that all attributes in the OBIEE request which caused validation errors are mandatory and not nillable. They need some value, but I didn't provide any.
So at this point OBIEE seems to be not guilty. And I have a weird situation. OBIEE does things in a correct way, and XMLSpy just works (well, not XML Spy itself, but who cares?).
Right now I don't know how to force OBIEE simply ignore attributes without values. It's possible that it has a parameter for that, but I don't know it. So everything below this paragraph may be completely useless. And all I've done is not supported by Oracle in any case. But fun (at least for me).
DISCLAIMER. All I show here is for educational purposes only. Do not repeat unless you know what you are doing.
I've decided to check how OBIEE and BI Publisher will behave if I make all attributes non-mandatory.
As this is not a usual for me guide, I won't post step by step instructions and screenshots here. If you need more details, ask in comments.
In order to change BI Publisher web service XSD, I should take xmlpublisher.ear file, unpack it, change WSDL file and after that pack it again and publish.
ear file is located in $ORACLE_HOME/bi/bifoundation/jee. I unpacked it using 7z archiver (ear file, in fact, is a zip archive). I got a few folders plus xmlpserver.war file. This war file is also a zip file, so I unpacked it and got a WSDL file - ReportService.wsdl.
After that, I made a few of changes. First of all, I marked all elements of runReport message as optional (minOccurrence=0). And the second change - I added a new element called "obihackers" with only two allowed values: "freenode" and "telegram". I added it because I want to check how OBIEE handles elements with fixed values and how BI Publisher web service reacts on this type of elements in requests.
Packing files back into war and ear file is simple. It is done with jar command from the JDK. Two important things should be kept in mind. You must change a directory to the place where all files are stored. It's possible to use simple "cd" command or -C key of the jar executable. And you must use -M option of the jar. These requirements are applied to creating both war and ear files.
Publishing is pretty straightforward. Login to WLS console, stop bipublisher distribution, delete it, deploy changed ear as an application and start it.
OK. Let's check what we have now. There is no point in checking XML Spy as it was working before. I want to see how OBIEE handles my new WSDL.
The first test: try to execute runReport. No luck. The same java.lang.NullPointerException. Hm. And what was the request? The same. Nothing has changed.
OK. The next experiment. Remove nillable="true".
Yes! That makes a trick. I've managed to call BI Publisher web service from OBIEE without error.
But one thing remaining. What happens when I fill in obihackers attribute? As you can see it doesn't offer me a list of possible values (one of the things I want to check).
The answer is:
The error is not the same as it was before, but it's still an error. No point in checking other values.
As a conclusion.
- BI Publisher WSDL has a correct XSD schema.
- OBIEE creates correct SOAP requests.
- BI Publisher ignores it's own XSD schema.
- BI Publisher does no validation of SOAP requests against XSD!
- BI Publisher works badly with unexpected parameters in requests.
- It's possible to tweak BI Publisher XSD.
- ...but nobody knows will it work or not.
OBIEE specialist since 2007 and Oracle Discoverer before. DWH architect, BI enthusiast, blogger. Lazy cats owner. All opinions are my own and not the views of my employer.