Hi All,
Does anyone know if it is possible to pass a .Net DataSet in a Web Service and be able to access/manipulate it within webMethods 6.1???

I am aware that the .Net DataSet object can be serialized into XML and thus parsed in webMethods, but can it be done natively, or in any other way which requires less fiddling?

Any help is good help
thanks,
Adam

Adam,

Can you expand further about how you would pass a .Net DataSet in a web service without serializing it into XML? Assuming you could send it in some kind of binary format like Base64, what would you use on the Integration Server to process the binary object?

You might have a look at the new webMethods Microsoft Package (WmDotNet) to see if that gets you closer to what you are trying to do. BTW, what are you trying to do?

Mark

Thanks for your response Mark,
At this point, I am just doing some investigation to see whether it was possible. Where I was heading with my question was whether the webMethods Microsoft Package natively supports .Net data structures (ie DataSets) or whether a form of conversion was inevitable…

Adam

OK. What language are you using to create your .Net assembly? What is the type definition for your data set? I have the Microsoft package installed if you want to send me some code to test.

Mark
mcarlson@conneva.com

Mark, the language would be c#. I cant send you any concrete code that i have used or a type definition at this point because it was a hypothetical question referred to me and I havent got any further details. I expect they were just looking to pass the data though to webMethods, which was already in a DataSet.

I have since landed my hands on a copy of the documentation for the Microsoft Package, and there is no mention of datasets anywhere. When I originally considered the question, I thought of something like this…

IData inputIData = IDataFactory.create();
IDataCursor inputCursor = inputIData.getCursor();
IDataUtil.put( inputCursor, “DataSet1”, myDataSet );
inputCursor.destroy();
IData outputIData = null;
try {
outputIData = serverContext.invoke(
serviceFolder,
serviceName,
inputIData );
}

The drama with the above code would be what to do with it in webMethods. The input would have to be some sort of object, but would you be able to extract/convert any (useful) information from that object which could be used? I suspect not…

Failing that, unless you could suggest a better approach, I think the best alternative would be to just render the DataSet into XML and process it like any other XML. (Useful link which discusses the debate about posting DataSets to webServices: [url=“http://msdn.microsoft.com/webservices/building/frameworkandstudio/tipstricks/default.aspx?pull=/library/en-us/dnservice/html/service02112003.asp”]http://msdn.microsoft.com/webservices/building/frameworkandstudio/tipstricks/default.aspx?pull=/library/en-us/dnservice/html/service02112003.asp[/url])

Adam,

Thanks for the link to the interesting article.

The readme.html for the webMethods Microsoft Package (WmDotNet) contains the following in the Known Issues section:

I think this means that you could not invoke services that returned structures classes including DataSets, but I haven’t tried this yet.

Mark

Mark,

looks like that answers my question. I guess serializing it into XML is the way to go.

Thanks for your help on this one

Adam

Guys,

The question I have for you is actually the other way around: How can I return a dataset from a webMethods web service?

We have a customer that wants to invoke a web service on webMethods and pass an integer as input. The web service is then supposed to return that integer and another auto-generated integer within an “XML Dataset that has 1 table and 1 row.”

I’m not familiar with .NET, let alone .NET Datasets, so I was wondering if you guys could tell me if this is possible, and if so, how to do it.

If at all possible, I’d like a solution that does NOT require purchasing or downloading other webMethods packages.

Thanks,
Percio

Percio,

You can generate a schema for the dataset in visual studio. It’s just another “view” of the dataset definition. Use this as the basis for the document you create on the webMethods side.

Not much extra work on your end, and your .Net developers access the dataset via row and column as if it was read from a database. The XML is “hidden” from them.

Cool, huh?

Mark

Mark,

Thank you for the quick response. However, I’m not quite sure if I understand. Let me repeat back to you what I think you are saying:

1. In Visual Studio, generate a schema (XSD file) for the .NET DataSet
2. Use the XSD file to create a Document on the Integration Server. So I could create a New Document Type and select the XSD as the source
3. In my service, create a document reference to that new document type in the Output pane
4. Map data into that document
5. Generate a WSDL from the service and provide it to the customer
6. When the customer consumes the web service, the webMethods Document Type (ie. IData) is actually going to look like a .NET DataSet on their side (???)

Let me know if this is correct. If so, that would be really cool. My only problem would be with Step 1 because our customer is not being very cooperative, but I think we could work something out.

Side Note: I’ve been looking around the web for information on .NET DataSets and web services, and I have found several articles and forums that simply say: using .NET DataSets within web services is a BAD IDEA because of the lack of inter-operability. Now, I just have to figure out a way to tell my customer that.

Thanks,
Percio

That’s the general idea.

Your service inputs and outputs use soapRequestData and soapResponseData objects.

For details, (don’t skip this!) see the web services and SOAP guides. If you haven’t done this before, be prepared for spending some time getting the hang of it.

Lack of inter-operability means, even though it is XML, the dataset is a MS-centric data structure. So if they want to convert their C#/VB app to Java, it’s going to be a pain. That’s probably a fair criticism if you care about that.

They may be pushing you for this approach because they already have code in place that interacts with the dataset.

If this is not the case, and they can work from your WSDL, interacting with your web service will be even easier if they skip the dataset step. Instead of doing a readXML into a dataset, they access the fields in your web reference directly.