LoadRunner GWT to XML Conversion - gwt

We have an application which uses GWT for the communication. I have enabled DFE (In Loadrunner - Vugen) and selected GWT as the option and provided application .WAR file as the input to extract All Application related .jar files.
Recorded the scenario flow, and i see all the requests are converted from GWT to XML format. But then when i reply the test script i am having errors as DFE is not able to convert the HTTP response from GWT fromat to XML format.
What are the other options that we can try to resolve this error and convert to XML format? And is there a way that we can supress the Loadrunner error message, so that it will proceed with the next steps instead of failure?
Do we need any additional .jars for converting HTTP responses?
HTTP Response (In GWT Format): //OK[[],0,5]
Error Message:
Action.c(93): Error -27040: Data Format Extension: Extension: GWT - ERROR
[GWT_DFE] - Failed to parse response:
java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:403) ~[?:1.8.0-internal]
at java.util.ArrayList.get(ArrayList.java:416) ~[?:1.8.0-internal]
atcom.gdevelop.gwt.syncrpc.SyncClientSerializationStreamReader.readInt(SyncClientSerializationStreamReader.java:450) ~[SyncProxy.jar:?]
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.readObject(AbstractSerializationStreamReader.java:46) ~[gwt-servlet-2.0.4.jar:?]
at com.hp.dfe.GWT_DFE.deserializeResponseToXML(GWT_DFE.java:462) [classes/:?]
at com.hp.dfe.GWT_DFE.decode(GWT_DFE.java:704) [classes/:?]
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0-internal]
at java.lang.reflect.Method.invoke(Method.java:483) ~[?:1.8.0-internal]
at com.hp.dfe.GWT_DFE_DYNAMICALLY_REFLECTED.doOperation(GWT_DFE_DYNAMICALLY_REFLECTED.java:70) [classes/:?]
at com.hp.dfe.GWT_DFE_DYNAMICALLY_REFLECTED.decode(GWT_DFE_DYNAMICALLY_REFLECTED.java:60) [classes/:?]
at com.hp.dfe.GWT_DFE_LAUNCHER.decode(GWT_DFE_LAUNCHER.java:456) [classes/:?]
[MsgId: MERR-27040]
Action.c(93): Error -27040: Data Format Extension: Extension: GWT - ERROR [GWT_DFE] - failed to read as a response
Øp–ñ´Ò
[MsgId: MERR-27040]
Thanks.

That looks like an empty (void return type) response for an old version of gwt - the status was success (//OK), there are no flags set (0), the version is pretty old (5), and the array of strings is empty, since there is no other data to send back. Sounds instead to me like your GWT_DFE class is expecting that all responses always have a value, or that something else is very wrong in how they are handling the response (perhaps they can't handle the old version well? I'd be just blindly guessing at this point, that code isn't publicly available).
If you have a RemoteService method like void sendMessage(SomeObject object), there may be no need for any return type other than the onSuccess response itself. The matching async interface would then have AsyncCallback<Void>, and would not get a return value.

Related

SOAP Web Service Client error, While consuming the service

I am getting this error while using SOAP web service client with axis 1. I had created stub from the wsdl file and tried to consume it then I got this error. wsdl is given to me by someone else.
error in msg parsing: xml was empty, did't parse!
below is the error message and stack trace for the same. Anyone can help.?
In order to fix the javax.activation.DataHandler issue you must add the JavaBeans Activation Framework activation.jar in your classpath.
In order to fix the javax.mail.internet.mimeMultipart issue you must add the Java Mail API mail.jar in your classpath.
The warning messages printed in your console shows that the above jars are not in the classpath.
There are several common reasons to receive the message:
error in msg parsing: xml was empty, did't parse!
The most obvious is that no message was sent. If you have some way of inspecting your transport channel, that would be worth looking at.
Also, the xml message could have been sent in an unexpected character set, e.g. A header declares it to be "Utf-8" but it is really "Win-1252", sometimes you can get away with that if you only use 7-bit ASCII characters, but anything in the 8-bit plane will cause it to bomb.
Also, the xml message could have had a byte order mark unexpectedly inserted at the beginning of the message.
Also, the xml message might not have the document declaration ( starting in the first byte of the message, that violates the specification, and often causes parsers to puke and claim that no message was found.
All things considered with this error message, the parser was not able to find a valid xml message that it could parse, so it didn't. You need to grab the data on the transport channel and figure out what exactly is wrong to resolve the issue.

How to get ResponseEntity body in spring-integration

I am using xml based configuration - http outbound gateway to trii=gger a rest service, the response is ResponseEntity and I dont know that service details. The output I receive should be put in a JMS Queue.
How can I update the below to extract only the body of response entity and pass to output-channel? If there is a transformer, please give example. Is it possible using config?
<int:chain input-channel="gsInChannel" output-channel="dest-channel">
<int-http:outbound-gateway
url="https://ia-zatie.str13.tst.belst.nu/ia-zaatie/rest/signal/v2"
http-method="POST"
header-mapper="headerMapper"
request-factory="sslFactory"
>
</int-http:outbound-gateway>
</int:chain>
dest-channel is jms:outbound-channel-adapter
boot version 1.4.3 and integration version 4.3.6
Error: org.springframework.messaging.MessageHandlingException: error
occurred in message handler
[org.springframework.integration.jms.JmsSendingMessageHandler#0];
nested exception is
org.springframework.jms.support.converter.MessageConversionException:
Cannot convert object of type
[org.springframework.http.ResponseEntity] to JMS message. Supported
message payloads are: String, byte array, Map, Serializable
object.
I was using HTTP POST method and so not expecting, a response. SoO has not included expected-response-type, which returns the body
<int-http:outbound-gateway
url="https://ia-zatie.str13.tst.belst.nu/ia-zaatie/rest/signal/v2"
http-method="POST"
header-mapper="headerMapper"
request-factory="sslFactory"
expected-response-type="java.lang.String">

WSO2 ESB WS-Security with MTOM

Having WSO2 ESB 4.9.0, is it possible to enable the client WS-Security, set-up a policy for the endpoint, where the external (backend) service returns the MTOM attachment?
requirement: the external backend service requires the request to be signed and returns (optionally) MTOM response, which is not signed (plain).
As soon the Rampart module is engaged and an inbound policy is in force, the response doesn't get through a simple proxy with following exception:
Caused by: org.apache.ws.security.WSSecurityException: Error in converting SOAP Envelope to Document; nested exception is:
org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException: Expected xop:Include as the sole child of an element information item (see section 3.2 of http://www.w3.org/TR/xop10/)
at org.apache.rampart.util.Axis2Util.getDocumentFromSOAPEnvelope(Axis2Util.java:149)
at org.apache.rampart.RampartMessageData.<init>(RampartMessageData.java:268)
... 11 more
Caused by: org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException: Expected xop:Include as the sole child of an element information item (see section 3.2 of http://www.w3.org/TR/xop10/)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
at org.apache.axiom.om.impl.llom.OMSerializableImpl.build(OMSerializableImpl.java:78)
at org.apache.axiom.om.impl.llom.OMElementImpl.build(OMElementImpl.java:722)
at org.apache.rampart.util.Axis2Util.getDocumentFromSOAPEnvelope(Axis2Util.java:84)
... 12 more
Caused by: javax.xml.stream.XMLStreamException: Expected xop:Include as the sole child of an element information item (see section 3.2 of http://www.w3.org/TR/xop10/)
at org.apache.axiom.util.stax.xop.XOPDecodingStreamReader.next(XOPDecodingStreamReader.java:187)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
... 15 more
However - there is the Include element:
<inc:Include href="cid:30545cee-7014-4149-8b77-7014e3e12a8c#xxxxxxx" xmlns:inc="http://www.w3.org/2004/08/xop/include"/>
Trying to test the service locally (creating a mockup service similar to the external service) I've got an exception:
Caused by: org.apache.axiom.om.OMException: Part content ID cannot be blank for non root MIME parts
at org.apache.axiom.attachments.Attachments.getNextPartDataHandler(Attachments.java:648)
at org.apache.axiom.attachments.Attachments.getDataHandler(Attachments.java:350)
which I assume is related to the issue https://wso2.org/jira/browse/ESBJAVA-3585. Is it related or I have wrong mockup service? Does MTOM works with security policy enabled?
Seems there are two issues involved:
Caused by: javax.xml.stream.XMLStreamException: Expected xop:Include as the sole child of an element information item (see section 3.2 of http://www.w3.org/TR/xop10/)
This is caused by the "pretty print" feature of the backend service. Axis 2 enforces the specification strictly, where the xop:Include element must be the sole and only child, therefore no whitespaces are allowed.
org.apache.axiom.om.OMException: Part content ID cannot be blank for non root MIME parts
This seems to be a bug, not yet solved at this time.
https://wso2.org/jira/browse/ESBJAVA-3585
Workaround could be change the message type to text/xml (effectively inserting base64 payload to the XML element), good for small/reasonable attachment sizes.
If the attachments can be bigger or the load is high, it is to be considered to store the attachment as a file and pass back only the file name.

Bean Validation 400 errors are returning default error page (html) instead of Response entity (json)

I have a JUnit testsuite: GrizzlyHttpServerFactory + Jersey + Bean Validation
(jersey-container-grizzly2-servlet/jersey-bean-validation ver 2.12, grizzly-http-server ver 2.3.16,
hibernate-validator ver 5.0.0.Final)
The 400 errors generated by a ValidationException are returning Grizzly's default error page (html)
instead of the Bean Validation's Response entity (json). I've tried a ClientResponseFilter and its
entityStream also contains the html error page.
When I run the system under Tomcat, the ValidationExceptions return a Response with a json-formatted
entity.
Any ideas on how to configure Grizzly/Jersey/Validator to NOT return the error page (html)
and put the ValidationExceptions into the Response's entityStream, just like Tomcat?
Thanks in advance,
Mike Norman
After looking into the code to which alexey pointed to for Jersey 2.13, I found out that the code path in question can be avoided by setting the property jersey.config.server.response.setStatusOverSendError to "true".
So, as a workaround until JERSEY-2673 is fixed, I just placed property(ServerProperties.RESPONSE_SET_STATUS_OVER_SEND_ERROR, "true"); into my ResourceConfig class and was able to see the custom error responses in the browser.
I went throw Jersey code and looks like it's the way Jersey works and IMO it's just a coincidence that it works fine on Tomcat.
Jersey processes the validation (and probably not only validation) errors following way:
org.glassfish.jersey.message.internal.CommittingOutputStream#flushBuffer(boolean)
writes JSON error message to the Servlet OutputStream;
org.glassfish.jersey.servlet.internal.ResponseWriter#commit()
calls HttpServletResponse#sendError(int, String), that according to the Servlet spec:
... If data has been written to the response buffer, but not returned to the client (i.e. the
response is not committed), the data in the response buffer must be cleared and
replaced with the data set by these methods ...
So Grizzly clears up buffer with the JSON error and replaces it with the default error page.
I'd suggest to file an issue # Jersey issue tracker
https://java.net/jira/browse/JERSEY

Parsing response from the WSDL

I've generated the web service client in eclipse for the OpenCalais WSDL using the "develop" client type. Actually I was following this post so not really going in detail. Now when I get the results this way: new CalaisLocator().getcalaisSoap().enlighten(key, content, requestParams);, I get the String object, containing the response XML. Sure it's possible to parse that XML, but I think there must be some way to do it automatically, e.g. getting the response object in the form of some list whatsoever?
The response from the SOAP interface is already parsed. The englighten() method returns an XML string. When you call it with SOAP, this response is wrapped within even more XML. The SOAP library already parses the outer SOAP XML and returns the result of the enlighten() method, which is also XML.