Response from Web Service in Glassfish from C# client - java

I'm having a problem where my C# client can't parse the data from my webservice in Glassfish.
I have a WSDL and XSD for my webservices as follows:
http://www.consorciovivedigital.com:8080/ServicioInterventoria/ServicioInterventoria?WSDL
http://www.consorciovivedigital.com:8080/ServicioInterventoria/ServicioInterventoria?xsd=1
And I'm using the next C# client to test this webservice:
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using ServicioInterventoria;
public partial class _Default : System.Web.UI.Page
{
ServicioInterventoria.ServicioInterventoria proxy;
protected void Page_Load(object sender, EventArgs e)
{
proxy = new ServicioInterventoria.ServicioInterventoria();
ResultadoMensualIC[] res = proxy.ObtenerResultadosMensuales("Intv12", "2014-07-07T08:08:08");
System.Diagnostics.Debug.WriteLine(res.Length);
System.Diagnostics.Debug.WriteLine(res[0].FechaCorte);
}
}
The problem is that when I execute this code, the res array has the amount of objects that should have, but each value of each object has the default value instead of the correct value. I used Fiddler to check the traffic and it receives the correct SOAP response with the correct data, but it seems that my C# client doesn't know how to parse the data.
I checked with a Java client, and I can get the correct data without any problems, and seems that my C# it's the only one giving problems with this.
Maybe there is a problem with the targetNamespace in the SOAP response, but I don't understand why works correctly in Java but in C# just puts default values.
Anyone have any idea what could be the problem?
If someone needs more information about it, let me know
Thanks beforehand

I solved last week. The problem was that the SOAP response didn't put the namespace for each attribute, then, the C# client doesn't know how to match this (seems like a limitation of C#). And, the other problem was the order of the SOAP response, because, the C# client was expecting each object as was defined in the WSDL, but the response it's ordered alphabetically, in this way, the C# client, doesn't match correctly each attribute.
I did some modifications to the client. First, in each model, for each attribute I added the namespace, something like this:
#XmlElement(name = "IdInterventor", namespace = "http://ws.bigdatasolutions.co/")
public String getIdInterventor() {
return IdInterventor;
}
With this, the SOAP response always puts the namespace for each attribute, which was neccesary for the C# client.
After that, at the beginning of each model class I add this tag, to define the order as defined in the WSDL and expected for the C# client.
#XmlRootElement(name = "AspectosFinancieros")
#XmlType(propOrder={"idInterventor", "numeroContrato", "ano", "valorContratoOperador", "fechaFirmaContrato",
"valorAdicion", "fechaProrrogaAdicion", "valorDesembolso", "fechaPagoDesembolso",
"valorAnticipo", "fechaAnticipo", "valorUtilizacion", "numeroActaAprobacion",
"fechaUtilizacion", "valorRendimiento", "fechaRendimiento", "numeroComprobanteRendimiento",
"valorComision", "fechaComision", "valorGastosAdministrativos", "fechaGastosAdministrativos",
"nombreFiducia", "numeroContratoFiducia", "fechaContratoFiducia", "fechaProrrogaAdicionFiducia",
"marcaTiempo"})
public class AspectosFinancieros {
I checked the expected order in the auto generated class in the C# client.
I hope someone find this useful.

Related

Mule Anypoint Studio Passing in JSON and working in Java

I'm not too familiar with Anypoint and we will probably only use this program once, I've looked at tutorials on the website but I feel I can't find one that demonstrates the task we have. Basically we are trying to read a JSON file that will be sent to the software, from there we want to use JAVA to read/alter the contents into a desired XML formatting. Finally we then send back or redirect the XML results.
1: I am trying to accept a JSON file from a HTTP POST, I believe I have accomplished this part by using the tutorials and an HTTP element with metadata attached representing the JSON format that may come. Using postman to send the json data as well.
2: From here is where I start to get completely confused. I am wondering what I would need to do in order to pass the data into a Java class object to read the JSON file and begin using Java code (getters/setters) instead of the Anypoint interface in order to start designing the xml layout.
Thanks,
I think the next step is for you to define a model class(with getter/setter), which would represent your json file contents. Since you have already the POST part, the next thing you would do is to use JSON to Object Transformer which the model is injected in.
<json:json-to-object-transformer returnClass="com.alexfrndz.Person" doc:name="JSON to Object"/>
After adding the transformer, you could use a mule custom transformer,
Here is the custom transformer.
package com.alexfrndz;
import org.mule.api.MuleMessage;
import org.mule.api.transformer.TransformerException;
import org.mule.transformer.AbstractMessageTransformer;
public class PersonTransformer extends AbstractMessageTransformer {
#Override
public Object transformMessage(MuleMessage message, String outputEncoding) throws TransformerException {
Person person = (Person) message.getPayload();
//Do your transformation hear
return null;
}
}
Here is how you implement it,
<custom-transformer class="com.alexfrndz.PersonTransformer" doc:name="PersonTransformer"/>
Hope this will help you.

How to make changes in marshalled output in Java web service client

I am trying to interact with a third party web service, who requires me to send a security token as a part of each request. The token is a node by itself, and I acquire it from the response of an initial call.
The web service endpoint is dotNet, and I have a Java client.
Apparently, the server side expects me to send the security token exactly like it was provided to me: literally the same string: so it won't do if its content has a different size, order, etc.
So, in SoapUI, everything works fine. There is a token in the response of the initial 'startSession' call, which I copy into the request of a next call.
But in Java (I tried JAX-WS and CXF generated code, both rely on JAXB) it doesn't work. I receive the token as an object after it is unmarshalled, and I use this object in the next call.
When marshalled and send, it is missing a namespace attribute in a subnode. The server side says it won't continue because the token is incorrect.
So, by using JAXB outbound logical handler functionality, I am able to add the missing namespace without any problems in the DOM source (I was also able to achieve this with a CXF interceptor).
The problem now is, that the attributes, when marshalled, are ordered in such a way that the result still not matches the provided token as it was before it was unmarshalled. Alhough it should not matter, the order of these attributes is crucial.
I have no idea how to solve this, unless it is possible to actually modify the output XML string. I even tried a dirty hack by removing all attributes from the subnode and replacing them with one attribute that visually looks the same; but then the outer two double quotes become single quotes...
I hope anyone has an idea. Because I have none.
Cheers.
UPDATE:
I should have mentioned that the attributes in question are namespace(d) attributes. The node should look like this:
<HawanedoSessionInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.thecompany.com/Hawanedo/Business/v2.0c">
However, after using outbound JAXB handler to add the missing xmlns="...", my result looks like this:
<HawanedoSessionInfo xmlns="http://schemas.thecompany.com/Hawanedo/Business/v2.0c" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
In the HawanedoSessionInfo class, I used XmlType.proporder and #XmlAttribute like so:
#XmlType(name = "HawanedoSessionInfo", propOrder = {
"xsd",
"xsi",
"xmlns",
and some other non-attribute sub-elements..
private String xsd;
private String xsi;
private String xmlns;
#XmlAttribute(ns="http://schemas.thecompany.com/Hawanedo/Business/v2.0c")
public String getXsd() {
return xsd;
}
public void setXsd(final String xsd) {
this.xsd = xsd;
}
#XmlAttribute(ns="http://schemas.thecompany.com/Hawanedo/Business/v2.0c")
public String getXsi() {
return xsi;
}
public void setXsi(final String xsi) {
this.xsi = xsi;
}
#XmlAttribute
public String getXmlns() {
return xmlns;
}
public void setXmlns(final String xmlns) {
this.xmlns = xmlns;
}
So apparently the proporder option does not help in this case?
UPDATE 2:
Like I wrote in my answer, it now works. Based on this LINK,
in the HawanedoSessionInfo class I added:
#XmlCustomizer(HawanedoSessionInfoCustomizer.class)
I created the customizer class exactly as described in the linked page, and I added the jaxb.properties.
So I did two things:
1) I added my attributes to (the top of the already existing) propOrder attribute. I added the attributes as instance variables and created the getters/setters. I annotated the getters with XmlAttribute.
2) I implemented the XmlCustomizer solution.
Now comes the strange part. According to Fiddler, the order of the attributes is still not changed! But I must stress that this is now working, ONLY after implementing the Customizer. What is happening here? :)
So in principle you cannot control order of attributes in a standard way, but ....
Depending on jaxb /java version the order can be determined by alphabetical order of the names, the order of declaration.
You could try in your code if a) moving the fields around changes anything, b) renaming the fields (the XMLAttribute than have to map to original name).
If you are lucky, it will work. But of course it is a hack and will work till next jaxb/java update.
The JAXB providers (the actuall implementation can have extra features), that can be used to customized the marshalling process). For example I found that: https://community.oracle.com/thread/977397 abut eclipselink.
I am sure there was a way of intercepting the soap body before it is send or governing the data serialization before it is send. I can think how it was called but try to google the jaxws client customization. If you capture the whole soap message simple xslt transforamation could fix the attributes order.
I feel your pain. The whole point of using xml, jaxws and such is to make our life easier and then someone providers decide not to follow standards and you end up with a mess that you were trying to clean for few days. Good luck and maybe try to contact xml gurus from Eclipse Moxy
I am so happy right now, because I got it working and it only cost me a full week to do so...:) With help of #Zielu, I was pointed to this link with the EclipseLink XMLCustomizer solution as suggested by Blaise Doughan: XMLCustomizer solution
I took the code in my original question (underneath 'UPDATE') and added the exact solution as suggested. Not sure if it is all necessary, but it works. Thanks guys.
It's possible you can control the order by using,
#XmlType (propOrder={"prop1","prop2",..."propN"})

Java REST WebService

I'm trying to build a Java REST web service that will do some processing on a get request (eg. send get request with info, do some calculations, then send back an object with the results). Any ideas how I can set this up easily in Netbeans? I've been playing with the New->RESTful web service... feature, but can't seem to get it to return an object.
AFAIK you're supposed to return a string representation of the result. For example implementing the getXml() method:
/**
* Retrieves representation of an instance of services.GenericResource
* #return an instance of java.lang.String
*/
#GET
#Produces("application/xml")
public String getXml() {
return "<entry></entry>";
}
You could use an XML API to turn your objects into XML strings and return them.
What kind of object do you want to return...?
In java rest webservice you can return many kinds of objects like json,xml.
You can follow these tutorials for creating any kind of java rest webservice -
http://www.mkyong.com/webservices/jax-rs/json-example-with-jersey-jackson/
This link shows example of get request which returns a json object. You can browse there tutorials for any other requirements.
I haven't tried it in Netbeans, but I have done it using Intellij tho, using maven. Just used servlets to get the requests and used GSON to convert the outgoing java object to JSON and send it out.
This is the project I did with some of my colleges.

Document-literal-bare webservice in Weblogic

I need to create a webservice, that accepts any xml in the request soap:Body element and replies with any xml in the respond soap:Body. The appropriate WS operation style is (in my opinion) "document-literal-bare". I expect that the resulting WSDL message would look something like this:
<s0:message name="process">
<s0:part type="xs:any"/>
</s0:message>
How am I to do it?
Details:
In Weblogic 10.3, I have written:
#WebService(.....)
#SOAPBinding(style=SOAPBinding.Style.DOCUMENT, use=SOAPBinding.Use.LITERAL, parameterStyle=ParameterStyle.BARE)
public class BackEndSimulatorWS {
#WebMethod
public XmlObject process(XmlObject request) {
.....
}
}
However the Eclipse protests with
(The "process" method) must be doc/literal/wrapped when binding wildcards to any.
I understand that the WS must be able to determine which method to execute, so I tried to annotate the method with
#Webmethod(action="simulation")
but this didn't help. When I replace the org.apache.xmlbeans.XmlObject parameter and response type with org.w3c.dom.Document, the error disappears, but the resulting WSDL messages are not general, they are of the {java:org.w3c.dom}:Document type.
Any help will be appreciated.

WCF Serialization problems with WSDL file created by Java tools

My team is tasked with getting several in-house developed .NET client applications to connect to some new Java web services. The Java web service is a third party, vendor supplied WSDL file that our team has a limited ability to modify/control...meaning we probably have the power to request our vendor to make slight tweaks to the WSDL, but major changes would probably be either unfeasible or difficult to request.
That said, we are attempting to utilize WCF/.NET 4.0 to generate the .NET proxy class files we need on the client side. The proxy client class file generation process executes without issues.
The problem is when we attempt to use the proxy class file in a client app. I have verified through the web trace tool, Fiddler, that the raw SOAP message request fails to get sent across the wire to the server.
The specific .NET exception message I get when attempting to call the web service method in question, looks like this:
System.InvalidOperationException was unhandled
Message=XmlSerializer attribute System.Xml.Serialization.XmlAttributeAttribute is not valid in baseLanguage. Only XmlElement, XmlArray, XmlArrayItem, XmlAnyAttribute and XmlAnyElement attributes are supported when IsWrapped is true.
Source=System.ServiceModel
When I examine the .NET autogenerated proxy class file, Reference.cs, I noticed that the request and response messages for my web service method looks something like this:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.MessageContractAttribute(WrapperName="QueryPBOT_MXWO_OS", WrapperNamespace="http://www.ibm.com/maximo", IsWrapped=true)]
public partial class QueryPBOT_MXWO_OSRequest {
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=0)]
public ConsoleApplication7.wsMaximo.PBOT_MXWO_OSQueryType PBOT_MXWO_OSQuery;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=1)]
[System.Xml.Serialization.XmlAttributeAttribute()]
public string baseLanguage;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=2)]
[System.Xml.Serialization.XmlAttributeAttribute()]
public string transLanguage;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=3)]
[System.Xml.Serialization.XmlAttributeAttribute()]
public string messageID;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=4)]
[System.Xml.Serialization.XmlAttributeAttribute()]
public string maximoVersion;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=5)]
[System.Xml.Serialization.XmlAttributeAttribute()]
[System.ComponentModel.DefaultValueAttribute(false)]
public bool uniqueResult;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=6)]
[System.Xml.Serialization.XmlAttributeAttribute(DataType="positiveInteger")]
public string maxItems;
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=7)]
[System.Xml.Serialization.XmlAttributeAttribute(DataType="integer")]
[System.ComponentModel.DefaultValueAttribute("0")]
public string rsStart;
public QueryPBOT_MXWO_OSRequest() {
}
public QueryPBOT_MXWO_OSRequest(ConsoleApplication7.wsMaximo.PBOT_MXWO_OSQueryType PBOT_MXWO_OSQuery, string baseLanguage, string transLanguage, string messageID, string maximoVersion, bool uniqueResult, string maxItems, string rsStart) {
this.PBOT_MXWO_OSQuery = PBOT_MXWO_OSQuery;
this.baseLanguage = baseLanguage;
this.transLanguage = transLanguage;
this.messageID = messageID;
this.maximoVersion = maximoVersion;
this.uniqueResult = uniqueResult;
this.maxItems = maxItems;
this.rsStart = rsStart;
}
}
I know that people reading this post will want to see the actual WSDL file we're trying to consume, but it is quite large, and I'm concerned the sheer size of it would make pinpointing the error quite difficult.
I'm hoping that the autogenerated client proxy file and the .NET exception will help someone recognize this WCF Serialization issue.
We've confirmed from our Java vendor that the style of WSDL they generate is doc-literal. After doing some research on the internet, it appears that WCF, by default. translates WSDL files with doc-literal wrapped, and that this may explain, at least in part, why we're seeing this WCF serialization issue with the WSDL file.
I've discovered, through trial and error, that the following attribute decorator in the proxy class file is the culprit behind the serialization issue:
[System.Xml.Serialization.XmlAttributeAttribute()]
If I comment out all instances of this attribute in the proxy class file and rerun my client app, the SOAP message successfully gets sent across the wire and I get a valid web service response come back from the server.
This fix is better than nothing, but I would very much prefer a solution that doesn't require myself or anyone on my team to constantly tweak these .NET autogenerated proxy class files.
I would like to know if there is something I can do, either through the various WCF tools or by modifying the WSDL file, that prevents that [System.Xml.Serialization.XmlAttributeAttribute()] from being applied to my request and response object properties?
Or at least a high level description of WHY we are seeing this serialization behavior in .NET with the Java WSDL file?
thanks in advance,
John
Use svcutil.exe utility with the /wrapped option on to generate proxy classes.
This will create slightly different classes then those created though Visual Studio in a way described by Ladislav Mrnka here. Resulting proxies should be free from the XmlAttribute issue when using on the client side.
Example:
svcutil /t:code wsdl.xml /out:wsdl.cs /serializer:XmlSerializer /wrapped
Here is how to do Mikhail G's solution within IDE:
Open Reference.svcmap under Service References
Add <Wrapped>true</Wrapped> under <ClientOptions> and Save
Right Click Reference.svcmap and hit "Run Custom Tool"
Visual Studio, where magic happens :)
Note: Tried with VS 2015. Prior versions may have same option with a
different name than "Run Custom Tool"
As a follow-on to stratovarius's answer, in VS 2017 the Service References folder is replaced by Connected Services, so you have to:
Open the {project}/Connected Services folder in Windows Explorer
Find and edit the Reference.svcmap with a text editor
Add <Wrapped>true</Wrapped> to the <ClientOptions> section
Save the file
In VS, right click on the service reference under Connected Services and select "Update Service Reference"
This cleared the exception from my service call.
Based on generated code it looks like your Java service expects request like:
<s:Envelope xmlns:s="...">
...
<s:Body>
<QueryPBOT_MXWO_OS xmlns="http://www.ibm.com/maximo" baseLanguage="..." transLanguage="..." ...>
<PBOT_MXWO_OSQuery>
...
</PBOT_MXWO_OSQuery>
</QueryPBOT_MXWO_OS>
</s:Body>
</s:Envelope>
The problem is that WCF recognized QueryPBOT_MXWO_OS as wrapper element for request. I'm not sure why it fires exception but probably there is some restriction that wrapper element can't have attributes. I'm suspicious that this is just global error handling shared with version which uses IsWrapped=false where usage of attributes is error.
You can try to modify your proxy in this way:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.MessageContractAttribute(IsWrapped=false)]
public partial class QueryPBOT_MXWO_OSRequest
{
[MessageBodyMemberAttribute(Name="QueryPBOT_MXWO_OS", Namespace="http://www.ibm.com/maximo")]
public QueryPBOT_MXWO_OS QueryPBOT_MXWO_OS { get; set; }
}
[XmlRoot(ElementName="QueryPBOT_MXWO_OS", Namespace="http://www.ibm.com/maximo")]
public class QueryPBOT_MXWO_OS
{
[XmlElement(Namespace="http://www.ibm.com/maximo")]
public ConsoleApplication7.wsMaximo.PBOT_MXWO_OSQueryType PBOT_MXWO_OSQuery;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
public string baseLanguage;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
public string transLanguage;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
public string messageID;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
public string maximoVersion;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
[System.ComponentModel.DefaultValueAttribute(false)]
public bool uniqueResult;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
public string maxItems;
[XmlAttribute(Namespace="http://www.ibm.com/maximo")]
[System.ComponentModel.DefaultValueAttribute("0")]
public string rsStart;
}
I'm using an external "old" Java generated WSDL in my .Net Core app and the auto-generated Reference.cs did not work for me. I had to remove the [System.Xml.Serialization.XmlAttributeAttribute()] in order for it to work.

Categories