I am sending some SOAP headers to a WCF service and I am trying to catch them using behavior extension.
When the message is received I am going through its headers collection.
Each header is of MessageHeaderInfo type which does not have a value property.
How can I extract the value? It can be done with an ugly parsing (to remove the xml elements around the value) but it feels lame.
your help is most appriciated!
The way you normally use message headers is by defining a DataContract (or an XmlSerializable class) to represent your header, then use Message.Headers.GetHeader<T>() to retrieve it. That method will do the deserialization and hand you a strongly typed object you can use.
Related
What is the realtime use case for serialization in RestAssured?
Even though we can send request body(JSON) as String.
I tried googling but did not get satisfying results.
There are few advantages that come up as your code logic becames more complicated:
You might want to send the same object to different endpoint which might not support json but xml content type. So you can simply have one pojo and RestAssured would take care of all conversions.
Your object might change in runtime. So you will have to introduce changes to your string accordingly. This is quite an error-prone way. Serializer would assure that you send somewhat what is a proper json considering syntax stuff, escaping what needs to be escaped and so on.
There might be the case when you fetch object from one endpoint and send it to another. Hence you would be able to use class for deserialization and further serialization in runtime.
In our project we expose a number of web-services that were generated from a wsdl. After generating them, I can see that the requests and responses are mapped to POJOs and when I am making the response, I just set a new POJO. This works really nice. However, I have a problem with the request. When we receive the request I expected that the payload will be a POJO mapping the parameters from the request. The payload becomes actually an array of objects. I can access the values but this is not very comfortable. You can take a look at the picture.
I can see that the under "Variables" in the method it is correctly matched to the POJO we would like to have. Is there some setting that I am missing somewhere so that we can get the payload to be mapped to correct POJO type?
Re-run the WSDL to Java codegen but this time with wrapper style disabled, see: https://cxf.apache.org/docs/wsdl-to-java.html#WSDLtoJava-wrapperstyle
I want to pass HTMLPage as a return value of my WCF REST Service to my HTML5 application (client).
Is there a way to do this? Or any other approach?
The simple way: return a Stream from the operation you want to return the HTML page from, and set the outgoing content type to "text/html". You can find more information about it at http://blogs.msdn.com/b/carlosfigueira/archive/2008/04/17/wcf-raw-programming-model-web.aspx.
If you don't want to create the HTML page yourself, and instead want something which can convert some object into the page, you'll need to dig deep into the innards of WCF, and use something like a message formatter to do the conversion for you. That's really a lot more work, so I'd strongly recommend the simple way, unless you already have some sort of mapping between objects and its representation.
I am in a bit of a pickle with a current project. We have an integration partner who is refusing to conform to contract, and they are expecting a fault contract with custom headers, rather than the WSDL-defined message contract that includes the same headers and a contractually valid message body. It is not a problem to send a SOAP fault with WCF, as one can simply throw FaultException. The real bind is the requirement that the fault contain custom headers. I was able to serialize a custom header by using the OperationContext, however it does not serialize the way our integration partner requires.
Using OperationContext.Current.OutgoingMessageHeaders, it is possible to create a custom MessageHeader<T> that contains the object you wish to include in the header...it can be a POCO, DataContract, or MessageContract. When using a message contract, namespaces seem to get ignored, and the serialized message has a bunch of invalid xmlns= attributes on each member of the message, which is also a problem. Once a MessageHeader is created, calling the .GetUntypedHeader(name, namespace) method will generate a MessageHeader that can be added to the OperationContext's OutgoingMessageHeaders. The problem is that you can't add an object to the headers directly...they apparently must always be wrapped, since the GetUntypedHeader method requires a wrapper element name and namespace.
The required header is as follows:
<SOAP-ENV:Header>
<imsx_syncResponseHeaderInfo xmlns="http://www.imsglobal.org/services/lti/xsd/CoreOutcomesService_bv1p0">
<imsx_version>UNUSED</imsx_version>
<imsx_messageIdentifier>12345678-abcd-1234-ef00-1234567890ab</imsx_messageIdentifier>
<imsx_statusInfo>
<imsx_codeMajor>failure</imsx_codeMajor>
<imsx_severity>error</imsx_severity>
<imsx_messageRefIdentifier>12345</imsx_messageRefIdentifier>
<imsx_description>yadda yadda some error message here</imsx_description>
<imsx_codeMinor>
<imsx_codeMinorField>
<imsx_codeMinorFieldName>SomeCodeName</imsx_codeMinorFieldName>
<imsx_codeMinorFieldValue>somecode</imsx_codeMinorFieldValue>
</imsx_codeMinorField>
</imsx_codeMinor>
</imsx_statusInfo>
</imsx_syncResponseHeaderInfo>
</SOAP-ENV:Header>
If it was not for the fact that the header, imsx_syncResponsHeaderInfo, has three child elements, we would probably be in business. However, it is impossible to create a message header directly that wraps three separate objects, and when using a MessageContract with IsWrapped=false, every direct child element of the imsx_syncResponseHeaderInfo element gets serialized with an xmlns attribute that defines an incorrect namespace (it seems to take the TNS of the service contract). That makes the header invalid according to the contractual schema, and the consumer cannot deserialize it.
Is there some way to add a MessageContract to the outgoing message headers of a WCF-delivered SOAP Fault, without requiring that it be wrapped, and such that the child elements to not get serialized each with their own xmlns attribute containing the TNS of the service contract?
As noted above:
The issue was actually due to how a business partner was deserializing our message contents. They did not want to take responsibility for the issue at the time, and the burden fell on my team and I. We finally managed to get them to fix their own issue, so we never actually had to solve the problem.
Is it possible to receive a request with attributes and use the XmlSerializer to deserialize it and send a response back with just elements using the DataContractSerializer?
Also, if you receive a request with attributes, must you use the XmlSerializer to deserialize the content?
For the second question: if you have attributes, then you need to use the XmlSerializer - the DataContractSerializer doesn't support them.
For the first question: yes, it's possible. No, it's not easy. The selection of the serializer is done at the operation formatter level. WCF allows you to change the serializer per operation by using the [XmlSerializerFormat] or [DataContractFormat] (which is default), but that will bind the serializer to both request and responses.
If you really, really want to do it, you can create your own formatter (replace it using some operation behavior), then in that formatter you can choose how you serialize / deserialize the inputs / outputs (you can even use different serializers for each parameter), but you'll need to create one formatter, which isn't something too easy to do.
I've written some posts about message formatters and replacing serializers in Silverlight which can give you a hint on how to start about it. But if you can live with XmlSerializer only, that'll be a lot easier.