I have a business case where we need to receive an IDOC and transmit it as received. We don't have to care about version change or other things. Is it possible to do it without generating IDOC schema?
Have you tried?
I'm 92% sure you could do this with the legacy SAP Adapter. It just returned Xml like any other Adapter. You then had to use the XmlDisassembler and such.
The WCF SAP Adapter/Binging...you'll have try. The WCF Bindings in general are a bit more sensitive to schemas and such.
Related
What I want is to decorate my data contracts with few attributes (e.g. min,max, string length etc.) and get the XML schema generated for my SOAP (non .net) clients. After some research on internet, I have come across the following article:
http://wcfsecurity.codeplex.com/wikipage?title=How%20To%20-%20Perform%20Message%20Validation%20with%20Schemas%20in%20WCF
This seems to be pretty manual to me. I am after some more decent solution and out of the box functionality. With WCF offering so much, I will be surprised if it has missed this whole concept of SOAP standard validation.
Any help on this will be much appreciated.
The XML schemas for the DataContract objects are found in the WSDL for the service. WCF does not explicitly validate soap messages against these schemas for a number of reasons. First, the process of deserializing soap messages, in effect, performs validation based on the DataContract or XML serialization defined on the data classes. Next, there is a definite performance hit if every soap message was being validated against the XML schemas. Lastly, WCF supports soap message versioning for both forward and backward compatibility through the IExtensibleDataObject optional interface capability. To do this, XML schema validation would most likely be too strict.
All, can anyone provide me some guidance on allowing NServiceBus to consume XML messages off a queue that were not created by NServiceBus. I am trying to integrate with a 3rd party system that drops XML messages to a queue. I have VERY little control over the XML the 3rd party produces.
I have tried wrapping their XML with the -Messages/- tag and I can get the message to hit the right handler, but many of the fields (especially in child classes) just deserialize to null. The 3rd party produces several "types" of messages but in all cases the XML is reasonably simple.
I'm trying to avoid writing an adapter that just reads XML and drops messages on the bus.
Any advise would be appreciated.
Thanks
The key lies in how you generate the message classes. If you can, you should get the XSD schemas from the third party that represent the XMLs they are sending you.
Then you can generate classes off the schemas using xsd.exe which will pretty much guarantee clean de-serialisation from XML to type.
If you can't get the schemas then you can again use xsd.exe to infer the schemas from the messages. However this method is not particularly fail-safe, and will expose you negatively to anything unexpected the message which does not conform to your inferred schema.
The serialization in NSB is abstracted so you could write your own serializer based on that format. You can then tell NSB to use your serializer instead of one of the built in ones.
I need to receive XML data from HttpPost requests. Currently I use HttpWebRequest to send the request and I convert the request to xml with StreamReader and XDocument.Parse.
Are there any benefits to switching over to WCF? Thanks!
If you don't plan to dramatically extend your application and only want to switch to WCF so that you are using it, no. :-)
WCF will give you some more flexibility - you could for example consume data in other data formats or from other transport formats (Named Pipes, ...)
I hope i understood your question correctly !!!
The use of WCF lies where you know that both the sending as well as receiving end share the same data contract.
I think in your case, using WCF will benefit if both are MS application and the contract is not supposed to change very frequently.
as the title suggests, is this possible?
At a superficial level yes, it is possible. But would you want to re-implement in SQL the entire SOAP stack to validate the message for ws-security, ws-metadatexchange, ws-addressing, ws-reliablemessaging and what else?
Is this a good job for sqlclr? Absolutely not. Why would sqlclr have to handle the transport and enveloping of a message? This should be handled close to where the message is accepted, way before it gets written into the database.
So let WCF handle the SOAP layer, that's one thing is actually good at. There is no reason why the database layer should end up with the entire SOAP package.
I'm looking to use the MsmqIntegrationBinding to integrate with a legacy queue which has a serialized object as the message body. Has anyone come up with a way to obtain the "metadata" of the message body and create a service side class to use within the service?
For example, if I put in a serialized Product object from System A and my service needs to consume it, how do I provide MsmqMessage the type if I do not have the Product class on my side? I was thinking of reading off a message in a separate program, deserializing, and then emitting via the code dom. Ideas?
I wholeheartedly recommend against attempting to emit the deserialized type at runtime in the message destination. Either work with the XML at the destination to obtain the data you desire, or build data contracts that both the source and destination can adhere to.
Hmm... in WCF, you can define service methods which take (and optionally return) an untyped Message type. This seems to fit your bill quite nicely.
Other than with strongly typed messages, you'll have to do all the putting together of the message on the client and the taking apart on the server by means of reading the raw XML - but that seems to be what you're looking for, right?
Find more information and samples here:
WCF - Handling Generic Messages
How to pass a generic object through WCF
Untyped messages on WCF
Untyped messages have some restrictions, e.g. you can only read them once on the server, but you should be able to manage your scenario with this, I think.
Marc