I have system A which produces an xml-file and system B which takes the file. How can I implement this exchange using Biztalk with WCF?
You have two possible different solutions as I see it and it basically comes down to how typed you WCF service needs to be.
Do you need to transform you message into a new format? Or are you planning to use other features in BizTalk as content based routing etc? Are you at all interested in the content of the message while in BizTalk are you OK with just passing it thru?
If you are looking for a solution with the capabilities as described above you'll need to get the schema for the XML message you want to receive into WCF service and publish that service. Once the message is in BizTalk it's then typed and you can do what ever with it using BizTalk.
If you however just want to pass it thru you could just publish a service that received as message of type XML document and pass that thru. Here's a good post describing the a few different techniques to create a generic service accepting any XML as input.
Related
I spent few days search on this case. I checked out all wcf asynchronous implementaions.
I wasn't able to find what I was looking for.
Below is scenario.
WCF is running to accept xml
WCF needs to response to user for success receiving xml and release
the request immediately
WCF then needs to do processing to save xml to database and parsing xml to
convert something else.
I don't want to use separate service to process above. I want to use one service to handle all 3 cases above.
I checked out asynchronous way of coding in WCF, but this doesn't release the request right away. What is the best practice for this? Is there any sample code I can use?
Thank you in advance.
I think you would be better suited to using a different technology. Maybe look at Windows Workflow Foundation.
You can host WCF Workflow Services the same way as you host a standard WCF service, the main difference is that you can create specific workflows that can continue after acknowledging receipt of the original message.
You do this by persisting the message and returning to the user. WF allows you to create actions that continue after sending response back to the caller.
Visual studio provides you with a design surface that allows you to drag and drop components to create custom workflows. Additionally you can also make calls to other services if required.
With .net 4.5 you can now use C#, in previous versions of WF you had to use VB.net.
You can read about it on the MSDN site here:
http://msdn.microsoft.com/en-us/vstudio/jj684582.aspx
Hope this helps
I have been provided an XSD and a sample Xml file that contains the results I will be getting.
I am to build a Web Service that accepts this data and enter into a SQL 2005 table. Each time my service is invoked, I am expecting 1200+ rows of data.
I have also been provided two Xml files, success.xml and failure.xml, that are responses I am to provide back to the caller?
I would like to build a WCF service on the .Net 4.0 framework with one 'MethodToCall'. The other party would call this web service and pass in the data.
I used the SVCUTIL.exe file.xsd /dconly /importxmltypes to get an output.cs file.
Now what do I do?
How do I iterate through the rows to add to my table?
With so many rows, will I run into issues of having my service timeout or something?
Can I do the table insert/update in a batch after disconnecting from the wire?
Any sample or pseudo code would be appreciated.
How do I iterate through the rows to add to my table?
usually it generates classes using List for sequences in XSD, so you can iterate using foreach.
With so many rows, will I run into issues of having my service timeout
or something?
There are settings of binding like
<readerQuotas
maxDepth=""
maxStringContentLength=""
maxArrayLength=""
maxBytesPerRead=""
maxNameTableCharCount="" />
consider to increase its values.
Can I do the table insert/update in a batch after disconnecting from
the wire?
Think again, do you really need it? You should send response to sender that data is successfully processed. But you are going to send the response before data is written to the database. It could cause problems.
if the xml you got is not a soap envelope than you cannot build a wcf service that gets exactly it. you can build a service that gets that xml wrapped inside soap. that may or may not be what you want. to build a service that gets exaclty this xml use asp.net web api.
to build a wcf service given an xsd (and considering the limitation above) use wscf.blue.
I'm building a WCF SOAP service at the moment. I will, of course, need some authentication on the service.
Reading this very helpful blog post says that to use the built-in authentication points requires that the endpoint use the wsHttp binding.
This would be fine if I could guarantee that users would be communicating with the service through a client based on the meta-data exposed by WCF (basically, something like a client written in C# with a web service reference). However, I can't guarantee this!
I will still need to allow users to communicate with just raw (unencrypted) XML.
So, questions:
Does the wsHttp binding still allow for raw XML input?
If not, would I be wiser to
Implement two separate authetication points? One for raw XML input and one for encrypted input
Or
Allow input from wsHttp to fall back on some in-method validation that would be shared with the raw XML input?
Is it wise to allow users to pass their credentials inside a raw XML request?
EDIT: It sounds like I miscommunicated or misunderstood something in my original post, so here I will clarify what I mean by "raw XML".
By raw XML, I mean just the SOAP packet and the accompanying HTTP headers - as I might send from soapUI or Fiddler. As I understand it, messages over the wsHttp binding are encrypted when a client is generated from the WSDL (for example, in C#).
If this is not the case, then how would I go about attaching the same sorts of credentials to a raw XML (for want of a better term) request as I do a request run through a client? Are they attached as HTTP headers? XML elements in the SOAP envelope?
wsHttp is a SOAP binding, which means that your content gets wrapped in a SOAP envelope, possibly with headers relating to the message and various WS-* specifications being used.
I would ask why you need to support raw XML? Most platforms today support SOAP messaging and the whole idea of SOAP is to provide interoperability between different platforms. On most platforms it is as easy to develop a SOAP client as a raw XML client. In most cases, it is simply a case of taking the WSDL and generating a client. If you want to use standard facilities like authentication and message encryption then this is a much better way to go.
There are currently no hooks to do interoperable authentication for raw XML. You will have to come up with your own mechanism to do this and it will be non-standard. For your web service users, this means it will be probably entail more development effort than if you just went with SOAP.
Consider this scenario that two WCF clients connect to one WCF service(server), this service will receive an object from one client and send it to the other one through some operation contract and client callbacks, both clients have the type for this object but we do not want the WCF service(server) to be dependent on this type.
The project is much bigger than this, but I wonder if you can send an object with an unknown type to a service and somehow receive it back on the other client. I saw this but it does not help me at all: Can WCF service transmit type (client doesn't know this type) information?
Thanks in advance.
You can do certain things with the "raw" Message data type - but it's really not pretty programming...
Read about it here:
How to pass arbitrary data in a Message object using WCF
WCF : Untyped messages on WCF operations.
Sending an "object" with unknown type is not possible in WCF because WCF requires a full compatibility with WSDL - and WSDL requires transparent type definition.
Having said that, if you use a type of object I believe there is a way for this to be loaded as a string and in WSDL it is defined as xs:anyType.
I personally would prefer defining the type as string and passing an XML which can be serialised using plain XML Serialization. I have used this in our company and it works really well, especially since we will be storing the XML as document in database.
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