How to Ignore unavailable fields from a SOAP Response

Question

I have a web service developed in SOAP, for which a client is generated already. Now I am adding a new field in response of web service. Now when I am invoking the client it gives error as the updated field is not available in Data Class available at client side.Is there any way to Ignore those property which are not available in data class while unmarshaling. the same works fine in REST. TIA

Answer 1

This works in REST because with HTTP only you don't have such a strict protocol of communication as it is with SOAP over HTTP. In SOAP a more restrictive and detailed technical contract is in place by default and both sides must comply with it. If you want the same behavior of REST you'd have to implement validation and rules yourself since it is a bit open and that is part a of the idea.

To solve your issue, you'll probably need to regenerate your client proxy/stub class, using the new WSDL file in order to make the client aware that a new field have been added and could be expected in the response of the server. You can also add this field manually to the response in your current stub class and mark it as optional, without using any of the auto-generating tools.

If you want to avoid breaking clients altogether (and regenerating/modifying classes) when you introduce changes in the future, you may try:

1. Creating new service version for new consumers, maintaining both - old and new version, making the new available only to new consumers;
2. Creating a new service operation for new consumers in the same service, maintaining both - old and new operation, making the new available only to new consumers;
3. Mark fields as optional - attribute minOccurs=0 in the WSDL (only possible when this is allowed by your use case). See XML Schema Indicators. In short in your WSDL, your element must look something like this: <xs:element name="el_name" type="xs:string" minOccurs="0" maxOccurs="1"/>. Try this way, without updating the contract at client side. Again, it depends on how strict the client is about following the contract.
4. Try and see if there are any specific options in Java to make the client more tolerant to optional values - for example - this one)*

These approaches are useful if you have many clients you cannot modify and you do not want to break communication contract with them. Be aware that all the above options come at a cost - you'll trade more maintenance and governance on your side for increased compatibility with clients. So choose wisely.

Hope this helps!