[Issues with RPC / Encoded] Web Services

I defined a WebService in IS 6.5 SP2 with a input field with type = string and a constraint content type = date.

In wsdl the field is type=“xsd:date”.

When I execute the WebService from a .NET application I got the following error:
<webM:message xml:lang="">[ISC.0049.9005] Input validation for service ‘Processo.PR002:GerirResultadoServico’ failed: ‘/RIN/DataServico VV-004 [ISC.0082.9030] Type mismatch, String expected’</webM:message>

Is this a bug in IS ? I installed all fixes but I got always the same error.

Thanks for any help

Joao Caseiro


You are experiencing firsthand the primary reason that the RPC / Encoded style of web services is not recommended by Microsoft and is disallowed by all versions of the WS-I Basic Profile.

The mapping of W3C XML Schema datatypes to programming-language specific types is frequently a source of problems. When you choose a constraint of xsd:date, the Microsoft wsdl.exe generates different code than when you use a constraint of xsd:datetime.

I created a simple service called “updateOrderDate” that accepts a string orderNumber and a date orderDate. When I constrain the orderDate to xsd:date and use wsdl.exe to generate C# code, the signature of the C# method is

public string updateOrderDate(string orderNumber, [System.Xml.Serialization.SoapElementAttribute(DataType="date")] System.DateTime orderDate) {

Because the W3C Schema xsd:date data type does not allow times, IS should and does return the "Value does not conform to datatype"
error message when you send a date and a time. If you want to specify an instant in time, constrain your IS string to the xsd:datetime data type.

My example works when a date of “2007-07-05” is sent, but fails with the same error you reported when “2007-07-05T20:00:00Z” is sent.

When I modify the updateOrderDate service to constrain the orderDate to xsd:datetime, the signature of the C# method is:

public string updateOrderDate(string orderNumber, System.DateTime orderDate) {

Now the example will work if your client code sends an instant in time along with your date (e.g. 2007-07-05T20:00:00Z).

The .NET 3.0 version of wsdl.exe reports the following error when you attempt to generate C# code from a WSDL that uses the RPC / Encoded style

Warning: This web reference does not conform to WS-I Basic Profile v1.1.
R2706: A wsdl:binding in a DESCRIPTION MUST use the value of "literal" for the
use attribute in all soapbind:body, soapbind:fault, soapbind:header and
soapbind:headerfault elements.
For more details on the WS-I Basic Profile v1.1, see the specification
at [URL="http://www.ws-i.org/Profiles/BasicProfile-1.1.html"]http://www.ws-i.org/Profiles/BasicProfile-1.1.html[/URL].

You didn’t specify which version of Visual Studio .Net you are using, the code generated by the latest wsdl.exe is different that that generated by an older version.

At any rate, in the short run, changing your constraint to xsd:datetime from xsd:date may resolve this issue. However, you should really avoid RPC / Encoded style web services altogether and invest some time into learning how to build an IS wrapper service or custom SOAP processor that supports the much more interoperable Document / Literal web services style.

There are numerous posts and several examples in this forum on that topic.



UPDATE: I attached a Integration Server 6.5 package containing the updateOrderDate Flow service as well as the WSDL generated by Developer for this service and a C# source file created by the .NET 3.0 SDK’s wsde.exe utility. Also added example good and bad request and response messages. BTW, the screenshot of the updateOrderDate wsdl diagram comes from the Eclipse WTP WSDL Editor that I wrote about yesterday.
WmUsers_SoapRPC_Example.zip (5.9 KB)
updateOrderDate.wsdl (3.36 KB)
updateOrderDate_example.cs.txt (4.77 KB)
updateOrderDate_request_good.xml (633 Bytes)
updateOrderDate_response_good.xml (679 Bytes)
updateOrderDate_request_bad.xml (623 Bytes)
updateOrderDate_response_bad.xml (3.61 KB)

I understand what you said and your examples where very usefull.

I tried defining the doc type in the Input of the service and it worked ok.

When I put the doc reference directly it doesn’t work.

I send you an example.
Test.zip (5.23 KB)

Good one