Consuming web application through Mashup
Hi,
I have created a mashup to consume an existing web application using scraper object. I get the html response successfully within the mashup environment.
When I try to access the mashup service (using the WSDL endpoint) from a remote client, it returns an object reference to the response object.
What I need is the html text so that I can display it inside my portlet. Has anyone tried something similar and converted the response object to HTML and rendered it?
Thanks in advance.
Kamal
Here's the client code:
ICSScraperStub stub;
try {
stub = new ICSScraperStub("http://zneta:7762/services/spai/ICSScraper");
ICSScraperStub.GetICSSiteResponse response = stub.getICSSite();
System.out.println("response from ICS mashup web service: "+response); //This prints an object reference...I need to get this back to HTML
}
catch(Exception e)
{}
- Login or register to post comments
- Printer friendly version
- 397 reads











Hi Kamal, The response
Hi Kamal,
The response object contains an xml document. You can traverse data in this document using the javascript DOM API.
ie: response.childNodes.item(0)
Instead of just refering to the response object, try using the line above.
Hope this helps,
Tyrell
Hi Tyrell, Can't use javascript api in java
Hi Tyrell,
I think you misunderstood my question. I have exposed the mashup service as a web service. I am calling the mashup web service (WSDL attached) from another web app in a seperate tomcat server.
This web app has a Web service client which calls the mashup web service through the code snippet above. This code contains a stub to the mashup web service client. The client is able to call the
remote service and gets a response as a java object reference. We need to get it back to the html response which we see when call the mashup service locally using "Try it".
I am also attaching the mashup script for your reference.
Thanks,
Kamal
Better output type annotations.
I can't really comment on what might be going wrong in the stub processing code you quote above, but I do notice something you might be able to twiddle with in the service itself.
Currently the service scrapes and tidies the page into XML, then converts it back to a string before returning it. The operation doesn't have any outputType defined, so the string result will be wrapped in an XML wrapper by default, something like:
<getICSSiteResponse>
<return xsi:type="xs:string"><html> ...
I'd expect your stub code to give you this result as an XML document of some kind, though it might be kind enough to unwrap the result into the original string. However, you probably instead want the tidied XML. You can do this within the mashup script in two ways:
getICSSite.outputType = "#raw"; // The output won't have any wrappers, and will just be plain xml.
getICSSite.outputType = "xml"; // The output will still have the wrapper, minus the xsi:type, but the contents of the return element will be XML instead of a string.
Maybe this more useful formulation of the returned content will work better with your stub, but if not I think you'll have to look at the consuming application more closely. Once we generate a valid and accurate WSDL the Mashup Server has fulfilled it's part of the contract.
P.S. Sorry for the delay - notifications of new forum postings don't seem to be getting to me.
Now consuming using axiom api
Hi Jon,
Thanks for your reply. I already changed the consuming application to use axiom api and the previous issue is resolved.
However, I changed my ICSScraper.js to take an input string (policyNumber) and return output string. Now, I am having a different error message.
The error is as follows:
org.apache.axis2.AxisFault: Required element policyNumber defined in the schema can not be found in the request
at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at com.aaamidatlantic.ICSScraperClient.getICSLoginPage(ICSScraperClient.java:37)
at com.aaamidatlantic.ICSScraperClient.main(ICSScraperClient.java:22)
I printed the OMElement before the ServiceClient sendReceive method is executed. Here's the println for that:
<s:getICSSite xmlns:s="http://services.mashup.wso2.org/ICSScraper?xsd"><s:policyNumber xmlns:s="http://services.mashup.wso2.org/ICSScraper?xsd">123564231</s:policyNumber></s:getICSSite>
I can see that the request message contains policyNumber data but still the method fails before even reaching the mashup server. However, the same service is consumed successfully if I remove the input/output parameters
and hardcode the policyNumber inside the js file and call the service.
I don't know if the mashup is not entertaining the request for some request or is it just failing even before it reaches the mashup server because there is nothing printed out on the mashup server console.
I am attaching the new js, wsdl file and client java code for your reference.
Any thoughts on this.
Thanks,
Kamal
P.S: For some reason, even I am not getting a notification for the responses to the posts.
The above issue is resolved
Hi Jon,
The above issue I mentioned in my previous post is now resolved. The problem was in the namespace that I was passing in the axiom api.
Instead of passing the namespace value in the following line of code, I passed a blank value and it worked.
OMNamespace omNs = fac.createOMNamespace("", null); // This works because I changed the value to ""
Looking at the WSDL, I saw that the elementFormDefault equals unqualified. This WSDL was generated by mashup.
I had another web service WSDL(not generated by mashup) and it had the elementFormDefault as qualified.
I had to pass the namespace value as the value in the targetNameSpace of the WSDL.
Thanks,
Kamal