I'm trying to Consume one SOAP webservice with SOAPUI and VB.NET to test.
But I can't understand one of the substructs SION_O_0010, it only show :
(...)
<SION_O_0009>aa</SION_O_0009>
<SION_O_0010 xsi:type="SI:SION_O_0010"/>
<SION_O_0011></SION_O_0011>
(...)
How Can I get the inner structure of SION_O_0010?
Regards,
Pedro
That element is empty. There is no inner structure.
Related
I am trying to create a REST web service which provides the exact same functionality as an existing SOAP based web service. Some soap requests can be quite complex and I am having trouble figuring out how these could be mapped to URIs. For example the following SOAP method body represents a search:
<HLRequest>
<HLSearch correlId=”1”>
<criteria numHLs="10" Level="AND" matchAll="true" exactHitCount="true" suppTemp="true" suppHLOnly="true" chainHLOnly="true" startDate="2011-01-01T00:00:00" endDate="2011-01-07T23:59:59">>
<symbols>
<symbol>CSCO</symbol>
<symbol>IBM</symbol>
<symbol>MSFT</symbol>
</symbols>
</criteria>
</HLSearch>
<HLSearch correlId=”2”>
<criteria numHLs="10">
<symbols>
<symbol>GOOG</symbol>
</symbols>
</criteria>
</HLSearch>
</HLRequest>
So I need to construct a method which handles URIs with an indefinite number of repeating query parameters and I'm not sure how/if this can be done within the REST paradigm.
Thanks in advance,
Ned
Your problem is that you're too hung up on a design pattern. There are things that REST is good for, and things that it's not good for, and you've just found one of the latter. You could come up with some scheme to map this data to a URI, but why would you want to? What problem would that solve? For this data, XML is probably the best way to represent it, so why not just post the XML?
Do you really need to map them all to URIs? A better approach for complex data is to make some json and post that. Apache CXF JAX-RS support can them automatically map that to bean classes.
I am trying to develop SOAP based webservice using CXF. My requirement is to accept any XML data structure as method parameter and then the logic to parse/handle this data would be internally taken care by webservice (A generic webservice for accepting request).
Hence I want to declare the method parameter as either org.w3c.dom.Element or org.w3c.dom.Document. I tried declaring method with these types but it gave an error.
Can anyone please let me know how, I can achieve this? I dont want to use REST approach.
Would a Provider based service work? Alternatively, make the method param a DOMSource or just Source. That may work better.
This is an interesting question I am sure a lot of people will benefit from knowing.
a typical web service will return a serialized complex data type for example:
<orgUnits>
<orgUnit>
<name>friendly name</orgUnit>
</orgUnit>
<orgUnit>
<name>friendly name</orgUnit>
</orgUnit>
</orgUnits>
The VS2008 unit testing seems to want to assert for an exact match of the return object, that is if the object (target and actual) are identical in terms of structure and content.
What I would like to do instead is assert only if the structure is fine, and no errors exist.
To perhaps simplify the matter, in the web service method, if any error occurs I throw a SOAPException.
1.Is there a way to test just based on the return status
2. Best case scenario would be to compare the doc trees for structural integrity of target and actual, and assert based on the structure being sound, and not the content.
Thanks in advance :)
I think that this is a duplicate of WSDL Testing
In that answer I suggested SoapUI as a good tool to use
An answer specific to your requirement would be to compare the serialized versions(to XML) of the object instead of the objects themselves.
Approach in your test case
Lets say you are expecting a return like expected.xml from your webservice .
Invoke service and get an actual Obj. Serialize that to an actual.xml.
Compare actual.xml and expected.xml by using a library like xmldiff(compares structural /value changes at XML level).
Based on the output of xmldiff determine whether the webservice passed the test.
in sharepoint webservices, I can use getListItems() to obtain the child elements of a list.
In a document library, sometimes the element is a folder.
"ows_FSObjType = 1"
Is there any way to ask SP for the child elements of this folder?
Querying with getListItems() using the folder ID gives me a SOAP Exception.
Edit:
I found that this webservice has got more method
Site Data Webservice
There is an "enumerate folder" method, which has got a "isFolder" property, but no method to recurse its contents.
Thank you, Sam. :)
On the GetListItems method, one of the optional parameters is an XMLNode called "QueryOptions". One of the elements you can put in that node is <Folder>.
So you should be able to pass in something like:
<QueryOptions>
<Folder>/My/Path/Here</Folder>
</QueryOptions>
I may be off a bit syntatically (didn't try to build and run a query when making this post), but the general idea should be sound. You can see more details on this in the MSDN GetListItems Reference.
When coding web services, how do you structure your return values? How do you handle error conditions (expected ones and unexpected ones)? If you are returning something simple like an int, do you just return it, or embed it in a more complex object? Do all of the web methods within one service return an instance of a single class, or do you create a custom return value class for each method?
I like the Request/Response object pattern, where you encapsulate your arguments into a single [Operation]Request class, which has simple public properties on it.
Something like AddCustomerRequest, which would return AddCustomerResponse.
The response can include information on the success/failure of the operation, any messages that might be used by the UI, possibly the ID of the customer that was added, for example.
Another good pattern is to make these all derive from a simple IMessage interface, where your general end-point is something like Process(params IMessage[] messages)... this way you can pass in multiple operations in the same web request.
+1 for Ben's answer.
In addition, I suggest considering that the generic response allow for multiple error/warning items, to allow the reply to be as comprehensive and actionable as possible. (Would you want to use a compiler that stopped after the first error message, or one that told you as much as possible?)
If you're using SOAP web services then SOAP faults are the standard way to return error details, where the fault messages can return whatever additional detail you like.
Soap faults are a standard practice where the calling application is a Soap client. There are cases, such as a COM client using XMLHTTP, where the Soap is parsed as XML and Soap faults cannot be easily handled. Can't vote yet but another +1 for #Ben Scheirman.